The reason this ground verifiability argument is still used so generously, is that this is how OSM started out - no aerial imagery, just us, our GPS traces and perhaps some pictures, notes and recorded audio. I would not dispute at all that administrative boundaries are an important component of any map. OSM is not really just a map though - it is a database you can make a map out of among many other things, and a very unique database at that: one created by people like you and me. The more data you introduce into our man-made OSM that is neither created nor verifiable by people like you and me, the more we depart from that notion of OSM as a map based on our collective knowledge, which is something that we should be very cautious about. And if you want to make that map, there are straightforward ways to incorporate things that live outside of OSM in it. It's hard to decide where to draw the line of what belongs in OSM and what doesn't, and it's hard not to have opinions on importing bleed into this discussion. With all the trouble the maintenance of the boundaries are causing, what is the compelling argument in favor that I am missing?
On Wed, Nov 6, 2013 at 2:29 PM, Jason Remillard <[email protected]> wrote: > Hello, > > The inconsistency is caused by those that insist on defining the > project in terms of things that can be verified on the ground. My > definition of the project has no inconsistency. > > A free map of the entire world. > > Thanks > Jason > > > > > > On Wed, Nov 6, 2013 at 4:04 PM, Serge Wroclawski <[email protected]> wrote: >> The answer to your "Where is the line" is actually quite a simple question... >> >> We have a logical inconsistency right now. We tell people that OSM >> contains a map of verifiable things. In fact, we remove things which >> are not observable! >> >> But political(administrative) boundaries are an exception to that. >> >> The explanation is always "Because a map is expected to have these >> boundaries", which is true, but it remains a logical inconsistency. >> >> For years there's been this "standoff" between consistency and >> practicality. The proposed solution would be to have another instance >> of the OSM database (just like we have the dev database) which uses >> the same API and same credentials. >> >> So what would go in there? Political boundaries. >> >> As for "splitting the project"- I think it does a little, but in a >> very well defined way. Only administrative boundaries would go in the >> administrative boundary map. >> >> You're right that it does change the nature of the project in a way, >> moving us from one to multiple (2) databases, and it may even be true >> that if we did this, people would want new databases. >> >> There are issues with any solution, but I do see a lot of consistency >> in this one. >> >> - Serge >> >> _______________________________________________ >> Talk-us mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/talk-us > > _______________________________________________ > Talk-us mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-us -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/ _______________________________________________ Talk-us mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-us
