Danke, dass due deine Einschätzung und Zusammenfassung teilst.

Let me start by saying: I am general for adding all the details to OSM. It’s our USP. However, when it comes to Business POI, I am really hesitant and unshure if this is a dataset that we should strategically “invest” into (AKA push for more data and more usage). Why? Because it’s an area that – more than other – will attract fraud … and I believe our moderation and detection tools are way out of league for that. To get a feel for the issue, check out this podcast https://gimletmedia.com/shows/reply-all/o2ho87. There are also posts like https://www.theverge.com/2019/6/20/18693144/google-maps-fake-business-listings-investigation-report and recently https://latlong.blog/2023/08/places-on-google-maps-can-they-still-be-trusted

But putting that aside…

My general take on POI is: This is something to be mapped on the ground (not remotely). As in: You should stand in front of the shop to map it … or have great local knowledge of the shop to map it.

Which means: Whenever we look into data like this, we should look into mobile mapping tools.

POIs are also something that is very annoying to map. A lot of tags, a lot of micro decisions and – especially you start typing opening hours – a lot of time spent typing per edit.

Which means: To really roll out POI mapping, we need better tooling in our mobile editors to map those.

• EveryDoor makes adding detailed tags a lot nicer
• GoMap has a opening hour scanner (camera => OCR => OSM Tag value), which can be a huge help
• StreetComplete also new Capabilities to add Shops

However, all of those are lacking features to validate external data and use a prepared external dataset as a basis for what the user maps.

There are several pieces missing in our toolchain…

• We need an easy way to process external data against existing data. I wrote about that in https://github.com/facebook/Rapid/issues/585#issuecomment-1249994877 “Help with data preparation”. We have many external datasets that we could use to guide map updates. But processing them in “maybe needs to be deleted in OSM”, “maybe needs to be added to OSM” and “maybe needs to be updated in OSM” is too hard right now.

• We need a tool that we can use as a shared Tasklist. This is needed so we can come together in a shared effort and in order to split up a big dataset into separate tasks. We also need a place outside of OSM to document our findings once we checked a task. The best tool we have is MapRoulette. However, we need a great mobile editor integration in order to use it for topics like the POI dataset – an IMO most other micro mapping datasets. I created https://github.com/maproulette/maproulette3/issues/1737 to track efforts in this area, but it is not a focussed topic for MapRoulette, yet.

And finally… - We need mobile editors to integrate MapRoulette as a tool to guide mappers to the next location “around the corner” which they then can update with minimal effort, due to the preparation of the external data in the MapRoulette Task. The issue above tracks my efforts to get MapRoulette inside editors. But we lack a shared understanding of the impact of such a workflow in order to get all the people needed to work on this.

All in all, we are slowly going in the right direction but have along way to go before we can efficiently update and add external datasets that require hyper local validation into OSM.

https://toot.cafe/@impiaaa/111218551039688662 Shows a great example how to micro map a newly opened park using Jake‘s tutorial.

@Harald Danke für die Links, einige kannte ich noch nicht. Leider kann ich auch aus diesen Links keine Übersicht erkennen. Im Gegenteil, wir haben leider Informationen sehr oft dupliziert und dann nicht überall aktualisiert…

Ich halte es daher weiterhin für hilfreich eine zentrale Tabelle zu pflegen die den Status erfasst und dann auf die Detail-Artikel verlinkt. Wenn jeder sein Bundesland einträgt, ist das ja schnell gemacht.

Vielleicht kann dann auch die neue Stelle beim FOSSGIS https://www.fossgis.de/news/2023_09_08_stellenausschreibung_osm-beratung/ dabei unterstützen die Lobbyarbeit – vor allem von DD1GJ – weiter zu führen.

@mcliquid: Sehr gute Idee. Willst du eine entsprechende Spalte einfügen in der Tabelle?

Danke fürs Teilen! Ich beschäftige mich gerade häufiger mit der Frage der Richtigkeit von amtlichen Daten ggü. der Realität vor Ort, da passt dein Bericht sehr gut rein :).

Thanks you for sharing your insights, cbeddow!

One thing I notice when talking about this topic: From the outside it looks like since the beginning a lot of Mapillary’s work is spent with extracting features from the images via AI. However, in my OSM mapping experience, the data generated from this is still not a relevant factor when mapping (and I tried many different approached over the years). On the other hand, good areal imagery is the base for more or less every map edit in OSM. And together with the 360°-point of view its the basis for most of our mirco mapping efforts in Berlin (eg. https://strassenraumkarte.osm-berlin.org/?map=micromap).

Looking at it from a “cost of data production” vs. “features added to the map” point of view it looks to me that this aerial imagery approach could win by a huge margin. I just hope we are not looking at the cool AI-kit all the time missing the boring image processing tool sitting right there, ready to be useful right away.

I am glad to hear you see a possibility for more experimentation in this area!

Update: GeoViso project wrote in https://gitlab.com/geovisio/blurring/-/issues/3

On our side, we are willing on a first phase to just offer pictures both through API and in-bulk, so third parties can retrieve complete datasets and create new use cases like this one. So if one want to work on this topic, we will be glad to help easing the reuse of our pictures 😊

FYI, there is also a little talk about this at https://github.com/facebook/Rapid/issues/922

FYI, I took the liberty to share this in https://twitter.com/BeforeAfterOSM/status/1635143644654211072.

Thanks for sharing! I posted it at https://twitter.com/BeforeAfterOSM/status/1648245126483918848. Hope that is OK, let me know if not …

Thanks for sharing. I wanted to try this as well to see if we can finally have an easy way to give visibility to otherwise “hidden” (unstyled) tags in OSM on a world-level.

From what I read it should be possible to create the pmtiles directly from tippecanoe, see https://github.com/felt/tippecanoe/releases/tag/2.17.0 and https://github.com/felt/tippecanoe#output-tileset

First, to get the right input for the overpass query, we need an area to work with. You could use a bounding box or an area relation.

A tool that I find very hand for this part of the process is https://hanshack.com/geotools/gimmegeodata/ which lets you search for relations and gives the OSM ID, Link, Download …

There is a new tool in the making that might be an alternative or fallback for OSMCha. There is not a lot public yet except osm.wiki/OSM_Monitoring_Tool. But I heard that more info will be posted soon.

So to be prepared for the next time OSMCha is not available…

To put it out there: In my opinion we should come start talking about how to make OsmCha more reliable. There has to be something that can be done with servers and server monitoring, that will help Wille with maintaining the project. That could be something the EWS helps with https://wiki.osmfoundation.org/wiki/Engineering_Working_Group. Ideally, Wille and EWS would start a conversation about that. Maybe the foundation can manage the servers or something … — I will not have the time to manage that conversation myself, but maybe someone here has.

Sorry for the late reply…; I wanted to go into a bit more detail on my thinking / decision tree. I don’t see any disagreement in this thread. But maybe this summary is helpful for someone:

In general, having the address on the house is a great thing IMO (good to review, map, query, audit). However, that only works for rural areas (AKA not cities), and mostly for residential buildings (AKA “one family houses”, not shopping centers, commercial buildings, apartments).

Outside of those parameters, one building shape will very often have multiple addresses without a way to separate the building properly (AKA no on the ground truth, no areal image that would help). In those situation, having a floating address inside but “above” the building (nearby the entrance, if possible) is most convenient IMO. It gives the address good visibility (in Editor and Viewer) and makes it OKish easy to query for addresses “inside” buildings.

On that note: The way our editors and tools are build right now, I prefer having the address nearby but not “on” the entrance. I can see why people map it this way, but right now it hides this important data too much, IMO. And it does not have any relevant advantage (AKA routers will be able to route to the “nearest entrance” just fine with a floating address placed nearby).

Another rule I try to follow is, to keep the mapping patterns in one region the same. AKA in Berlin, where we have floating addresses, I would not start adding a few to the building shape even if it where possible.

You screenshot clearly shows the residential building-case IMO, so I personally would merge them with the same (if its not too much additional work).

My take: In general, I prefer separate (and single purpose) address nodes. They are more flexible. But for residential buildings, that flexibility is not needed so merging them with the area is IMO a good idea as well. It is a bit annoying when both mapping styles are used in one area though, so I like when mappers stick to one pattern in one area :).

Hey, I know I am late to the party but I talked to a friend about the broader topic of importing external data just now and this notes-based-import-technique came up. So I wanted to finally write down my comment about the notes approach used for this project.

My take: I think a MapRoulette integration would be a far better approach than using OSM Notes this way.

In general, I fully agree that we should use a review-process to check this kind of data before adding it to OSM. However, the tooling of OSM Notes is not great right now (which is why tried to compensate with the MC-Notes-Theme, I guess), so adding a lot of notes for “imports” does not scale at all.

On the other hand MapRoulette is a great tool in our eco system that allows to manage the status of such external data pretty great. The process you describe for notes …

a new note was created for every missing datapoint. These notes are loaded by MapComplete and shown when appropriate. A contributor can open MapComplete, and then confirm that a bench, picnictable, toilet or playground is effectively there. If it is, they are invited to slightly move the item to a more accurate position using the best available aerial imagery in the region. If the item is missing or duplicate, this can be marked as such and the note is closed too.

… would just as well work for a MapRoulette project/challenge and task. The tool is very flexible in they way it can be configured; quite stable; maintained; and has an API to integrate it into external apps like MapComplete.

FYI, I created this ticket a while back to track the status of integration of MapRoulette in other tools https://github.com/osmlab/maproulette3/issues/1737.

About feature:

Thanks a lot for this work and feature, it looks great and is needed!

I wonder, is there a description of the use cases that the overlays will solve in this version of the feature? Especially: I wonder what the conditions are that make a line green/pink/red. Could I use this feature to re-survey an area? (See also https://github.com/streetcomplete/StreetComplete/discussions/3644.)

About “the end”:

I really wished the OSM(F) would find a way to support work like yours in a more long term capacity. Reading the effort it took for you to build this feature and get the funding to do so shows very clearly that work like this has to be funded and the funding really should become easier.

Best of luck finding a great fit for your future work!

FYI, I looked into this topic recently (or part of it, just the classification of state schools (as in “no musik and horse riding schools”) in Germany). I was astonished how hard it is to improve the tagging even for one country: https://github.com/openstreetmap/id-tagging-schema/pull/331

At first I thought the isced:level would be a good fit, but I am not sure anymore since they change their system apparently (see “Versions of ISCED” osm.wiki/DE:Key:isced:level#Werte_f.C3.BCr_D-A-CH) and our tagging is not prepared for versioning external reference systems … — and it is also super abstract.

However, the alternative would be to come up with special values for each country … which would be a lot of work if even possible.

Thanks Zverik, that looks great!