how to label TC's on a curve, using surface?

[Anonymous]

If I model a parking lot or street, using feature lines for curbs, I end up with a surface that has trinagles only, not
true arcs.
When i go to place spot labels on the surface for TC's, they will almost never actually hit the TC that the surface
actually models. For curved areas, the surface "chords" behind the true curb line.
My spot labels will be off the true TC a bit, and this matters because the face of curb is steep. A small offset
affects the elevation a lot.
This is not a new idea, it happened in LDT too.
How do most people model and label curbs? Is there a way to label based on the feature lines of the surface?
I do it with alignments, but it would be nice to use surfaces.

On top of all this, corridors make surfaes that you can label, you cannot label anything else that I know of with them.
Since the surface is faceted, it will not be reliable for labeling TC's (fine for most everything else though, nothing
else has steep edges like curbs - maybe walls though...).
I know we cannot label directly off a corridoor, I've harped on that before, but that leaves a gap in the system.
There must be a good strategy to cover this.
thx
James Maeding
Civil Engineer and Programmer
jmaeding - at - hunsaker - dotcom

[Anonymous]

Are you labeling at points that wouldn't have a tin point naturally? Most
grading plans I've seen labeled at returns, PCs, the sort of places where
the chording of the curve would be irrelevant. Do you label the face of curb
or the back of curb? Mountable curb or standard step? Just curious at this
point as I wait for an upload...

--
James Wedding, P.E.
Engineered Efficiency, Inc.
Civil 3D 2007
XP Tablet, SP2, 2GHz, 2G
www.eng-eff.com
www.civil3d.com

[Anonymous]

I've tried using an expression to add the curb height, then just make sure
the picked point is on the bottom.

....not sure I like the results, but it works, result like:

TC-500.50
BC-500.00

(Not sure what you're final desired output looks like, of course.)

"James Maeding" wrote in message
news:5525117@discussion.autodesk.com...
If I model a parking lot or street, using feature lines for curbs, I end up
with a surface that has trinagles only, not
true arcs.
When i go to place spot labels on the surface for TC's, they will almost
never actually hit the TC that the surface
actually models. For curved areas, the surface "chords" behind the true
curb line.
My spot labels will be off the true TC a bit, and this matters because the
face of curb is steep. A small offset
affects the elevation a lot.
This is not a new idea, it happened in LDT too.
How do most people model and label curbs? Is there a way to label based on
the feature lines of the surface?
I do it with alignments, but it would be nice to use surfaces.

On top of all this, corridors make surfaes that you can label, you cannot
label anything else that I know of with them.
Since the surface is faceted, it will not be reliable for labeling TC's
(fine for most everything else though, nothing
else has steep edges like curbs - maybe walls though...).
I know we cannot label directly off a corridoor, I've harped on that before,
but that leaves a gap in the system.
There must be a good strategy to cover this.
thx
James Maeding
Civil Engineer and Programmer
jmaeding - at - hunsaker - dotcom

[Anonymous]

I see the same gap.

I create a station/offset label that pulls an elevation from a profile
(reference text). Model the corridor to get a decent idea of cut/fill, but
that's about it. I agree with you, it's nearly impossible to use it for
accurate labeling along an edge, especially at a curve - until some invents
the CIN (Curvalinear Irregular Network - and even then I wouldn't trust the
rounding in State Plane to paint an accurate model) - it is probably the
biggest complaint I have from clients as well.

If you do decide to label, the problem becomes - you can't export the
labels, and you can't convert them to point objects (out of the box - but
knowing you James - there is a way, but you'll need to write it). The
marker will have an object snap associated with it (insertion point if it's
a block), so a person could physically place points at all spot elevation
markers - but they won't be dynamically linked.

Ya, I feel your pain. The only other option is to model beyond the extents
of the curb, but when working almost vertical c&g, this can be a bear to
wrap your brain around (curve, compound curve, into a reverse curb).
--

sm

Scott McEachron
DCCADD Dallas - Fort Worth
http://c3dpavingtheway.blogspot.com/




"James Maeding" wrote in message
news:5525117@discussion.autodesk.com...
If I model a parking lot or street, using feature lines for curbs, I end up
with a surface that has trinagles only, not
true arcs.
When i go to place spot labels on the surface for TC's, they will almost
never actually hit the TC that the surface
actually models. For curved areas, the surface "chords" behind the true
curb line.
My spot labels will be off the true TC a bit, and this matters because the
face of curb is steep. A small offset
affects the elevation a lot.
This is not a new idea, it happened in LDT too.
How do most people model and label curbs? Is there a way to label based on
the feature lines of the surface?
I do it with alignments, but it would be nice to use surfaces.

On top of all this, corridors make surfaes that you can label, you cannot
label anything else that I know of with them.
Since the surface is faceted, it will not be reliable for labeling TC's
(fine for most everything else though, nothing
else has steep edges like curbs - maybe walls though...).
I know we cannot label directly off a corridoor, I've harped on that before,
but that leaves a gap in the system.
There must be a good strategy to cover this.
thx
James Maeding
Civil Engineer and Programmer
jmaeding - at - hunsaker - dotcom

[Anonymous]

This chording of the surface model around curves will also affect structures placed along eop/curb face. If your structure doesn't fall on one of the usual corridor sections you'll need to specifically include it's station to get an accurate surface at that location so the structure gets to correct elevation.

[Anonymous]

I would say yes.
You might need to label a TC for many reasons on grading plans, it might be that a drainage pipe crosses under the curb.
I have a feeling the reference text answer is the best when surfaces are involved. Only prob is you must assume the
curb height. Transitions are not allowed in that method.

I do think this issue reflects AutoDesk's thinking on Civil 3D though.
They are not convinced that we need a real model of our design.
Programs like ASE Civil are limited on the subject of triangulated surfaces, but are far ahead in how elevations are
derived from the model.
So while C3D has integrated methods to build surfaces, they assumed surfaces are what we want.
Way back when, we never asked for that. We asked for objects that would help us integrate design, specifically
cul-de-sacs and knuckles.

Things like this make me continue to pursue home brew solutions that do consider a true model.
I'm sure Nick Merchant will eventually integrate his prog to C3D so it makes surfaces from his breaklines automatically.
Then his prog will be king of the mountain, lets hope he does not write his own surface generator, then C3D starts to
look previous generation. I keep thinking someone else with more time than me or Nick will jump in and write some C++
based prog that uses a true model system that puts us both to shame, but it hasn't happened. Its such a vacuum.

In the mean time, I still pay for C3D and will use it as much as possible. Sure wish the product manager was my
neighbor or something, I worry that the guys at the top have not talked enough with people doing final road design.

james.wedding <>
|>Are you labeling at points that wouldn't have a tin point naturally? Most
|>grading plans I've seen labeled at returns, PCs, the sort of places where
|>the chording of the curve would be irrelevant. Do you label the face of curb
|>or the back of curb? Mountable curb or standard step? Just curious at this
|>point as I wait for an upload...
James Maeding
Civil Engineer and Programmer
jmaeding - at - hunsaker - dotcom

[dana.probert]

I understand the logic here and the problem, theoretically.

I am going to do some experiements myself here in a little while because I am curious about how much of an elevation difference it makes. Are we talking tenths? Hundreths? I know every bit counts and I am not discounting the issue. I want to understand the problem better so that I can help come up with ways to mitigate it as well as provide any feedback I can.

Thanks!
Dana

[dana.probert]

ah ok, nevermind i answered my own question. the label would either hit the TIN triangle or be hanging in space over the curb missing the triangle. i can see it now.

when you make cogo points from corridor- they come off the corridor directly, right? could that be a solution?

[Anonymous]

Hey James,

First of all thanks for the plug.

Second of all, you must be psychic. The points you mentioned have already be done. The C3D compaitibility has been developed and integrated.

Currently we're about 95% finished developing a system that will automatically create a surface for each road alignment after the data is exported. Then it also automatically generates contours and calculates earthwork volumes. All this is done in a few seconds for each alignment. Cumulative volumes are also tracked and the surface also includes the ASE Civil pad definitions (Which are attached to the alignments) as well as user specified geometry and boundaries.

The nice thing is that the system works with all versions of Autodesk civil products from LDD R1 through Civil 3D 2007.

We'll probably have this in the product sometime in April.

Right now we're working with GR to integrate the California design and production standards. We've already established some of them, but we may not complete that for about another 6 months.

Since we brought (Unnanmed) on board, our development progress has doubled. In addition to the surface-building feature, he's also developing a commercial module that will be added on to ASE Civil. We're both studying C# so once we become productive with that we may develop our own surface modeling engine so we don't have to be Autodesk dependent in that area. But in the meantime, theirs works so beautifully... Nonetheless, our elevations will never, ever be based on surfaces but always on design geometry.

[Anonymous]

wow, you guys are moving!
You know, one thing you might think about, Nick, is an API to access the model's station, offset and elevation values.
Then customers can bridge any annotation needs on their own, without you having to recompile all the time.

Its very interesting that Adesk does not let us label certain things, like feature lines used for a surface or corridor
features. I know we can write our own, as an osnap on the feature does give a 3d point back, but now we are back to
non-C3D labels. The way things are going though, our firm will have to do that anyway for rough grading and final
design plan and profile (what's left?).

I'm still amazed that Adesk did not make basic annotation for plan and profile more developed. They had so many
examples, even the MadCap stuff that shipped with the product (Softdesk) they bought out.
Things like reference text and flexible callouts are fundamental, not 3rd release afterthoughts.
Even with reference text in C3D, you still have to pick the objects involved which is awkward. I much prefer the idea
of current alignments and surfaces so it knows what to use. I have a modeless dialog that lists the current align #1,
#2 and surface #1 and 2 for my callout program. That way, you can choose without picking graphics, which can overlap
and be hard to pick. What if I have a sewer on centerline? Which gets picked using the C3D way if both objects show?



Nick_Merchant <>
|>Hey James,
|>
|>First of all thanks for the plug.
|>
|>Second of all, you must be psychic. The points you mentioned have already be done. The C3D compaitibility has been developed and integrated.
|>
|>Currently we're about 95% finished developing a system that will automatically create a surface for each road alignment after the data is exported. Then it also automatically generates contours and calculates earthwork volumes. All this is done in a few seconds for each alignment. Cumulative volumes are also tracked and the surface also includes the ASE Civil pad definitions (Which are attached to the alignments) as well as user specified geometry and boundaries.
|>
|>The nice thing is that the system works with all versions of Autodesk civil products from LDD R1 through Civil 3D 2007.
|>
|>We'll probably have this in the product sometime in April.
|>
|>Right now we're working with GR to integrate the California design and production standards. We've already established some of them, but we may not complete that for about another 6 months.
|>
|>Since we brought (Unnanmed) on board, our development progress has doubled. In addition to the surface-building feature, he's also developing a commercial module that will be added on to ASE Civil. We're both studying C# so once we become productive with that we may develop our own surface modeling engine so we don't have to be Autodesk dependent in that area. But in the meantime, theirs works so beautifully... Nonetheless, our elevations will never, ever be based on surfaces but always on design geometry.
James Maeding
Civil Engineer and Programmer
jmaeding - at - hunsaker - dotcom

[Anonymous]

Our 2008 version is moving towards a type of "open architecture" that will allow users direct access ASE Civil design data. That way you can extract all the available design elements that you need and customize your own labeling program. In-house developers now using ASE Civil will really appreciate that. As well, you'll also have the capability of getting that same data from the LDD or Civil 3D database using ASE Civil's API that will automatically detect the environment in use, if any.

[Anonymous]

wow, a double pass of data from LDT to ASE to ME, sounds like a song from Sesame Street!
Now you will see my stuff on ASE on C3D on Acad, is that 4th party? That must be a record.
I wonder how many prog's out there have extensoins on extensions on extensions?

Nick_Merchant <>
|>Our 2008 version is moving towards a type of "open architecture" that will allow users direct access ASE Civil design data. That way you can extract all the available design elements that you need and customize your own labeling program. In-house developers now using ASE Civil will really appreciate that. As well, you'll also have the capability of getting that same data from the LDD or Civil 3D database using ASE Civil's API that will automatically detect the environment in use, if any.
James Maeding
Civil Engineer and Programmer
jmaeding - at - hunsaker - dotcom

[Anonymous]

That's funny!

Well, access to the ASE model is a direct line to dictionary info that our app' creates and manages. Access to the Autodesk civil models is just an exposure of the VLAX methods that ASE uses, which are pretty fast.

There are a LOT of Lisp programmers out there that want to, but cannot access the Autodesk civil databases because they don't know the syntax. I have people constantly asking me for that stuff, but I can't just give it away. I've told them to search the DG's but maybe they just don't have the time.

I know that mentioning VisualLisp in this group is sinful, so I'll just stop here before somebody decides to rip me up and tell me it doesn't work with Civil 3D, it's the wrong language, etc.