4 ms·

>we’re pumping all the good stuff that we can back in to OSM. This takes time due to OSMs consensus on not importing the masses of fixes we generate. This seem

by pedrocr 12y ago

>we’re pumping all the good stuff that we can back in to OSM. This takes time due to OSMs consensus on not importing the masses of fixes we generate. This seems strange. Anyone know the story?

morganherlocker 12y ago
OSM prefers user created data. Mass imports often contain errors all over the place (many going back unnoticed for years). OSM holds a general mindset that data should only be included if someone is fairly certain the data is correct (which they would not be on a mass import). "When in doubt, leave it out." That said, it is more of a guideline than a rule, and there have been mass imports in the past.
- Brakenshire 12y ago
  One solution might be for them to maintain their own error-checked database, and then provide a website and map overlay ontop of OSM, pointing out where the discrepancies are between the two. Then local mappers could go around and confirm the corrections. I do think in the long-run OSM will need some error-checking processes if it aspires to be a definitive database. At the moment, I could quite happily subtly mess up a motorway junction in Japan, and most of the OSM mapping software would have no way to knowing not to package it up and send it out. Vandalism is not an issue now, but as the dataset becomes more popular, I think some mechanisms will need to go into place to protect its integrity (particularly for major infrastructure).
  - sitkack 12y ago
    You might like the "Propagator Model" of computation, think of it is a probabilistic graph with CRDT like information augmentation. http://groups.csail.mit.edu/mac/users/gjs/propagators/ http://groups.csail.mit.edu/mac/users/gjs/propagators/ https://github.com/tgk/propaganda https://github.com/tgk/propaganda
maxerickson 12y ago
At some point it becomes difficult to mechanically integrate the data, and having the data nicely integrated is sort of one of the selling points of OSM. There is also a repeated pattern of imports planning on 'fixing it later' and then not really following through. Another thing is that existing OSM data will tend to be more recent, so 'trampling' it for better coverage isn't all that desirable. One thing that seems to get overlooked is that data that is in a state where it could be imported into the main database is also in a state where it can be mixed with a snapshot of the main database. So whoever has that data can make use of it to increase their coverage without worrying about how other users would want the data integrated.

by pedrocr 12y ago

>we’re pumping all the good stuff that we can back in to OSM. This takes time due to OSMs consensus on not importing the masses of fixes we generate. This seems strange. Anyone know the story?

morganherlocker 12y ago

OSM prefers user created data. Mass imports often contain errors all over the place (many going back unnoticed for years). OSM holds a general mindset that data should only be included if someone is fairly certain the data is correct (which they would not be on a mass import). "When in doubt, leave it out." That said, it is more of a guideline than a rule, and there have been mass imports in the past.

Brakenshire 12y ago
One solution might be for them to maintain their own error-checked database, and then provide a website and map overlay ontop of OSM, pointing out where the discrepancies are between the two. Then local mappers could go around and confirm the corrections. I do think in the long-run OSM will need some error-checking processes if it aspires to be a definitive database. At the moment, I could quite happily subtly mess up a motorway junction in Japan, and most of the OSM mapping software would have no way to knowing not to package it up and send it out. Vandalism is not an issue now, but as the dataset becomes more popular, I think some mechanisms will need to go into place to protect its integrity (particularly for major infrastructure).
- sitkack 12y ago
  You might like the "Propagator Model" of computation, think of it is a probabilistic graph with CRDT like information augmentation. http://groups.csail.mit.edu/mac/users/gjs/propagators/ http://groups.csail.mit.edu/mac/users/gjs/propagators/ https://github.com/tgk/propaganda https://github.com/tgk/propaganda

maxerickson 12y ago

At some point it becomes difficult to mechanically integrate the data, and having the data nicely integrated is sort of one of the selling points of OSM. There is also a repeated pattern of imports planning on 'fixing it later' and then not really following through. Another thing is that existing OSM data will tend to be more recent, so 'trampling' it for better coverage isn't all that desirable. One thing that seems to get overlooked is that data that is in a state where it could be imported into the main database is also in a state where it can be mixed with a snapshot of the main database. So whoever has that data can make use of it to increase their coverage without worrying about how other users would want the data integrated.