Is there anyone having an issue with the survey chains auto connecting between common feature codes? This seems to be happening when I edit a chain or a point in the chains linking code. Not exactly sure about this but it has to be one of the most frustrating experiences using SS4.
Does anyone have some insight as to the workflow when editing survey linework?
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
Hello Chris,
This issue is difficult to articulate. Let me describe the workflow:
1. import ascii file in NEZD format.
2. The project settings have been revised to accommodate the following linking codes:
3. These codes do work with the imports. I get linework that needs very little editing.
4. Now I begin the cleanup phase of the survey data. As I go through the file usually after a field walk of the areas I might need to change the line coding to reflect different curves. This means changing the linking codes from ArcPC or ArcPT to OC (arc single) or create a piece of new line work using the tool shown below:
5. This is where the train wreck occurs. When I edit the linking codes on one chain for whatever reason the survey chains with the same feature definition are being "revised" as well. This creates a situation where the survey line work isn't static or isolated to just the element being edited.
6. What OpenRoads seems to be doing is creating duplicate linework over top of the existing linework in the file. Most of the time this is very obvious because it is trying to connect similar chains together over and across large unrelated objects and areas. See the capture below:
BEFORE CHAIN EDITS IN OPENROADS
AFTER CHAIN EDITS IN OPENROADS:
7. Those chains came in from the import event correctly and now have been essentially destroyed by the workflow inside OpenRoads. I edited a completely unrelated survey chain using the tool (see capture above) and as a result I have the spaghetti line work in the capture above.
8. This is one instance in one project. I can assure everyone listening this is a common issue to 3 of my current FDOT survey projects underway now. It happens with all feature codes in all dgn files and in SS3 as well as SS4.
I have spent a lot of time exploring the workflows and documentation concerning OpneRoads and PowerGeopak. I can't see where I'm off the rails with what I'm doing here.
I have also tried importing the survey data with the built in Trimble link, .JOB , dc as well as LandXML, Ascii, Florida EFB and CAiCE PT4 formats. All have the same results.
Editing survey linework is a volatile process with an high occurrence of redundant unnecessary work effort.
Thanks for reading!
Cliff
Hello EL_C_
The issue can be rectified by simply changing the following settings (see capture below):
The setting converts the linear survey features to a static point list rather than a dynamic list based on the active linking codes.
This setting must be current when the ascii file is imported. Changing the setting post import will have no effect on existing data.
Clear as mud right?
It's always something simple that causes so much trouble.