Civil engineering feature implementation (Transportation Engineering)
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
Be nice to others! Read the FreeCAD code of conduct!
- Joel_graff
- Veteran
- Posts: 1949
- Joined: Fri Apr 28, 2017 4:23 pm
- Contact:
Re: Civil engineering feature implementation (Transportation Engineering)
So I just implemented basic LandXML support for horizontal alignments *only*. That was no small feat. Still, I have a reasonably good implementation for managing both importing and exporting data from / to LandXML. Note that it won't generate clothoids at the moment.
It's based on a Py3 / Qt5 build of FreeCAD and is not backwards compatible with Py2. Given the recent issues with libexpat binary incompatibilities between coin and debian, it may not run on some distros.
@microelly2 - I'm open to using a custom XML tool that imports and exports XML formats, but it needs to support pretty-printing as well. At the moment, I'm happy to just let the libexpat issue solve itself eventually, but if you have an interest in more fully developing your XML parser, I'll gladly test it. I have no issue reducing external dependencies.
At this point, I'm debating where to go next with horizontal alignments. That is, I feel I need to provide some creation tools for that without relying on the Sketcher as I initially planned, since it proves to be unreliable at larger scales.
That said, I see three primary alignment creation workflows:
1. Generation of an alignment from a series of existing, tangentially-connected lines and arcs
2. Generation of an alignment from an existing spline
3. Generation of an alignment using specific tools.
Note: geometry could be generated from the Sketcher, but it would require sketching at a much smaller scale, then scaling up after the fact.
Also:
The first two options would yield a separate spline which represents the actual alignment. The source geometry (whether arcs / lines or a spline) would be entirely separate and not parametrically linked. Changes to the source geometry would not update the result unless the user specifically regenerated the alignment. This is useful for creating an ad-hoc alignment (without really doing any engineering), or importing an existing alignment from another file and doing a one-time conversion to a FreeCAD-based horizontal alignment.
The third option would provide tools to create an alignment directly - thus the editing is done 'on the spline', so to speak. That is, changes that are made with the tools automatically update the spline - no separate geometry required. This option will take the most time. Not sure how I feel about tackling that at the moment. The first two options seem a little more approachable since they don't require managing as much user interaction.
It's based on a Py3 / Qt5 build of FreeCAD and is not backwards compatible with Py2. Given the recent issues with libexpat binary incompatibilities between coin and debian, it may not run on some distros.
@microelly2 - I'm open to using a custom XML tool that imports and exports XML formats, but it needs to support pretty-printing as well. At the moment, I'm happy to just let the libexpat issue solve itself eventually, but if you have an interest in more fully developing your XML parser, I'll gladly test it. I have no issue reducing external dependencies.
At this point, I'm debating where to go next with horizontal alignments. That is, I feel I need to provide some creation tools for that without relying on the Sketcher as I initially planned, since it proves to be unreliable at larger scales.
That said, I see three primary alignment creation workflows:
1. Generation of an alignment from a series of existing, tangentially-connected lines and arcs
2. Generation of an alignment from an existing spline
3. Generation of an alignment using specific tools.
Note: geometry could be generated from the Sketcher, but it would require sketching at a much smaller scale, then scaling up after the fact.
Also:
The first two options would yield a separate spline which represents the actual alignment. The source geometry (whether arcs / lines or a spline) would be entirely separate and not parametrically linked. Changes to the source geometry would not update the result unless the user specifically regenerated the alignment. This is useful for creating an ad-hoc alignment (without really doing any engineering), or importing an existing alignment from another file and doing a one-time conversion to a FreeCAD-based horizontal alignment.
The third option would provide tools to create an alignment directly - thus the editing is done 'on the spline', so to speak. That is, changes that are made with the tools automatically update the spline - no separate geometry required. This option will take the most time. Not sure how I feel about tackling that at the moment. The first two options seem a little more approachable since they don't require managing as much user interaction.
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
pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
- HakanSeven12
- Veteran
- Posts: 1481
- Joined: Wed Feb 06, 2019 10:30 pm
Re: Civil engineering feature implementation (Transportation Engineering)
FinallyJoel_graff wrote: ↑Tue Apr 09, 2019 4:05 pm At this point, I'm debating where to go next with horizontal alignments. That is, I feel I need to provide some creation tools for that without relying on the Sketcher as I initially planned, since it proves to be unreliable at larger scales.
I have a problem. When I open FC give me this
During initialization the error module 'Resources' has no attribute '__file__' occurred in C:\Users\Hakan\Desktop\FreeCAD 0.19\Mod\Transportation\InitGui.py
Please look into the log file for further information
OS: Windows 10
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.16267 (Git)
Build type: Release
Branch: master
Hash: ddb335cfe057336f1958d68126bb0471328d735c
Python version: 3.6.6
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: Turkish/Turkey (tr_TR)
Support me: Hakan Seven on Patreon
Modern UI: Modern UI on FreeCAD Forum
Trails Workbench: Trails Workbench on FreeCAD Forum
Modern UI: Modern UI on FreeCAD Forum
Trails Workbench: Trails Workbench on FreeCAD Forum
- Joel_graff
- Veteran
- Posts: 1949
- Joined: Fri Apr 28, 2017 4:23 pm
- Contact:
Re: Civil engineering feature implementation (Transportation Engineering)
Odd.
The __file__ attribute simply returns the complete filepath of the module.
Try typing the following in the Python console:
You should see something like:
That reminds me, I need to add back that extra layer of namespace protection...
The __file__ attribute simply returns the complete filepath of the module.
Try typing the following in the Python console:
Code: Select all
>>> import Resources
>>> Resources.__file__
Code: Select all
'C:\\Users\\username\\AppData\\Roaming\\FreeCAD\\Mod\\freecad-transportation-wb\\Resources\\__init__.py'
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
pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
Re: Civil engineering feature implementation (Transportation Engineering)
Always use a prefix. Such as using TransportationResources.py instead of Resources.py. FreeCAD developers basically share FreeCAD and prefixing is currently the predominant and rather effective strategy, on how to avoid name clashes. Note that i recommend you use such strategy everywhere. Naming commands, icon file names ... You could port Transportation module to use the new module import style (you should still prefix things like icon file names though):Joel_graff wrote: ↑Tue Apr 09, 2019 7:30 pm That reminds me, I need to add back that extra layer of namespace protection...
https://github.com/FreeCAD/Workbench-Starterkit
P.S. If you have more question about the new import style modules, best to ask @looo.
- Joel_graff
- Veteran
- Posts: 1949
- Joined: Fri Apr 28, 2017 4:23 pm
- Contact:
Re: Civil engineering feature implementation (Transportation Engineering)
Microelly set it up orginaly as t'transportation-wb' for the root module. I moved out of it because it was too polluted with code I didn't use and I didn't like the long name. I plan on renaming it to something shorter and more memorable and using that as the prefix for the workbench. Not sure what you're referring to about the new naming style of modules, though...triplus wrote: ↑Tue Apr 09, 2019 9:26 pm Always use a prefix. Such as using TransportationResources.py instead of Resources.py. FreeCAD developers basically share FreeCAD and prefixing is currently the predominant and rather effective strategy, on how to avoid name clashes. Note that i recommend you use such strategy everywhere. Naming commands, icon file names ... You could port Transportation module to use the new module import style (you should still prefix things like icon file names though):
https://github.com/FreeCAD/Workbench-Starterkit
P.S. If you have more question about the new import style modules, best to ask @looo.
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
pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
Re: Civil engineering feature implementation (Transportation Engineering)
There was a lengthy discussion:Joel_graff wrote: ↑Tue Apr 09, 2019 11:20 pm Not sure what you're referring to about the new naming style of modules, though...
https://forum.freecadweb.org/viewtopic.php?f=10&t=21128
And the result was:
https://github.com/FreeCAD/Workbench-Starterkit
Some examples:
https://github.com/FreeCAD/freecad.plot
https://github.com/FreeCAD/freecad.ship
- Joel_graff
- Veteran
- Posts: 1949
- Joined: Fri Apr 28, 2017 4:23 pm
- Contact:
Re: Civil engineering feature implementation (Transportation Engineering)
So.. I still need a name for the workbench. Something slightly shorter than 'transporation-wb' for namespacing purposes.
A few I and others liked:
A few I and others liked:
- Roads / Roadways
- Roadrunner
- Trails / Trailways (Trails could be a road, a railroad, or some other path)
- Edsel
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
pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
- Joel_graff
- Veteran
- Posts: 1949
- Joined: Fri Apr 28, 2017 4:23 pm
- Contact:
Re: Civil engineering feature implementation (Transportation Engineering)
Gee. That's really helpful.triplus wrote: ↑Tue Apr 09, 2019 11:34 pm And the result was:
https://github.com/FreeCAD/Workbench-Starterkit
Some examples:
https://github.com/FreeCAD/freecad.plot
https://github.com/FreeCAD/freecad.ship
Anyway, I'm a bit confused still. It looks like the standard workbench structure moving forward will be /.FreeCAD/Mod/freecad/my_workbench, correct?
So every workbench in the 'Mod' folder will live under the 'freecad' subfolder?
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
pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
Re: Civil engineering feature implementation (Transportation Engineering)
It's your baby, therefore you get to name it. Choose the name you feel best describes the module purpose, or just use some name you like, and basically that is your namespace.
P.S. As for the new import style modules. Initially the plan was to put them in Ext folder. But somehow they still ended up working, when located in Mod folder and installed through an Addon manager. Therefore think of it you are still a pioneer, going down that road. Likely it depends, on the complexity of the module. If there is a rather small amount of .py files involved and all dependencies are provided in standard Linux, macOS and Windows FreeCAD binaries. For that i don't feel you need new import style module. Unless we decide at some point and depreciate the current (i guess the old) way of doing things.
P.S. As for the new import style modules. Initially the plan was to put them in Ext folder. But somehow they still ended up working, when located in Mod folder and installed through an Addon manager. Therefore think of it you are still a pioneer, going down that road. Likely it depends, on the complexity of the module. If there is a rather small amount of .py files involved and all dependencies are provided in standard Linux, macOS and Windows FreeCAD binaries. For that i don't feel you need new import style module. Unless we decide at some point and depreciate the current (i guess the old) way of doing things.
- HakanSeven12
- Veteran
- Posts: 1481
- Joined: Wed Feb 06, 2019 10:30 pm
Re: Civil engineering feature implementation (Transportation Engineering)
Joel_graff wrote: ↑Tue Apr 09, 2019 7:30 pm Odd.
The __file__ attribute simply returns the complete filepath of the module.
Try typing the following in the Python console:
You should see something like:Code: Select all
>>> import Resources >>> Resources.__file__
That reminds me, I need to add back that extra layer of namespace protection...Code: Select all
'C:\\Users\\username\\AppData\\Roaming\\FreeCAD\\Mod\\freecad-transportation-wb\\Resources\\__init__.py'
Code: Select all
>>> import Resources
>>> Resources.__file__
Traceback (most recent call last):
File "<input>", line 1, in <module>
AttributeError: module 'Resources' has no attribute '__file__'
>>> dir(Resources)
['__doc__', '__loader__', '__name__', '__package__', '__path__', '__spec__']
>>>
Support me: Hakan Seven on Patreon
Modern UI: Modern UI on FreeCAD Forum
Trails Workbench: Trails Workbench on FreeCAD Forum
Modern UI: Modern UI on FreeCAD Forum
Trails Workbench: Trails Workbench on FreeCAD Forum