FreeCAD Trails Workbench (Transportation and Geomatics)

[paullee]

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 (230.87 KiB) Viewed 1718 times

[bidandou]

Should be this one I suppose

Capture d’écran de 2019-09-21 21-20-25.png (64.15 KiB) Viewed 1712 times

[paullee]

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.

[HakanSeven12]

No need scipy for triangulation anymore.

[paullee]

Thanks, somehow would attempt again to see if it works on Fedora 30.

[paullee]

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' ?

[Joel_graff]

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.

[HakanSeven12]

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]

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 ?

[Joel_graff]

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...