Topic: Civil 3D 2016 SP1 | New .NET API for Feature Lines

[BlackBox]

Has anyone found the documentation for this?

[mjfarrell]

this?

[Jeff_M]

Object Browser in VS??? It looks like all of the methods and Properties are fairly self explanatory. Only one method to create a featureline....must use an existing object. Looks like most, if not all, of the COM methods/properties were included...hopefully not just wrapped but actually rewritten to work faster (see Tery Dotson'scoments in the thread about this in the C3D customization forum.)

[Jeff_M]

this?

Nope, not yet anyway. Has not been updated with this new API addition.

[mjfarrell]

this?

Nope, not yet anyway. Has not been updated with this new API addition.

sorry, who would figure that they would not bother to update ONLINE documentation?

[Jeff_M]

The online docs are for C3D2016, I've never seen them change the Developer docs to include new features added in a ServicePack. Due, in part, to the fact that then the docs would not be applicable to those without the SP. I'm just happy this finally got added to the API! Dave S. had told me they were working on it but not sure of when they'd get there.

[mjfarrell]

What they cant put a header that says SPXXX ( For those who have installed Service Patch XX)   ?  Yeah, I guess they aren't that clever.

[BlackBox]

Thanks - I checked several places, as noted in the SP1 release typepad page from Almas, but was unaware that the online docs were not updated for SPs (Dieter says online is the only docs maintained, but C3D is very different from ACAD as far as how each group works).

In any event, when I didn't see any mention of the assemblies being updated (or overlooked that in the read me?), and didn't see anything different from 2015-2016 online API guide, I thought I'd ask.

Hadn't checked Ovject Browser yet, as I finally took the time to uninstall VS 2015 RC, and installed VS 2015 Enterprise today - the install wasn't done until after I left the office. *shrugs*

Cheers

[BlackBox]

Thank you, Augusto!

DevBlog Announcement:

http://adndevblog.typepad.com/infrastructure/2015/08/civil-3d-2016-sp-1-new-feature-line-api.html


Direct link to Feature Line API (online):

http://docs.autodesk.com/CIV3D/2016/ENU/API_Reference_Guide/html/856470c7-bf8f-2fa4-db5f-d290252f36c0.htm

[nobody]

any ideas / ways to use it? the insert point might be handy but struggling to think of real uses for it

[huiz]

Featurelines are great! Creating them programmatically can be useful if your application needs to draw intelligent 3D polylines. I wrote a program to convert a land survey (CSV files) into geometry (3D polylines and blocks). Now I can extend my application to export featurelines, so it is possible to add curves to 3D geometry.

But I think it has more advantages to get data from featurelines. Each function I have now to extract data from geometry, result in exploding selected featurelines into non-intelligent 3D polylines. Now I can extract more accurate data from featurelines as well.

[BlackBox]

any ideas / ways to use it? the insert point might be handy but struggling to think of real uses for it

Yes, in fact - I have a very specific application in mind.



I'm not particularly a fan of how much work is currently needed to 'grade' a site, particularly subdivisions in my case.

While I do need Alignments, Profiles, and Profile Views for plans production, I do not technically need Corridors, or Grading objects, for anything more than culling rim / grate elevations for sanitary / drainage structures, and daylight line - they're just currently what I'm relegated to using to obtain the information what I need - or so I thought.

I've long been using Feature Lines for rear lot lines, creating a Surface from stepped offset, and then use MINIMUMDISTBETWEENSURFACES to extract the intersection (aka daylight), and subsequently delete the working Surface. For this reason, I recently started _not_ producing Corridors for R/W to R/W, and instead pull Feature Lines from Alignment / Profile, trimmed that, joined it to this, and did stepped offsets from that to design a Surface from which to cull - but even that took some time to model, and I still need to label it for plans production.

Being that modeling Corridors, Gradings, and ultimately Surfaces takes longer than I'd like, I started to explore other ways of 'grading' my site for plans production, and I circled back to Expressions + Alignment Station Offset Labels.

While cumbersome to setup, once in place, grading the site (for plans) now takes a fraction of the time as compared to any of the aforementioned combinations, in terms of plan production, as one only needs an Alignment, and Profile; the Expressions + Labels do the rest.

At some point, I still need a Surface though, and I realized there's no in-built way of converting Station Offset Labels with Profile reference text to any usable format for building a Surface (which is ridiculous, IMO).

It's at this point, that I came up with CONVERTALIGNLABELSTOCOGO as discussed in this thread, and now I plan on adding the ability to directly create Feature Lines in kind.

Cheers

[nobody]

Not bad black box. I went the same route with some minor differences.  I realized I never had to build a surface at all, with exception of those needed for pipes / rims / etc as you had mentioned. It's handy to raise / lower them as needed.  I still do prefer featurelines over corridors, just like preferred 3d polylines over templates in LDD.  In that regards, I've toyed with,  and retoyed with and stopped toying with the idea of building an app that would generate a roadway subgrade. In the end, I realize that's exactly what corridors are (just a collection of featurelines), and if I ever really need it I could just use the built in functions.