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 (Transportation Engineering)

Post by Joel_graff »

paullee wrote: Wed Jan 16, 2019 5:26 pm On your problem, I used 'non-driving' constraints (on both X and Y) and name them.

Then you can 'trace' the position of that point. The only risk is user delete it.
I thought of that originally, and in most cases, it might be an acceptable solution. In fact, I'd bet there will almost always be a 'driving' coincident constraint will be available and I could repurpose that, since the user will likely always create closed shapes for templates.

I may use that for now. The only problem is a 'non-driving' constraint can be made to 'drive'. And none of the constraints are really intended for this purpose, driving or not.

Still, I really feel an 'empty' constraint is best - it cannot ever incur any computational overhead nor have any unintended effect on the sketch itself. I just don't know if something like that would be useful to the community as a whole.
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 (Transportation Engineering)

Post by abdullah »

Joel_graff wrote: Wed Jan 16, 2019 1:53 pm So to be clear, what I'm trying to determine is the following:

1. Is there any other feasible way to create permanent references (by a unique ID or otherwise) to a point in a sketch that will always remain, even if the sketch gains / loses points or that point moves?

2. Can I be sure that when the SketchObjectPython sees a change, that change will be atomic? That is, it won't possibly include multiple changes at once (e.g., a new point, plus an existing point moving).

3. Would it be possible to create an "empty" constraint that applies to a specific point? It's a constraint that does nothing but exist on a point (or edge).That would provide an excellent way to reference sketcher geometry externally by a unique, unchanging reference and save a lot of the hassle I've described above.

Pinging the two guys who I know will have an opinion. :)
abdullah wrote:Ping!
microelly2 wrote:Ping!
Congratulations for all that far that you are going with the Civil engineering WB. :)

I more or less understood the problem (road widening/narrowing). I am not sure I fully understand the solutions. I can try to answer the questions.

1)
Today (v.18): Yes in runtime (id not serialized).
>>> geo0 = ActiveSketch.Geometry[0]
>>> geo0.Tag
'aab26c14-9f21-45c4-ba03-f71eddf58cfb'
This tag will stay the same until you delete the object. Now you close FC and start it again. That object will get a different uuid on restoring, this new uuid will remain the same until you delete the object or close FC.

This uuid is not Sketch specific, but FC global, you won't find a repeated number in any other geometry in FC.

Tomorrow (v.19): If I manage to make Python defined geometry extensions, you will be able to associate whatever you like to a Sketcher Geometry AND this will be serialized.

This is an example of how this could work (the extension is NOT Python defined in this example):
example

Maybe Tomorrow (v.19): Maybe we get some ways to make a geometry not move at all.

2) Not my arena. I think that one is for microelly

3) I think this is an inferior solution to 1). I do not think this is the way. If 1) does not fulfil your needs, let me know why and we can find a solution for your problem.
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 »

Joel_graff wrote: Wed Jan 16, 2019 5:19 pm
microelly2 wrote: Wed Jan 16, 2019 2:54 pm This is a method to define a fix point in the sketch with constraints x y AAA,BBB
Whenever a user deletes it it will be reconstructed:
Hmm.. Maybe not quite what I'm after. ;)

I don't exactly want the point itself to be permanent... I just want to make sure I can always find that point using a consistent, unique identifier, no matter what the user does with the sketch. That is, the index may change if the user adds / deletes other points. The location changes if the user moves it. But in the end, the point itself still exists. I just need a way to identify that point consistently from outside the sketch.

Look, for example, at the sketch template I showed previously. It might represent a single roadway lane of a two-lane road (a typical roadway lane is 12 feet in the US). The sketch origin is at the road's center and the point at the far right would represent the right edge of pavement. I would want to name it 'EOP_RT' so I could permanently refer to it outside the sketch, and so it has a name that's meaningful to the user.

But how do I ensure that the point that I've named is always going to be the same point?

That's why I had the idea that maybe an 'empty constraint' attached to the point might be a solution. It doesn't constrain anything, it just provides a consistent way to reference the actual point from outside the sketch, unless, of course, the point itself (or the constraint) is deleted.
My example defines this point by two named constraints AAA,BBB.
If you delete the point or the constraints, with the next method call the deleted objects are recreated may be with other ids
but using the constraints names you can find the point-geometry and can use it by updating/replacing other constraints which should refert to this point. I do not have one constraint but two for the point. In your example we can call the constraints EOP_RT_X, EOP_RT_Y.
And the values for the constraints can come from some global database.
paullee
Veteran
Posts: 5098
Joined: Wed May 04, 2016 3:58 pm

Re: Civil engineering feature implementation (Transportation Engineering)

Post by paullee »

abdullah wrote: Thu Jan 17, 2019 9:00 am
>>> geo0 = ActiveSketch.Geometry[0]
>>> geo0.Tag
'aab26c14-9f21-45c4-ba03-f71eddf58cfb'


This tag will stay the same until you delete the object. Now you close FC and start it again. That object will get a different uuid on restoring, this new uuid will remain the same until you delete the object or close FC.

This uuid is not Sketch specific, but FC global, you won't find a repeated number in any other geometry in FC.

Tomorrow (v.19): If I manage to make Python defined geometry extensions, you will be able to associate whatever you like to a Sketcher Geometry AND this will be serialized.

This is an example of how this could work (the extension is NOT Python defined in this example):
example

Maybe Tomorrow (v.19): Maybe we get some ways to make a geometry not move at all.

I think I had a request to make the tag consistent (for Sketch geometries) and survive file open and close :)

I try methods to record these tags and upon file reopen, to match the id against the old and new tag - but this is tedious and make the whole process slow.

I know Realthundar have something in his branch that may tackle im another way, but it seems a consistent tag is more direct solution for sketch geometry.
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: Thu Jan 17, 2019 9:00 am This uuid is not Sketch specific, but FC global, you won't find a repeated number in any other geometry in FC.

Tomorrow (v.19): If I manage to make Python defined geometry extensions, you will be able to associate whatever you like to a Sketcher Geometry AND this will be serialized.

This is an example of how this could work (the extension is NOT Python defined in this example):
example
This is exactly what I need. Using existing constraints (like microelly outlined) or reference constraints (like paullee suggested) is certainly less preferable. I don't care what happens to the point - whether it gets moved, re-ordered, or deleted. I only care that, so long as it exists, I can identify it without fail using an identifier that is serializable and unique within the scope of the sketch.

In fact, now that I think of it, it's likely going to be necessary to be able to apply a name for every point in template sketches like this... Then I can use the vertex name to provide names for loft edges in the 3D model.

So is your example serializable at the moment? Can I use it in the interim until geometry extensions get figured out? (BTW, I thought geometry extensions were a really fantastic idea when I first read your post!)
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 (Transportation Engineering)

Post by abdullah »

paullee wrote: Thu Jan 17, 2019 11:31 am
I think I had a request to make the tag consistent (for Sketch geometries) and survive file open and close :)

I try methods to record these tags and upon file reopen, to match the id against the old and new tag - but this is tedious and make the whole process slow.

I know Realthundar have something in his branch that may tackle im another way, but it seems a consistent tag is more direct solution for sketch geometry.
I am not sure I understand all the consequences/implications of serializing a uuid and restore it in the current implementation. I tend to think I will get into trouble (get a higher chance of the new uuids not being unique). This I will have to study and understand first.

A good method for recording whatever together with a geometry will be geometry extensions.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Civil engineering feature implementation (Transportation Engineering)

Post by abdullah »

Joel_graff wrote: Thu Jan 17, 2019 1:20 pm
This is exactly what I need. Using existing constraints (like microelly outlined) or reference constraints (like paullee suggested) is certainly less preferable. I don't care what happens to the point - whether it gets moved, re-ordered, or deleted. I only care that, so long as it exists, I can identify it without fail using an identifier that is serializable and unique within the scope of the sketch.

In fact, now that I think of it, it's likely going to be necessary to be able to apply a name for every point in template sketches like this... Then I can use the vertex name to provide names for loft edges in the 3D model.

So is your example serializable at the moment? Can I use it in the interim until geometry extensions get figured out? (BTW, I thought geometry extensions were a really fantastic idea when I first read your post!)
The uuid is not serializable. See reply to paullee.

To be honest with you, I would center in another part of the development until the geometry extensions get merged for two reasons: 1) Geometry extensions will allow you to have whatever you want to have, 2) It is likely that together or immediately after the geometry gets merged, I will include part of the Realthunders idea, which will most likely provide you with a sketch geometry id.

If you do not feel like waiting, of course, you may try to adapt the existing uuid, but it is not going to be straightforward (serialisation), I fear.
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: Sat Jan 19, 2019 4:22 pm To be honest with you, I would center in another part of the development until the geometry extensions get merged for two reasons: 1) Geometry extensions will allow you to have whatever you want to have, 2) It is likely that together or immediately after the geometry gets merged, I will include part of the Realthunders idea, which will most likely provide you with a sketch geometry id.

If you do not feel like waiting, of course, you may try to adapt the existing uuid, but it is not going to be straightforward (serialisation), I fear.
I can probably wait. There's plenty on the to-do list for the moment, anyway. :) All the same, I could use constraints as a proxy as an interim solution, if I really need to test that before geometry extensions are ready.
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 (Transportation Engineering)

Post by Kunda1 »

The US numbered highway system in numerical order

Image
...and now back to your regular scheduled thread!
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: Wed Jan 30, 2019 3:04 am The US numbered highway system in numerical order
That's fantastic! :shock:

It's interesting to see the progression from east to west. Thanks for that!
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