Enhancement: Civil 3D Corridor Baseline and Cross Section Data

[jhdempsey86]

Prerequisites

• I read the contribution guidelines
• I checked the documentation and found no answer.
• I checked existing issues and found no similar issue.
• I checked the community forum for related discussions and found no answer.
• I'm requesting the feature to the correct repository (see also speckle-server, speckle-sharp, specklepy, speckle-docs, and others)

What package are you referring to?

Civil 3D Connector

Is your feature request related to a problem? Please describe.

This doesn't solve a problem, but adding in all this extra data gives us all the information about the cross sections which Civil 3D has already generated and made available though its API, and saves us having to reverse engineer the featureline data by writing lots of code to take slices through the featurelines to generate coordinates of points on the cross section.

Describe the solution you'd like

Civil 3D Corridors should store lots more additional information about the baselines, and the assemblies and subassemblies which make up each cross section generated along the corridor

Suggest to add a "@baseline" list at the same level as the existing @alignments, @eaturelines, etc... lists

Each baseline object should have the baseline name, horizontal baseline, vertical baseline, assembly name, start station, and end station properties. This is the information you see on the Civil3D corridor parameters window:

Also include the list of stations made available from the Baselines.SortedStations() API call

From here, follow the hierarchy of Civil3D objects from its API, so the Baseline objects should include a list of AppliedAssembly objects. The AppliedAssembly object should contain a list of AppliedSubassembly objects, and so on, for the full hierarchy down to CalculatedPoints as listed out below

• Baseline
  • AppliedAssembly
    • AppliedSubassembly
      • CalculatedShape
        • CalculatedLinks
          • CalculatedPoints

The AppliedSubassembly object should contain the list of parameters set for the subassembly from which it was created.
The CalculatedShape, CalculatedLinks, and CalculatedPoints objects should include the "Codes" which are applied to those objects

Describe alternatives you've considered

There are no alternatives. This is extra data available through the Civil3D API that should be included in the Speckle objects

Additional context

Storing all this information stores information about each cross section generated along the corridor, along with all the information stored in the subassembly parameters which give additional geometrical and non-geometrical information about the design they are representing.
At the moment, only featureline are available, so to get any kind of cross section from the data, we have to slice through the featurelines with a plane to get the coordinates,

Related issues or community discussions

None

[clairekuang]

Getting to this now - after looking into the API, would this proposed hierarchy for applied assemblies work? This would allow you to more easily retrieve all shapes, links, and points of a particlar applied assembly. Happy to discuss further in a call if necessary

public class AppliedAssembly 
{
  public List<AppliedSubassembly> subassemblies { get; set; }

  // all calculated shapes of this assembly
  public List<CalculatedShape> shapes { get; set; }

  // all calculated links of this assembly
  public List<CalculatedLink> links { get; set; }

  // all calculated points of this assembly
  public List<CalculatedPoint> points { get; set; }
}

public class AppliedSubassembly
{
  // the parent applied assembly of this applied subassembly
  [jsonIgnore]
  public AppliedAssembly parent {get; set;}

  // the indices of the shapes of this applied subassembly in parent.shapes
  public List<int> shapeIndices { get; set; }

  // the indices of the links of this applied subassembly in parent.links
  public List<int> linkIndices { get; set; }

  // the indices of the points of this applied subassembly in parent.points
  public List<int> pointIndices { get; set; }
}

[jhdempsey86]

My initial instinct would be to follow the Civil 3D API a bit more in the hierarchy, and store all the shapes/links/points underneath the subassembly they belong to, rather than the assembly level.
I would then have the List as the child of the shapes class, and List as a child of the CalculatedLink class.

It’s important to be able to associate the points to links, links to shapes, and shapes to subassemblies.
I don’t think we can do this with what you proposed.
I could see which points are in a subassembly, but no easy way to work out which point or shape they belong to.