feat(cli-vector): adjust the layers assigned to each schema layer BM-1299

[tawera-manaena]

This PR is a sibling of this PR in the basemaps-config repository.

---

Motivation

As a general rule, all features assigned to a particular Shortbread layer should have the same geometry type, with exceptions (i.e. the contours and land layers).

Currently, we have a few Shortbread layers that comprise features of differing geometry types (e.g. Points and Polygons, rather than Points only). We also have some datasets that are duplicated across layers and that are not targeted by any style entries. Such duplicates can be removed.

Modifications

I have identified and resolved the following inconsistencies for the following Shortbread layers:

• pois

  The pois layer contains Point and Polygon features. It should only contain Point features.

  • Moved the 50326-nz-rifle-range-polygons-topo-150k dataset to the sites layer and updated the stylesheet.

  I've changed the tags for the following features to more appropriate OSM key-value pairs:

  • Changed the tag for historic site Point features and updated the stylesheet.
  • Changed the tag for ladder Point features and updated the stylesheet.

• streets

  The streets layer contains LineString, Point and Polygon features. It should only contain LineString features.

  • Moved the following datasets to the pois layer and updated the stylesheet:

    • 50275-nz-ford-points-topo-150k
    • 50080-nz-chatham-island-ford-points-topo-150k

  • Removed the following datasets as they already live under the street_polygons layer and are not targeted by any style entries under the streets layer:

    • airports:

      • 50237-nz-airport-polygons-topo-150k
      • 50063-nz-chatham-island-airport-polygons-topo-150k
      • 52231-cook-islands-airport-polygons-topo-125k-zone4
      • 52168-niue-airport-polygons-topo-150k

    • runways:

      • 50333-nz-runway-polygons-topo-150k
      • 50914-nz-kermadec-is-runway-polygons-topo-125k
      • 52302-cook-islands-runway-polygons-topo-125k-zone3
      • 52268-cook-islands-runway-polygons-topo-125k-zone4
      • 52211-cook-islands-runway-polygons-topo-150k-zone4
      • 52190-niue-runway-polygons-topo-150k
      • 50103-nz-chatham-island-runway-polygons-topo-150k

I have adjusted the 'special tagging' logic for the following Shortbread layers:

• place_labels

  The logic for handling place_labels features currently preserves null-like values for certain properties. For example:

  { ... "natural": "cape", "place": "city", "water": "0" }
  

  I've adjusted the logic so that properties with values of "0" are interpreted as undefined. This is desired as such properties are already optional. This now allows us to discard such property key-value pairs instead of carrying them through.

  Before	After

Verification

I built this pull request as a container and triggered a Vector ETL Argo workflow using it. Once the workflow finished, I updated the topographic-v2 tileset to point to the 2193 and 3857 Cotar files generated by the workflow. This gave me previews links from which I could check that my schema and stylesheet changes were in-sync:

• Previews

  • labels-v2

  • topographic-v2

• Screenshots

  • sites: rifle range

    labels-v2

    topographic-v2

  • pois: ford

    topographic-v2

  • pois: historic sites

    topographic-v2

  • pois: ladder points

    topographic-v2

[tawera-manaena]

One moment. Something doesn't seem right about the place_labels features.

[tawera-manaena]

One moment. Something doesn't seem right about the place_labels features.

Before - In this commit, I had adjusted the logic for place_labels features with the intent of resolving properties with values of "0" as undefined. However, my zod changes meant that any feature with a "0" valued property was resolved to undefined at the wrong point in the sequence of checks. In other words, because undefined is not of type string, such properties failed the zod check, resulting in the feature being discarded.

After - In this commit, I've corrected the logic by pre-processing "0" valued properties as undefined before zod checks that it is an optional string, i.e. string | undefined. In other words, the zod check now works the way it was supposed to. So, features with "0" valued properties are no longer being discarded.

In the following screenshots, we can see that all of the expected place_labels features pass through intact:

Before	After