Our state DOT uses an architectural scale for their CAD environment, so bear with me. When we are using the named boundaries and sheet models in ORD, the sheet model measures at 2.83x1.83 for an ANSI D which is just 22" and 34" divided by 12 (or 12"=1") and thus the 2.83x1.83.
That being said when we plot a half size of 11x17 (ANSI B) we get a reported pen table "_Scale_" text substitution of 0.166'/in (see screenshot below). Which would be the width of the sheet model of 2.833 divided by 17".
So my question is there a way to change via the configuration variables that will show the actual scale of 1"=20' when using the pen table text substitution of "_Scale_". When ORD references in the the drawing model into the sheet model it is referenced in at a 1:240 scale (20 scale multiplied by 12). It seems like this takes away for the legacy work flow of scaling in a sheet border cell to your drawing. Any input on this would be greatly appreciated, or if anyone knows if there is a way to report the drawing reference scale when plotting in ORD.
We are using ORD 10.10.01.03
Thank you!
Dynamic text may be hard to display in this way since Bentley never intended for physical prints to be shown at a different plot scale. You can try to add a set of "levels" containing the optional "plot scales" text (e.g. 1"=20') on separate levels in the border file - all turned off by default or one level left on for the same fav that generates the main scale). Run the MVBA on the following page to batch the level routine (video explaining its use) Video: OpenRoads Level Display Batch Processor
Some notes to consider: Sheets were intended to be Paper Space, based on their given size (e.g. ANSI B). So they are 1:1 (no scale). It's really the size of the clipped area in relation to the Drawing model scale that does the magic.
(e.g. 11”x17” ANSI-B Sheet Model print area measures 0.91666 feet (11 inches) x 1.4166 feet (17 inches))
Sheets can be setup to utilize the "Detail Scale" dropdown. It is typically recommended to set up the sheet production DGNLIBs to contain seeds that specify the Sheet size (ANSI B, ANSI D, etc.) and that Detail Scale option works the scale. Every workspace I've ran across with strange quirks in sheet production were those attempting to scale with a preset seed. When Chuck Lawson and Bob Rolle demonstrated these on Bentley's YT and Learn server (https://www.youtube.com/watch?v=kqqNnVP9Ec4&list=PLnJUnxLwu_N4lBHgQyCX_hqpiV-hC1Tfv) They recommend the practice of setting these up based on real world sheet sizes (not scale). I know at first this wasn't all that clear, but after seeing issues with things the other way... let's just say stuff happens... and you adapt... conform...
Bentley Accredited Road Designer | Bentley Accredited Road Modeler
colliersengineering.com
This has been an interesting discussion for me and I have quite a bit of experience implementing both forms (i.e.,50:1, 1"=50'). Originally- and several years ago- I set up our sheets proportionally (50:1). This method would be the most familiar for our users, and the notion that reference would be scaled here by 600 for this particular scale- I thought- would have caused a riot in our office! As well, I could use our cell libraries, text styles, and dimension styles as they were in V8i.
As it turns out, my change to the Bentley preferred units was necessitated by OpenBridge designer simply because structural folk use the feet and inches convention (architectural). I knew this from the beginning of the process- of course- but figured that I could set up something for them and something for us which would be compatible; yet, being honest with myself and with the process, I really did know all along that I was on the wrong path. So, I went about dividing all of my legacy data by 12, and set my sheets to 2'x3' (1:1). All works well across all disciplines now, letting the drawing model control the "magic" as has been mentioned here before.
As regards the primary question of the discussion, every sheet in our WorkSpace has a border and every border has a set scale (scale bar, etc.). This scale bar is ON THE SHEET which is referenced by the sheet dgnlib through the named boundary dialog. The "Plot Scale" which is shown on Tom's image truly IS the plot scale. The scale listed on the sheet truly IS the drawing scale. Such as it is- and how the DOT built the sheet- I see nothing wrong here. In order to avoid confusion, I would remove the field "Plot Scale" altogether as it truly is of no value that I can perceive.
One question for you Shawn: what I see in you dropdown are sheet sizes and types only. How do you know what scale your drawing is? Are these fixed to a particular scale with the horizontal and vertical "known" by the users, or are you setting all parameters after the named boundary is selected?
I have attached a few images here. The first one is setting the named boundary which additionally sets the scale, the length, and the left and right offsets of the named boundary when the sheet is produced. The Convention here is the type of sheet (in the case P&P), the horizontal scale, the vertical scale, and the named boundary needed appended "PLAN" or "PROFILE" (shown in the first and second images). The third image is of our typical sheet within the dgnlib; one can see the scale bar physically attached to the sheet. The string "Plan Annotation.Sheet Alignment Name" reads the name of the alignment and populates it there. Much of the rest of the sheet is populated via WorkSet properties. We have created Plan and Profile sheets for proportional (20H, 2V, 30H, 3V) as well as 5 and 10 times vertical scaling. With such a group of sheets, we can be assured that any and every scenario can be covered. Of course, we have Plan only sheets, Plan/ Plan sheets, Profile sheets, Profile/ Profile sheets, etc. The sheet dgnlib is set "full size" (2' x 3") and we use two levels to control the plotting for either 11x17 or 24x36. Which one is chosen is determined via a plot style. We have had ABSOLUTELY no issues using these methods, and our users can easily ascertain exactly the scale and vertical exaggeration (profiles) of the sheet they intend.
Best Regards,
Mark
Mark Plum said: One question for you Shawn: what I see in you dropdown are sheet sizes and types only. How do you know what scale your drawing is? Are these fixed to a particular scale with the horizontal and vertical "known" by the users, or are you setting all parameters after the named boundary is selected?
I think there's a misunderstanding regarding the necessity of a specific "scale" to these seeds. More on that explained below. If you follow Chuck and Bob's instructions, those seeds can be any scale, but when ran by the named boundary tool the named boundary adjusts its size automatically - in essence, adapting to the Detail Scale dropdown (you can also download FDOT's workspace and investigate this behavior).
For the purpose of this post, I'm ignoring the compound vertical (plan with profile sheet) discussion and likely a great discussion we can startup on the forums.
In regards to plan view, if setup correctly, users should not need to modify the length/offset and overlap values of the dialog (obviously additions to the seeds can be added based on client needs). This entire discussion gets more into localized standards that a set of users would need to be trained on (correct me if I'm wrong there... e.g. in what cases to use other modes of the tool - as seeds can be established per client/company standard for each). In FDOT's case (pictured in my previous comment) the dropdown represents the Sheet "size" yes, but is part of a dgnlib seed that scales (along with the drawing model) with the set size provided by the Detail Scale selection highlighted below. Even though the seed for 11x17 is setup in a 50 scale default/drawing dgn file, the Named Boundary tool creates saved views (named boundaries) based on the "Detail Scale" selected. In no way am I saying that listing by FDOT is all-encompassing. My point in the comment is that there is no need to specify a scale with the "Drawing Seed" dgnlib (yes it can be done and I'm still a little curious regarding the pros/cons to that methodology - e.g. specific scale bars added per scaled seed).
In the case below, the Drawing Seed and Detail Scale is set to load values and settings (users are only instructed to change Names, station limits and boundary chords as needed.
DGNLIB (notice it's 50 scale)
Subsequent 20 Scale PlanPlan Sheet
Shawn:
Thank you for the clarification, and indeed how what you have stated here is an interesting manner of producing sheets. I know- many years ago- that I was investigating something of this sort, but with mixed results, and such is the reason why I decided to go down the path which I did. I have a copy of the FDOT workspace and will investigate further, of course.
Thanks Again, & Best Regards,
I'm curious where you landed on this Mark Plum ... There's a similar concern mentioned recently on the forums. The more I go through the logic of other alternative methods, it still seems to cause users issues. I'd like to revisit this and come up with a best practice, however our main clients have their own production workflows and standards established to suit their expectations.
I am glad that you brought this subject back to my attention!
As it is, we have kept things where they are (quite simply, I did not get a chance to reinvestigate the additional knowledge here). Our system is a bit cumbersome, but works flawlessly as it auto assigns all parameters. Since 10.12, we have noticed solid increases in load speed as well, and ORD 2023 looks to be even more promising in such regard. But indeed, I really do need to carve out some time to take a thorough look at the information provided in this conversation!
P.S. I am forwarding this conversation into the "mentioned recently" conversation you have addressed.