Open Roads Survey for InRoads Survey Users Guide

This is a desperately needed manual! The more I play with this, the more I am convinced that I will never switch to Open Roads!

Can you hear my frustration? I'm going on a rant. You can join me or ignore me. I just need to vent a little.

Now I am getting no linework and all of my points are assigned Default as their feature. I've tried bringing in our standard TDS RAW files, or our already save FWD files. What I get is crap!

When I was getting lines, I we having issues with JNC or DASH "-" coding, along with dual point coding. Dash coding is for an Electric Pole with a Guy Wire. You shoot the pole with EP and the Guy Wire with GUY-EP and you get a line connecting the two and the Guy Wire cell rotates to align with the line. Alternatively, you could use one of the following:

  • EP-GUY on the pole
  • EP JNC GUY on the pole or
  • GUY JNC EP on the guy wire

Since I am not getting my point codes nor my ST codes recognized, a dual code is light years away.

I have found no other coding method that worked as well as InRoads Survey, and was pleasantly surprised to see that Civil 3D can now be configured to recognize most of InRoads codes, including dual coding. I feel like Open Roads Survey is a step in the wrong direction.

When I link my XIN, why doesn't the software automatically also use my control codes? And why are the buried so deep into the software. And why is the help on many of these settings no help?

For Example, what is a "Description Separator"?

With InRoads, we use ALPHA CODES and CONTROL CODES. And every other bit of info is entered as Attributes, which are not inline with the other codes. All I need is for it to read alpha codes and control codes for each point and then read the attributes associated with the point.

I still cannot believe that we are expected to have no alpha codes that "contain" linking codes? Who thought that was a good idea.

  • You may want to review the document in this Wiki  post:

    communities.bentley.com/.../transitioning-to-bentley-civil-survey-document.aspx

    It provides insight behind some of the settings and what to look at when moving into Bentley Civil Survey.  

    Regards,

    Lou


    This is a test

  • Lou,

    I attended the Moving to Open Roads session at BE 2012. And have been going over it. I have also looked at the PDF from that page in your link.

    While both are good, they cannot tell you why an XIN, when linked does not appear to work as well as the book examples. (Also, is there a data set that can be downloaded for that PDF? I have the Transitioning Data set.)

    I have another thread going where I discuss linked XIN issues. What I found, is that there are two locations where there are listings of features in the XIN and from my own experience with multiple firms and multiple XIN files from multiple sources is that the software is not keeping these lists synchronized. And I believe these lists are one of the causes or symptoms of linked XIN files missing and/or ignoring features.

    We have always used a single XIN for survey and design not only because that is how most of our clients work, but when a designer uses a survey surface, the last thing you want is a new surface feature to exist in the survey XIN that has failed to make it into the design XIN. (I also fought hard for a single set of INI & FWF files in the pre-XIN days for the same reason.)

    However, I also do not think the Moving to Open Roads document spends enough time on survey issues. And the Best Practices document also cannot go deep enough into detail. The Survey portion of our XIN file is extensive and has many features and 99.9% use custom codes and Attribute information to generate 99% of any labeling needed. I was a key contributor to the development of this XIN as we pushed the local DOT to migrate from an ICS based topographic mapping process to an InRoads Survey based process. If you go to MD SHA's website and download their workspace, you can see some of what I am working with. The reason I say some, is that their XIN file has a major flaw - almost none of the survey features are defined as surface feature. So while you can push a Survey to a DTM, the resultant DTM is composed of features with Styles assigned to them that do not exist in an XIN file. So linking the XIN file to OpenRoads is problematic. I have spent hours correcting this, trying to get something that works for InRoads Survey and InRoads as well as linked for Open Roads. It was this task that has prompted some of my other threads.

    Please review these other threads and see if you can answer some of their questions. Also, let me know if you would like me to email my version of their XIN file to you. To see everything, you will need that workspace for all of its cells and linestyles and DGNLIB's, etc.


    Charles (Chuck) Rheault
    CADD Manager

    MDOT State Highway Administration

    • MicroStation user since IGDS, InRoads user since TDP.
    • AutoCAD, Land Desktop and Civil 3D, off and on since 1996
  • Unknown said:
    While both are good, they cannot tell you why an XIN, when linked does not appear to work as well as the book examples.

    Quoted for truth.