Modify

Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#5031 closed enhancement (invalid)

export .osm with consistent precision

Reported by: HamishB <hamish_b@…> Owned by: team
Priority: normal Milestone:
Component: Core Version: tested
Keywords: export Cc:

Description

(copied to a new wish from #4445 comment 2)

Hello,

when opening .osm files downloaded then exported using JOSM, Merkaartor, and Xapi I have noticed some differences that, when mixed, cause the Validator to fail to detect duplicate nodes. It's an ascii representation + floating point precision issue.

  • JOSM seems to export with %.9g (~1cm)
  • Merkaartor seems to save with %.8f (~1mm)
  • Xapi seems to export with %.7f (~1cm)

I would argue that %.9g is no good for JOSM as it changes the positional precision only for longitude, based on if you are 100 degrees east or west of England. %g maintains overall number of numbers, not number of decimal places.

Latitude (which could plausibly accept reduced precision near the poles) is always <100 so except for by the equator (<10deg) is slightly more consistent. Longitude precision varies by 4 orders of magnitude depending on if you are <1 deg, <10 deg, or <100 deg.

I suggest for JOSM, Merkaartor, and Xapi to all agree on a single print format, and for that format to be %.8f (slightly beyond what survey grade RTK GPS will give you, but no more as to avoid cluttering everyone's disks with geo-noise).

I take it the back-end database is PostGIS storing coords as sql type DOUBLE PRECISION?

(fwiw JOSM r3208 also fails to open the downloaded Merkaartor 0.14 .osm file due to missing version= tags in nodes, but I guess that is a Merk bug)

thanks,
Hamish

Attachments (0)

Change History (6)

comment:2 by jttt, 14 years ago

According to http://wiki.openstreetmap.org/wiki/API_v0.7#Better_precision, coordinates are saved in osm as 32bit integer (which is calculated by multiplying coordinate in double by 10 millions and rounding).

I think it would make sense to use the same format in .osm files.

in reply to:  2 comment:3 by HamishB <hamish_b@…>, 14 years ago

Replying to jttt:

According to http://wiki.openstreetmap.org/wiki/API_v0.7#Better_precision, coordinates are saved in osm as 32bit integer (which is calculated by multiplying coordinate in double by 10 millions and rounding).

ok, so that means for the current DB the appropriate format is 1e7 behind the decimal mark, aka "%.7f" for both lat and lon, right?

I think it would make sense to use the same format in .osm files.

Based on the (signed) 32bit int tip, I agree.

so storage space is -2147483647 to 2147483647 (aka -214 to 214 degrees; 16% unusable/wasted space). only possible gotcha is if someone has longitude data 0-360 instead of -180 to 180. (easy to fix corner case, n.b. commonly found in mapping of non-earth planets [for when OSM expands in future :) ])

thanks,
Hamish

in reply to:  description comment:4 by bastiK, 14 years ago

Resolution: invalid
Status: newclosed

Replying to Hamish <hamish_b@…>:

when opening .osm files downloaded then exported using JOSM, Merkaartor, and Xapi I have noticed some differences that, when mixed, cause the Validator to fail to detect duplicate nodes. It's an ascii representation + floating point precision issue.

  • JOSM seems to export with %.9g (~1cm)
  • Merkaartor seems to save with %.8f (~1mm)
  • Xapi seems to export with %.7f (~1cm)

This is not true (anymore (?)) for JOSM. Internally, it stores each coordinate as a double (8 bytes) and writes as many decimal places as needed to parse the very same double value when reading it in again. This is about 15 decimal places for nodes that have been added or moved in JOSM and exactly 7 decimal places for Nodes that are unmodified. (Note that trailing zeros are omitted.)

If we cut all values to %.7f, then save and reopen will not preserve the exact values. (OK, they are finally rounded when uploaded to the server, but anyway.)

So, I think the current behaviour is correct, for now.

comment:5 by anonymous, 14 years ago

Hi,

could you point me towards the code that handles this? I'd like to get my head around it more.

For me Java source code directory hierarchies are a bit of a mystery (although JOSM's doesn't look too bad) and I don't have a local checkout to grep through. the closest I got was this:

source:trunk/src/org/openstreetmap/josm/data/coor/Coordinate.java

thanks,
Hamish

comment:6 by bastiK, 14 years ago

trunk/src/org/openstreetmap/josm/io/OsmWriter.java#L117

This method is used to convert double to String.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.