Survey Directions -> What Are the Long Term Goals

This is a response to Lou's questions from another post (http://communities.bentley.com/products/road___site_design/f/5922/t/85870.aspx) which I did not start, but did put in my $0.02. So rather than hijack the other users thread (which may have already happened) I wanted to take this to its own thread.

Currently, we use InRoads Survey (in all of its various platforms (PowerCivil for North America, InRoads Survey, InRoads Suite, PowerSurvey) to process all of our topographic surveys no matter what the final CAD platform. For InRoads or GEOPAK, we use both the graphics and the DTM's. We have used a few methods over the years to get the DTM into GEOPAK, but now, is is a simple save as GEOPAK TIN.

We also need to feed survey data to Land Desktop and Civil 3D. For this, simple CAD graphics is not sufficient. We can use LandXML for the DTM, but the end users want the deliverable in as much "native" format as possible. This means all points as "Point Objects" and linework as "Survey Features" or "Feature Lines" which are all "Objects" in the Autodesk world.

To create Points, we use the Survey XML Report tool to create "smart" point lists. These may or may not include the InRoads linking codes, depending upon the target - Land Desktop (no codes) or Civil 3D (codes) but both will also include a combination of alpha codes and attribute values. There are read by the Autodesk software as $1 $2 $3, etc. and the labeling tools of the point objects can perform some "custom code" like functions and create intelligent labels and even scale the symbols as needed.

Since we can no longer use InRoads in AutoCAD's 64 bit code, these capabilities are critical.

Additionally, over the years, we have found that certain codes cannot be edited after import, but require corrections made outside the product in the raw file and then must be re-imported. Sometimes, you do not find these problems until after you have made numerous edits within the product. To delete the setups and re-import the RAW file would cause you to loose all of that work. So we also developed a report that will write a new RAW file out that contains all of the edits, so that the users can then modify those other shots that must be fixed prior to import. Once those new edits are complete, the revised RAW file is imported as a new fieldbook and the processing can continue. This same workflow may be needed in Civil Survey - it is really too soon to know for sure.

On a related item, we have a primary client that has a alphacode of MISCPT for Misc. Random Point, MISCBL for Misc. Breakline and MISCDNC for Misc. Do Not Contour. These are to be used whan something is encountered that does not have an alpha code. During my testing of Civil Survey, I found a survey file where I was getting a bunch of MI codes. It took some time, but I eventually determined that Civil Survey was reading MISCPT as MI SC PT. The net result was that every MISCPT was getting stored twice, once with the original number and once with _1 appended to the number. The first one was was assigned a linking code of StartPC and the second point was given ArcPT. The linking codes should not split a single text string into multiple linking codes.

I am not sure but I believe it was also having issues with the MISCBL and MISCDNC.

Finally, I have assigned the CIVIL_XIN variables to load the XIN files automatically. However it is not working properly. I use variable with Project Defaults for InRoads so I simply pointed the two new variables to the same variables InRoads uses. In the Workspace Configuration, it shows them assigned. But if I bring in a survey without manually linking an XIN, it does not see my features.

I'll close with that and post other issues questions in other threads.

Parents
  • I would agree with all the arguments that Linking codes or (Control Codes) characters not being allowed be in a feature definition is a problem.  

    Data that was collected today using the linking codes that have been used for 10-15-20 … years not sure how long, will no longer load unless you modified the data.  Modifying survey data is not a good business to be in.  Any survey data collected over the past 10-15-20 year will also not load, due to this new restriction.

    This also affects other software used.  The linking codes on other survey software would also need to be modified.

    I would think Importing of survey data collected in the past would be an important function of the new Survey Software, without needing to modify the data.  Even the ability to open InRoads Survey FWD files should be supported, as is no modifications.

    Plus: I also find that even though our CIVIL_XIN variable is defined you must go into the project exploer > Civil Standards and manuall link the Active Feature Styles for every DGN and every new model created.

    Mike Longstreet
    Vermont Agency of Transportation
    Civil Engineering Technical Support
    VTCAD Help

  • In looking for some other information, I stumbled upon a post I made in the Beta forum on Linking Codes. What I see now is many of my linking code issues from that post was due to this "Linking code not permitted within feature code enhancement."

    IMHO, this "feature" is not desirable for many users. At the very least, we need something like the Variable Manager from InRoads where we can disable this "feature" and restore traditional InRoads parsing if alpha codes and control codes.

    Without that, you will be hard pressed to retire InRoads Survey in favor of OpenRoads Civil Survey.

    That and the ability to create the same InRoads Survey XML Report that is currently part of InRoads Survey.

    I understand that after certain edits, the original data is probably no longer relevant, but I would not be surprised to see certain clients dictate that we are not permitted to use some of these edit tools for that reason.

    As you move forward, I am often pleased to see that some posters are DOT members. Unfortunately, in todays climate, many DOT's do not see the benefits of having that level of involvement in new product developments. I do not believe that our DOT has anyone who has ever posted on these forums and would be surprised if any have participated in any Beta processes as well.

    I can attest to the fact that when I left the DOT over twenty years ago, that level of involvement left with me. After more than seven years away, I had a chance to return under a consultant contract and they were not doing anything differently then, than they had been when I left. It was as though I had been away only a few days, except many faces were different. They still lack full integration of survey features as surface features - while a survey feature is saved as a DTM feature, they do not assign any surface attributes to the feature. In the Style manager, if you turn on the filter checkbox for both survey and surface features, only a handful of features will remain in the list. This makes it very difficult to use existing DTM features with proposed features when trying to tie exiting and proposed designs together. This tells me that they are not using a huge portion of InRoads in production. And such omissions hampers their consultants when working for them, too.

    I will be willing to bet that when many of these organizations look into these new versions, there will be a lot of push-back.  


    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
  • We will certainly add a setting that forces linking codes to be space separated from a feature codes; thus removing the restriction that any portion of feature codes cannot contain a linking code.   We have always supported the ability to jam the linking codes up against feature codes probably because of legacy.  Remember the early days when some collectors were numberic only.  Even the ones that did have alpha keys were hard to get certain characters.  We always went for speed in the field and wanted to support as many workflows as possible.  This will just be another setting that gives the user the flexibility to work as desired.  

    In the meantime, the substitute strings setting will have to be used to change the linking codes from whole word ST to .ST, or anything else unique.  Then change all the linking codes to match that change. (.ST  .PC .PT, etc.)  NOTE: This is an office software change only and does NOT require field coding changes.  All past and legacy data will work with this method.  For example; the code STEPS ST would be changed to STEPS .ST during import by string substitution, signifying the start of STEPS linear feature.

    We aprreciate the feedback and suggestions.

    Answer Verified By: caddcop 

Reply
  • We will certainly add a setting that forces linking codes to be space separated from a feature codes; thus removing the restriction that any portion of feature codes cannot contain a linking code.   We have always supported the ability to jam the linking codes up against feature codes probably because of legacy.  Remember the early days when some collectors were numberic only.  Even the ones that did have alpha keys were hard to get certain characters.  We always went for speed in the field and wanted to support as many workflows as possible.  This will just be another setting that gives the user the flexibility to work as desired.  

    In the meantime, the substitute strings setting will have to be used to change the linking codes from whole word ST to .ST, or anything else unique.  Then change all the linking codes to match that change. (.ST  .PC .PT, etc.)  NOTE: This is an office software change only and does NOT require field coding changes.  All past and legacy data will work with this method.  For example; the code STEPS ST would be changed to STEPS .ST during import by string substitution, signifying the start of STEPS linear feature.

    We aprreciate the feedback and suggestions.

    Answer Verified By: caddcop 

Children
No Data