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
Posts: 1851
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Civil engineering feature implementation (Transportation Engineering)

Postby Joel_graff » Tue Apr 09, 2019 4:05 pm

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.
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
HakanSeven12
Posts: 937
Joined: Wed Feb 06, 2019 10:30 pm

Re: Civil engineering feature implementation (Transportation Engineering)

Postby HakanSeven12 » Tue Apr 09, 2019 7:10 pm

Joel_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.
Finally :)

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)
User avatar
Joel_graff
Posts: 1851
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Civil engineering feature implementation (Transportation Engineering)

Postby Joel_graff » 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:

Code: Select all

>>> import Resources
>>> Resources.__file__
You should see something like:

Code: Select all

'C:\\Users\\username\\AppData\\Roaming\\FreeCAD\\Mod\\freecad-transportation-wb\\Resources\\__init__.py'
That reminds me, I need to add back that extra layer of namespace protection... :roll:
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
triplus
Posts: 9475
Joined: Mon Dec 12, 2011 4:45 pm

Re: Civil engineering feature implementation (Transportation Engineering)

Postby triplus » Tue Apr 09, 2019 9:26 pm

Joel_graff wrote:
Tue Apr 09, 2019 7:30 pm
That reminds me, I need to add back that extra layer of namespace protection... :roll:
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.
User avatar
Joel_graff
Posts: 1851
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Civil engineering feature implementation (Transportation Engineering)

Postby Joel_graff » Tue Apr 09, 2019 11:20 pm

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.
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...
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
triplus
Posts: 9475
Joined: Mon Dec 12, 2011 4:45 pm

Re: Civil engineering feature implementation (Transportation Engineering)

Postby triplus » Tue Apr 09, 2019 11:34 pm

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...
There was a lengthy discussion:

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
User avatar
Joel_graff
Posts: 1851
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Civil engineering feature implementation (Transportation Engineering)

Postby Joel_graff » Wed Apr 10, 2019 1:22 pm

So.. I still need a name for the workbench. Something slightly shorter than 'transporation-wb' for namespacing purposes.

A few I and others liked:

  • Roads / Roadways
  • Roadrunner
  • Trails / Trailways (Trails could be a road, a railroad, or some other path)
  • Edsel
So far as trademarks go, I think we can avoid the issue by prepending the name formally with 'FC' or 'FreeCAD' and just use the name itself internally. For example, 'FreeCAD-Trails' would be the workbench name, and 'Trails' would be the module namespace.
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
Joel_graff
Posts: 1851
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Civil engineering feature implementation (Transportation Engineering)

Postby Joel_graff » Wed Apr 10, 2019 1:33 pm

Gee. That's really helpful. :)

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
triplus
Posts: 9475
Joined: Mon Dec 12, 2011 4:45 pm

Re: Civil engineering feature implementation (Transportation Engineering)

Postby triplus » Wed Apr 10, 2019 10:22 pm

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.
User avatar
HakanSeven12
Posts: 937
Joined: Wed Feb 06, 2019 10:30 pm

Re: Civil engineering feature implementation (Transportation Engineering)

Postby HakanSeven12 » Thu Apr 11, 2019 6:18 am

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:

Code: Select all

>>> import Resources
>>> Resources.__file__
You should see something like:

Code: Select all

'C:\\Users\\username\\AppData\\Roaming\\FreeCAD\\Mod\\freecad-transportation-wb\\Resources\\__init__.py'
That reminds me, I need to add back that extra layer of namespace protection... :roll:

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__']
>>>