We have noticed if named boundaries are moved or adjusted the drawing model references shift.
Is this new version 10.09 considered a beta version? If so, we should all be nervous. I noticed in the first versions of ORD the drawing model references weren't even in the correct location when Bentley was trying to promote the software back in 2018. I brought it up at a conference, stating to them this software is not usable if coordinate data is unreliable. There was little concern , stating the label tools would produce the correct data. Since then the new versions created drawing models in the correct location, but if you adjust the named boundary in the default model or a container file the drawing model references using the named boundary still shift. Causing us to constantly check the drawing model references. I am very concerned a small adjustment in matchlines could cause a shift and we won't catch it. Large projects have hundreds of sheets , this can be an overwhelming number of files to manage and QC.
Is there any solution to this problem?
ok, so the reason I have a differing perspective may be that I view the Drawing models as intermediate models that we do not really use, except to add manual details like dimensions, notes, etc. We use the Sheet models for all outputs, DWG, PDF, etc. I could be wrong, but I believe this is the intent of how the tools were designed? I could be completely wrong on that, but explain why my experiences are a bit more positive. This is something we explain to all our users and has made the process a bit smoother.
The reason for this is that the Sheet model outputs are always consistently created with 0,0 at the origin and can be swapped in and out of titleblocks, etc. without adjustment every time. This is also why we have no issues with the Plan sheet side of things - adjusted Plan Named Boundaries keep the Drawing model origin in the same spot to avoid the need to regenerate the associated Sheet model.
Although I appreciate what you mean with the Drawings being out of "sync" with the real world co-ordinates, changing this workflow would actually make those of us with Sheet workflows have do additional work. We dont consider the Drawing model to be something we would ever deliver to anyone for "real" world information, the same way as a Sheet model.
I agree that adjustment of Profile Named Boundaries is a problem and i'm definitely not debating that there are not problems with some of the drawing production tools, because there definitely are, but i have a differing opinion when it comes to Plan drawings.
Regarding Annotation, that is a slightly different issue and I can't say I disagree with the issues, but that is a product of attempted automation gone to far that will probably get "fixed". This randomness is the product of doing anything that initiates a recalculation of annotation.
I find it amusing that Civil 3D is always the alternative that keeps getting brought up. As an organization that has tried it and wasted a lot of effort trying to get it to work efficiently, you may get smoother drawing production workflows (which i disagree with), your opinion may change when it takes you 45 minutes to open a simple highway DWG set with those drawings and then kick yourself after the last fatal error means you need to reopen it again.
Regards,
Mark
OpenRoads Designer 2022 R3 (10.12) | Microstation 2023.1 | ProjectWise CE 3.4
Mark,
If you create annotation in the sheet model. How do you used labels? They don't seem to work in sheet models. We can't even track station and offset in sheet models.
I agree with you that annotating in the sheet model would be easier if not for the difficulty in placing coordinate and station offset data. Also it would be a hard sell for me to convince people to not annotate in real world coordinates like v8.
Right now we are working on a project with many sheets and all the annotation is in the drawing models. Adjustments are being made to matchlines and sheet limits because of design changes and all of the drawing models are shifting around causing problems.
Zane Pratt
Civil Designer
This whole drawing model thing has been around a long time. I played with them in the 2004 edition. I believe the original drawing model intent was a tool to create 2d views from and 3d model. A saved view could be created and referenced in a new 2d drawing model. This allowed designers to annotated a 3d view in a 2d space. Then, this annotated 2d drawing model could be referenced into a sheet. For civil projects, this doesn't work so well. We have 2d plan models we are referencing into a 2d sheet. We don't need a drawing model for plan views. Cross sections and profiles make since (if they worked). I could live with the plan view drawing model as well if it worked.
This whole OpenRoads plan production system is broken. It is sad, because we are paying price. Bentley has no clue the struggles we are going through with this software. I honestly don't think they care, because they would have fixed these issues years ago.
I will be totally honest, plan production with OpenRoads Designer can take 2 to 3 times as long as v8. Constantly redoing profile annotation. Plan and profile annotation automatically updating for no reason. Drawing models moving. Confusion about live nesting. The list goes on.
They should call ORD 10.09 the Guinea Pig Edition. That is what I feel like. Good luck to everyone.
I strongly agree with Zane's statement that "plan production with OpenRoads Designer can take 2 to 3 times as long as v8", which is why my preferred workflow still involves creating plan sheets in model space and printing using Print Organizer.
Is your coordinate issue not resolved by going into the drawing model, opening the reference file attachment dialog, and for the attached design model resetting the X and Y offsets to zero? I have found that I can insert vertices in the named boundaries and this has no effect on the drawing model station and offset annotations. But, if I change one of the four corners of the original named boundary, then the station and annotation offsets do change. However, if I then reset the X and Y offsets to zero, then the station and offsets return to their correct values. So, as others have noted in other threads on this topic, it would seem that the workflow is to reset your X and Y offsets after revising named boundaries. This doesn't seem too onerous since the named boundaries are likely being edited one at at time anyway.
If 100s of boundaries have to be moved for some reason, then this would be tedious. It would be nice if there was a batch process for resetting the offsets, or to check that this has been done, as a quality control check.
Karl Dauber, PEAdvance ConsultingLaurens County, SCkarldauber@advconsult.netwww.advconsult.netwww.linkedin.com/in/karldauber