Ok,
At this point, I've been going a bit in circles trying to figure out how to encapsulate the civil specific geometries I outlined in my video inside sketcher.
The problem is, there's no straightforward way to create a custom part that can be used in sketcher. Generally, I want to create a complex curve along with it's associated construction geometry and constraints as a custom part, of sorts.
To this point,I've toyed with the idea of building a custom Python class to manage this and serializing it using custom properties in the containing SketchPythonObject. That seems like a viable solution (especially since there is a list property)
Microelly2, however, has been introducing me to the interactive sketch work he's done and I'm trying to imagine how it could be used to contain civil / transportation alignment data.
There's really a lot of different kinds of data to be stored:
1. Stationing for the entire alignment (along with station "equations" which accommodate discontinuities)
2. Entire alignments, which may or may not intersect with one another, but may be a part of the same project
3. Alignment components (tangents / curves)
4. Component geometry (construction geometry) and constraints
Microelly2 proposed creating a sketch which encompassed an entire alignment, and then making a child sketch which handled the constraining construction geometry (tangents, chords, radii, etc). This approach would solve the clutter issue I mentioned as the construction geometry and constraints would exist in a separate sketch which could be shown / hidden.
But as I considered it further, I think I've got a clearer picture of the data hierarchy for this sort of work. Specifically, I see the data being broken down into the four categories suggested above.
Thus, where microelly2's hierarchy was:
Code: Select all
Alignment Sketch
|----> Constraints Sketch
Mine is a bit more complex:
Code: Select all
Corridor (Project) Sketch
|----> Alignment Sketch
|----> Component Sketch (tangents / curves)
|----> Geometry Sketch (constraining geometries - tangents, chords, radii, etc.)
I am certain I don't fully grasp the way this works, but I'm trying to ensure we have the interactivity necessary to fully construct a corridor alignment in 3D.
Understand I'm thinking about a typical highway construction project. It may involve a new alignment along the main road, with minor changes in sideroads that intersect. Additional "frontage" roads may be created that run parallel, and there may be some alignments which never intersect.
For example, the Corridor / Project sketch might contain b-splines generated from all alignments. It's geometry is not directly editable as it's auto-generated from changes made in the lower-level sketches. However, this would be a great place to develop / manage project-level (global) data that applies to all alignments within it. Further, this geometry would act as the necessary ancestor to child geometries to provide interactivity between them (since sibling interactivity doesn't appear to be possible).
Then, each Alignment sketch would represent any given alignment, primary or secondary. Again, the geometry here is auto-generated and not editable. It provides the source of the aggregated alignment geometry represented in the corridor sketch. Best of all, at the alignment level, we finally have a place for stationing! I still don't know how it can be represented visually, but it is, hierarchically speaking, where it needs to be defined.
Finally, the component / geometry sketches are where work is done. Each sketch tuple represents a single component in the alignment and that component's corresponding construction geometry. So, suppose the user clicks a "Two-Center Curve" button in the UI. A new component sketch and the corresponding geometry child sketch are auto generated and populated, then attached at the end / selected point in the alignment. Then, the higher levels (alignment and corridor) are auto-updated with the change...
In the end, the user works primarily between the component sketch and geometry sketch (much like microelly2 demonstrated in his video). The higher level sketches are simply auto-updated and provide more global data structures for use in editing the lower level sketches.
Sorting through the sketches is a problem, though. A large project would quickly become encumbered by many hundreds of sketches. Using stationing and descriptive naming, it's a small matter to describe where each sketch is located in the project, but the actual hierarchy can't be represented in the element listview.
So I suppose that means a treeview needs to become the default (or optionally switched in) to represent sketch document structures which have a parent-child relationships.
So that's my inspiration ... and it only took two cups of coffee!
Anyway, I imagine my attempt at describing my thoughts has made this about as clear as mud to everyone else. I think we're on the right path, but please ask me to clarify if there's something not understood.
microelly2's video on interacting sketches: