Great stuff!

there does not yet exist a single end-point to a service to simply reconstruct the history of any arbitrary object with regards to all 5 types of edits mentioned above.

The oshdb might offer what you’re looking for. ;)

Congratulations to you and the rest of the SotM-2018 team for organizing such a wonderful event. It will certainly not be easy to set up something similarly cool for next year’s State of the Map. ;)

Also good luck at your new job!

I’ve forwarded your question to the editor-layer-index repository on github: https://github.com/osmlab/editor-layer-index/issues/149#issuecomment-387666832

But the area actually contains an object that was modified in the changeset: https://www.openstreetmap.org/way/101781403 (a typo in the tag contact:website was fixed). Not sure why it doesn’t show up on “the changesets viewer in JOSM” (btw: never heard about this, is it a new plugin?) … maybe it’s a bug/deficiency on their part?

It could be improved by focusing on only data modified in the area.

@PierZen: I’m not sure if I got your message right, but the Latest-Changes tool should already do exactly what you suggested. Also, I can’t seem to get the mentioned changeset popping up when opening the latest-changes link you posted…

same here :-/

Yes, sure. But one of my main design goals for this tool was to avoid having to set up and run any kind of database containing the full OSM data, so that’s not really an option for me, unfortunately.

But if anyone out there already runs a (daily) updated OSM DB which could produce deltas of the counts of tags in their db (for little extra processing cost), please contact me – I’d love to use that data for updating the taghistory service.

@SafwatHalaby: yes, but regular planet diffs don’t contain all necessary data to keep this kind of data up to date (because they don’t include the tags the modified osm objects had before the diff). Overpass’ augmented diffs could in principle work, but they have other technical issues, see: https://github.com/tyrasd/taghistory/issues/10

Right. I’ve changed the wording now. :)

Btw: I managed to find the pre-rails ruby code of the website/api you pointed at earlier: https://trac.openstreetmap.org/browser/subversion/sites/www.openstreetmap.org/ruby/api/osm/dao.rb?rev=2808#L1062 which seems to correspond to OSM’s API version 0.3 (while the rails-port started at version 0.4 afaics).

Thanks for the clarification and background information, Richard! (But what exactly do you think is not quite accurate in my text?)

Very impressive!

Btw: 7 decimal digits already correspond to about 1.1cm.

Aha! Here we probably have our bad boy: https://www.openstreetmap.org/way/512314784 (a building with one node in Vienna and the rest of its nodes in Zambia).

@maxerickson: If that was the case, could it also explain that this glitch is only visible on zoom 19 and not on any other zoom level?

wow, that’s odd.

The brown area has an apparently horizontal edge (at a latitude of approximately 40.13558) when you follow it from here eastwards (up until a longitude of ~27.47677), and a regular zig-zag structure in southwards direction. Towards the north-west it looks “randomly glitchy”.

Very cool, but a main killer feature from the original walking papers is missing here (as far as I can see): the ability to automatically georeference scanned-in walking papers to quickly have them in an OSM editor as a background layer.

@Jedrzej Pelka: You mean the short flash of a black screen when switching layers, right? Does it look better now? I’ve now actually added in a bit of fading to make the layer switching smoother.

@imagico: Right. But I’m not sure if Joost (or anyone else) has already had time to actually look into it, though.

@Zverik yeah, I think so.

@CloCkWeRX: There’s already a ticket for that on github: #219.

JOSM’s ContourMerge plugin can also be quite helpful in such situations (especially if you want to avoid creating “unnecessary” multipolygon relations for areas without actual holes): First, split the forest very roughly along the river, unglue the middle section and use ContourMerge to join the two forest halves with the respective riverbank outlines.

PS: For those interested in the technical implementation details: Recently I’ve switched out Vladimir Agafonkin’s rbush library with his kdbush implementation, which offers even faster indexing, resulting shaving off another few seconds of startup times. Awesome stuff!