Support alternate points of view in boundaries layer

[nvkelso]

Natural Earth supports the concept of "points of view" (POV) to indicate the claimants for different boundary disputes.

Right now Tilezen supports just the default "defacto" point of view, but sometimes that deviates from US State Department and United Nations views. And showing maps of India, Pakistan, China, and other areas require special treatments.

Tilezen should support both a default POV (now) and additional POV for country and disputed boundary lines (possibly also region but Natural Earth data doesn't support that now).

[musculman]

When looking at this feature it would probably make sense to think about how to solve the fact that you would need to give different geometries depending on the view used.

In particular, we should not only think about a particular border being listed as belonging to two (or more) countries, but also the fact that these countries might have different understanding on where the actual border is.

Therefore, it has two main use cases:

• pure disputed borders: if view of Country A is used, the border of country A is here, if view of country B is used, the border is not here but somewhere else.
• different border depending on the view. As opposed to the previous case in which the border is either shown as disputed (dashed) or belonging to country A or B; in this case, the border is not there and it is somewhere else, changing the actual shape of the country.

For some simple raster tile examples, I think it might be worth looking at the example from HERE Map Tile API.

Looking at a possible implementation for a border with an example, could be:

• is_disputed_by=A

• is_accepted_by=B
  This border will be displayed in country B but not in country A.

• is_disputed_by=A
  This border will be displayed in all views, but not in country A.

Additional attributes worth considering are:

• claimed by : an attribute that indicates which country claims a cartographic administrate polygon or linear administrative boundary in a disputed area.
• controlled by: in disputed areas which country is, according to international agreements, in control of the area.
• line of control: usually marks the internationally accepted boundaries, but are located in areas under dispute. Some countries might claim large territory, but de-facto control only up to this line.

[zerebubuth]

As an alternative way of looking at things; borders (national or otherwise) are largely fictitious. In some cases, there is a physical barrier marking the boundary. This makes it easy to map and draw - the big fence or wall is the border. Where there is no physical barrier, the border is by nature more abstract and porous, so it matters less exactly where it is drawn.

Some countries mandate, sometimes by law, that maps used within their jurisdiction are drawn to support their opinions (and often, ideology). Therefore, rather than calling it a view, we could call it a mandatory_delusion where it differs from the ground truth (de facto) feature.

The logic for drawing might look something like:

ground_truth = feature.properties.get('ground_truth', 'draw')
key = "mandatory_delusion:" + this_country_code
should_draw = feature.properties.get(key, ground_truth)
if should_draw = 'draw':
  # draw it
# otherwise, don't draw it

In other words, a country-specific flag overrides a default "ground truth" flag, which defaults to drawing. If it turns out there are large blocks of similar delusions, we can do a two-level scheme (i.e: look for the country first and then the block for the override). This way we don't have to put a lot of extra properties on the large numbers of borders or labels which are not disputed.

[musculman]

I would really not call it something like mandatory_delusion or ground_truth. By the pure nature of this topic, it is highly sensitive and controversial, using property names like those can only cause problems. The word view derives from the fact that what you are seeing when using that view is just the world according to certain political understanding of a particular country, in other words, the political view of that country.
It's fine if another word is used, but if you look at other companies providing this solution, you will notice that the choice of words is always carefully considered.

Regarding the fact that it should not bloat non disputed borders, that is usually achieved by having a simple boolean that will tell you is_disputed= true|false and only if it is true you look for the additional optional values, like shown above. That way you just need a single value that can be nicely encoded.

Regarding the ground truth, please keep in mind, there is no such thing, only the truth according to certain political considerations, so the default view is in fact already an agreement between one or more countries. You could consider for example having the default view as the UN view, but even in that case, the UN considers many borders as disputed and there are many lines of control that further modify it, as I mentioned above. One should be very clear about what is their default view, whether it is UN, US or any other variety.

[zerebubuth]

Regarding the ground truth, please keep in mind, there is no such thing, only the truth according to certain political considerations

You're right, which is why (half-jokingly, although I should have telegraphed that more clearly 🙇‍♂️ ) I suggested we make this explicit in the property name. In many cases, there is physical infrastructure which can be measured as empirical truth, but I imagine the vast majority of borders are not marked physically in any way. I suppose that proves the point that people can be quite sensitive about being reminded of the (at best, consensual) unreality of borders.

having a simple boolean that will tell you is_disputed= true|false

There's no need for an additional boolean under the scheme I described, the presence of one or more view:${ISO_CODE} keys implies is_disputed=true and the absence of any implies false.

[musculman]

Thanks for the additional clarification.
Let me see if I understand that proposal correctly, because I think I am missing one point there.

In the case I mentioned in my first comment, of actual changes on the country border depending on the view; let's consider a border that only exists for country A and let's call that border X and every other country in the world puts that border somewhere else, let's call it border Y. Remember they are different geometries.
With the system you describe, how would you encode that?
Border X would have view:iso_of_country_A and nothing more but what would Border Y have? All other possible countries? or would it simply not mention any disputed? If you do that then the view of country A would also show it, that is why above I mentioned this mechanism of is_accepted_by and is_disputed_by... I know it is probably confusing so that's why I am happy to see a discussion to improve it / design something else that is better. Let me know please if I misunderstood your proposal or how to code such an example.
Just for the record, it is a real life example but I did not use real country names :) :)

[zerebubuth]

I'm suggesting that it could be described as:

• Border X properties: {"view:iso_A": "show"}
• Border Y properties: {"view:iso_A": "hide"}

(If we don't like show|hide then we could use accepts|disputes or True|False. I think show|hide would make more sense to people writing the map style, but any binary pair of values would work.)

It's possible to work out is_disputed by asking if any key starting in view: is show. We don't need to list the countries which follow the majority view - since there are only two options, they must hold the opposite view to the minority.

So Country A will show Border X and hide Border Y, because those are the explicit overrides. Any other country will show Border Y and hide Border X, because those are the defaults.

For more complex situations, where several countries hold a different view, the scheme still works although it may be wasteful to list them all out. The maximum number of different disputants that I can see is a six-way dispute over the Spratly Islands. However, there's very little common geometry amongst the claims, so I'd assume we'd still end up with a single view:XX property per feature.

[musculman]

Thank you for the explanation, I had indeed misunderstood it :)
For examples like the one you listed we might need to think of having also the additional properties like claimed_by or controlled_by depending on the routing capabilities that you want to support, if any, because you can usually ask your routing engine to avoid areas controlled by certain countries or to avoid disputed areas at all. For example if your user has a certain passport that is not allowed to cross some countries/borders.

[musculman]

I will try to create a first draft of what we have discussed on this, unless someone is already preparing it.

[nvkelso]

Suggest using "point of view" like we do language localization but instead by ISO 2-char country codes (in practice this is sparsely populated on minority of features, but then some features are very contentious!):

• is_accepted_by:{cc}=True

  • This border will be displayed in country B but not in country A.
  • {cc} is ISO 2-char country codes
  • This act as a "whitelist"
  • Optional value when a boundaries line is disputed in some way.
  • When value is False it is not exported in tiles
  • When no per country booleans are specified than that boundary is not disputed by anyone and renders by default.
  • When present the render only renders the line (visible=true) when it matches a stylesheet variable specifying the "point of view" as a 2-char country code.

• is_disputed_by:{cc}=True

  • This border will be displayed in all views, but not in country A.
  • {cc} is ISO 2-char country codes
  • This act as a "blacklist"
  • Optional value when a boundaries line is disputed in some way.
  • When value is False it is not exported in tiles
  • When no per country booleans are specified than that boundary is not disputed by anyone and renders by default.
  • When present the render will not render the line (visible=false) when it matches a stylesheet variable specifying the "point of view" as a 2-char country code.

Alternatively we could support an array of "point of view" values, like:

• is_accepted_by: [cc1, cc2, cc3, cc4]
• is_disputed_by: [cc1, cc2, cc3, cc4]
• This is not supported in current MVT encoder but there's a convention to support text string with JSON blob contents. GeoJSON and TopoJSON formats don't have issue with it.

We already have different boundary layer kind values (list) for the following, and the "point of view" can be applied equally to all of them:

• country
• disputed
• line_of_control
• indefinite
• indeterminate
• lease_limit
• overlay_limit
• map_unit
• region

With respect to "line of control":

• This is already covered with kinds: disputed, line_of_control, indefinite, indeterminate, lease_limit, and overlay_limit
• Please see how Natural Earth uses these for examples of each.
• So I think the same "claimed by" and "controlled by" can be handled the same as for normal country (and other)

[nvkelso]

I'm open to {"point_of_view:cc":"show"} or {"point_of_view:cc":"hide"}, too.

We could in that case still keep it "truthy" but make it True (show), False (hide), and Null (no opinion/use default point of view, drop the property)?

• "point_of_view:cc": True, False, Null

[zerebubuth]

I would prefer {"point_of_view:cc": "show"} or {"point_of_view:cc": "hide"}, because I think this is more readable than boolean values. If we really, really want to use default values, then I think we should use:

• {"is_accepted_by:cc": True} - means any cc listed in this feature accepts it, and other countries do not.
• {"is_accepted_by:cc": False} - means any cc listed in this feature does not accept it, and other countries do.

If the property isn't given (i.e: None), then the view of the country is that of the default majority, opposite to that of the explicitly listed minority.

[musculman]

@nvkelso: I have some questions about your last comment:

• was there any issue with @zerebubuth's approach? I was preparing this as a first draft of documentation as with his solution we could save one variable by deducting the value of the others assuming the defaults. Please would you mind explaining if you found any issue with it?
• nvkelso: I am not sure how do you want to apply the point of view to the boundary layer kind values list you mention, do you mind claryfing that?
• you are right, we can reuse existing line_of_control

Boundaries Layer

(...)

Natural Earth supports the concept of points of view (POV) to indicate the claimants for different boundary disputes.
When displaying a map you need to consider if you are going to support the different points of view or if you are just going to use the de-facto one, which is in line with US State Department and United Nations views (TODO: link?).
If a particular point of view is used, the boundaries of the selected country view are shown; otherwise the default boundaries view is shown.
A typical use case is that a particular area of the world is considered as disputed by two or more countries. Therefore, each country shows that area as part of itself. If you request a particular tile with the political view of country A, the response shows the area as belonging to A. Similarly, if you request the tile with the political view of country B, the response shows the area as belonging to B.
This means that in order to use this optional feature you need to define a point of view value, in a similar way as you define language localization, but using ISO 2-char country code.
In each case, in order to display correctly the disputed borders you need to understand what border should be displayed in each case, and control this logic on your Rendering Engine.

Please note that the the boundary layer kind line_of_control is also relevant for displaying correctly the point of view.

Border X properties: `{"view:iso_A": "true"}`
Border Y properties: `{"view:iso_A": "false"}`

Country A will show Border X and hide Border Y, because those are the explicit overrides. Any other country will show Border Y and hide Border X, because those are the defaults.
In case of borders that have different geometry depending on the point of view used, they will have view:iso_C and only the country with that point of view, C, in this case, will display the new geometry as everybody else will simply ignore it.
It's possible to work out what borders are disputed by asking if any key starting in view: is true. We don't need to list the countries which follow the majority view - since there are only two options, they must hold the opposite view to the minority.

Boundaries properties (optional):

(...)

• view:{cc} - it is a boolean field, where true represents show and false represents hide. Keep in mind that any other country not listed having this view will apply the default value. See the example above for more details.

Boundary kind_detail values for country

For kind country we can have the following optional kind_detail values:

• claimed_by - an attribute that indicates which country claims a cartographic administrate polygon or linear administrative boundary in a disputed area.
• controlled_by - in disputed areas which country is, according to international agreements, in control of the area.

[nvkelso]

Something like?

For undisputed country boundaries:

• "point_of_view": False which would be dropped from the tile
• "point_of_view:cc": Null which would be dropped from the tile

For disputed country boundaries where default needs to be hidden and different geometry shown:

• Default geom:
  • "point_of_view": True
  • "point_of_view:cc": False
• Alternative geom:
  • "point_of_view": True
  • "point_of_view:cc": True

Then Tangram would set (psuedocode):

layer:
    boundaries:
        disputed:
            filter: { point_of_view: True }
            draw:
                line:
                    // hide lines with points of view unless that country believes it's theirs
                    visible: function() { return feature['point_of_view:'+global.point_of_view_cc]) || false; }

I think claimed_by and controlled_by are useful for the backend database but shouldn't be exported in the vector tiles (instead transform them into point_of_view:cc).

I can take care of the documentation parts if this seems workable.

I'm curious if @bcamper thinks the above solution is best situation for Tangram.

[musculman]

@nvkelso are you still planning to do the documentation part? Otherwise I can follow with a PR on this.
But, because my latest proposal on my comment is slightly different compared to your last comment, it is perhaps better that you do it? Just let me know, thank you.