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 out 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.