[Talk-us] Admin borders in the US

[stevea]

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."

I'm not saying this cannot be done, or should not be done, I'm just 
asking for a sharper focus on HOW it could be done.  Because "leaving 
alone" the API and tools effectively perplexes me.  Maybe that's just 
me, but can we think our way out of this?  With good design, civil 
discussion and the technical prowess required to do so?

It seems we have arrived at a bit of consensus, which is a nice 
starting place:  early agreement that a "separate DB/layer/whatever" 
might be editable by our standard tools, and "the API should stay the 
same."  We might need to be a bit more flexible on that last point, 
I'm not sure.  But is that a good goal to continue to discuss as what 
we (roughly) want to address this issue?

Thank you,

SteveA
California


>On 11/4/13 3:03 AM, Simon Poole wrote:
>>   As a consequence I
>>  think it would be best to have borders (and other similar objects) in a
>>  separate DB/layer/whatever (makes live simpler for nearly everybody and
>>  stops the typical accident from happening), but the data should still be
>>  edited by our standard tools (in other words the API should stay the
>>  same) and by anybody with a OSM account.
>>
>this is approximately what i had in mind.
>
>richard