Corridor.GetFeaturelinesByCode - Question

[Lazarica-t]

Hi Paolo,

I have a question regarding how the Corridor.GetFeaturelinesByCode node works.

1. When working with more complex corridors that are made up of a couple of regions the node gives me a Featureline for each region, what is a bit unclear is why doesn't the start and end of these Featurelines match with the stations in Civil. In the CivilConnection versions prior to 5.0.0 I was getting 1 single Featureline for the entire corridor regardless of how many regions is was made up, which was pretty convenient. Is the node working as intended?

2. If we do a Featureline.PointAtStation on any of the resulting Featurelines (even with station values that are out of range of the featureline Start - End) I am receiving the expected points which is a good thing and also a bit cofusing..doesn't the node take into account the Start - End of the Featureline?

Best Regards! :)

[atultegar]

Hi, I am also having same problem. And I posted that issue here. and it is tagged as 'won't fix'.

You can find that issue in Closed issues.

Thanks

[Lazarica-t]

@atultegar thanks for the info, did not see it. Well at least I now that it's working as intended so now I need to accommodate this info into my script workflows.

[paoloemilioserra]

depending on the subassembly the feature lines may not be generated for the entire length of a region (e.g. when you have a switch in the SAC), the changes made need to reflect what you have in Civil 3D (which could be an "intermitting" feature line in the same region). The data used to create the feature line geometry is stored in an XML in your temp folder as explained in the documentation. In the XMl you can see that some points are "breakpoints" meaning where the feature line stops and then restarts again down the baseline. This behaviour has been implemented way before version 5 but there was a subtle bug and it has been fixed. To update the location of Revit elements assigned to a feature line I had to be quite flexible as, in principle, between two consecutive updates the changes in the corridor structure can be so disruptive that the feature line is not there anymore (change of station, change of region, change of alignment, etc...). For this reason it searches points that can still make sense preserving the code and the side of the original feature line to at least maintain the connection with the corridor. This is what I call resiliency in the update process.

[Lazarica-t]

@paoloemilioserra Thank you for the explanation. I can understand why you decided to take this approach, it's just unfortunate that there are some unexpected side-effects.

Testing a bit more the new CivilConnection version I found another interesting side-effect for the Featureline.PointAtStation node:

• For corridors with more complex paths (a lot of twists and bends) you get some bonus points as a result (they seem to be the result of the intersection between the featureline and the XY planes at the corresponding input stations)

And as a comparison using a previous version:

[paoloemilioserra]

CivilConnection returns only the point closest to the featureline. You must examine the code before making comments here, that is why it is open sourced.

https://github.com/Autodesk/civilconnection/blob/master/Src/CivilConnection/2020/Autodesk2020/Featureline.cs#L318

[Lazarica-t]

I'm not saying the code is not doing what it's suppose to do, I was just sharing the results for a more particular case (Corridor composed of different regions with a complex path). I get it that those extra points pop up there due to the way in which the corridor was build and having the Featureline made up of several segments it will generate points of intersection for each segment (if there are any), and for this particular corridor it just so happens that the same origin ZXPlane intersects 2 segments of the Featureline and thus resulting an extra Point and being the only point it's by default the closest. I can work around this, but I thought it is important for other users to see that it is important the manner in which the Civil 3D corridors are build and why they might get unexpected results.

[paoloemilioserra]

Again, look at the code, it returns only one point per featureline regardless how many intersections you get.

[Lazarica-t]

I agree with what you are saying. Maybe I did not express my self correctly or din not properly highlighted the input, there are more featurelines (some have the same code name, but with different start end stations).