Hey community,
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.
Thanks,
Will
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.2.61
ORD - 2021 R1 10.10.1.3
ORD 2022 R1.1 - 10.11.3.2
ORD 2022 R3 - 10.12.2.4
Microstation v8i SS 10 - 08.11.09.919
Power InRoads v8i - 08.11.09.615
ProjectWise - 10.0.3.453
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?
Regards,
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.
communities.bentley.com/.../144343