Hi Richard, In my opinion, changing the back end (which would be ton of work), is probably not the best way of addressing the issues you are seeing.
We are still dealing with the hangover from the batch poorly done imports in 2009 and 2010. We also have an editor issue. A better approach would be to - Run an project to try to fix the imported poorly borders in the US, like we are fixing the tiger data. Or perhaps just pull them all out and re-import, state by state. - Make some changes to the editors to not allow dragging an entire admin border over, and not sticking other things to them by default. Thanks Jason On Tue, Nov 5, 2013 at 8:17 AM, Richard Welty <rwe...@averillpark.net> wrote: > 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 > _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
