Ideal ist, wenn du zusätzlich auf die OSM Wiki Seite mit der jew Lizenz-Freigabe verweist; das beantwortet dann für alle die Frage, ob wir die URLs auch nutzen dürfen.

Wenn die Layer in iD fehlen, nützlich sind und genutzt werden dürfen, ist das editor-layer-index Projekt auf github der beste Ort damit sie bald alle nutzen können.

Tipp für Deeplinks: die iD Version unter https://ideditor.netlify.app/ erzeugt links die du direkt aus der Adresszeile kopieren kannst.

Update: Henry tested the phone LiDAR workflow and documented it here: https://wilkinson.graphics/blog/2025-10-25-3d-mapping/

There’s also some discussion about it in this thread: https://en.osm.town/@tordans/115439288177284145

UPDATE: Last weekend, at the FOSSGIS 25-year event and in subsequent chats, I continued the discussion around this topic and want to add a few points:

It is, of course, correct and appropriate to describe datasets as different. What this is really about is how one dataset is presented as right and, as a consequence, the other as wrong, incomplete, or inferior.

An evaluation of a dataset must always take place in the context of a specific use case. For a given application, one can then make a recommendation that a certain dataset is better suited for that purpose — and explain why.

In the parts of the new HeiGIT analysis that I’ve read so far, I did not notice a description of such a use case.

The quality of the comparison dataset is also still unclear to me and others. Since its age, methodology, and limitations (for example, the level of detail) are crucial for assessing the results, it would be important to highlight these aspects — including in the short summary displayed above the charts in the tool. That section already links to the comparison methodology (which is good); it should also provide access to this contextual information, as it is essential for interpretation.

On another level: HeiGIT conducts many analyses within the OSM ecosystem and is widely seen as an expert in the analysis and quality assessment of OSM data. With that comes a particular responsibility to present the strengths and weaknesses of OSM — and of its alternatives — carefully and fairly.

And to stress it once again: evaluating and scrutinizing OSM without also evaluating the alternative datasets already distorts perception and is unfair to OSM. This becomes particularly clear in the Bachelor’s thesis mentioned earlier: OSM was evaluated carefully and thoroughly, which is great. However, the study does not address what alternative data sources exist and how they perform.

The result is that the takeaway becomes something like: “Caution — OSM isn’t entirely clean, be careful.” Instead of what would be a fairer conclusion: “OSM is an excellent data source — in fact, often the only one that provides reasonably good, up-to-date data with transparent processes for improvement. But like any open dataset, it may require regional updates and cleanups — for which processes already exist.”

Without this broader context, the impression remains one-sided. For many similar use cases, there are simply no real alternatives — and when alternatives do exist, they typically require at least as much manual correction, while offering poorer tools and less transparent processes.

In that sense, I would be very happy to see OSM framed more neutrally — or even positively — in future analyses, and to see an honest discussion of the weaknesses of other datasets as well.

FYI, there is more discussion / comments on this post in the comments at https://en.osm.town/@tordans/115297914265203391

What was their reaction to your inquiries on this? There is an email contact at https://github.com/osmlab/appledata I also wonder why there is no GitHub issue for your region…

Hinweis: Unter osm.wiki/Verkehrswende-Meetup/Kameraverleih gibt es auch einen Kameraverleih, gerne vor allem für Radinfrastruktur https://radinfra.de/mitmachen/fotos/.

FYI the linked github is a 404 https://github.com/Archit1706/osm-temporary-road-closures