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