Trails Workbench (Transportation and Earthwork Workbench)

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!
paullee
Posts: 2322
Joined: Wed May 04, 2016 3:58 pm

Re: Geomatics Workbench

Postby paullee » Sat Sep 21, 2019 8:08 pm

bidandou wrote:
Sat Sep 21, 2019 7:45 pm

should install requests module

Code: Select all

pip install requests
Also all the fixes made by HakanSeven in Geomatics WB are now available in GeoData (a pull request has been created)
Thanks maintaining this WB and looking into this problem :)

Realised 'request' should be kind of python module, but seem haven't found any missing in Fedora 30... no really idea which one is needed.

Installed (being told a few of them had been installed)... same result
...
Screenshot from 2019-09-22 04-02-40.png
Screenshot from 2019-09-22 04-02-40.png (230.87 KiB) Viewed 427 times
bidandou
Posts: 7
Joined: Sat Sep 07, 2019 9:35 pm

Re: Geomatics Workbench

Postby bidandou » Sat Sep 21, 2019 8:24 pm

Should be this one I suppose
Capture d’écran de 2019-09-21 21-20-25.png
Capture d’écran de 2019-09-21 21-20-25.png (64.15 KiB) Viewed 421 times
paullee
Posts: 2322
Joined: Wed May 04, 2016 3:58 pm

Re: Geomatics Workbench

Postby paullee » Sun Sep 22, 2019 12:13 am

Thanks ... should have installed something similar on Fedora30 ...

Code: Select all

[paullee@localhost ~]$ sudo dnf install python2-requests.noarch python3-requests.noarch
...

Package python2-requests-2.21.0-2.fc30.noarch is already installed.
Package python3-requests-2.21.0-2.fc30.noarch is already installed.
Dependencies resolved.
Nothing to do.

User avatar
HakanSeven12
Posts: 758
Joined: Wed Feb 06, 2019 10:30 pm

Re: Geomatics Workbench

Postby HakanSeven12 » Wed Dec 11, 2019 9:54 am

No need scipy for triangulation anymore.
paullee
Posts: 2322
Joined: Wed May 04, 2016 3:58 pm

Re: Geomatics Workbench

Postby paullee » Tue Dec 17, 2019 7:55 pm

Thanks, somehow would attempt again to see if it works on Fedora 30.
paullee
Posts: 2322
Joined: Wed May 04, 2016 3:58 pm

Re: Geomatics Workbench

Postby paullee » Tue Dec 17, 2019 7:59 pm

Joel_graff wrote:
Sun Aug 04, 2019 2:11 am
HakanSeven12 wrote:
Fri Aug 02, 2019 12:00 pm
I think FreeCAD need a fix that works for all workbenchs.
I agree, but this is a problem at the scenegraph level - Coin3D uses single-precision floating point and since the next option (OpenSceneGraph) is the same, there's no way to really fix it.

The solution, if it can be accomplished, lies in data segmentation, I think. And I think how the data gets divided up really depends on the type of modeling that's being done. I could be wrong about that, though.

In any case, before a general solution can be proposed for FreeCAD, it needs to be prototyped. And really, I think this problem is really limited to the sort of datasets that you and I work with - geospatial stuff. So if a solution is to be implemented, it should be done here.

In any case, I'm willing to at least kick it around a bit and see if I can make something work - but I need your dataset to do that - and maybe an example post, showing exactly where the errors appear.
Read this thread again and realize this underlying problem - anything @wmayer @yorik can do about this?

I remember I tried to place some Arch Objects at 'real world coordinate' and probably due to same underlying problem, there was weird result.

So it is fundamental if FC can be used at 'real world coordinate' ?
User avatar
Joel_graff
Posts: 1717
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Geomatics Workbench

Postby Joel_graff » Tue Dec 17, 2019 8:58 pm

paullee wrote:
Tue Dec 17, 2019 7:59 pm
Read this thread again and realize this underlying problem - anything @wmayer @yorik can do about this?

I remember I tried to place some Arch Objects at 'real world coordinate' and probably due to same underlying problem, there was weird result.

So it is fundamental if FC can be used at 'real world coordinate' ?
The only way to manage the issue is to "normalize" coordinates to within single-precision limits (I forget exactly what those are atm). That means determining an "offset" position for those coordinates and setting a placement at that position, then locating the larger coordinates relative to that placement. Of course, if the placement is too large, then it needs to be offset relative to another placement and so on.

Whether or not this problem is worth solving internally in FC is certainly a matter of valid use cases. FC has been in existence for nearly 20 years and I have not seen this use case come up in the forum archives (which date back to 2011), so it has to be rare. Still having a robust, standardized approach to handle coordinate systems that exceed SP limits would be nice. :)
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: 758
Joined: Wed Feb 06, 2019 10:30 pm

Re: Geomatics Workbench

Postby HakanSeven12 » Tue Dec 17, 2019 9:04 pm

Joel_graff wrote:
Tue Dec 17, 2019 8:58 pm
The only way to manage the issue is to "normalize" coordinates to within single-precision limits (I forget exactly what those are atm). That means determining an "offset" position for those coordinates and setting a placement at that position, then locating the larger coordinates relative to that placement. Of course, if the placement is too large, then it needs to be offset relative to another placement and so on.

Whether or not this problem is worth solving internally in FC is certainly a matter of valid use cases. FC has been in existence for nearly 20 years and I have not seen this use case come up in the forum archives (which date back to 2011), so it has to be rare. Still having a robust, standardized approach to handle coordinate systems that exceed SP limits would be nice. :)
I agree
paullee
Posts: 2322
Joined: Wed May 04, 2016 3:58 pm

Re: Geomatics Workbench

Postby paullee » Wed Dec 18, 2019 4:46 am

Joel_graff wrote:
Tue Dec 17, 2019 8:58 pm
Whether or not this problem is worth solving internally in FC is certainly a matter of valid use cases. FC has been in existence for nearly 20 years and I have not seen this use case come up in the forum archives (which date back to 2011), so it has to be rare. Still having a robust, standardized approach to handle coordinate systems that exceed SP limits would be nice. :)
Thanks taking time to explain.

In architural design, we used to put the layout over survey map which is usually prepare according to ' real world coordinates'. We can thus read the coordinates of a building corner , grid for setting-out purpose, no problen in Autocad so far.

I thought for your civil . transportation design, you need thsame informatiom ?
User avatar
Joel_graff
Posts: 1717
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Geomatics Workbench

Postby Joel_graff » Wed Dec 18, 2019 12:26 pm

paullee wrote:
Wed Dec 18, 2019 4:46 am
I thought for your civil . transportation design, you need thsame informatiom
Yup. Hakan and I are pretty much the only use case for large-scale coordinate systems around here. Which leaves it up to us to fix it. :)

But it's good you mention your need as well. You shouldn't have to work too hard to solve your situation, as I suspect you don't have to produce large terrain maps like the Geomatics workbench would, but I still think it's a good idea to lobby for an internal FC approach to solving this issue.

I've tried to come up with a way to handle large coordinate systems seamlessly in FC (that could be incorporated into the core) and I haven't really been successful...
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