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.
We are striving to make civil survey the premier package that allows you to import, process and edit your survey data and prepare it to be sent as your deliverable. We are always looking for ways to improve our product. You mention that certain edits can only be performed by exporting back out to the native raw file and re-importing. I would be interested to learn about these required edits so that we can look at the possibility of adding them to the our edit tools.
Regarding the alpha codes such as MISCDNC, MISCPT, etc: No part of a FEATURE DEFINITION Name may contain a linking code. For example, if you have a FEATURE DEFINITION “STEPS” then that will conflict with standard linking code “ST” If this is the case for your data, then you can change your linking codes to be unique like .ST .PT .SC etc. Then you could use String Substitutions in Survey Project settings to replace “ ST” with “ .ST”, “ PT” with “ .PT”, etc.
This restriction on having no part of a linking code in an alpha code is really problematic. And in my case, there were some codes that worked even though they contained the same codes. In the past, linking codes and alpha codes always required a space between other codes, but did allow adjacent numeric codes for figure sequencing or point number identification. It seems to me that these type of differentiations were reasonable and pretty standard across the industry. I am pretty sure I am not alone in my objection to such a change. The client that drives our codes is our local DOT. I'm willing to bet that many of the DOT's will take issue with this type of change. And who knows how many firms and crews are well versed in this code, in this area. Multiply that by the number of DOT's using Alpha Codes with InRoads Survey and you have a lot of unhappy survey managers, clients, crews, etc. And ours is not a large DOT. I can't imagine NYSDOT or PennDOT finding this very palatable.
We have the following ALPHA Codes: BRST, MASTARM, PAST, POST, STAR, STANK, STEP, STONE, STUMP, LOCUST. The standard begin curve in InRoads is PC - we have TPC, THe Control Code PT conflicts with MISCPT, PTREE. The code CL (close figure) conflicts with CLPR, CLUPR. The code for non-tangent curve NT conflicts with GVENT and PLNTR
As for corrections that cannot be made without a re-import, the InRoads XS codes cannot be fixed easily after import. If an SP is accidentally included in a TDS RAW file. (This can occur if a crew member attempts to edit a code after it has been completed.) The TDS software adds the new description as an SP. Once imported, that point number is treated as a control point. The only way to release it back to being a computed point is to edit the RAW file and re-import. There may be others, but those are two that I have encountered on more than a few occasions. We also have a client that expects us to submit a RAW file that matches the FWD file. This is the easiest way to make sure they match. Otherwise you are performing edits in Survey while also editing the RAW file.
The ability to write a custom XML report to create a PNEZD file is exactly the format we need for Civil 3D is also essential. But it also offers a methodology to convert between raw file formats. One could create a report to write a FBK file and more. Here is a snippet of one of my PNEZD.csv files:
1088,515614.8797,1269858.9514,417.4197,TREE 24 MAPLE
1089,515661.6347,1269842.7549,417.9421,TREE 10 DOGWOOD
1116,515613.8796,1269882.5925,413.2375,PINV 6 OTHER
1173,515493.7349,1269937.1936,414.8362,SIGN NO U TURN
1218,515619.5080,1269720.6889,418.0770,SGPV CONC
1345,515475.5942,1269855.5905,415.6041,BLDG BRICK 1 STORY
1416,515417.0875,1269914.0108,412.9590,EP PEPCO 757454-4863
1454,515436.9785,1269891.2901,415.1211,SGGR GRASS
2280,515179.9283,1269490.9083,430.7253,EVG 3 CEDAR
2776,515464.2586,1269949.5538,407.4942,PINVJ 42 RCP
2777,515465.8442,1269949.0797,409.2904,PINVF 27 RCP
This is done by combining Attribute values with Alpha Codes in the XML Report. It can aslo specifically add text based upon the code - for example PINVJ is our code for a 42 in pipe invert the only required attribute is type: RCP, CMP, etc. The report adds the 42 for PINVJ and 27 for PINVF, unless they have entered an elliptical size and then it passes that along instead of the "known" size.
Do not throw the baby out with the bath water, please!
One more thing: Is there a really good example of the linking codes, with diagrams that show the use? Some are pretty self explanatory, but others seem redundant. For example, we would code ST PC to start a figure on a curve. Why would we need a StartPC code? and PC NT and PT NT work just fine as Non-Tangent starting or stopping a curve. Why would we need two other codes?
Charles (Chuck) Rheault CADD Manager
MDOT State Highway Administration
One other thing I forgot to mention. I have not had to do this yet, but if I do I know I can.
We use one coding method for all surveys. As we add clients, if they have an XIN we modify their alpha codes to match the ones we currently use. At some point, I may need to split codes in our standard so we can collect for the two different clients. If that happens, I could use an exported XML Report to recombine the split codes.
For example, we shot BC and TC for Bottom and Top of Cub and use attributes to identify concrete or asphalt, since the client does not used different symbology by type. If a new client does draw concrete curbs on a different level, we might need to create two alternate codes and for the one client, they both point to one feature but on the other they point to two. However, if the client with one feature requires only one alpha code, after the fact we can export a new RAW file where the alpha codes are combined into a single code.
Or, I can use the attribute values to direct an output report to substitute one of two alternative codes. Then, upon re-import, one code with two attributes becomes two codes.
Next to OpenRoads technology, XML reports are one of the greatest tools of InRoads and need to remain in the product. And as you move forward, should be made part of more of the tools, rather than less.
We also have many alpha codes with ST (and others) in the name based on our DOT. We use InRoads SS2 fine, but it sounds like the future InRoads may need some investigation.
Hi guys.
I'm not going to take a shot at Caddcop's questions... way too many and beyond my knowledge anyway. That probably needs a response from Bentley.
I can let you know that the linking codes (ST as mentioned in Brian's post) are user definable. If you find that one of your field codes conflicts with a default "survey" (previously Data Aquisition) linking codes, you can simply change the default linking codes to something else. I've attached an image of dialog for the linking codes. These can be either alpha or numeric.
And you have the option to exclude codes that you don't use... so you can limit this list to only the ones you actually use.
HTHs
The InRoads control codes go all the way back to Fieldworks. Alpha codes have never been restricted from containing control codes - only that they cannot duplicate them. You can use numeric characters only as "figure" identifyers to allow the collection of multiple figures concurrently. Some control codes require numeric arguments representing distances or point numbers. In the case of the InRoads control code JPT, I only recently determined that the space between the JPT and the point number was optional.
Any changes to these "rules" will have a large impact and is not good news.
On a related front, as I mentioned, we also deliver DWG files for Civil 3D and InRoads Survey is a key component of this. We decided long ago that having a single set of alpha and control codes for our crews was essential. The survey crews should not need to know the deliverable CADD platform or client before performing a survey. The deliverable for Civil 3D cannot contain only "dumb" graphics" but must contain Civil 3D objects as these will respond to Annotation/Drawing scale better than native AutoCAD objects. And since Civil 3D 2010, it has been possible to use many of InRoads control codes to bring points and linework directly into Civil 3D. And Civil 3D's "rules" for alpha codes and control/linking codes are more aligned with the Fieldworks/InRoads Survey approach. And as in Bentley's Civil products, they are 100% user configurable. As it stands, we can use ST (Begin), CL (Close), JPT (Connect Point), PC (Begin Curve), PT (End Curve), DIST (Right Turn). For a few other codes, it is necessary to choose between options. Civil 3D's Rectangle code is both RECT and CLSRECT depending upon the number of points already in the figure or if a number is supplied. So 2 points, Rectangle and a number is InRoads RECT command, while 3 point, Rectangle is InRoads CLSRECT command. The Point On Curve command is closest to the new SPC command in InRoads and the Circle command is closest to the EXTARC command. Both of these have more than one input method but, the ones I listed are the best fit.
Before you think of me as a complete Luddite, let me point out that the expanded codes of Civil Survey would allow us to match more commands in Civil 3D that InRoads supports. I am only arguing about the restriction against an alpha code containing control/linking codes. Requiring a separation character between codes is not unreasonable and having an option separation between codes and numeric values is not a problem. I have never seen any type of coding that allows one to combine multiple commands into a single character string with no separation character. To me, that's just crazy!
We support additional functionality, but not at the cost of losing productivity. It is easy to train users to new codes. It is much harder to have them "unlearn" codes that previously were allowed.
P.S. I just reviewed the Civil Survey Help File and found these statements:
Control codes must be separated from the Field or Linking code with a space. (Under Control Codes topic)
However, under the section on Data File Parsing, I found this:
Warning: InRoads users, feature codes should not contain linking code character strings. Use Substitute Strings to fix.
Of course, this is right below where you can specify a Description Separate and and Attribute Separator.
Some of these seem to be self contradicting.
At the very least, we certainly could use some extensive examples of how and why we even need much of this.
Looking through our codes, we have many alpha codes that contain the so called linking codes (and have never given us a problem before). And having a few hundred Alpha codes doesn't leave many linking code combinations unused (and now we have many more options for linking codes too).
substitution strings->poor workaround. It isn't user friendly.
Maybe Bentley can think a bit more about this change.