Civil engineering feature implementation (Transportation Engineering)

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
User avatar
Joel_graff
Veteran
Posts: 1949
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Civil engineering feature implementation

Post by Joel_graff »

matt wrote: Mon Jul 17, 2017 2:43 pm as a sidenote, alignment is implemented in ifc as ifcalignment

If I understood it correctly, parsing an "ifc-alignment-file" was implemented recently in ifcopenshell

maybe that helps?
Gee. That looks like it could be useful.
FreeCAD Trails workbench for transportation engineering: https://www.github.com/joelgraff/freecad.trails

pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Civil engineering feature implementation

Post by abdullah »

Joel_graff wrote: Sat Jul 15, 2017 2:14 am I should mention there is no "offending arc" per se. It is, though, as abdullah states - the solver's taking the easiest way out, and if two items are not closely aligned, they're subject to being moved - I intuitively understood that's how the solver is meant to function. But, of course, it creates problems in our use case.

Thus, either we write code to generate geometry that matches the existing tangents closely (which I have an algorithm about half-written to do that), or add functionality to FreeCAD that allows us to "lock down" certain geometry for the solver - much like the lock constraint does.

I will open an issue for the latter option above.
Kunda1 wrote: Sat Jul 15, 2017 3:47 am I assigned issue #3127 to Abdullah
The big picture is quite big.

Converging to unexpected (some call them wrong) solutions has been studied algorithmically from the creators of the solver (I can refer to very old threads, ickby-logari), and from a practical point of view "flipping avoidance" (not sure who exactly, but there is a lot of "good practices" for the sketcher in the wiki).

So far, the best recent attempt to my knowledge to provide an anti-flipping behavior/stability comes from DeepSOIC, who implemented angleviapoint (the kind of angles that take three geometric elements for creation). I also remember he used this in some tangencies and normals.

Additionally I have in my list a sketcher geometry element locking functionality (when activated makes a geometric element behave like if it were an external geometry, so it is unmovable).

I think somebody suggested in the past a mechanism to aid the solver finding the solution the user wants (not sure how such a thing would work).

With this I mean that some degree of improvement may be achieved, either by extending existing functionalities to new use cases (to this use case), simply by improving the algorithms (like if it were easy! :) But we have smart people in here, so it may come...) or by introducing new functionalities.

From what I have seen in this thread and my impressions of the sketcher/solver, I would say you won't succeed without such an algorithm of matching existing tangents closely enough. If when doing so there are still problems, then most probably there is a bug that must be fixed (I can imagine that problems may arise from things like an arc being CW or CCW).

The probability of the solver meeting your expectations increases as the number of DoF decreases, so it is good to constraint everything that should not be movable. In line with this last statement is the lock feature I was talking above (one should be able to misuse it in cases where constraining is not practical, for example I have 50 arcs, some of them connected and I want to make a tangency that is misbehaving, one option could be to lock arcs not involved, do the tangency and then unlock the arcs afterwards if/when needed).

I am being verbose here because when I see that feature in a couple of months probably I won't remember anything of this, but I will read the thread associated to the ticket.

IMO one ticket or several is not very relevant ATM, just document what you perceive as problem/need for improvement (feature or bug as you feel it). The most important thing for me when I deal with a ticket is that I have to do close to zero effort in reproducing the problem (open attached file => do minimal amount of actions =>get the failure; or alternatively, a sequence of python console commands exposing the issue). BTW, the second most important is the analysis done by people trying to reproduce the issue (we have a vibrant community helping in the tracker/forum which save lots of developer time filtering out false positives and providing additional information in real bugs). We all make FreeCAD.
User avatar
Joel_graff
Veteran
Posts: 1949
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Civil engineering feature implementation (Transportation Engineering)

Post by Joel_graff »

abdullah wrote: Fri Jul 21, 2017 2:56 am IMO one ticket or several is not very relevant ATM, just document what you perceive as problem/need for improvement (feature or bug as you feel it). The most important thing for me when I deal with a ticket is that I have to do close to zero effort in reproducing the problem (open attached file => do minimal amount of actions =>get the failure;
The failure, as it were, appears to result from tangentially constraining highly complex curves. In the example video I posted, the failure occurred when applying a constraint between the alignment and a spiral curve (consisting of three arcs and two tangents). I don't know that the complex relationships in the geometry was responsible for the failure, but it is the easiest case to demonstrate. Anyway, I've not yet rebuilt that case. I will try to do so soon.

The way you describe the situation makes a lot of sense - it matches my general intuition, anyway. I think that the idea of locking geometry before solving (and unlocking afterward) would go a long way to addressing the user expectations issue. It may just be that a few, well chosen conditions that need to be toggled in the UI to suit the need, but for whatever those other conditions may be, the geometry locking one seems the best place to start.

Anyway, I will try to reproduce the solver failure I identified in my video soon, and will plan on finishing those routines to generate tangential geometry in lieu of an integrated solution.
FreeCAD Trails workbench for transportation engineering: https://www.github.com/joelgraff/freecad.trails

pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
User avatar
microelly2
Veteran
Posts: 4688
Joined: Tue Nov 12, 2013 4:06 pm
Contact:

Re: Civil engineering feature implementation (Transportation Engineering)

Post by microelly2 »

here a case study
connect two line segments (red) by two arcs (all tangent constrainted)
there are 4 possibilities
bp_565.png
bp_565.png (41.8 KiB) Viewed 2039 times
at the moment I dont know whether it is possible to get all 4 cases for one starting configuration.
But I think it should be possible to create 3 or 4 solutions by a script and then the user must select the expected one/can switch between them.

when I careful change Sketch the 3 solutions follow until the sketch becomes unsolvable
Attachments
tangent_sketch_vb.fcstd
(14.01 KiB) Downloaded 67 times
tangent_sketch_va.fcstd
(13.46 KiB) Downloaded 55 times
User avatar
Joel_graff
Veteran
Posts: 1949
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Civil engineering feature implementation

Post by Joel_graff »

matt wrote: Mon Jul 17, 2017 2:43 pm as a sidenote, alignment is implemented in ifc as ifcalignment

If I understood it correctly, parsing an "ifc-alignment-file" was implemented recently in ifcopenshell

maybe that helps?
Ok, so I've done a little digging, but I still need to get into IFC to understand it better.

At a glance, this appears like a perfect solution for what we're trying to do. It's BIM-focused (which is what this is all about, anyway) so maybe it's best to use this tool to generate alignments?
FreeCAD Trails workbench for transportation engineering: https://www.github.com/joelgraff/freecad.trails

pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: Civil engineering feature implementation

Post by Kunda1 »

Joel_graff wrote: Sat Jul 22, 2017 5:54 pm
matt wrote: Mon Jul 17, 2017 2:43 pm as a sidenote, alignment is implemented in ifc as ifcalignment

If I understood it correctly, parsing an "ifc-alignment-file" was implemented recently in ifcopenshell

maybe that helps?
Ok, so I've done a little digging, but I still need to get into IFC to understand it better.

At a glance, this appears like a perfect solution for what we're trying to do. It's BIM-focused (which is what this is all about, anyway) so maybe it's best to use this tool to generate alignments?
yorik wrote:ping
@yorik may have an interest in this thread now.
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
User avatar
yorik
Founder
Posts: 13630
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Civil engineering feature implementation (Transportation Engineering)

Post by yorik »

Kunda1 wrote: Sat Jul 22, 2017 6:57 pm@yorik may have an interest in this thread now.
I have, always keeping an eye here ;)
User avatar
Joel_graff
Veteran
Posts: 1949
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Civil engineering feature implementation

Post by Joel_graff »

Joel_graff wrote: Sat Jul 22, 2017 5:54 pm At a glance, this appears like a perfect solution for what we're trying to do. It's BIM-focused (which is what this is all about, anyway) so maybe it's best to use this tool to generate alignments?
So I've looked a into the IFCAlignment specification. It's class structure coincides nicely with some of the thoughts I've discussed with microelly2 about how to organize the sketcher hierarchy.

There's also a transportation engineering-related German standard, OKSTRA, which tends to be more engineering-centric (focused on curve layout by engineering parameters) as opposed to the IFCAlignment's (and FreeCAD's) geometric-centric approach. I don't know that OKSTRA is the best specification, but converting between the two is documented on the BuildingSMART website.

The reason I mention OKSTRA is because it provides the engineering-friendly data specification that inevitably needs to be incorporated into an alignment design tool.

With that said, there's also the IFCOpenShell software, which converts the IFCAlignment data into more common CAD geometries. I presume this would be a part of the alignment design tool as it appears to provide geometry validation functions. Anyway, everything I see coincides well with our initial design concepts, inasmuch as I think I understand it.
FreeCAD Trails workbench for transportation engineering: https://www.github.com/joelgraff/freecad.trails

pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: Civil engineering feature implementation

Post by Kunda1 »

Joel_graff wrote: Tue Jul 25, 2017 12:27 am
@Joel_graff while @abdullah is unavailable...what else can be done to move this effort forward?
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
User avatar
Joel_graff
Veteran
Posts: 1949
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Civil engineering feature implementation (Transportation Engineering)

Post by Joel_graff »

Kunda1 wrote: Tue Aug 22, 2017 6:23 pm @Joel_graff while @abdullah is unavailable...what else can be done to move this effort forward?
I doubt much. I really need @microelly2 to help me prototype the hierarchical sketcher structure we were talking about previously, so until he comes back from vacation, I can't do anything, there... hence my seemingly misguided involvement in the demo video. :) The issues for which @abdullah is responsible don't really stand in the way of moving forward. In the end, I expect they'll qualify as user experience annoyances more than anything. :)

I've also been considering whether the path we've laid out is really the right one. It may be overcomplicated, but it's kind of hard to know until we get into it...
FreeCAD Trails workbench for transportation engineering: https://www.github.com/joelgraff/freecad.trails

pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
Post Reply