Trimble Business Center

All,

We have been seeing a problem in the PRO exports from "Road Surface" when re-importing them into TBC. Please view the photo below. In green is the corridor surface and in red is the PRO when re-imported into TBC. I've also attached the Alignment as a xml, the corridor surface as a xml, and the PRO that we are having problem's with.

What we are seeing a horz shift to the line strings, as well as vertical profile bumps present as well. 

Any help would be appreciated. We had thought this problem was with RXL's only, however we are now seeing similar issues with the PRO's. Any advice or further testing would be appreciated. If any other files are needed or a better breakdown of our steps would help please let me know. 

Cameron

Apologies that I did not get to this this week and I am out for a few days now - I will be back Wreds nexr week and will make this a priority then 

Sorry for the delay

Alan

Cameron

The PRO importer is not something I am proud of - it was written to facilitate the Import of basic PRO Data only (Polylines, Sets, Surfaces and Alignments), and for that purpose it is OK, however for Corridors I do not recommend using the Importer at all as you will see this type of issue because the Importer basically slices up the Corridor into "Cross Sections" and imports them as Templates and then interprets the surface model between the templates - and this is why you are seeing the surface model differences between the two - the Exported File is fine and if you opened that in Terramodel (A better test) you will see that it is fine, it is just the Imported Version into TBC that is incorrect because of the way that the Corridor Model is imported.

This importer was written by a group in Trimble that was not 100% familiar with PRO Files and the Terramodel Toolpack Engine, and it does a poor job on importing the Corridor Model specifically. It treats the Corridor like A DC File (Road Templates file that is used by Trimble Access (in RXL format) and that because it is section based will be correct where the sections are created but in between will be interpreted. The challenge with sections is when the Section changes and one section has more nodes in it than the prior or subsequent section - then the software puts links between the sections to form a "TIN Model" and those can be "Just Wrong" - it just is not a good way to represent a corridor model unfortunately. The PRO File has the full Surface definition and all of the "Breaklines" of the model and SCS900 / Siteeworks has the full Terramodel Engine (Toolpack) incorporated so that it can compute the Corridor correctly and anywhere along the job - directly from the model - it is by far the best solution for Corridor Models out there.

You should find no issues at all in SCS900 / Siteworks

Alan

Alan,

I really appreciate the response, and your message is very detailed. It does a great job of explaining the situation. This slicing of the corridor into "Sections" makes a lot of sense. 

When we ran into issues with the RXL's we have been back testing all files exports in TBC as a way to ensure that our files going out to the field were correct (if we did not have a controller handy at the time). I will see about getting Site-works and a emulator installed to parse the exported data through them for QA. I have no doubt that you are correct in saying that they work correctly in those tool sets. 

Thanks again for taking the time to post this answer. It helped clear things up. 

If you do not mind, I have one last question, in regards to this strain of logic. Our company has mostly TSC3's with Trimble Access loaded up. Our practice has been to use RXL's up until we were seeing issues. We have a few that we have been pushing PRO's out to now that have SCS900 loaded on a small percentage of them. My question is this:

"If you were modeling complex heavy highway corridor in TBC and had surveyors that were using Trimble Access on TSC3's what export would you use to get them road staking files (road corridors with the ablitily to select station/offset/list the point node names and prorate the slope if need be)." 

If the answer is RXL's what would you do to help ensure nothing was lost from the corridor in TBC to the TSC3? 

I'd be happy to make a new post of the above question if that would be better. 

Cameron

Cameron

The Geospatial Team would recommend one of two workflows for Road Staking

in Access - those being

1) RXL Format Files

2) GENIO / Trimble Access Strings

The second option is for markets where the Bentley MX Software is heavily

used (UK, Australia, Middle East etc.) or a similar product to MX (12D)

from Australia. While any linestrings / alignment can be exported to a

Trimble Access Strings / GENIO file, the naming convention of MX is a 4

character name for all strings like K001 = Kerb, V001 = Verge, PLP (Point

String of Light Poles), PTR (Point String of Trees) etc. If you have fuller

names they currently get converted to a random name / string number (not

truncated to 4 characters), although there is a fix to the Formatter that

allows the string names to now be truncated to 4 characters (but that can

have the effect of making meaningful string names less meaningful etc.

The RXL Format is under review, the Geospatial team are looking at ways to

make that better for the future, however currently if you take a "Good

Corridor Model in TBC" and select output to RXL (which is a similar format

to the old DC Roads File) then TBC basically slices up the model into Cross

Sectons, and then uses a user defined tolerance value to check all of the

cross sections created  to see where one cross section differs

"significantly" from the prior / subsequent sections to determine which

ones it can "throw out" and which ones it has to keep (for the integrity of

the Road Model). The Road Model will be much larger after output than the

source model data as a result, and you can have hundreds if not thousands

of Templates in the RXL file.

In the output of RXL process, there are some options as to how you want to

handle the sideslope elements - I believe you can use the last segment Left

and Right of the HAL as the sideslope or you can define a single default

sideslope value e.g. 3:1 for Cut or Fill conditions that will get added to

the corridor RXL output. These sideslope elements can be extended /

shortened in the field so that you can find the Daylight Points on the

existing terrain etc. I believe that you can also change the slope value on

those elements in Access, if you find e..g that Daylight is outside of the

ROW line and you need to change to a different slope for specific locations

along the alignment.

It has been a long time since I used Survey Controller / Access in a

production mode, so I may be slightly off on my comments above, I have been

involved with SCS900 since 2003 (when we started the product) and I have

really not tracked Access / Survey Controller in detail since that time. We

elected Terramodel PRO Files as our Roading Format because it is a much

stronger Road Model than DC / RXL files for complex road work. We use the

Terramodel Toolpack Engine as the Road Computation engine in SCS900 /

Siteworks so that we get full compatiblity on that data type in the field.

If you need me to map through the Export of RXL Files for Access I can try

to do that next week for you - however Access is a little out of my

specific wheelhouse, but I am sure that I can get with someone from

Geospatial to assist as needed

When exporting the RXL File, you should use a tight interval of e.g. 1' or

2' and put in the tolerance that you are prepared to accept as an error

e.g. .01' so that it generates a lot of sections and then weeds out where

it doesn't need the extra sections because "nothing is changing". Bear in

mind that where you have elements widening or super elevating and where you

have Vertical Curves / horizontal curves you will need more data (like

densificaton of a corridor surface model in TBC) but in long straight

sections where the slopes and widths of elements are constant you need less

data. If you however start off with 10' or 20' intervals, you immediately

introduce unacceptable errors into the model output (unless you only intend

to stake and check at those specific locations - in which case you would be

OK). The only ? I have is on the Sideslope elements and whether or not the

source model in TBC should have those or not - if you have constant Cut or

Fill Slopes along the road, then you may be better off not having

Sideslopes in the TBC model and just add them to the RXL outputs. If you

have complex sideslopes / multi element sideslopes or sideslopes where the

slope is varying along the highway, then you will need the sideslopes in

the model output to RXL format.

I am happy to try to assist you get the correct workflows - you can import

an RXL file back into TBC to see what you get back - you can build a

surface from it and then build a CF Map to see what errors are introduced -

however I am not sure how Access computes between sections - whether it

creates a surface TIN and slices that, or whether it linearly interpolates

between nodes between sections - that would be a question for the

Geospatial folks to answer.

Hope this helps

Alan

On Thu, Mar 14, 2019 at 11:21 AM ctomkins@kapurinc.com <trimble@jiveon.com>

Alan,

I’ve gone back and forth with vendors, clients, and surveyors for years it seems trying to figure out solutions and understand why the RXL’s function the way they do.

This is by far the best answer and most comprehensive explanation that I have gotten. I want to thank you for taking the time to investigate this and explain it in this level of detail, no one else ever has (that I can find).

No video would be needed for the workflow on my behalf, I’ve worked through the various parameters of RXL exports and options more times then I’d like to admit, and the current system of checks and settings we use has proved “enough” for what we need done. However if you did create one, I guarantee you i'd watch it. 

Your Paragraph on side slopes was also very informative, I’ve had little success before in finding out more about that command option.

I do agree with the process you described with the tighter interval, and you are very correct in terms of what it does with file size, if a TSC3 could handle a 25+MB RXL…. well I’d have no problem. Alas it can’t (at least not well). So, we have stuck with creating the most simplified corridors we can and exporting RXL’s that are no larger then 5MB if we can help it. Those corridors usually only stick to roadway and grading work is left to be staked with TTM or CSV Points files and or 3D DXF lines.

We have been testing out the CRD. File formats for road staking as well. Do you have any input on what your experience has been with those? Seems to give a PRO type staking option to the Access software, at least that’s my take away.

Your last paragraph is exactly what we do to QA our exports, re-import, and run a CF report, in a perfect world they would identical. They are not, but we find where the differences are and try to clean them up when and if possible.

I look forward to what the geo-spatial team is able to create/edit for the future of RXL’s. However, we are slowly making our way to using SCS900 and PRO’s which seems to be the best solution for us.

I want to thank you again; this post was more information then I was able to gather in quite some time. I’ll be sharing this with my group and I’m sure that it will help determine what we need to do for future projects.

Thanks,

Cameron Tomkins

PS. You mention above that you have been involved in SCS900 Development since 2003. That sounds like it could be an interesting story and I’d love to hear more about it. If you are aware of any links, articles, seminars, or summaries of how that work was done or what was involved. I’d love to hear/watch/listen to any of it. Development of the software's and UI of these applications is super interesting to me. 

That is a discussion for "Over a Beer or Three" I guess

Glad I could assist

Alan

On Fri, Mar 15, 2019 at 7:15 AM ctomkins@kapurinc.com <trimble@jiveon.com>

I'm in the Chicago land area, not sure where your base is. If our paths ever cross at a convention/seminar/PUG event or if you are ever in my area I'd be more then happy to have one of those discussions. 

Much Appreciation,

Cameron