Joel_graff wrote: ↑
Wed Mar 06, 2019 10:34 am
LandXML has a huge schema that covers a wide variety of engineering data. At the moment, I'm only focused on the alignment and profile portions of it. I do have a generic LandXML parser module built that can be used for support, but I don't plan on writing any surface-specific XML parsing stuff any time soon
I have been looking for where to share my own experience with LandXML. I thought of General Discussion, or Arch tutorials, but here at least someone else is working on LandXML. I should admit that I am not a programmer, nor did I set out to do anything but extract a point cloud that I needed to create a terrain surface.
I received three files from the Surveyor. A .pdf 2D scale drawing, a .dwg, and an .xml. The Surveyor works with (AutoCAD) Civil3D.
• The .pdf contained the property line, some existing conditions details, and the location of every shot, with the elevation given as an annotation. This produced such a clutter of details, that it was almost impossible to read. This is the site drawing that went into the Geotech’s report.
• The .dwg was poorly suited to the project requirements. The origin was about 7 km to the southwest. Everything but the contours was in 2D with annotations for the elevations. The contour lines were at the proper elevations, but they were discontinuous and they had loops and other artifacts that made them poorly suited for reconstruction into a terrain surface using Yorik’s macro. (ruled surfaces between bspline contours). It is clear that the only purpose of the .dwg was to prepare the Paperspace drawing.
• I had no problems importing the .dwg into FreeCAD, and this became the basis of a new terrain model. I reset the origin to the south west corner of the property line. There were some unsuitable objects which couldn’t be fixed, so I traced sketches over them and deleted the originals. There were over 200 survey points, all in 2D. I could have fixed them manually, one at a time, but I found a better solution.
• The .xml file turned out to be LandXML. An excellent format, but I couldn’t find an importer or converter. I did find a viewer, so I could see that the file contained the 3D details that were missing from the .dwg.
◦ I knew that .xml is a text format, so I opened the file in a text editor. I was able to locate a list of 3D points that represented the survey shots.
◦ With that, I was able to apply a procedure that Bernd had detailed in the Transportation Workbench discussion. (Import Point Cloud from Spreadsheet) https://forum.freecadweb.org/viewtopic. ... 3&start=90
▪ I copied the list of 3D points and pasted them into a spreadsheet.
▪ I striped away everything but the x, y, and z coordinates.
▪ I saved these as a CSV except with spaces as delimiters.
▪ I renamed points.csv to points.asc.
◦ I tried importing the file into FreeCAD as a point cloud. This worked, except that the scale was out by what looked like a factor of 1000, the origin is miles away, and it also seemed that x and y were reversed.
Snipet from the LandXML file:
<Definition surfType="TIN" area2DSurf="1471.43928663317" area3DSurf="1567.216914780276" elevMax="7.29" elevMin="0.">
<P id="5">4974.21 5019.626 6.654</P>
<P id="6">4992.97 5013.261 3.87</P>
<P id="7">4968.976 5016.162 5.61</P>
<P id="8">4981.011 5020.944 6.116</P>
<P id="9">4989.285 5012.569 3.888</P>
<P id="10">4984.203 5006.759 3.552</P>
<P id="11">4981.127 5006.904 3.547</P>
<P id="12">4974.885 5008.104 3.714</P>
<P id="13">4971.833 5007.762 3.788</P>
<P id="14">4972.735 4998.547 3.395</P>
<P id="15">4972.084 5016.472 4.909</P>
<P id="16">4976.351 5017.156 5.206</P>
<P id="17">4978.782 5018.304 5.787</P>
<P id="18">4970.502 5010.494 4.409</P>
• In the spreadsheet:
◦ Swap the order of the X and Y columns.
◦ To bring the points closer to the origin of the drawing, reduce the X and Y values of each point by 4900 m.
◦ Fix the scale by multiplying every value by 1000 to convert meters to mm.
Excerpt from points.asc; the file I imported into FreeCAD as a point cloud:
119626 74210 6654
113261 92970 3870
116162 68976 5610
120944 81011 6116
112569 89285 3888
106759 84203 3552
106904 81127 3547
108104 74885 3714
107762 71833 3788
98547 72735 3395
116472 72084 4909
117156 76351 5206
This strategy worked; the scale and orientation are now correct. The placement was still off by a bit, but I was able to do a precise move of the point cloud to correct this.
Now that I had a set of 3D points overlaying the 2D details imported from the .dwg, I was able to use my previously tested procedures to build 3D terrain surfaces.
I didn’t use the contour lines from the .dwg. Instead, I traced sketches over them, in order to simplify the lines and to make them better suited to the upcoming triangulation procedure.
My Site procedures:
• Contours from image. Import image, scale, sketch over contour lines.
• Contours from DXF. Import DXF, sketch over contour lines.
• Terrain from contours. Triangulate surface between contour sketch vertices.
• Terrain macro. Ruled surfaces between bspline contours.
• Import point cloud. Prep point data for import.
I didn’t use any one procedure to build the final terrain surface. Rather, I used some contour lines, some survey points, and some survey transits (3D polylines). The result was better, and simpler, than what I could have achieved with any automated method.
This procedure is well suited to the scale I was working at (contour interval = 1 m), but might soon become cumbersome at a larger scale.
I found when I examined the .xml, that it was organized into 4 sections:
• The header contained project information.
• The next section contained 2D data that was organized to match the surveyors workflow. Points were grouped and labelled to represent different objects being measured. This section serves as a reference to the following sections where the same data is represented without such organization.
I ignored this section because I already this 2D data in my model from the .dwg import.
• The third section contained all the 3D points as a table. This is what I copied into my spreadsheet, and the only part of the .xml that I used for this procedure.
• The last section was another table, representing a triangulated surface or TIN. I would have liked to import this surface, but this was beyond my skills and experience.
Importing just the 3D points was sufficient for the project I was working on. I was able to triangulate a surface manually from the imported point cloud, and to reproduce as much of the survey information as was relevant.
Site investigation is substantially complete, and I am working on the fourth concept model for the new house.
Survey.dwg and PointCloud.asc imported into FreeCAD
Terrain surface from point cloud.