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

Viele Fahrrad-Spezialfeature haben wir unter osm.wiki/Verkehrswende-Meetup/How-To-Map aufgelistet; die Reparaturstationen aber noch nicht.

Über MapComplete kann man viele Fahrrad-Zusatzangebote gut eintragen https://mapcomplete.org/cyclofix.html?z=18.7&lat=52.4834502536896&lon=13.446684047435156&q=Berlin%2C%20Rixdorf#node/12020581824

Update: At SOTM US GrabMaps presents updates on KartaView which include custom hardware for 360° imagery with image anonymization on device and LIDAR, a new release of imagery in the US, support to view 3D models on the web app and a sync service to upload imagery to Mapillary in parallel.

https://youtu.be/N92rACDMRak?si=oAAJEYOwqH6wXY2z

Unfortunately nothing about creating aerial-like imagery for craft mapping from this data, though.

Update: HOTOSM is working on automating image capturing via drones https://www.hotosm.org/tech-suite/drone-tasking-manager/ I shared this blog post with them in Slack; maybe this can be extended to 360° imagery at some point…

Thanks for sharing. FYI I just added your post to our collection of approaches for this problem space https://github.com/a-b-street/osm2streets/discussions/195#discussioncomment-13517207

Thank you for sharing!

PS: for bike infra in Germany there is also https://radinfra.de/kampagnen/currentness_too_old/ which highlights „old“ data in OSM

I remember this right, don’t I: the object.timestamp and .version only changes when tags are changed. Geometric only changes don’t show up. So in order to update eg a house it’s not enough to just move it you also have to add a ‚check_date‘ or similar.

Thank you for sharing and welcome :)

Visual feedback: I did not understand the relation part the first time I read the diagram. Suggestions: - remove the yellow line from the relation info box to the object and rely on the border color only. Or add a line to all the objects that have a border. Having only one line suggests that this is a info box for only one object. - write out the „RELATION“ kind next to the icon or replace the icon. The icon is too obscure for inexperienced users. - does „all public members“ mean „only add public objects in the given are as members“?

The biggest pain point for me is writing but also merging filters. I have a layer definition and want to use that in certain conditions so I have to merge those filter conditions into the base layer. The same would be true for conditional color styles (etc) but I did not even try that.

Mapbox had a JavaScript library once to build filters but I think that is abandoned.

The workflow we use for tiles-geo.de is to design the layers separately in one of the GUIs, extract the layers via API and manage interaction aspects in React. We still need to solve the layer order (I know how bit did not do it yet).

Hallo! Meines Wissens gibt es keinen einfachen Weg, das zu tun. Es ist Handarbeit. Es gibt aber Werkzeuge, die mit genügend Erfahrung den ganzen Prozess einfacher machen, vor allem JOSM. Die Einarbeitungs-Hürde dort ist aber erheblich. Ich glaube mein Vorgehen wäre, erst mal in einer Relationen weiter zu arbeiten und dann im community Forum oder einer Chat-Gruppe nach jemandem zu suchen, der die beiden Relationen zusammenführen kann. Theoretisch gibt es auch das Konzept von Superrelationen, aber das scheint mir hier fehl am Platz.

Ps: Dich könnte auch das neue Projekt radinfra.de interessieren.

Hallo! Ich verstehe ehrlich gesagt die Frage nicht genau aber es klingt danach, dass du im Forum eher eine Antwort bekommen wirst als hier. Den Link findest du osm.org/help

@Juicio: Thanks for keeping us updated an for a very successful GSoC project!