For reference: A similar proposal had been brought up in 2013. It was discussed mostly on the osm talk mailing list, as well as on github and in at least one meeting of the OSMF License Working Group.

Nice find and thanks for the fix!

it turns out to be the border of “Zone Strassendienst” (road maintenance area)

My guess would be that both the road maintenance area and the originally imported data from OSM are based on the same outdated/imprecise border data. Probably the boundary dataset from ISTAT (Italy’s national statistics agency) – I just checked and they still seem to have this “bug” in their data set even in their 2021 release.

Finding deleted data is difficult.

It’s actually not too hard to do using the ohsome API if you have some basic (Q)GIS skills:

• somehow get the bounding box of where you are looking for deleted objects (I always use Norbert Renner’s bbox tool)
• enter the bbox it in the elementsFullHistory/geometry ohsome API query; same for the time range and filter (I used geometry:polygon and building=* here)
• execute the query and save the resulting geojson
• open the geojson as a qgis layer, and activate the Temporal tab in the layer properties, the proper fields for start/end times should be automatically selected
• activate the temporal controller, and use the slider to look for map features which were deleted

it does seem like 8 years ago most of that hospital was mapped unsure when everything was deleted

I cannot find any hints of deleted hospital buildings in that area. How did you come to your conclusion @Rovastar?

Taginfo now also features historic development data in its new “chronology” tag (see https://blog.jochentopf.com/2020-11-08-10-years-of-taginfo.html) now. It’s limited to tag keys and the “most frequent tags”, but I think this should already solve most needs for current tag count statistics (and for the rest one can still use https://api.ohsome.org). PS: Taghistory’s web interface is updated now to also fetch taginfo’s chronology data if available.

Hallo Znaika! Manchmal dauert es einfach eine Weile bis Änderungen an den Kartendaten in allen Kartenstilen sozusagen “ankommen”. Laut dem wiki wird die OpenCycleMap “nur” alle 1 bis 2 Wochen aktualisiert: osm.wiki/Featured_tile_layers

Hab also einfach noch etwas Gedult. :)

Oh, I misread your message then. But if I’m not mistaken the corresponding code would be at OAOpenStreetMapRemoteUtil.mm#L79 and from what I can see there, it looks as if “OsmAndiOS” really does not set the its version in the User-Agent header.

I’ve opened https://github.com/osmandapp/OsmAnd-iOS/issues/845 for this.

the version isn’t reported in the user agent on upload

hmm, very strictly speaking, wouldn’t this be a reason to block the application because of violating the API usage policy (https://operations.osmfoundation.org/policies/api/):

Technical Usage Requirements […] Valid User-Agent identifying application and version.

The source site (planet.osm.org) is missing a swath of data from April 2013.

Interesting, and good to know. I guess it could have made sense to download and use the full changeset dump from https://planet.openstreetmap.org/planet/changesets-latest.osm.bz2, which doesn’t seem to be missing any changesets and would have been slightly quicker to download. ;)

I believe the query above is slightly misformated. It should probably read:

[out:json][timeout:25]; // fetch area “Rubano” to search in {{geocodeArea:Rubano}}->.searchArea; // gather results ( nwr["delivery:description:it"~".*COVID-19.*"](area.searchArea); ); // print results out body geom;

or use the following short link: https://overpass-turbo.eu/s/S0x

@lyx: It was actually the rather senior mapper who made this inappropriate reply: “Baloo Uriza” (formerly known as “Paul Johnson”). This cannot be seen very well on the OSM user interface, but via the XML returned by the notes API it is clear: osm.org/api/0.6/notes/1995084

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: osm.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?)