So we have bad data in OSM and you want to fix it by making it harder to correct. Somehow I don't follow your argument... :-)
While I do agree that it would be nice to have some kind of "layering" feature that allows us to aggregate date from different databases, this is a huge undertaking. It is much more than just adding a different database and let users change the API URL in their editors. How would you handle the ID spaces for instance. And it is totally unclear how things that are supposed to be changed together (think borders following a river or road) are to be handled. I suggest we keep the one database and think about how to improve the editors where needed. The JOSM filtering feature for instance is great to keep things "pseudo-separate". Jochen On Tue, Nov 05, 2013 at 08:17:35AM -0500, Richard Welty wrote: > Date: Tue, 05 Nov 2013 08:17:35 -0500 > From: Richard Welty <rwe...@averillpark.net> > To: Talk Openstreetmap <talk@openstreetmap.org> > Subject: [OSM-talk] Admin borders/separate database > > i brought up the subject of admin borders in the US over > on talk-us and there was a lot of useful discussion. i think > folks are mostly clear on the issues and tradeoffs, so i'd > like to float a proposal for an evolved approach. i'm moving > the discussion here because it's not just a US thing. > > basically, having admin borders mixed into the core OSM > map is problematic for various reasons. in the US, we have > a bunch of uncoordinated imports from different, inconsistent > sources, and a bunch of hand editing that is sometimes well > intentioned, and sometimes accidental, and not always > correct. the resulting map can be quite ugly at times. > > there is an argument that some make that because > borders are usually not easily verifiable on the ground, > they don't belong in OSM at all. i'm somewhat sympathetic > with the argument, but i also think that we have a bunch of > data consumers that need/want borders. many map users, > not so concerned with philosophical purity, expect to see at > least some of these borders in a map. > > so the rough outlines of the proposal (feel free to kick this > around) are as follows: > > a new database is created under the framework of OSM. > the purpose of this DB is to contain borders. after it is > reasonably complete and data consumers have been > adapted to use it for their admin border needs, the old > admin borders can be removed from OSM core. > > it uses the same schema and API so existing tools all > work for editing. it has the same access restrictions as > the current core OSM database; the only barrier to entry > is that you have to learn enough about your editor to > repoint it at this new DB. every member of the OSM > community would retain the same access rights they > have now. the minor barrier to entry, combined with > the fact that it will be impossible to glue border > nodes to other features, will probably address 98 or > 99% of the issues we see today. > > for the US, we'd probably want to do a fresh build of borders, > mostly from current TIGER although in some areas other > sources might be more appropriate (for example, in > Massachusetts MassGIS is available and probably a better > choice.) > > one open question is do we move other borders into this > map? there are lots of things like the New York State > DEC borders for various bits of conserved land, National > Park & National Forest borders, and so forth that maybe > out to move with admin borders. but perhaps we should > start with admin borders only for proof of concept and > to control the amount of work that needs to be done. > > richard > > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
