geometry of features stores more digits than osm server - the rounding at the upload causes a shift of nodes

[bo.goiny@…]

when creating features in JOSM, the coordinates have 11 decimal places. but when i download features from OSM Server, they only have 7 decimal places. because of the rounding to 7 decimal places at the upload, there is a small shift for every node, depending on the amount of rounding. this also changes the angles of features, so that for example a buildings has no longer 90° angles.

i think this is the source of the problem, that sometimes the extrude tool for example has problems.
also, squaring tools like mapathoner plugin need to work with tolerances to exclude these small angle differences from 90° in their selection.

if it would be possible to reduce the decimal places in JOSM to 7, the upload might not cause these small placement changes for every node due to the rounding.

[taylor.smock]

The OSM server only keeps 7 decimal places. For the full details, see ​osmwiki:Node#Structure.

The OSM server essentially does the following:

    int convertIncomingCoordinate(double incomingLatOrLon) {
        double multiplied = incomingLatOrLon * 1e7;
        int rounded = (int) Math.round(multiplied);
        return rounded;
    }

The reason why it does this is for both precision issues (IEEE 32bit floating point data types lose accuracy, 1e-5 at highest latitudes) and storage reasons.
For reference, the 32bit integers they are talking about on the wiki page go from -2,147,483,648 to 2,147,483,647. Since we can go to -180 and 180 degrees, this means that there are 7 digits which can be used for the decimal portion of a lat/lon.

Again, we cannot fix this. This is an issue with the backend storage database. As noted in the wiki article, this is ±5.56595 mm for longitude at the equator. It will be less the further north/south you go.

See ​https://github.com/openstreetmap/openstreetmap-website/blob/master/db/structure.sql#L444-L445 for the database specification for the latitude/longitude values (they are integers).

[bo.goiny@…]

thank you taylor.smock for the fast answer!

i understand now, why there has to be 7 digits for the decimal portion and why this cant be changed.
i dont know if its even possible, im not an IT-specialist. my idea was, when creating a node in JOSM that they already have only 7 digits and not 11 for the decimal places. If that would work, the conversion of incoming coordinates would not lead to changes in rounding because all values would fit into the 32bit int range.

[taylor.smock]

If I am understanding what you want,

when creating a node in JOSM that they already have only 7 digits and not 11 for the decimal places

This is technically possible.
However, JOSM is (apparently) not used only for OpenStreetMap, and those other use cases might not be rounding to 7 digits. For example, when JOSM saves to file, we don't round. This allows other programs to convert the saved file into other formats, like geojson, which can be used in other applications.

Besides that, I would strongly prefer to keep as much accuracy/precision as possible for as long as possible. Some of the tools use the positions of other objects to create new nodes, and rounding to OSM precision would lead to new nodes potentially being off. Yes, there will be a shift from the conversion to 1e-7 precision, but that is (currently) the best option we have. We could probably avoid updating the location of nodes in the dataset if the differences is less than the server precision, but I'd rather show people what got saved.

[bo.goiny@…]

extrude tool fails on nearly square building

[anonymous]

okay yes i understand that the full accuracy should be kept. but maybe it could be an option in the "OSM Data" preferences.
it could be a checkmark to reduce accuracy to osm server standards to avoid nodeshifting.

i uploaded two jpg where you can see a small building where the extrude tool failed.

when validating osm data validators need to make all buildings square again before using extrude tool to adjust buildings or they have problems like in the pictures really often.

[taylor.smock]

That is a different problem.

You really should have opened a ticket along the lines of

After squaring a building and uploading, the downloaded building is not square enough for the extrude tool to avoid creating unnecessary nodes

[bo.goiny@…]

https://josm.openstreetmap.de/ticket/22460

thanks for your help.

i created a new ticket like you suggested.