TECHNICAL TIP ~ InRoads DTM Conflicts, Part 2
What constitutes a problem in the surface?
Before that question is answered it should be mentioned that the subject matter covered here is primarily discussing the "mechanics" of surface problems:
- What they are from a software perspective
- How to find them
- How you might deal with them
- How InRoads itself deals with them "behind the scenes" programmatically
But let's look at this from another angle before we move on.
(Digression Regarding Surface Sources)
There are existing surfaces and proposed design surfaces. And while InRoads doesn't really differentiate the use of its tools to that degree, there are differences when it comes to the nature of surface problems and my philosophical approach to addressing them. (Anyone who has attended one of my classes has heard me discuss this in a fairly emphatic sort of way.)
From an existing surface perspective, the 3D data forming the surface model would typically come from field collection, and in many cases, very little if any additional surface data would be entered 'manually'. This means that the data developing the surface model is almost exclusively generated by the surveyors out in the field. The systematic collection of each strategically located shot, properly coded, is what will result in the eventual 3D data that the surface triangles are formed from. The surveyors are collecting information that they can physically see in order to build a representation of an actual portion of the earth's surface. This means, in terms of the 'source' of any surface conflicts, the responsible parties are those in the field collecting the data. Yes, the software plays a role in interpreting the data, but let's at least assume (maybe a wild assumption, I know) that the software has been properly configured to post-process the surveyors precisely collected shots correctly.
From a design perspective, the engineer / designer / technician is using InRoads to input the proposed elements that will form the eventual finished model. They are creating an electronic simulation in the computer of something that will accurately represent something that will be constructed in the future. The InRoads operator uses the available tools to add any design elements, such as flowlines, crownlines, edges of pavement, sidewalks, toes and tops of slopes and so on, into the design surface. This data, entered by the InRoads operator, is what will result in the eventual 3D that that the surface triangles are formed from. This means, in terms of the 'source' of any surface conflicts, the responsible parties are those entering or designing the data on the project.
So, the stage has been set. And therefore, if a surface contains elevational conflicts or 'errors', we should be perfectly clear that those errors have a 'source'. And the 'source' is in the best position to address them. And (assuming valid software configuration) the 'source' is either the surveyor collecting the data, or the designer building the design surface.
Now let me say this loud and clear ... surface conflicts happen all the time. The name of the game is to 1) know that they exist, 2) be able to locate them, and 3) be able to fix them.
I took this deviation from the heavier technical content to point you in a particular direction. And that direction is the 'source' of the surface issues. Knowing this should help you to better identify and to eventually not be surprised by these problems. And in some ways this is one of the keys to understanding how any surface conflicts are ultimately corrected. This should also orient you to the fact that the field collection process, as well as the design process using the InRoads tools, has to be done properly and with a greater emphasis on the resulting models that these activities produce. With this orientation the magnitude of problems that are encountered in your surface should decrease over time.
It's attention to detail.
(End Digression)
Coming very soon - ZI Issue 83: The answer to: Exactly what is a Surface problem?