What I’d really like to read in this diary entry to make the story complete, is how these edits were actually spotted.

The data team at Mapbox regularly reviews changesets using https://osmcha.mapbox.com . Of course this is just a small percentage of changes, so theres many many more skipping anyones eyes.

Currently, maps.me user can more likely do something similar to it than anyone else

Don’t quite agree, its new users who are likely to do this rather than with any specific editor. Look at what happened today with iD osm.org/user/PlaneMad/diary/40722

Very cool!

Oh wow, congrats!

This works beautifully and is really the kind of data tool that should be more integrated as a layer in both Wikidata and OSM. Looking forward to exploring the data in other parts of the world =)

Wille, your work has been phenomenal in laying the groundwork for a more powerful community validation tool on OSM. For instance: list of all changesets with no additions and atleast 5 deletions in London.

Really excited with all the developments so far and what the future of OSMCHA looks like with a map interface!

Thank you for your work mcld! This opens up room to add so many more features that anyone using to a modern map these days is used to.

This is a beautiful post Joost, with some very nice approaches at evaluating the completeness of the map.

Wondering if you were able to find a pattern in what type of features were more actively mapped over time. Considering an active mapping community and declining edits on road features, was there a corresponding increase in edits to other types like addresses or turn restrictions?

From personal experience it seems like there is a very definite order in what features get completed on the map based on complexity and quantity of data to add: roughly roads, railways, street names, natural features, amenities, POIs, buildings, boundaries, navigation data, addresses. So maybe if the most heavily edited feature is addresses, it might point to more basic features like roads being more complete?

Also maybe numbers alone would never be able to tell objectively how ready a map is, the ultimate test might be to actually use the map successfully to navigate in the real world :)

This is amazing! This is probably the most detailed map of Andahuaylas ever made http://lxbarth.com/compare/?osm&google#18/-13.65673/-73.38886

Thank you saintam1, a big improvement from what it used to be :)

@reshma

Yu can see instructions on correcting the boundaries on a local tile server here: http://xsce.org/wiki/generating_map_tiles

“Data have no meaning if there is no use”

So true, we need great stories of how this data is being used for all of South Asia. Our governments have been trapped with proprietary data and platforms for too long at the cost of public money.

Looking forward to this year, I can already feel its going to be a hallmark one for OSM in the region.

Try MMI. From comparing the Himalayan village I fieldmapped Rakkar, I think the OSM data in MMI dates back to sometime in 2013. The changes I made in 2014 are not there.

To find where OSM ends and propriety data begins, or if everything is just mixed.

Nice work, Thanjavur looks quite nice. I wonder if its ready to make a printed tourist map in Tamil?

Groups would have been so good. For a community thats so much about interacting and exploring, there is woefully inadequate interactions on the website itself.

This is looking so good! I had added some basic details a year ago when attending a wedding at the Bhuvana Hall. Such beautiful countryside!

Glassman, updated the link, should work now. I’ll need to check if these tokens keep changing by itself. Thanks for reporting.

Excellent writeup highlighting the cultural data issues on temples and language tags on the map. A possible solution to the Chinese labels is to use more granular tag variations like Wikidata does, and maybe try to ultimately have the various translations in Wikidata itself.

The FB incident is interesting, did they allow users to edit/improve OSM from FB?

I’d ask the question “what problem are you trying to solve?”. If it’s not broken, don’t try to fix it.

The problem is the inconsistency caused by having multiple keys from OSM to another database, when it could easily be eliminated. Two wikipedia tags for a feature go against the best practice of what is documented in the wiki.

Kosovo is an interesting edge case, and thank you for bringing it up. There is no clear answer to that one, but solving the 99.9% trivial cases now is just good data gardening.

ff5722, tbicr good catch. Just added an update.