[Talk-us] Admin borders in the US

[stevea]

>On 11/5/13 6:59 PM, stevea wrote:
>>  I don't mean to pour water on what is a sizzling and robust
>>  conversation -- quite the opposite.  But as a computer scientist, I
>>  don't see how "putting" (moving, creating anew...) borders (and WHAT
>>  other objects -- we likely need to be careful in our design of what we
>>  mean by "these objects" and "similar objects") into a "separate
>>  DB/layer/whatever" can be achieved by the API staying the same, and
>>  continuing to be edited by "our standard tools."
>>
>umm, use a different port with the same xml api pointed at a
>different DB? this is hardly rocket science - this is speaking
>as a computer scientist and a network engineer in two of
>my previous careers.
>
>richard

OK, that is helpful; thank you.  But then what?  Assuming a wonderful 
(pure, largely error free...) "migration" where good (boundary) data 
in the new layer replaces bad (boundary) data in the "standard" 
layer, must we then access any and all border data via the new layer? 
If yes, how might the blending/merging of the two (for now) into one 
occur, e.g. for simple rendering?  Would new default behavior be to 
make two (three, four...) requests via the new ports to the new 
databases to "blend it all back together?"  In a seamless way?

Supposing this is successful (it can be, I'm not saying it can't) 
where might this bifurcation end?  While it could be a technological 
solution for "we need to improve bad (boundary) data in OSM" reasons, 
hasn't the project done OK (maybe even well) so far without 
multi-db/multi-layer bifurcation?  (A distancing of the path between 
contributor, where and how the data live, and the data consumer). 
The complexities of turning what is now one into many concern me.  It 
feels oddly like a shattering of the project:  first along lines of 
borders, in the future, who knows along what lines?

Again, I'm not trying to pour cold water here, just type out loud 
some concerns, and see if the proposed solution will be transparent 
or more complexity than it is worth -- for all users and tools that 
need updating, as well as data flow paths that now, say, use 
planet.osm but in future need to also use a border.osm file, etc.

OSM has gone nine years without data bifurcation.  I'm not saying it 
can't or shouldn't be done.  I am saying OSM (contributors) have 
managed to well improve our data without doing so, at least so far.

Use caution, discuss, vet, avoid pitfalls where they may lie, prove 
that benefits outweigh risks, etc.

SteveA
California