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!

Danke fürs Teilen! Ich finde es immer wieder faszinierend, welche Details in OSM eingetragen werden :)

Für interessierte, hier gibt es einige dieser Steine von TBesse in OSM: https://overpass-turbo.eu/s/1OPE Beispiel für einen Stein osm.org/node/918947050

@TBesse: Wie werden diese Daten in verwendet? Nutzt ihr sie als Datenhaltung für euren Heimatverein? Gibt es andere Daten-Nutzungen, die du kennst?

Hinweis: Unter https://www.besse.de/buecher/2021_Lebacher_Grenzstein-Tour.pdf wird OSM erwähnt aber der Link ist defekt. Ich verstehe auch nicht, was mit Touren gemeint ist. Sind in OSM Touren-Relationen erstellt zu den Steinen? Sind das Touren die der Verein erstellt hat? Und interessehalber, sind diese beschildert?

@Juicio this is looking great and thanks for the weekly updates.

(One thing that would help me is if you wrote a short note as a comment here when you update the post; it is hard to notice the updates without any notification or such. The RSS feed does not refresh unfortunately, so subscribing to your blog does not help either :).)

A few thought on the feature:

• My UseCase is “see image that are 6 month or fresher” (or 1 year, 1.5 years, 2 years, “all”). The year slider from “week 6” is a lot better for that then the fiddly date picker that we have for Mapillary today. However the “year” steps would be too “big”, at least for the last 2 years. Would that work with month or 6-month steps?

• I like using the “color by age” feature in Mapillary whenever the filter don’t show enough images. Here is an example: https://radverkehrsatlas.de/regionen/bb-kampagne?map=17.6/52.48028/13.42014&config=rcqwse.2ufbwk.6q9&v=2 The usecase is: First I filter by 6 month and 1 years. When I find no good images, I look at all images and use the colors as a way to quickly select the least old image without looking at exact dates.

• It would be great to have https://github.com/openstreetmap/iD/pull/10046 for Panoramax as well, using the key osm.wiki/Key:panoramax

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 osm.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