Coming into Ss3 from InRoads, we have had a fixed set of linking (control) codes for a long time and when new codes were added, the help file was enhanced to include examples with images.
The Survey tools of Ss3 really need to address this in depth. For us InRoads users, we have used ST to start a figure. If we used ST PC, it starts a figure with a curve. If there is more than one shot between this and the PT (or if no PT is coded) this becomes a best fit curve passing through all points. If there is no intermediate point before the PT, as long as there is one more point after the PT, it creates an arc tangent to the trailing tangent segment.
In the middle of a figure, we can start a curve with a PC and all of the same rules apply. And in that figure if one end of a curve needs to be non tangent, we can add an NT following the PC or PT.
All codes were separated from other codes with a space. Alpha Codes could have numeric sequence numbers and those were provided with no space after the alpha code. Additional information came from attributes. Any changes to this will be problematic.
We also can use a JPT with a point number to draw a line to a point, based upon its number. But there is also a JNC which is join to nearest code. This can also be abbreviated using a dash (-) and its mode common use it to connect a GUY shot to a utility pole. With our biggest client, that would be a shot codes as EP JNC GUY or EP-GUY. And the GUY shot does not need to come before the EP shot. InRoads just finds the nearest GUY shot and draws a line. In practice, it is more common to code the GUY shot as GUY-EP or GUY JNC EP as this can also rotate the GUY cell to the line.
When I look at the new linking codes, I cannot see a one to one match up. That's going to be an issue. And with no detailed, illustrated examples, I'm not sure of the best match up to make. And with no JNC code, that will also be an issue.
When a survey involves a bridge, we try to keep the bridge shots in their own raw files. These get saved into a separate fieldbook. In The new software, these all end up in a single terrain element. Ideally, when a new fieldbook is created and used, a new terrain element should get created. Or, at least we should be given the option to use the current terrain element or to specify a new terrain element and once more than one is opened, if a new field book is created, the option to select an existing terrain element or new terrain element for that fieldbook as well.
Finally, we are a Civil 3D shop as well. We have been using InRoads to process all survey for Land Desktop and Civil 3D for as long as we have been using InRoads Survey. In Civil 3D 2010, they introduced codes that are much closer to InRoads codes than to these new Bentley Civil Survey codes. The reason we adopted InRoads Survey was two fold - first and foremost, it allowed the crews to worry about one set of codes and one collection method, leaving the final CAD format to the office personnel. Secondly, we could actually process in AutoCAD - I knew this was a Red Herring, but some of the long time AutoCAD guys didn't trust the files converted from DGN to DWG and this quelled their fears.
With a 64 bit OS and 64 bit AutoCAD, we can no longer run InRoads in AutoCAD. We have developed a workflow that works in this new world and are even looking at using InRoads to create a basic ASCII coordinate file which when brought into Civil 3D handles the linework, point symbols and DTM. But for this to work, I generally need the simpler coding option of InRoads Survey. Even then, there are come codes which do not align one to one. And unfortunately, the new codes do not necessarily address this either. And the additional codes and their options would make a matching up even more problematic.
One more thing - this ASCII file is created with a custom Survey XML report. Nothing I've seen in the new Ss3 survey tools would give me this type of output. And the LandXML file these tools do create is not a LandXML Survey file but a COGO file. And there is no sign of the linking codes
So, we need:
- A detailed explanation of the use of all of these new codes, with illustrated figures.
- A method to continue using the current InRoads Codes for the foreseeable future.
- An equivalent to the JNC code or some kind of work-around.
- An option to allow the use of certain new codes while maintaining the ability to continue using current InRoads codes.
- More comprehensive XML Reports.
- The ability to reload a data file to update its portion of a survey.
- The ability to load multiple field books and have a choice of terrain element for each.
Now that I know that our major client is also looking at Ss3, I feel the need to be vocal and pro-active on this. I suspect as more DOT's get into this, the InRoads shops will have similar comments (except for those involving Civil 3D - but even that is no longer a given, as a few are now allowing a deliverable in Civil 3D.)