Hallo. Du meinst wahrscheinlich, dass die Layer nicht mehr im iD editor verfügbar sind? Das liegt kurz gesagt daran, dass es allgemein Bedenken gibt, ob die Lizenz der Luftbilder es erlaubt OSM Daten daraus abzuleiten. Für weitere Details, siehe z.B. https://community.openstreetmap.org/t/bayern-ab-01-01-2023-sind-viele-geobasisdaten-der-vermessungsverwaltung-kosten-frei-verfugbar-nutzbarkeit-fur-osm-ist-noch-zu-prufen/7051/162 oder https://github.com/osmlab/editor-layer-index/pull/2438#issuecomment-2304393789

@SomeoneElse: Yeah, (route) relations have been a bit neglected in iD in the past. Some bugs have already been addressed (e.g. https://github.com/openstreetmap/iD/issues/7653), but there is definitely still a bunch of work to do. Thanks for adding some suggestions for this already on github; let’s continue to discuss these ideas there. :)

Wow, this is amazing! Superb work, Daniel.

My code is now online. But I’m afraid that there is currently no downloadable OSHDB dataset available from https://downloads.ohsome.org/OSHDB/ to easily replicate this. :(

The ways would only be counted here if they match the given list of tag keys: So, road edits would not be counted, and building edits would only be included if they also have a tag like building:material.

PS: I’ve now also played around with the filters and have an extended version where changes are only considered when the respective change edits (or creates) at least one of the mentioned tags. The idea is to exclude large scale data clean up operations where only tags are touched which are not in the list of “to be considered local knowledge” tags (like this example changeset). You can find the results attached to the code snippet. Interestingly, the relative numbers in these result are again in the same ballpark to the numbers of the “simpler” analysis (maybe very slightly tending a bit more towards the “long tail”). I guess the most likely explanation is that the different mapper “types” (i.e. local knowledge mapper vs. data quality issue fixer) all follow a similar distribution with few heavy mappers and many mappers in a long tail. In retrospect, that should not be considered to be all too surprising, giving the nature of OSM. 😅

Hey Rubén. Thanks for sharing the code of your analysis. However, from what I can see, the results it produces are not quite accurate:

• First, you seem to be using a non-history OSM extract as the base of your study. By doing this you loose all but the last change to a particular OSM feature, when it has more than one change. This is going to bias the results towards contributors with many edits, as they are more likely to overwrite a change from another mapper. Also, this will result in an undercount of both the total number of changes and the number of mappers.
• A second thing I noticed is that you’re only considering OSM features mapped as nodes, while most of the tags you are looking at are typically also found on ways (e.g. amenity=school, amenity=hospital, etc.) and some are even almost exclusive to OSM ways (e.g. building:colour, roof:shape, etc.). My educated guess is that this omission will not incur a large bias towards any mapper type, but it would make comparing countries with each other more difficult (e.g. when different countries have different mapping conventions for either tagging addr:housenumber on the building outline way or as a separate node).

I’ve re-run the calculations on proper OSM history data (using the OSHDB) and came to the results posted below. Interestingly, while the absolute values are off by roughly a factor of two to three, the percentages in the results are not affected by that much.

Also, I took the liberty to add a few additional rows to the table for extra context:

The smoothness tag would probably be a of good use here.

@Matija Nalis, well, it still shows the history for all tags up to some time in 2018. But I guess that after 5 years the added usefulness of that partial data is quite limited.

Hi! iD maintainer here (thanks Samson for the ping, btw).

The 400 error could be a temporary error, but could also be caused by a bug in the iD editor. Pretty hard to diagnose from a distance. @La Chaussiere: Could you please forward me some additional details (e.g. which API request failed, the full error message, etc.) about the error, so I can take a deeper look into what could be the root cause here. You can send it to martin@raifer.tech or the email listed above (if you need assistance in getting these details, I can also give you a few pointers if needed).

That said, usually it is possible to restore the data after an unsuccessful upload and download the osmChange file on the upload form (see https://i.imgur.com/UzP7pqp.png) which contains all your data. This file can be used to upload your changes through JOSM if all else fails.

I’ve put some notes of the first meetup on the wiki: https://wiki.openstreetmap.org/wiki/ID/Monthly_Meetup/2023-02-20

The next edition will be on March 24 at 4pm UTC.

@KyZEN: The slippy map version on https://tyrasd.github.io/osm-node-density/ is updated yearly (the last update was in June/July 2022). To compare different years, use the layer selector on the top right of the page.

The Sketch Map Tool from HeiGIT might be a replacement for fieldpapers in the mid term. Compared to fieldpapers, currently the downsides are that it only produces single page maps, and the results of the scanned-in maps are GeoTiffs. These GeoTiffs can be opened in JOSM using the ImportImage plugin after renaming the file ending from .geotiff to .tiff.

FYI: the PR was merged today and will soon be used in iD. Thanks for the the initiative and for your patience.

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: https://wiki.openstreetmap.org/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. ;)