Adding non-administrative boundaries in vector tiles

[Rub21]

From OpenHistoricalMap/issues#1251
Non-administrative layers have been included in a separate provider named ohm_non_admin. We have also modified the boundary data fetching process. Previously, the imposm pipeline was designed to only store boundary=administrative in the database. We are now collecting all boundary=* tags and will use materialized views to filter between administrative and non-administrative data.

Since there is currently there is 3346 non-admin objects, we haven't implemented filters like admin_level for these layers yet. For administrative boundaries, we filter by admin_level for zoom levels, Do you think it's necessary to apply some kind of zoom-level filtering for these non-administrative layers as well?

currently deploy in staging https://vtiles.staging.openhistoricalmap.org/#1.57/13.5/27.1

cc. @1ec5

[1ec5]

Since there is currently there is 3346 non-admin objects, we haven't implemented filters like admin_level for these layers yet. For administrative boundaries, we filter by admin_level for zoom levels, Do you think it's necessary to apply some kind of zoom-level filtering for these non-administrative layers as well?

Possibly. Some boundary types always have admin_level=*, like boundary=indigenous_administration and boundary=religious_administration, so there’s no problem with reusing the filters. boundary=statistical also comes with admin_level=* much of the time. At low zoom levels, we can filter out boundaries with high administrative levels as well as the centroids of small boundaries.

Some boundary types don’t have anything like admin_level=*:

• boundary=place comes with place=*. We can reuse the filter for place=* on areas from other layers.
• boundary=timezone shouldn’t have any filter, although the centroid could be filtered based on size. They tend to be large enough to show at low zoom levels.
• boundary=postal_code can all be filtered out at the same time based on zoom level, since they’re inherently local features.

[1ec5]

I wonder if we should add any additional fields. A map of religious administration boundaries would probably want to filter by religion=* and denomination=*, while a map of time zone boundaries would probably want to style by utc=*. We could break out these relation types as separate layers, or if we combine them, then a more generic property could hold something that differentiates the features that share a single boundary type.