Closed MaZderMind closed 11 years ago
They have been (mentioned on dev), http://lists.openstreetmap.org/pipermail/dev/2012-October/026049.html
Oh, thank you. I was not aware of the node->position().defined()
method which enables my client code to ignore those nodes (they can't be rendered on a map anyway). As osmium offers a way to handle this gracefully, it's probably not an issue with osmium, so I'll close this ticket.
Thanks for the help ;)
Hi
Brian DeRocher pointed me at an issue where strange lines occured on his history renderings.I followed the path of the bad data and found, that when reading the current history_2013-02-05_1701.osh.pbf you'll get millions of nodes with the invalid coordinate lon=214.7483647 lat=214.7483647
./osmium_debug history_2013-02-05_1701.osh.pbf | grep 214.748 -C 5 | less
gives us
The problem does not occur when reading the respective osh.bz2 file. Both files are from http://osm.personalwerk.de/full-experimental/ (the osh.bz2 beeing a copy of planet.osm.prg).
Taking a look at those specific node-versions shows, that at those node-versions don't have a location, because the redaction bot fiddled out, that the locations originate from a decliners account, while the tags are from an acceptor. So the full-history-dump contains nodes with tags but without (valid) coordinates.
Those nodes are represented in xml as
Which irritates the xml reader. As a small testcase I downloaded the respective way-history-xml from the api and tried to process it with osmium:
I'd be happily providing a patch, when I just hat an idea on how a library like osmium should work with such crippled nodes.
Those issues should probably be discussed over at dev@