Replace holes with the corresponding boundary polygons

[jannikmi]

The dataset contains (boundary) polygons with holes. Hole are not really empty. It is a special property of the dataset that holes are actually filled by boundary polygons of another zone.

Storing and processing holes separately is actually redundant. This can be improved.

• First assert that for every hole exactly one boundary polygon of a different zone with equal bbox can be found
• ...

Also mention this in the upstream data set project?

[ringsaturn]

It's interesting to see this between "America/Denver" and "America/Phoenix". 😆

https://ringsaturn.github.io/tzf-web/?markers=%5B%7B%22lat%22%3A35.7354%2C%22lng%22%3A-110.1242%7D%2C%7B%22lat%22%3A36.058%2C%22lng%22%3A-111.1871%7D%5D&lat=36.057981&lng=-110.643311&zoom=9

[jannikmi]

@ringsaturn yes, by working in the timezone domain I learn a lot about the complexities of our civilisation.
Actually I found Asia/Jerusalem vs Asia/Gaza to be most problematic: (real geopolitical complexity)
cf. https://github.com/jannikmi/timezonefinder/blob/350-replace-holes-with-boundaries/prototypes/hole_boundary_analysis_findings.md#interpretation

[jannikmi]

@ringsaturn have you done something similar in your library?
@evansiroky is that something you can fix "upstream" in your boundary builder directly?

[ringsaturn]

Yes, I have a geojson file define some areas should be excluded from pre-index step: https://github.com/ringsaturn/tzf/blob/main/preindex/exclude.geojson

[evansiroky]

I believe these boundary definitions are correct to the best of my knowledge. The boundaries can certainly be changed if there is evidence there should be a change.

[jannikmi]

Sorry @evansiroky, I was not very specific. What I meant was that the polygon holes are redundant to other polygon boundary shapes. Is that something the geoJSON format requires, or could these redundancies be removed from your dataset?

[evansiroky]

I believe the "holes" of one zone are necessary so as to not imply that the zone is present in the area where an enclave of another zone should exist.

[jannikmi]

@evansiroky You are right. The semantic of the hole is required, but the duplicate storage of hole and enclave polygon is not. Instead of storing the hole coordinates, one could for example just point to the enclave polygon (ID). Is that something your dataset format (or geoJSON) could support?

If not, the downstream libraries like timezonefinder would need to individually implement such an optimisation.