[Tagging] Feature Proposal - RFC - Mapping disputed boundaries (Version 1.3)
frederik at remote.org
Sat Dec 8 16:33:28 UTC 2018
so I've read the proposals that are on the table for the first time now.
I wasn't sure at first whether your proposal would break existing tools
that only look at boundary=administrative but I see from the discussion
page that you understand it is important to keep things working. It
would be worth making this clearer to the skim-reader of your proposal.
I haven't yet understood how the relationship between
boundary=administrative relations and your new relations is supposed to
be in the future though. Would boundary=administrative not be identical
to your boundary=de factor (apart from the yet-to-be-addressed maritime
I am not 100% sure whether you are advocating to duplicate any and all
existing relations right away. If yes, I am against that; I would like
to map disputed boundaries only where disputes exist. You say in your
recent email that "For any countries with no active disputes, there's no
change needed at all." so I assume you're not planning to create
"boundary=master" or anything for non-disputed countries. This is good.
I am uncomfortable about your "list of claiming entities" and the
importance it has for this proposal. I think that the fact that your
proposal requires a well-maintained list of who is and isn't a valid
claiming entity is a big weakness of the proposal. I am wary of
bueraucratic statements like "if Transnistria joins the list, the
boundary between it and Moldova would become admin_level=2". It doesn't
sound right to me to have such things governed by a list. I can see how
the list might be the least worst solution but I'm not in love with it.
I don't understand what boundary=minimal is for. It should be easily
deducable from the other boundary relations and I don't see its added value.
I am not really sure about the notion of "zones of control" which seems
essential to your proposal. If there are two countries both bordering a
lake, and both of them think the far shore of the lake is the boundary,
does that then make the lake into a "zone"? It sounds like an arbitrary
concept to me. In some cases the "lake" might actually be an area that
has a name and can be called a zone, but in many cases it will just be a
dispute over where the border actually is, and the bit in between that
is claimed by both parties is just where the country relations overlap -
I don't see why it should have its own "identity" and relation in OSM.
What is the use of this? You say it should be added to the boundary
relations with the role "zone", but adding whole relations to boundary
relations is unusual (only done in places where "subarea" is common).
Doesn't feel natural to me and I don't see the use since the delineation
of the "zone" should already be visible from the overlapping boundaries.
If I have two countries A and B and each claims that area C which sits
in between them is theirs. Then if I understand you correctly, the
"Master Boundary A" will contain all boundary ways around A and C, and
the "Master Boundary B" will contain all boundary ways around B and C.
Why would C then have to be its own "Zone" and why would it have to be
added to the A and B relations?
On the whole I'm a bit concerned about the complexity of your proposal -
not only the proposal but also the somewhat legalese way in which it is
presented, which I fear will keep many people from even reading it to
the end, or contributing. This is an important issue and I'm
uncomfortable with having 15 people vote yes on this and then saying
"this is how we do it from now on". I wonder if maybe we should -
provided the proposal gains enough traction - simply declare two
"testbed areas" in OSM where we apply the new tagging and give users a
chance to get a feel for it before we roll it out world-wide.
And yes, we definitely need good comparisons between different
proposals, or perhaps a few more different proposals to add to what's
already on the table. Your proposal is complex enough already to make it
near impossible for anyone to suggest improvements - most people's way
of suggesting something would probably rather be "why not do it this
way" and then writing up their own ideas ;)
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
More information about the Tagging