We have codes and cells for crews to pick up pavement marking symbols and words (turn arrows, LEFT, ONLY, etc.) and other single point shots, like Signal Heads on Poles and Mast Arms.
We were never able to come up with a methodology to rotate the cells automatically while using InRoads Survey. Since Survey Data, once processed was basically static, we had our office processors simply rotate them as needed once a survey was nearly ready for delivery.
With Open Roads, the Survey Data is far less static. Is there some method that this could be accomplished that would persist any refreshing of the survey data?
You could use the smartobjects.mvba Annotate.RotateCell to rotate the cells. You could also turn off the update for the Survey features after you have established the cell rotations.
For more information about the Road and Site design tools, visit the Road and Site design WIKI at: http://communities.bentley.com/products/road___site_design/w/road_and_site_design__wiki
Answer Verified By: caddcop
I just found that procedure. BTW, what is the proper way to "turn of the update for survey features" ?
Charles (Chuck) Rheault CADD Manager
MDOT State Highway Administration Maryland DOT - State Highway Administration User Communities Page
Go to Project Explorer > Survey and right click on the Default model and select Deactivate Survey Processing Rules.
This brings to mind two issues:
1. deactivating survey rules would "freeze" the terrain model.
2. If new data is added to the survey field book the rules have to be activated. This would be some what equivalent to applying a "redraw". This can cause major issues with the graphic presentation of the survey data.
I prefer to export a graphic only dgn file and push the DTM out to a LandXML or GeoPak TIN file. This keeps the survey container file dynamic, which seems to be the nature of ORSS4 survey.
Cliff
This is kind of similar to how we worked it in Civil 3D at my last company. I learned that the hard way.
The story goes like this:
We had a small survey done for a business entrance design. The survey had enough points but needed some extra breaklines. I found it easier to manually add them using some type of Civil 3D tool but since they were not "in" the survey, they were not automatically in the terrain object created from the survey. So I added them a live breaklines to the terrain object and then froze their layer. Later, someone needed to do some type of editing in the survey file. For some reason, they felt it necessary to thaw the layer and then decided these newly displayed elements were "in the way" and erased them. Suddenly, my terrain element was back to needing more definition to accurately reflect the ground. Later, the designer came to me complaining that his model and profiles had changed. From that point on, we always "promoted" the survey terrain element to its own file. This way, even if someone screwed with the survey file, even though its terrain object would be screwed, the "promoted" terrain object was a snapshot of the earlier version. If you knew there was more survey, you knew it was necessary to repeat the "promotion" process.