Importing survey files in ORD CONNECT - issues

Hey Mike, Are you working with the default Bentley workspace or a DOT workspace?  I'm not involved in survey workflow on a regular basis, however I try to understand as much as I can to offer support for our team during this new nationwide effort to roll out Connect Edition.   With that said, here are two DOT resources I have bookmarked that may prove helpful in understanding what's going wrong in your case.  Feel free to reach out to those groups on the communities via their group pages. Your question and feedback will help them as well!  I will try to link them below. OHDOT Survey process  https://www.youtube.com/watch?v=u1M_e08zxKo&list=PLdyShNRgZlb7_1DShGfj1sIojTMfDJIJa  and FDOT survey orientation https://www.youtube.com/watch?v=CawUHgF4LfM   Links to their Community pages: https://communities.bentley.com/communities/user_communities/ohio_dot__consultants/ and https://communities.bentley.com/communities/user_communities/fdot_cadd_support/

Hi Shawn,

Thanks for the response.   We are using the default Survey translators (as supplied with v10.8.0.88 of ORD), for all of our current internally developed workspaces/worksets, as well as the default Bentley Workspace/Workset.

I have reviewed several on-line videos on ORD CONNECT survey processing (including the ones you provided), however, most show how to import data to field book, but do not show you the Survey Settings or what the actual data file they are importing looks like.   Sevaral also use a PNEZD formatted .txt for importing data, but this format removes the Survey Observation data.  Considering the robustness of ORD CONNECT, PNEZD seems like a less ideal solution for data import.   We have had some luck bringing in .rw5 files,when you  just have {shot code} {Linking code} but there are issues when you have {shot code} {linking code} {field notes} and/or {shot code} {shot code} {linking code} {field notes}  type data.  I'd be fairly happy just finding a clean way to address this situation, as I could make due with any other smaller issues with the .rw5 format.   

Both .xml files as well as .fbk files contain the point code linking data when exported from the Data Collector, but that data does not get recognized by ORD when importing. (see original post for issues with these formats)

Has anyone developed a .TIW that works better than the "out of the box" translation for .xml, .fbk, and/or .rw5?  We are attempting to find one (or two) Data Collector output formats that can be properly processed/translated into either ORD or C3D with minimal effort.  Currently our Civil 3D folks have had better luck importing Survey data cleanly with these formats than we have with ORD.  I'd like to change that. 

I am open to any/all suggestions on how to best address this. 

Thanks

Mike

There are a multitude of settings that can effect how codes are interpreted. Our users are used to using a coding approach based upon InRoads Survey, which was Linking Code [space] shot code [space].

We started evaluating Open Roads Survey while it was still part of InRoads SELECTseries 4, so many settings needed refinements, some of which they addressed via configuration variables.

With ORD, all of these are now in the Survey Settings. These are what we used to get that to work. There are posts discussing many of these. Unfortunately, the Help documents do not cover many of these with any meaningful detail, if at all.

When it comes to attributes, we use the attribute capability of the data collectors. This does require extra setup and sometimes, extra effort before they are read properly. We use only point attributes even if the data is related to the figure the point is part of. We also use a type of generic point type which results in a code assigned to the attribute different than the point it is actually assigned to. This means we have to use this variable - CIVIL_SURVEY_IGNORE_TDS_FC_RECORD  so that the points do not get reassigned to the code associated with the FC record.

I believe you can still use the "DOT" code for attributes. It was part of InRoads TIW settings. After a shot was recorded, you could add a note and if you made the first character of the not a period/decimal point/dot, that was the signal to the TIW that this was an attribute record. After the dot, you could enter an attribute name followed by a space and then the attribute value. Originally, this method only worked with single word values, so we modified our TIW so that it used a comma between the attribute name and its value, so the value would contain spaces (but not commas). Eventually, they reworked the code so anything following the initial space was read as the attribute value.

They really need a more robust Help document and some in depth videos on Survey Standards

There are a multitude of settings that can effect how codes are interpreted. Our users are used to using a coding approach based upon InRoads Survey, which was Linking Code [space] shot code [space].

We started evaluating Open Roads Survey while it was still part of InRoads SELECTseries 4, so many settings needed refinements, some of which they addressed via configuration variables.

With ORD, all of these are now in the Survey Settings. These are what we used to get that to work. There are posts discussing many of these. Unfortunately, the Help documents do not cover many of these with any meaningful detail, if at all.

When it comes to attributes, we use the attribute capability of the data collectors. This does require extra setup and sometimes, extra effort before they are read properly. We use only point attributes even if the data is related to the figure the point is part of. We also use a type of generic point type which results in a code assigned to the attribute different than the point it is actually assigned to. This means we have to use this variable - CIVIL_SURVEY_IGNORE_TDS_FC_RECORD  so that the points do not get reassigned to the code associated with the FC record.

I believe you can still use the "DOT" code for attributes. It was part of InRoads TIW settings. After a shot was recorded, you could add a note and if you made the first character of the not a period/decimal point/dot, that was the signal to the TIW that this was an attribute record. After the dot, you could enter an attribute name followed by a space and then the attribute value. Originally, this method only worked with single word values, so we modified our TIW so that it used a comma between the attribute name and its value, so the value would contain spaces (but not commas). Eventually, they reworked the code so anything following the initial space was read as the attribute value.

They really need a more robust Help document and some in depth videos on Survey Standards