Is there a screenshot showing the difference between untagged / paved / unpaved Road variants? I scrolled through the Github ticket showing various graphics but it’s not clear to me whichbturned out as the eventual way styling that was shipped.

Thanks from a fellow QA Mapper for this effort, the necessary attention detail and most of all for sharing this writeup. I’m irregularly performing these tag reviews on the cuisine, religion, denomination tags, but just a few months later there’s always enough new tags to start over 😁

Very useful QA tooling. Thanks.

If a memorial has subject:wikidata set there’s still a warning “No image, wikimedia_commons or wikidata” shown. Particularly smaller memorial plaques don’t have a dedicated WD entry, so I subject:WD would suffice there. Can you maybe loosen the warning message to a notice in that case? Something like “No main wikidata, but secondary wikidata present”?

Thanks for creating this report 👏 Great QA tool to use in combination with https://osm.wikidata.link/ to complete the mapping OSM->WD

Thanks for going the extra mile (literally) to add all those details. The only items that you might want to revisit is the amenity names. I doubt the cafes all just double the name of the installation. Quick online search suggests they may have different names, but best to verify on the ground.

I was using OpenInfraMap country statistics over the course of last month to complete power plant information that was lacking source tagging. So the OSM data quality has increased already a bit since this research was undertaken. While China is still underrepresented (as with all OSM data) there’s the oppossite extreme nearby: Japan has the highest rate of Solar plant tagged objects. So might be interesting to perform your comparison for Kruitwagen’s predictions and OSM.

Also I was wondering if the centroids of the predictions could be used as input for a Maproulette task to not copy over geometries, but ask mappers to look at tracing solar plant outlines at that location (similarly to Mapswipe narrowing down where to send mappers). Not sure if this approach would be compatible with CC licensing and if the mapping work would still be considered derivative. A good start would just be at Maproulette task for large installations.

感谢您对公共交通基础设施的贡献。 这是有用的验证工具的链接： http://osm-subway.maps.me/index.html

Can’t wait what you hack together with the new expanded data set. Have fun on your continued professional journey.

I think what Christoph is aiming at is the the lack of verifiability of large natural geographical objects, particulalry in a maritime context, but also named objects of topograhical relief. Particularly how do you verify the outer boundary of a OSM polygon for a: * maritime bay * maritime strait * valley * ridgeline * mountain range * peninsula * cape * cliff * mountain (not it’s highest point, but the geographical feature all the way down to its feet) It’s pretty clear that humans generally have a consensus on where roughly a geographical feature is located by pointing at some central point or area. But how do you translate that fuzziness of a centroid label into exact outlines as required for representation as an area object?

I find the argument “Let’s include ‘station’ into the object name so I can tell it apart” a quite weak one in the context of digital geographical data. This argument doesn’t take into account that the object also includes the information that one object is a railway or metro station and the other a highway or shopping mall etc. And to follow the logic you would have to include “parking” in the name of every amenity=parking object or “bus stop” when naming every bus stop. But this piece of information should not be part of the name as it can be supplied by the OSM data visualizer via other methods, i.e. an icon, colouring or similar. Technically the tool using the data could even programmatically append -역 to every name of an object that is a station.

That’s why I always loved the way www.openstreetmap.de went the way of showcasing OSM as an enabling project to do stuff™ with geo data. I think the tech transition to vector has the potential to unlock similar avenues to show what can be done with open geo data.

Is the above map scan the only source you have for the boundaries? Or are you consolidating previous boundary data that were already present in OSM data? I assume there’s not really an “Open Data” approach anywhere within the Ashgabat administration…

How is the alignment in urban and rural areas of Turkmenistan in you experience? I found it to be generally much more consistent and less skewed than a lot of previously available imagery.

I am also both an active Maps.ME user (so slightly biased to get this data consumption pipeline from OSM data to app working) and a long time public transport (PT) mapper as well. I found your proposal and the validator tool highly useful to push PT mapping in OSM forward. I used your approach to map multiple subway systems mainly across Asia and it helped a lot to identify and solve problems. Many of the tagging and mapping I found in place was quite outdated and often even inconsistent within the same city.

The one thing I didn’t understand the whole past 1st and 2nd proposal attempts was why it’s not possible to allow both areas and nodes for stations. This freedom - to start with a basic node, but replace it with more detailed mapping if there’s a way to obtain more detailed dimensions - has always been one of the pillars of scalability for Openstreetmap.

I’m glad to hear you will split the proposal part of your scheme from the instruction page and look forward to a great new go to resource being established for PT mapping in OSM.

Hi Yevgeshik, Please ignore what is shown on the visualized map. As “SomeoneElse” above already explained there is a bug in the map renderer. The data for the tramlines is still correct in the OpenStreetMap database which you can easily verify via the Overpass link that Polyglot sent. You need to click “Run” on the top left of the page to execute the API query. Then you will see the correct data overlaid on the incorrect map rendering.

No need to put rumors and accusations in the world when there is nothing to base them upon apart from a buggy map visualization. Keep in mind that OpenStreetMap is about collecting the geographical data and not about rendering one map.

Btw. Up until checking actual usage I was under the impression that exit_to was more popular than destination. Good to see that destination already has a healthy 5x advantage and growing: https://taginfo.openstreetmap.org/compare/destination/exit_to

Thanks for the great summary and sharing the tool. Do you know of any other QA tool to verify destination tagging apart from Check Autorität? http://k1wiosm.github.io/checkautopista2/

And even where we have a place-tag don’t forget that we have still tons of unmapped places: http://resultmaps.neis-one.org/unmapped#2/23.7/3.5

Great to see these efforts now landing in 2.0. Looking forward to all the enhancements building on top of it that will arrive over the next months. Thanks for all your work “team modular”

Thanks for running for this position and the detailed application. You got my support.

Regarding your 2nd point in your HOT vision: Do you see HOT moving beyond the current scope of mapping more in developing countries also to drive a more proactive mapping of emergency infrastructure (a currently underrepresented field IMHO).