OpenStreetMap
Beware: version 3.14 (and earlier) of OsmAnd for iOS moves OSM POIs without telling you
Posted by stragu on 15 September 2020 in English.If you are a user of OsmAnd Maps for iOS, you might have to refrain from using the current version (3.14) to edit OSM POIs. I just figured out that, after editing a bunch of POI opening hours in my suburb, the changeset also affected the locations of the POIs, even though I did not touch that.
It looks like the editor rounds the coordinates of the POIs to 6 significant figures, which might look like a move of only a few meters on the map, but the changes get more drastic as you move away from the equator and the meridian. I suspect people editing in Oceania and East Asia will see more obvious changes.
In this picture, from data in eastern so-called Australia, the arrowheads roughly show where the POIs should be, and the green line shows the longitude where they were moved:
OSMCha shows that close to 1000 changesets were created with version 3.14. Note that not all changesets will need fixing, because some of them will only remove a feature, and I don’t think polygons are moved. But we might need to review further.
However, version 3.14 is not the only one affected: at least versions 3.10, 3.11, 3.12, 3.13 of OsmAnd iOS also have the bug. See for example this node’s history, in which version 3.13 of OsmAnd iOS rounded the coordinates:
I need to check with versions earlier than 3.10 still, but thought I’d put the word out already. If you use OsmAnd on iOS to edit OSM data, you might want to review your edits with OSMCha by using filters: use “osmand maps” in the “Editor” field. You might also want to stick to GoMap to edit OSM data until a new version of OsmAnd is released with a fix.
The OsmAnd iOS bug report is located here: https://github.com/osmandapp/OsmAnd-iOS/issues/833
Discussion
Comment from stephan75 on 15 September 2020 at 19:03
So what about BLOCKING all affected Osmand iOS apps according to its version numbers from uploading to the OSM API?
IMHO urgently needed!!
Comment from SimonPoole on 15 September 2020 at 21:11
@stephan75 If the version isn’t reported in the user agent on upload there is no easy way to do that.
Comment from stragu on 16 September 2020 at 00:17
@SimonPoole the changeset key “created_by” does get tagged with “OsmAnd Maps 3.xx”, so it could be done. You can see it by using the “Editor” tag in OSMCha.
Comment from tyr_asd on 16 September 2020 at 08:15
hmm, very strictly speaking, wouldn’t this be a reason to block the application because of violating the API usage policy (https://operations.osmfoundation.org/policies/api/):
Comment from SimonPoole on 16 September 2020 at 10:13
@tyr_asd “if” is the key, it just isn’t clear right now if it includes the version or not. Regardless of ToU compliance or none, version specific blocking currently can only happen if the user agent includes the version (and that it is running on iOS I suppose), as there is no API internal way of blocking apps based on a version string or similar.
Comment from tyr_asd on 16 September 2020 at 11:52
Oh, I misread your message then. But if I’m not mistaken the corresponding code would be at
OAOpenStreetMapRemoteUtil.mm#L79and from what I can see there, it looks as if “OsmAndiOS” really does not set the its version in the User-Agent header.I’ve opened https://github.com/osmandapp/OsmAnd-iOS/issues/845 for this.
Comment from stragu on 19 September 2020 at 10:22
The issue described here was fixed: https://github.com/osmandapp/OsmAnd-iOS/issues/833 It is now available in the 3.80 release, so everyone using OsmAnd to edit OSM data should update ASAP. I just tested it and it does not round the coordinates anymore: osm.org/node/3355055357
Comment from SomeoneElse on 19 September 2020 at 11:08
A restriction at the API level, even if technically possible, would be a bit of a blunt instrument and can’t easily explain to a user what they need to do to resolve their problem.
As stragu mentioned above, you can identify problem changesets via OsmCha. I’ve not checked all possible values, but can’t see any obvious recent problems. If anyone finds a user still using an old version and creating problem data please create a ticket with the DWG (via email or the report button) so that we can explain the problem to them and help them to upgrade.
There certainly are problems in the data still, and some of them aren’t easily fixable (for example, the v1 of osm.org/node/7389230651/history was via the problem version so there’s no way of knowing where that well really is). Some of the node moves will be fixable though - if anyone needs any help identifying problems and undoing problem node moves please ask.
Best Regards,
Andy (from the DWG)