1x1 meter square not big enough for -o osm ? about gpsbabel

[robertlipe]

"We don't know how to count that low!"

osm_name_from_wpt() is identifying all four point of this to be the same point. That's admittedly not very awesome, but it's also below the lower bounds of anything we care about. (See earlier on "not professional surveying" and "billions served".)

It's not even really some decision where we consciously enforce a lower bound. osm_name_from_wpt() returns the same value for all points and so the rest of the code ends up thinking we're a point instead of a box when it later attempts to split it into quadrants. Just bumping up the number of kept digits would slow the writer for everyone else.

If I were to take any action here, it would be to issue an error message and die upon detecting this case. Maybe we could detect this and collapse the wayward way[] into a node and not blow up performance. Maybe.

Honestly, unless this bothers someone from the OSM team badly enough for them to address this, I don's see this getting any traction.

[tsteven4]

As a workaround you can use the transform filter, which will have the side effect of naming the points. This will cause the osm writer to recognize them as being different. However, it will also cause the first and last point in the LinearRing to be transformed into different nodes.
./bld/gpsbabel -t -i kml -f x.kml -x transform,rte=trk,del -o osm -F -

[jidanni]

Maybe have an environment variable where people could increase the sensitivity without it wrecking it for others.

You got a whole field of catastral mapping that you're locking the application out of.

[jidanni]

Actually, if you think about it, here we're trying to perform a very valuable task. It doesn't involve interpolating the numbers at all. It's just rearranging them into a different format.

It's almost as if we need to encode our numbers or rot13 (probably wouldn't work) to keep the program from thinking too much about them.

Therefore there needs to be a mode, that just simply disengages any introspection of the numbers at all, allowing rearrangement of them, unhindered.

[jidanni]

#1048 (comment)

Six digits gets below .4mm, which is on on the order of the thickness of a nice business card. I can live with that.

Me too, but -o osm was blowing up at even one meter,

$ perl -wle 'printf "%.9f\n", 24.1817855 - 24.1817765;'
0.000009000
$ perl -wle 'printf "%.9f\n", 360/40000000;'
0.000009000

So something indeed is wrong.

[tsteven4]

OsmFormat::osm_name_from_wpt uses QString::arg(double) with one argument, which by default uses format specifier 'g' with a precision of -1. QLocale shows format specifier 'g' interprets precision as the "maximum number of significant digits (trailing zeroes are omitted)", and " any negative precision is ignored in favor of the default, 6." Thus OsmFormat::osm_name_from_wpt may not get us to six digits after the decimal point.

This can be verified by with the example from #1047 using qDebug to print the names:
"\u000124.1818\u0001120.864"
"\u000124.1818\u0001120.864"
"\u000124.1818\u0001120.864"
"\u000124.1818\u0001120.864"
"\u000124.1818\u0001120.864"

1-e6 degrees is 0.11 meters at the equator, not 0.4mm as stated in #1048.

I would suggest explicitly setting the fieldwidth, format and precision to 0, 'f', and 6 respectively when converting latitude and longitude in osm_name_from_wpt.

[tsteven4]

The current behavior is a result of 4673a257576e7bd5e August 4, 2013. Before that commit we used xasprintf with a format %f. From https://en.cppreference.com/w/cpp/io/c/fprintf I believe that would use 6 digits after the decimal point.