Ok, so I haven't had much time to really work through the implementation for the transportation module, but I've had some very helpful conversations with @microelly2 regarding sketcher feedback objects. At the moment, before I get too much into writing code, I'm trying to develop a clear picture of what the implementation should look like. Forgive the length of this, but it's helpful to me to think out loud, so to speak..
So, the module needs to use two types of alignments: horizontal and vertical. Both use the same kinds of geometries, but relationships and terminologies vary. Additionally, there is some interplay between the two types of alignments. For example, it's occasionally necessary to force certain parts of the horizontal alignment to align to certain parts of the vertical alignment (horizontal curves shouldn't coincide with vertical curves - I don't want to be driving around a curve while also driving over a hill, for example). Also, both alignments are measured using a common stationing.
A quick review of how stationing works is in Chapter 6 of the following document (page 16 or so):
https://www.codot.gov/programs/tetp/con ... eading.pdf
As I've thought more about it, I've been considering implementing these elements as FeaturePython objects (FPOs). At the moment, I'm looking at it like this:
- A Feedback sketch would consist of two clients, each rendering an "alignment" FPO. One would be a horizontal alignment and the other, vertical.
- The "alignment" FPO would either be two separate FPOs or just one that is customized for horizontal / vertical orientations at the time of construction.
- Each alginment object would have a stationing property - they would be synchornized in code (I think just forcing the vertical's property to match the horizontal's will be sufficient).
- Each alignment is made up of line / curve geometries with corresponding constraints. (tangents, one / two / three center curves, spiral curves)
- Each geometry element could be constructed as a separate FPO, to manage the geometry and it's specific constraints.
- Creating separate FPOs for the individual elements makes managing each element (and it's constraints) possible on a selection basis. That is, simply picking an element means the FPO code can automatically pick the corresponding constraints and apply operations to them in aggregate.
- A single feedback sketch is strictly limited to a two-client flavor, and each feedback sketch corresponds to one and only one alignment. This corresponds nicely with the way alignments are generally managed in transportation engineering, as opposed to representing multiple alignments (and their H/V curves) in a single feedback sketch.
- Using FPOs to encapsulate the alignment hierarchy makes application of both local and system wide properties easier to manage.
- Using FPOs potentially makes interacting with the alignments more straightforward as geometries and their corresponding constraints can be individually selected and manipulated.
- Need interoperability between sibling feedback sketches (master - master interoperability would be sufficient), or the ability to nest feedback sketches
- Constraints need to be made individually visible / invisible, since they would now exist in the same sketch as their corresponding geometries
- Does this hierarchy seem reasonable?
- Are the needed features (interoperability between feedback sketch masters / toggle visbility for individual constraints) already available or manageable in some other way?
- Do I have a completely wrong-headed view of how to use Feature Python Objects?