I believe I've found a bug with how osmosis handles replication diffs,
control characters, and duplicate keys. Because it involves control
characters, this bug can't be seen by viewing the objects in the
browser, so I've supplied shell commands that will show them.

In changeset 90486873 a node was introduced with the tags

   <tag k="shelter_type" v="weather_shelter"/>
   <tag k="shelter_type^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?" v="lean_to"/>

where the ^? are the DEL character (U+0001). This was obviously not
what the user intended, but is valid OSM XML and correctly reproduced
by the API if you query for the node (e.g. with the shell command
`curl -s https://www.openstreetmap.org/api/0.6/node/7881523719/3 | less')

This was transmitted out in the minutely replication feed with sequence
number 004183898. If this is examined with
`curl -s https://planet.openstreetmap.org/replication/minute/004/183/898.osc.gz | zcat | less -p 90486873'
this reveals the XML

      <tag k="shelter_type" v="weather_shelter"/>
      <tag k="shelter_type" v="lean_to"/>

This XML does not contain the DEL characters, and has two keys which are
the same. We found this because it was resulting in a duplicate key
error, but aside from that Osmosis is producing results inconsistent
with what is in the database.


_______________________________________________
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osmosis-dev

Reply via email to