OpenRoads SS4 survey chains...what is happening?

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?

Parents
  • Before you make any edit to the survey informatio, it has the correct linework and graphics drawn between points, but then it clears when you make an edit? What process are you using to make the edits to the points and what are you trying to change? Are you trying to change the coding to control how the point is coded or make some other type of edit to the survey details?


    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

  • Cliff,

    Are you removing the "E"nd of the chain first?

    Ex.
    Begin Line with B
    End line with E

    B6041
    6041
    6041
    6041
    6041
    E6041

    So, if you remove the "E", then the linear feature will pick up a different survey chain with the codes "6041"

    Are your linear feature codes unique?

    Ex. 1st code B6041, 6041, 6041, 6041, E6041
    2nd B6042, 6042, 6042, 6042, E6042
     
    Power GEOPAK 08.11.09.872 
     
    Lucas Conkright
    Hampton Lenzini and Renwick Inc.
    P 217-546-3400
    "Full service engineering at a higher standard"
  • 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.

  • Cliff,

    Did you get this resolved?
     
    Power GEOPAK 08.11.09.872 
     
    Lucas Conkright
    Hampton Lenzini and Renwick Inc.
    P 217-546-3400
    "Full service engineering at a higher standard"
Reply Children