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
_______________________________________________
Talk-us mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-us
