[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)


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://
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


Paul Norman

For the Data Working Group

More information about the dev mailing list