[OSM-dev] OsmAnd data corruption bug
Paul Norman
penorman at mac.com
Sat Mar 9 00:02:38 UTC 2013
Some recent rendering oddities on tile.openstreetmap.org were tracked
down to a changeset created by OsmAnd+ 1.0.0 beta.
The changeset in question is 15289464. What happened in this changeset
is OsmAnd reused the existing node 212751160 (from the TIGER import)
for a POI across the world. This caused the road to span the globe,
which is obviously problematic. I have reverted the changeset and re-
created the POI as node 2191602854
I do not know what the cause of this bug is. A potentially related
fact is a nearby POI is node 425502320 which is exactly 2*212751160.
This implies that some kind of bitshift or multiplication/division
error may be present.
The user agent used for the upload was "Dalvik/1.6.0 (Linux; U;
Android 4.0.4; S100 Build/IMM76I)" and the client made the following
requests in quick succession (approximately 1s apart)
/api/0.6/node/212751160
/api/0.6/changeset/create/
/api/0.6/changeset/15289464/upload
Another potential case of this bug is node 1015982684v3 in changeset
15265049 with the nearby node 2031965368 (2*1015982684).
A search shows that in some places in the OsmAnd code there is getId()
<< 1 , and other places getId(). Even if this bug is no longer
present, I cannot see that bitshifting IDs ever makes sense.
A related problem is that OsmAnd did not send a valid user-agent
identifying application or version. The API usage policy (http://
wiki.openstreetmap.org/wiki/
API_usage_policy#Technical_Usage_Requirements) requires that the user-
agent identify application and version, and this one does neither. The
server admins are not yet certain if it is necessary to block the user-
agent used here.
Could you please advise:
1. What versions of OsmAnd might have this bug if it has been fixed,
and when it will be fixed if it is still present
2. What user-agents do the bugged versions use, in case it becomes
necessary to block them
3. Was this data corruption issue a known issue? If so, please advise
the admins or dev@ in the future if it is necessary to block user-
agents corrupting data
Thanks,
Paul Norman
For the Data Working Group
More information about the dev
mailing list