basemaps fix(tiles): disputed boundaries for incomplete relational data

Sometimes the disputed tags are not existing on the relations itself and we need to additionally check on the OSM ways for disputed tags.

Here is a comparison on the Morocco wall:

Before on main After fix

Apr 28 '25 10:04 mxzinke

Thanks for working on the disputed tag. In general we aim to align the protomaps basemap as far as possible with tilezen.

Can you have a look at how they handled boundaries and include also the other things they had? Maybe things like "dispute" and "claimed_by" etc...

See https://github.com/tilezen/vector-datasource/blob/89eeec6e98c6f5ae25d72970953ba93bb8b635a1/yaml/boundaries.yaml#L107

Apr 29 '25 14:04 wipfli

https://github.com/tilezen/vector-datasource/blob/89eeec6e98c6f5ae25d72970953ba93bb8b635a1/yaml/boundaries.yaml#L107

Can we create an issue for that instead, would like to fix these boundaries first, than we can discuss further?

Apr 29 '25 14:04 mxzinke

The tilezen logic breaks down roughly to this:

  - filter:
      all:
        - geom_type: line
        - unrecognized_dispute: yes
    min_zoom: 8
    output:
      <<: [ *output_properties, *dispute_properties ]
      kind: unrecognized
    table: osm

The above means if the unrecognized_dispute tag is truthy, set kind = unrecognized

  - filter:
      all:
        - geom_type: line
        - admin_level: ['2', '4', '6']
        - boundary: claim
        - any:
            - claimed_by: true
            - disputed_by: true
            - recognized_by: true
    min_zoom: 8
    output:
      <<: [ *output_properties, *dispute_properties ]
      kind: disputed_claim
    table: osm

The above means that if admin_level is 2, 4, or 6, and boundary=claim, and either claimed_by, disputed_by, or recognized_by is truthy, then set kind = disputed_claim

  - filter:
      all:
        - geom_type: line
        - disputed_by: true
        - any:
            - dispute: 'yes'
            - disputed: 'yes'
    min_zoom: 8
    output:
      <<: [ *output_properties, *dispute_properties ]
      kind: mz_internal_dispute_mask
    table: osm

The above means that if disputed_by is truthy and either dispute or disputed is truthy, usemz_internal_dispute_mask for the kind value.

  # These are kind=disputed_reference_lines that, for viewpoint XX in disputed_by,
  # project to kind:xx=unrecognized.  The lua preprocessing
  # project admin_level 3 and 5 cases to appropriate tags for us, so we don't need
  # to handle them here
  - filter: {admin_level: ['2','4','6'], boundary: disputed, geom_type: line}
    min_zoom: 8
    output:
      <<: [ *output_properties, *dispute_properties ]
      kind: disputed_reference_line
      kind_detail: {col: admin_level }
    table: osm

The above means that if admin_level is 2, 4, or 6, and boundary=disputed, set kin = disputed_reference_line and kind_detail to the admin_level osm tag.

The above rules evaluate from top to bottom if I remember correctly, so the first one which matches will be taken.

Apr 30 '25 05:04 wipfli

The mz_internal_dispute_mask is defined here: https://github.com/tilezen/vector-datasource/blob/89eeec6e98c6f5ae25d72970953ba93bb8b635a1/vectordatasource/transform.py#L9438

Apr 30 '25 05:04 wipfli

@wipfli I suggest not moving the tag from kind=country to kind=unrecognized_country for disputed boundaries, since this is a breaking change and style may need to be adjusted.

For now, I added more osm tags to set the disputed=true tag. I think this does not match the right logic as proposed by you — yet. Let's apply this fix for now and drafting the correct behavior in a separate PR.

Apr 30 '25 08:04 mxzinke

Sorry for the delay. I plan to review this pr on Monday. The direction looks already good.

May 09 '25 13:05 wipfli

Thanks for this pull request. According to taginfo, the dispute tag has recently seen a lot of removals, so I think it is best not to include it. The tag disputed on the other hand seems to be active:

May 12 '25 05:05 wipfli

I will push changes directly to your branch @mxzinke

May 12 '25 05:05 wipfli

From how I understand the code, we now require for a line to be in the boundaries layer that it is part of a relation with boundary=administrative, disputed, claim. On disputed boundaries one would expect that boundary=disputed, but as you have pointed out there are situations for example on the Berm where we find boundary=administrative on the relation but then disputed=yes on the way. This tagging seems a bit odd but your pull request seems to fix the issue correctly.

May 12 '25 06:05 wipfli

@mxzinke do you know if there are examples where we have boundary=administrative on the relation and boundary=disputed or claim on the way?

May 12 '25 06:05 wipfli

Thanks for fixing up the PR!