Hallo Simon, ich empfehle dir alle Videos von den Konferenzen unter https://parkraum.osm-verkehrswende.org/ zu schauen. Darin beschreiben wir, wie wir in den letzen 3 Jahren das Schema zum Parken im Straßenraum für Auswertungen genutzt haben.

Zur Zerstückelung: Wenn man versucht nur über Zerstückelung den Parkraum präzise zu erfassen, dann kommt es dabei zu viel zu vielen und viel zu kleinen Abschnitten. Das macht die Region in OSM nahezu “unwartbar” für die Zukunft. Unsere Lösung ist daher der Subtraktive Ansatz den wir auf der Webseite beschreiben. Dabei muss viel weniger zerstückelt werden.

Vielleicht willst du zu einem der nächsten Meetups kommen https://wiki.openstreetmap.org/wiki/Berlin/Verkehrswende, da können wir uns weiter dazu austauschen.

This is great!

Great news. Can you share a bit more on which improvements have been made during the migration process?

Thanks for reaching out Branko! Here are a few thinks I have been thinking about for a while. I can tell you more about each of those ideas…

(a) Improve low interaction, positive communication on osm.org by adding (selected) reactions to changeset comments. — Why: The social aspect of OSM is at least as big and important as the geodata part. And I think we lack behind in looking into how to improve it on osm.org. One low hanging fruit is to add an ability to the website to show (positive) feedback on something without writing text. Github and all other social platforms – including messengers – use a limited list of emojii to allow reaction on events and comments. With such a Feature, I can show my “<3” on a changeset, without adding text. Or promote and validate a comment mit a “+1”. We also need to find the right emoji to express some disagreement without making the dialogue worse. — There is no ticket on this, yet. I consider this very impactful but also too big to tackle for the osm.org-maintainers or someone in her free time. I was hoping the paid EWG projects might evolve to tackle things like this, but this is a very slow process.

(b) Improve communication by auto linking currently separate threads — This builds on the idea that we can use better tooling to improve the conversations we in our OSM eco system. The idea is, to add a pingback/trackback system to changesets and other comment formats. Example: I read a note, update the map and because I referenced the note in my changeset comment it gets automatically created link back to that changeset. The same goes for changesetes that reference themselves. — There are already established and tested ways to to thin in Github but also the WorPress eco system, which can be used as a frame of reference. — There is no ticket on this, yet. I consider this very impactful but also too big to tackle for the osm.org-maintainers or someone in her free time.

(c) Improve communication by adding at-messaging on osm.org. — Again, given that Changeset comments and OSM Notes are a center point of communication on map related topics, the fact that we cannot “ping” each other in those messages make the communication worse. Of course, other questions have to be tackled like a notification system that can handle such pings. — There is no ticket on this, yet. I consider this very impactful but also too big to tackle for the osm.org-maintainers or someone in her free time.

(d) Improve Navigation on OSM.org with a UX Redesign for logged out and logged state. — Why: Right now, logged in and out states are not very separate. The logged in state is less ideal because space is taken up by actions that are focussed on logged out users. The navigation experience of logged in users could be a lot better. UseCases like “go to my last changeset” involve a lot of clicking around. At the same time, I see a great opportunity (but also dragons…) in fokussing the story of osm.org when looking at what we present to logged out users. (strategically this might be better left as a separate project) — There is no ticket on this, yet. It consider starting the a well scoped and worded ticket is already part of the UX work and should be done by an UX designer that has some time to think about this first.

(e) Enhance the changeset data with micro-bounding boxes. — Why: We have issues with “world spanning changesets” again an again. Those create issues for all tools, the osm.org website and OSMCha are the most prominent. But there are also tickets on nearly all editors I monitor discussing how to limit users to create such changesets. However, there is also a possible technical solution that Simon mentioned (https://en.osm.town/@simon/111311834237289626): What if we enhance the changeset processing to return not only the changeset bbox but also micro-bboxes for regional segements of data. A changeset that spans Paris, London and Berlin could have 3 micro-bboxes for the changes in those cities. A changeset that spans all Berlin but could have 2 micro-bboxes for changes in Mitte and Neukölln (districts). Tools like OSMCha could than use those micro-bbox data for their processing which would improve their usefullness. — There is no ticket on this, yet. It would be a great first step if someone with some knowledge about the issues and possibilities where to start this conversation on osm.org.

(f) Enhance OSMCha to “subscribe changes in this are” by email (and RSS) (with Object type filter) — Why: We need more visibility into changes after we edited the map. This is one of the main issues I have in getting people that are not OSMler at their core to contribute their expert knowledge to OSM like city planner, local tourism agencies and so on. The need to have the feeling of control over what happens with the data they contributed or the region they contributed to. OSMCha is the best solution we have right now and IMO it is not good enough to solve this use case. There is a lot that can be done here with some Funding and help.

(g) Improve the tooling that allows to compare external data to OSM data in order to understand but mainly prepare data to be added to OSM. I wrote about this in https://github.com/facebook/Rapid/issues/585#issuecomment-1249994877 “Help with data preparation”. Any tooling that makes it easier to take two datasets (lines or points or mixed) and separate them in “already in OSM”, “missing in OSM” will be great. Ideally those tools will help the person working with the data to understand the differences and look into the data (show map, inspect properties, see buffers …) to easily modify the settings.

(h) Port StreetComplete to iOS. — Thats it, that is the whole idea :-). However, the implications are quite bit. Tobias Zwick wrote about what would have to happen in the SC git repo. And one core question is, who will maintain this version. — On the other hand: It would open up so much potential for new, local mapping campaigns if the tool where cross platform…

(Consider this a +1 to rouelibre1)

(i) Improve tooling for local mapping initiatives. — One USP and strength of OSM is local knowledge. But once a topic gets too big for one to handle, we lack good tooling to coordinate and motivate a group of people. Especially if those groups are a mix of newbies and veterans. Unfortunately the tooling and workflows differ a lot based on what the projects groups goal is. However, a few things are commonly true: A grid based approach like the tasking manager is mostly not suited for adding data to existing line and point data; we should be looking at task based tools instead. — StreetComplete is a great tool for campaigns like “add curb height to all crossings in our neighborhood” and since SC recently added QR-codes a local group can easily share this project with newbies and veterans alike and have a clean editing workflow with great UX. However, that limits us to Android users and also to only those groups of tasks that are specified within the app. — A more open approach is MapRoulette, which allows adding all kind of tasks and work on them collaboratively. It is also editor agnostic, which is great to make our diverse group of newbies and (JOSM) veterans happy in terms of editors. However, MapRoulette severely lacks in the mobile editing area. https://github.com/maproulette/maproulette3/issues/1737 is a good overview on this. There is potential to do cross tooling work (and likely extend MR a bit) in order to get make MR the vocal point of a local initiative on a specific mapping topic. MR will be the shared task manager, activity hup, statistic source and leaderboard. And different editors can be used – based on preference but also OSM experience – to add the data in question. — One low hanging fruit for Microsoft could be to help your colleague Bryce to create a great MR integration for GoMap (starting point https://github.com/bryceco/GoMap/issues/240).

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 https://wiki.openstreetmap.org/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 :).