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