Potentially wrong results returned about pytzwhere HOT 17 OPEN

I checked the points manually. It looks like pytzwhere is not dealing with polygons within polygons correctly. Your results are indeed correct.

from pytzwhere.

Thanks for the info. As far as I remember that area of Arizona is a mess due to the Navajo Nation and the Hopi. I will check it out though :)

from pytzwhere.

I also think it is because of polygons within polygons. My algorithms is stopping when the point was found to be included in a polygon, too. I decided not to change my algorithm, because actually this is a mistake within the data and correcting it would make it ugly and slow.

from pytzwhere.

That makes sense. However, it is actually not a mistake in the data. It is legitimate for timezones to have timezones within them.

from pytzwhere.

Why? Then your data would suggest that this area is in two timezones... I don't think that makes sense.

from pytzwhere.

I should rephrase this for clarity. I didn't mean to say that a point would actually be in two polygons, but within the American/Denver timezone there is a part that is American/Phoenix. This video does a much better job at explaining it than I ever could.

from pytzwhere.

But still a timezone has to be unique and therefore the surrounding timezone would need to be excluded from the surrounded tz. Otherwise algorithms don't really have a chance of deciding which timezone it is (except hardcoding it) or am I wrong here?

from pytzwhere.

Polygons can't have holes in them. To ensure every coordinate was located within exactly one polygon would require changing the data to have a "seam" connecting the hole with the outer boundary. So it's just a matter of convention. We pull the data from http://efele.net/maps/tz/world/ and they follow one convention. The only solution here would be to reprocess the data to remove all layered polygons.

from pytzwhere.

The original data from Eric Muller does have holes though. I just checked.

from pytzwhere.

"Holes" as in the polygon defines both an outer and inner boundary?

from pytzwhere.

For me the ideal solution would be to convince them to correct the data (for me layered polygons are mistakes), but I don't know realistic this is.
By the way do you have a way of automatically creating your .csv from efele.net data?
I thought about that issue , but I just decided to leave it that way for now. There are just a few points where this matters and the effort for fixing this seemed to big.

from pytzwhere.

Yes a "hole" as in having an outer and inner boundary

from pytzwhere.

I remember running into issues with "holes" when initially working on this project. I can dig in next week to see if I can figure it out

from pytzwhere.

@MrMinimal64 I wrote a very short shell script that converts Eric Muller's shapefiles into a GEOjson.

@pegler Maybe it makes sense to use the multi-polygon timezone data? I used the polygon one so far but this discussion makes me wonder if we shouldn't use the other.

from pytzwhere.

I think I know how to fix this. I am working on it.

from pytzwhere.

This should now be fixed in the development branch. The development branch now correctly deals with holes. There are a few other little things I would like to add to that branch before we can release it but for testing timezonefinder it should already be sufficient

from pytzwhere.

@cstich @pegler hi guys, is there any new progress on this?

from pytzwhere.