Civil engineering feature implementation (Transportation Engineering)

[microelly2]

Nice demonstration how the solver fails.

The solver always finds the "nearest" solution of a constraint system, but
this "nearest" must not be what we want.
We have to draw a configuration which leads the server to our expectations.

With the sketcherobjectpython we can add more intelligence than only solve equation systems.
we can push the system on a death point to the right direction .
then the server can run.

The core task is to define boundary conditions where the sketcher solver finds the solution we expect.

The simple testcase is a task to create a triangel by 2 sides and the not enclosed angle.
There are 2 solutions. How to write a sketcher extension which can switch between both solutions.

[Kunda1]

phpBB [video]

Nice demonstration how the solver fails.

The solver always finds the "nearest" solution of a constraint system, but
this "nearest" must not be what we want.
We have to draw a configuration which leads the server to our expectations.

With the sketcherobjectpython we can add more intelligence than only solve equation systems.
we can push the system on a death point to the right direction .
then the server can run.

The core task is to define boundary conditions where the sketcher solver finds the solution we expect.

The simple testcase is a task to create a triangel by 2 sides and the not enclosed angle.
There are 2 solutions. How to write a sketcher extension which can switch between both solutions.

ping

Any suggestions on how to tweak the solver to use parameters that are more geared to the objective of this proposed WB ?

[Joel_graff]

Nice demonstration how the solver fails.

The solver always finds the "nearest" solution of a constraint system, but
this "nearest" must not be what we want.
We have to draw a configuration which leads the server to our expectations.

With the sketcherobjectpython we can add more intelligence than only solve equation systems.
we can push the system on a death point to the right direction .
then the server can run.

The core task is to define boundary conditions where the sketcher solver finds the solution we expect.

The simple testcase is a task to create a triangel by 2 sides and the not enclosed angle.
There are 2 solutions. How to write a sketcher extension which can switch between both solutions.

I know this probably won't make sense, but when I saw the way the curves failed... my intuition told me it was gimbal lock - essentially, what looks like the shorter path ends up becoming the longer path... Don't suppose you've implemented quaternions to calculate angle rotations in the solver...?

Anyway, on a topic I know a little more about..

This is, obviously, an edge case for the way the solver was intended to be used. And I think we can fix it without having to work with the solver. But it's important to distinguish between the user's intuition of how the solver works from the way that it actually works.

Specifically, a user's intuition would expect:

1. That the general orientation of all geometry should remain unaffected (i.e., no tangent reversals)
2. That previously drawn geometry is canon - and should remain generally fixed unless directly manipulated by the user. Perhaps more functionally, geometry is manipulated by it's selection order. Thus, if I pick two points to constrain tangentially, the latter selection is moved, while the former remains unchanged.

Whether or not those are realistic expectations is another matter. And if it doesn't make sense to force them upon the solver, then another way should be found.

However, these expectations need to be accommodated at some point. I love the Sketcher's more "organic" approach to the process, but alignment construction (in my world, anyway) tends to happen in a methodical serial fashion, and it's no good if previously-placed elements move every time a new one is added.

[Kunda1]

Looks like if Feature issue #1560 'Provide ability to fine-tune auto constraints' was implemented it could be helpful with this WB as well.
Synchronistically @abdullah assigned it to himself

[Kunda1]

ping

@ickby what is the methodology to customize the solver in sketcher to behave in the way we want it to in he future WB?

[Kunda1]

ping

How's it going so far?

[Joel_graff]

@microelly2 and I have been chatting trying to figure things out. I suppose I should bring the conversation into this thread.

Mostly, it's about how to organize the data in a hierarchy that makes sense using the SketchObject class and interactive sketches.

I'll update shortly.

[Kunda1]

@microelly2 and I have been chatting trying to figure things out. I suppose I should bring the conversation into this thread.

Mostly, it's about how to organize the data in a hierarchy that makes sense using the SketchObject class and interactive sketches.

I'll update shortly.

Yes, thread activity shows vibrancy, builds interest/buzz. So please continue this conversation in the open. Thanks!

[Joel_graff]

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:

phpBB [video]

[Kunda1]

@Joel_graff ping. Any proof of concepts yet ?