RE: Open Roads Survey - Power InRoads Ss3 Refresh - TDS RAW Angles Read as dd.dddd and not DD.MMSS

Here is an examples and some background - all of this is based upon MD SHA V8 CAD Standards. There is a TDS RAW file and a PDF in the zip file:

1. The PDF can be used to create a flip book for the crews to carry in the field in case they can't remember a code or an attribute menu item. The Green border pages list control codes - the codes have not been updated for a few of the newest InRoads Codes - EXTARC, SPC. The Yellow border are the Alpha Code pages. Note the Red ATTRIB column - this directs the crew to what attribute menu can be used. Note that many different Alpha Codes share ATTRIB menus. The Red border pages show the ATTRIB code menus. I believe these are "features" to the data collector.
2. This example used a lot of the ALL CODES feature instead of many of the special features for particular types. For example the PINV[A-Q] should use the PINV attribute feature. Failing to use the correct feature code in the attribute menu can result in a custom code label that is incorrect or missing information that should appear. However, this data-set has a nice variety of features in a small area and is a good test file for that reason. Over time, I have made corrections and adjustments to make it work for other testing.
3. The data collectors do not recognize the codes on a shot as features, requiring a separate selection process to assign attribute values. Also, while the data collector software supports linear, point and area features, the coding used must be recognized by the software to function. Since this does not happen using InRoads coding, only point feature coding is available.
4. The number of Alpha codes is large and since InRoads ignored the attribute feature name, it was decided to use a many to one approach for coding attributes. And, if I had my way, there number of alpha codes were be even higher while the number of attribute features would be lower.
5. The XIN file and CELL library all come from the aforementioned MD SHA V8 CAD Standards. However, it has a number of flaws.
   
   1. None of the cells are annotative - some should not be, but many should be for DA/Civil Survey.
   2. Most survey features are not defined as Surface Features. Once written to a DTM in legacy InRoads, they have a style assigned to them that matches the Survey Style, but that style has no 3D/Plan settings enabled, so you cannot get a feature to highlight or redisplay. This also has a negative effect on processing in DA/Civil Survey as many features do not display as they did in legacy InRoads.
   3. The default Survey Symbologies for temporary graphics are still set for using one of the versions of InRoads where the temporary graphics text sizes were not being set in Pixels.
6. No features in the XIN are set to use bylevel. The MD SHA standard was not created to allow its use.

The new TDS version that can only export RAW files writes attributes by switching the Attribute code value for the shot code value. However the rest of the attribute gets written in a totally foreign format. Here is a snippet of one shot with an attribute, as it would traditionally be coded:

SS,OP912,FP2263,AR201.360600,ZE86.000600,SD32.777034,--EPR
FC,PN2263,FNROAD
AT,TNTY,TVMAC
AT,TNN

The new TDS code writes it as follows when exported to TDS RAW:

SS,OP912,FP2263,AR201.360600,ZE86.000600,SD32.777034,--ROAD
--EPR
--    TY:MAC
--    NB:

And the large space following the second and third -- is a tab character. InRoads does not know how to read these and I suspect the GEOPAK code cannot either.

We used a macro in Notepad++ to reformat this to use the dotted note attribute, which looked like this when completed:

SS,OP912,FP2263,AR201.360600,ZE86.000600,SD32.777034,--EPR
--.TY MAC
--.NB

The bottom line, the software needs to not only continue to support the TIW code, it may need to add the capability to read the new native format of the New TDS software.