Closed davmol closed 4 years ago
@davmol
Thanks for pointing out this issue. It has been fixed in some other branch but not the master.
I have just pushed a commit https://github.com/cyang-kth/fmm/commit/ff8bd8f49922999e7ed443f938ce843003802e2e to fix this issue by adding std::setprecision(8)
.
Now you should be able to see a much more precise result.
looking better now:
Matched geometry: LINESTRING(654157.67 5472517.8, ...) though due to the UTM system not every coordinate x,y has the same precision. Maybe it's better to give some more digits in precision and then give it a round to 2 decimals if the coordinate system is metric and maybe 4 if its in degrees?
@davmol
Currently, the projection of the coordinate system is not checked yet but defined by the user. As a lot of classes need to be redesigned to consider it automatically. Maybe it is better to add a parameter of precision to the export_wkt()
function with default value of 8 so that you can define your own precision if you want.
@davmol
The precision has been moved to the export_wkt as an argument in this commit aa587f51ffca932b080916a0712a519e92c06d9d. Try to pull the master branch and check if it works.
that seems like an appropriate solution. thank you!
Describe the bug The output of mgeom.export_wkt() and pgeom.export_wkt() for the metric epsg 32632 is very vague:
Matched geometry: LINESTRING(654158 5.47252e+06,654185 5.47249e+06,654225 5.47245e+06, ... )
X: 654158 meter Y: 5.47252e+06 meter = 5472520.0 meter
Expected behavior The output should also be applicable for metric coordinates and thus be rounded in a sub meter domain
Screenshots map: osm black line: network (not osm) blue dots: input wkt green dots: pgeom as dots red line: mgeom