I have tried offsetting a line, copying, exporting as a DWG/DXF and re-importing, exporting to C3D (forgive me!) as an XML and saving as a DWG... Some of these methods sort of work but the results are poor. If I check the linestring using the object explorer the elevations at the same point on the alignment and linestring do not match.
The other very noticeable thing is that the curves from the original alignment when exported as a DXF or DWG and then re-imported do not match by approximately 2cm (in my test case). The DXF/DWG is chording the curves. Is there a place to adjust this value?
Any help gratefully appreciated.
I also need to do this from time to time. Offsetting it by 0 doesn't give a very good representation of the vertical alignment. The best I have been able to do is create a corridor with a basic instruction of any kind starting at the centerline, then densify the corridor surface, explode it, and keep only the centerline. Still not a perfect vertical alignment with vertical curves, but very close.
My workflow is the same as Wayne's when I need the CL.
It is always helpful to describe the problem you are trying to solve rather that asking for a specific solution.
These two objects can be very different in their properties and how they can be used. Hopefully we create new objects only where there is a real need or purpose. We also have to consider how an object will be exported to our field devices and transfered to other CAD products. An alignment can have a station equation and spiral curves and circular vertical curves while a linestring cannot. Each has limits and intended uses.
You cannot offset a vertical curve along a horizontal curve and hold both the grade in or out and the cross slope of a cross section. As the length of the line changes with the offset in a HAL curve, something has to give. That is why the offset command creates straight lines along the parabolic curve. You can tighten up the number of points created with the project settings>computations>Surface>breakline approximation parameters. Change the horizontal and vertical tolerance to be 0.001 to get more points. You can use the geometryreport command to check the specific values.
Ideally you would leave things parametrically defined. You can use the alignment to create a surface and tune the surface to vary the density when needed. Your template can define the offset nodes and they will vary with the density settings.
Once you offset the alignment you now have dumb CAD data. It may have a purpose, but now you have to manage when it is applicable and if you change your design, you have to remember to create a new offset. If you really just want a copy, then use the copy command.
One small trick that might help. Offset the HAL. Edit the hal. Create a new VAL and use the append to alignment option to use the offset line as the basis for the VAL. Create a new profile view. If the new val is not at the right station, use the Move command to move it from its current beginning to the desired station and offset. The new VAL should be the same elevation as the old VAL, at each of the VAL points created. A HAL can have multiple VALs.
With a little more definition of what you want to do with the offset linestring, we might find you need something different than what I described above. Hopefully this helps.
Tim: thanks for the detailed answer. I'll tighten up the tolerances as you suggest. The problem is simply creating a linestring from an alignment. That's why I posed the question as I did.
The reason is that SCS900 will not allow creating a design with an alignment and a surface. You can pick one or the other, or create two designs. So, in the field, you have to switch back and forth to stake a line/stake a surface. Access (which I rarely use now) takes linestrings and makes it "stake an alignment" when all I need to do is stake a line.
Thanks again for the details. Much appreciated.
It seems this problem is more related to SCS900/Siteworks than TBC, to me. Also, one can create a design with an alignment and associated surface in TBC that is usable in SCS900/Siteworks using the Field Data (now Construction Data in v5.0) workflow. Perhaps I'm not understanding what you're trying to accomplish, though. Either way, I'm sure there's a solution to what you're seeking. What are the specifics of the design you're trying to employ in the field? Is this a roadway project or something else?
Charlie: I agree there is a limitation in SCS900 in this regard. The former Field Data (now Construction Tab) in TBC would only allow creation of a design that had either an alignment or a surface, not both. That has been addressed in Siteworks.
The problem is that for many Siteworks only runs on Windows 10 devices (EG TSC7) and the vast majority of us still use TSC3's in the field. The only way to stake a line and at the same time be able to stake a surface requires making alignments into linestrings. SCS900 will not stake an alignment if the design (Field Data Tab/Construction Tab) was created for a surface. In the Design Map section of the Job Site Design Manager I choose those linestrings to add to the design. Then you can stakeout the surface and the linestrings in the same design. Otherwise you are constantly switching between designs in the field. Accurately creating those linestring from an alignment in TBC is the issue.... hence my original question.
The problem will go away once we switch to TSC7's running Siteworks.
Thanks for the input.
TBC / BC-HCE and SCS900 has always supported the combination of an Alignment and a Surface Model in the same design - it has always been the "Road Surface" type of design that asks you for the Surface and the Alignment(s) that you want to use and it writes you a PRO file of the combination - you can then export Linework to go with it as a DXF Design Map.
This has been in SCS900 since v1.0 of the Road Module in SCS900. I think and has also been supported in SCS Data Manager and BC-HCE and now TBC since that time. The big benefit of this approach is that you can have a Subdivision Surface Model and 10 alignments for the Subdivision Roads and you can export the one surface and all the Alignments in one PRO file. If the Surface Model is made up of Linework, that linework will also I think be sent out to the PRO file, and will get sliced by the Road Engine in SCS900.
When staking this you can use the Surface, the Alignment, the Alignment + Surface and if the Surface happens to be a Corridor Surface then its "Breaklines" will be available in the Stakeout as selectable nodes for the road Section etc.
Alan: You are correct in that it is available in the Roading Module and you export a Road Design from TBC. However, it doesn’t work if the client does not use/have the Roading Module. I was looking for a workaround for the customer who doesn’t have the Road Module.
2 Designs - Alignment and Surface.
Design - Alignment design
Settings\Second Surface (recent SCS) / Underlying Design (early SCS) - Surface design
You may need to configure info bars to display elev/cut/fill from second design.
This is also good when using Road Surface designs for surface checks beyond the typical corridor where the cross sections don't correctly represent the surface triangulation, and/or where a surface continues beyond the alignment (eg. cul de sacs).
I run into this issue when doing data prep for my 3D models. There are many cases where I need only a portion of an alignment and therefore will use just a linestring instead of the whole alignment. Typically I will use the offset command because I found this to be the quickest and easiest way to convert the alignment into a linestring. As Marshall mentions though, the tolerances are not the same. The results are close but there still tends to be manual manipulation required to clean up the new linestring.
Adjusting the vertical tolerance in Project Settings/Computations/ Surfaces/ Breakline Approximation Parameters did help with tighter results. Are there are negative effects to having the vertical tolerance tighten up to .001?
Is it possible for this function to apply the parabolic geometry from the alignment to the vertical portion of the linestring. This would give you a true copy/offset of the alignment you are working with.
Patrick: exactly! It is odd that you can append a linestring to create an alignment and create a linestring (as you point out) with parabolic/circular vertical components but not make an alignment into a linestring...
I understand that if you are offsetting an alignment that something has to 'give' (either horizontally or vertically) but if your offset values are 0 and 0 then why does it distort the result?
As Tim points out when you "Convert one object type into a different object type there has to be a full match up capability, otherwise the process will only work in certain situations. The Linestring hass only a Symmetrical Vertical Curve - it doesnt support Vertical Arcs or Asymmetrical Vertical Curves for example. A Linestring can not have Superelevation, nor can it have stationing nor can it have Station Equations. So while A Linestring can become an Alignment because it can only contain a subset of what is possible in an alignment, it cannot so easily be converted the other way because it cannot hold all of the information that an alignment has, and as a result we have to start compromising the data in certain scenarios i.e.
So while Straight and Arc segments can match in Hz and Straight and Vertical Curve Elements can match in the Vertical, and Grade Breaks can become VPIs in a Linestring, in all other scenarios we would have to state "This is not possible" or "This has been done by compromising the data" which is something we try to avoid doing in the software.
While tools like Offset Line or Create Sideslope or Create a Corridor and Explode it, or run a Geometry Report and Reimport the data will all work to a point, they are all compromises to the solution and can generate unacceptable errors if not checked or setup properly.
You could of course argue that working where possible and compromising where not would be acceptable for e.g. N American Subdivisions - but that doesn't work globally where they use Vertical Arcs in place of Vertical Curves etc.
What we really need is a dedicated tool that creates you a "close approximation" based on chording where the alignments won't match up. That is a development requirement. I will submit it as a User Story to the Dev Team and see where that takes us. The alternative would be to create a copy of an alignment and allow it to be Broken at a Start and End Station (without distruction of partial elements (which is not so easy to do geometrically and is incompatible with formats like LandXML that for sure would not support that.)
Is a chorded approximation good enough where it fails?
It is a feature that is needed. For a work around I have used the Create at Intervals tool. I use an interval of 0.5 to 1.0 feet. After creating the points I removed the straight grade points and then Connect Points to build linestrings. It's not perfect but seems to be good enough.
Once created you can join the points using Create Linestring From Points
and then run Project Cleanup to strip out the Vertices that dont add any
value - all possible, just a few more steps than ideal for sure.
On Mon, Jan 14, 2019 at 11:35 AM email@example.com <firstname.lastname@example.org>
Alan: First, I really appreciate the detail you've provided. Obviously it's not a "simple" thing to do.
I would say that most of the time (for me) a chorded solution would work if the external distance (chord to arc) could be specified.
For the "disposable" parts of alignments:
I really like the idea of an easy way to break an alignment. That would be a great feature. Is this perhaps a candidate for a "macro" or too complex?
Macros can do anything so all very possible. Also in Code anything is
The tolerance is specified using the Breakline Approximation Parameter in
Project Settings - Computations - Surfaces - You spec a Horizontal and
Vertical Parameter - that is what is used by the Offset line command today.
On Mon, Jan 14, 2019 at 11:39 AM email@example.com <
I did a little bit of testing to see what is actually done in current implementation of Offset Line
The special case of 0 Offset Horizontally and 0 offset vertically is the only time where we could do something different - however I would argue that that is a separate command need or we have to build in a special case to keep the Symmetrical Vertical Curves if the entire curve is selected. Note if you truncate a Spiral or a Vertical Curve element of any kind using a Start and End Station limit, then those elements would all have to be Chorded because you cannot easily truncate a Spiral or a Symmetrical or Asymmetrical Vertical Curve.