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!

Thanks for sharing – and organizing this! I really like this process and think we should have more of it.

Danke fürs Teilen. Das Video hilft sehr um einen Überblick zu bekommen.

Mir fällt noch https://osm.wikidata.link/ ein, das auch OSM und Wikidata vergleicht.

I never get tired of seeing improvements to the map like this.

Same :-) 👏

It could be worth creating a theme for https://github.com/pietervdvn/MapComplete for your usecase.

Pieter Vander Vennet’s talk on this years SOTM gives a good overview: https://media.ccc.de/v/sotm2021-9448-introduction-and-review-of-mapcomplete

It could be worth creating a theme for https://github.com/pietervdvn/MapComplete for your usecase. That would allow for a single-purpose mobile editing experience (with build in visualisation). However, it is a browser app, so offline support is limited.

Thank you for a great and very easy to use app!

Thanks AntoJvlt!

Hi AntoJvlt, thanks for sharing!

How can I resolve an issue on https://gsoc2021-qa.nominatim.org/osmoscope/#map=14.618837772215969/13.40799/52.49792&l=https://gsoc2021-qa.nominatim.org/QA-data/same_wikidata/osmoscope-layer/layer.json as false positive? Example: node/473867813 (State Berlin) and node/240109189 (City Berlin) both reference https://www.wikidata.org/entity/Q64?uselang=de which represents State + City. Being able to mark cases like this as false positive will make it easier to work with the QA Tool.

Danke fürs Teilen!

Vielen Dank fürs Teilen! Sehr interessant!

Vielen Dank @Supaplex030, eine tolle Visualisierung und Auswertung! Ein hervorragendes Beispiel für das Potential von OpenData und OSM.

Thank you all for your encouraging comments!

@voschix: I did not reasearch the insurance dimension of this. I make sure the whole thing can move in the direction of travel (or oposite) if I get stuck in a tree or something, the whole thing moves and does not break. Other aspects would need more testing to find out more.

@ibanez thanks for sharing your setup.

I will experiment with video at some point. And test out the --interpolate_directions option soon, thanks.

“freedom of panorama” – thanks for the link. I tried getting more clarity from Mapillary and other sources without much success. For now I will wait and see what happens.

Tolle Recherche, danke fürs teilen. Interessehalber: das klingt für mich nach einem guten Fall für alt_name=…kanal (um den alternativen Namen auch zu dokumentieren), oder?

Thank you for taking the time to share this!