4 ms·

Let me explain which is the innovation of it: There are offline OpenStreetMap clients, but there aren't ways to update said map offilne, or to create "mini-OSM

Let me explain which is the innovation of it: There are offline OpenStreetMap clients, but there aren't ways to update said map offilne, or to create "mini-OSM" that later can sync with the main one. For instance, if you're doing a survey in Amazon with a local community, you would need to make a survey, go back somewhere with internet, sync the data with OSM, download the new file and go back to the local community. The innovation those guys are making is to create a mini-OSM, so the village could have its own mini-OSM, and later that mini-OSM could be synced to the main one. They are not the only ones trying to do that, an NGO called Digital Democracy is also trying (https://digital-democracy.org https://digital-democracy.org)

digikata 11y ago
Hmm, I wonder what happens when you take a team which is heavily editing in a village, and then multiple team members each have their individual mini-OSM of the same village to sync back? Don't you end up needing to be able to express edits as an OSM equivalent of patches for each edit?
- maxerickson 11y ago
  Osm changes are already expressed as atomic changes to each version of an object. Reasonably resolving a conflict where two different edits increment the same version of the same object is a difficult problem (the typical way it is currently done is reject the later edit and force manual review/fixup of the conflict). If someone adds a road and joins it to an existing road at existing point A, while someone else adds a duplicate of the same physical road and joins it at existing point B, it's going to take a rather aggressive heuristic to automatically discard one of them.
  - wawi 11y ago
    Time of entry is the canonical index.
  - tuxguy 11y ago
    Your comment reminded me of managing merge conflicts in git (or any distributed source control system) With conflicts, best way to resolve is a human manually deciding how to merge (which part of commit A & which part(s) of commit B to include) :D
  - digikata 11y ago
    That makes me think that applying a machine learning algorithm to suggest conflict merge fixes would be a fun little project.

digikata 11y ago

Hmm, I wonder what happens when you take a team which is heavily editing in a village, and then multiple team members each have their individual mini-OSM of the same village to sync back? Don't you end up needing to be able to express edits as an OSM equivalent of patches for each edit?

maxerickson 11y ago
Osm changes are already expressed as atomic changes to each version of an object. Reasonably resolving a conflict where two different edits increment the same version of the same object is a difficult problem (the typical way it is currently done is reject the later edit and force manual review/fixup of the conflict). If someone adds a road and joins it to an existing road at existing point A, while someone else adds a duplicate of the same physical road and joins it at existing point B, it's going to take a rather aggressive heuristic to automatically discard one of them.
- wawi 11y ago
  Time of entry is the canonical index.
- tuxguy 11y ago
  Your comment reminded me of managing merge conflicts in git (or any distributed source control system) With conflicts, best way to resolve is a human manually deciding how to merge (which part of commit A & which part(s) of commit B to include) :D
- digikata 11y ago
  That makes me think that applying a machine learning algorithm to suggest conflict merge fixes would be a fun little project.