InRoads version 615
Triangles in a DTM were edited (flipping and deleting), the surface saved and a LandXML file generated from the surface. The DTM was then opened in Trimble Busines Center. The problem is the original triangles, NOT the edited triangles are displayed in Trimble. Is InRoads retirangulating as it exports to LandXML or do the triangles simply need to be locked before generating a LandXML file?
Please take a look at the wiki article below for a workaround to your issue:
communities.bentley.com/.../8327.aspx
The artical addresses triangles deleted from around the perimeter of the surface. I don't see how it will resolve the issue with triangles that are 'flipped' in the interior of the surface.
Yes, you are absolutely right about that. Unfortunately, I am not aware of any setting or toggle that can be changed to preserve the edits to the triangles. Since InRoads is feature-based, the triangles are going to be recalculated based on the features. Since the features haven't been edited, you go right back to your original triangles. One workaround would be to import the triangle legs as breaklines and then export the surface. This would retain those flipped triangles.
What we have learned:
1) InRoads retriangulates prior to exporting to LandXML
2) Trimble Business Center appears to retriangulate LandXML files that have features in them.
3) LandXML files containing only triangles will preserve some but not all of the triangle face edits as seen in Trimble Business Center.
4) Importing the triangles as features into a surface or saving the DGN file as a DXF file will preserve the triangle edits as seen in Trimble Business Center.
5) Using the Place Feature command in place of the triangle editing tools to control the faces of triangles is an alternative that works.
The conclusion I come to is that we need to redefine our requirements on how to produce LandXML files for surfaces that will be placed into our construction bid packages.
Answer Verified By: Paul-PennDOT
One final note. We have continued looking at this and it appears that the triangle editing tools in InRoads are only working on graphics. This means #1 above is probably incorrect and #3 is questionable.
We're having the same issue with PowerGEOPAK. We have a workaround to create an external boundary, using a "drape boundary" (see thread: communities.bentley.com/.../92188.aspx). This works fine for the boundary of the project, but as noted above, leaves all internal edits at risk of reverting. What I think we'll have to tell our users is to NOT edit triangles internally. Instead, they'll need to edit the source data to provide the desired result. In many cases, this is actually the proper way to address a problem with triangles anyway. However, this is a problem that Bentley needs to address directly. All of these "workarounds" don't solve the problem. A way for PowerGEOPAK or InROADS to keep track of triangle edits is needed.
Frank Boston, Michigan DOT Survey Support
We, too, are having this problem, even when exporting to GEOPAK TIN. It is very frustrating to perform all sorts of edits to a terrain, only to find out that when exported, the edits are not there. The terrain is exported since other downstream processes can't quite yet use terrains and must use GEOPAK TINs or InRoads DTMs.
Feel free to read through the following thread. communities.bentley.com/.../282639.aspx.
For PowerGEOPAK, here's what I've put together as a workflow recommendation for our users, based partially on work in this and related forums. I don't know if something similar would make sense for InROADS, as I don't use it.
RECOMMENDATIONS
Note that saving a clip boundary using the method outlined here will ONLY preserve your triangle edits along the boundary of the project. No internal edits will be preserved. Our suggestion is to NEVER edit the internal triangle structure; rather, you should edit the source data to fix any issues, so that the triangles reflect your intent.
Don't forget that one of the best advances in SS3 terrain modeling is that ALL functions can be undone. If you do something and your triangle edits revert, stop, take a breath, and UNDO. Now take time to think about what you need to do, and prevent the problem if possible.
Frank,
Thanks for the suggested workflow. While it sounds tedious, it will certainly save a lot of headaches preserving deleted edge triangles.
Much of the internal terrain editing I do involves flipping a lot of triangles so that the resulting contours look better (smoother ground, probably more representative of reality). I haven't found a way to edit the source data to reproduce this in a terrain. Have you experienced this?
Unknown said: RECOMMENDATIONS Note that saving a clip boundary using the method outlined here will ONLY preserve your triangle edits along the boundary of the project. No internal edits will be preserved. Our suggestion is to NEVER edit the internal triangle structure; rather, you should edit the source data to fix any issues, so that the triangles reflect your intent. Don't forget that one of the best advances in SS3 terrain modeling is that ALL functions can be undone. If you do something and your triangle edits revert, stop, take a breath, and UNDO. Now take time to think about what you need to do, and prevent the problem if possible.
We are just now being forced to use Inroads for certain DOT work and from what I'm reading here this scares the hell out of me. How could you possibly ever create a surface through source data that was 100% correct when you create your surface? I have worked on thousands of surfaces and never once have I ever created the surface with 100% accuracy the first time through. Sure, some are really easy and probably would be okay without my edits but we're talking about miles of highway topo with thousands and thousands of points. The editing can take quite some time, and now we find out under these conditions they are preserved! I'm amazed.
Mauritzj - Yes, that workflow is VERY tedious. That's why I say Bentley needs to address this. Paul Brandl at PennDOT suggested importing the triangles into the DGN so that they would be fixed in place (see above). This is probably a simpler solution, although it basically makes the terrain less "live", if you know what I mean. Maybe that's a good thing. I think the workflow I've adopted still keeps the terrain model "live", for future work.
As far as flipping triangles, I guess we don't worry about that as much here. In the "old days" I worked for an aerial survey firm, where the "look" of the output was of utmost importance. That dated back to drafting days, and the fact that we were still trying to meet those visual standards. Here at MDOT, the attitude is more like, "so what if it's ugly, as long as it's accurate". Obviously this is an oversimplification, but you get the idea. While I might want to find and fix spikes and holes that shouldn't be there, I don't worry about the look of individual contours. As a photogrammetrist, my viewpoint has always been that if there's a problem with the triangles, then there's a problem with the underlying data. (Not counting edge triangles.) To answer your original question, no, it probably isn't practical to try editing your source data to get triangles to flip. Paul Brandl's method would preserve your triangle editing work in this regard.