I've been having a recurring problem when generating sheets and placing annotations using the Openroads workflow. I am using the Illinois Department of Transportation (IDOT) workspace. I create a sheet container file from scratch using the IDOTeng.dgn seed, and bring in some references before cutting sheets. For reasons I don't understand, certain civil tools create items and annotations that are off by a factor of 10 given the annotation scale. For instance, in the picture below, the centerline alignment annotation comes in at the proper sizing for the 1" = 20' scale, but the civil labels generated by the civil labeler come in exactly 10 times too big. However, the arrowheads on the leaders extending from those labels are the correct size.
Sometimes, the tick marks for the alignment annotation come in at the right size, and the text 10 times too big. With other drawings, the text comes in 10 times too small. When I change the annotation scale, the text will always be off by a factor of 10.
At times the named boundary tool also cuts the named boundary length by a factor of 10. For example, for 20 scale plans the length should be 600', but it comes in as 60'. Changing manually to 600' makes the cut sheets look screwy.
This is maddening and requires me to scale all sorts of annotative items by 10 at random.
Our civil workspace is entirely within one directory on projectwise, and the IDOT standard dgnlibs can be copied to local folders in the project directory so they can be edited (but I don't want to do that yet).
I appreciate any help.
Since the bulk of these issues are in ORD, you may want to look for the ORD discussion board and ask there.
You may also need to contact IDOT directly. They may be aware of an issue that they haven't publicized. It's also possible the problem in with their resources. I know of other DOTs who have had issues with the way ORD defines scales, requiring them to redefine just about everything. Although I haven't seen a lot of complaints about IDOT, there have been a few.
One thing you can check would be working unit definitions. Open the DGNLIB that contains the text styles and/or the element templates go to the design file Settings and find the working units. Use the "Advanced settings" and take note of the unit Resolution. Now check your design file or your seed file, and compare that resolution. If they are the same, the issue is somewhere else, but if they are different, that is probably the source of the conflict.
Power GeoPak 08.11.09.918Power InRoads 08.11.09.918OpenRoads Designer 2021 R2
Most likely due to CONNECT/ORD having a resolution of 10,000 per distance unit but the resources being used were developed in v8i where file resolution was 1,000 per distance unit. The difference between the 2 resolution values is 10.
We ran into this issue when updating to CONNECT/ORD. All line styles & text sizes, elements within a file/model, etc. (converting from v8i to CONNECT/ORD) had to be redefined to account for the resolution change. The resolutions I am referring to are specific to our files and the resolution in your files may be different.
Microstation CONNECT 10.17.00.209
ORD CONNECT 2021 R1 10.10.1.3
Microstation v8i SS 10 08.11.09.919
Power InRoads v8i 08.11.09.615
Thanks mwlong and MaryB. I think there are some issues in this regard. Both the seed and the feature_definitions_labels.dgnlib have resolutions of 1,000, but the see has a solids area of 10 miles and the dgnlib has a solids area of 1 mile. Our alignment geometry file, which was created by another user and I believe is upgraded from a Geopak SS10 file, has a resolution of 10,000 and a solids area of 10 miles.
So the seed and the dgnlib have the same resolution but the solids area is off by a factor of 10. I don't know what the solids area is, beyond an article saying it isn't super relevant to V8 dgns. Could this still be causing the issue?
The Solids Area for CONNECT/ORD is recommended to use the 10 miles. I know this value affects the drainage utilities. We ran into an issue where the 3d inlet box & top unit cells were not be placed properly. The top unit was floating above the box rather than sitting on top. This setting should not really affect anything else.
William Vierling said:Both the seed and the feature_definitions_labels.dgnlib have resolutions of 1,000
This will cause the issue that you are experiencing. The elements within the feature_definitions_labels.dgnlib file are 10x larger because the file resolution is "less dense"than the Geometry file. The Geometry file's resolution is 10x finer than the feature_definitions_labels.dgnlib.
Don't know if this article can help you. Annotation scale, ACS scale.