Does not return timezone for this lat long: tzwhere.tzNameAt(40.573238372802734, -73.99983978271484)

[avlakin]

tzwhere.tzNameAt(40.573238372802734, -73.99983978271484) => Null

Returns a null, but should be this: http://www.darrinward.com/lat-long/?id=92197

[benjie]

@thislakin I believe this is probably the same issue I'm facing with the source data, e.g. for the south coast of England:

Seems to be offset by roughly 0.005 degrees North West.

[mattbornski]

Interesting. Is there a newer/more correct set of source data available anywhere?

[paulochf]

I found this problem while using the Python port pytzwhere.
Also, I opened a issue there. pegler/pytzwhere/issues/15

@mattbornski, it also happens at Spain' southern coast.

[mattbornski]

Interesting to note that the Earth's land surface is of course always changing, whereas these polygons were generated by some person at one point in time and are not changing at the same rate. It seems natural to me that if I am off the coast of a landmass, I would treat myself as being in the timezone of that landmass. Is there any convention on that? If (hypothetically) there was some nautical convention that specified that ships at sea are not in any timezone, then what if we added a config flag for the sanity of anybody who is not oceangoing and fudged points outside of all polygons into the nearest polygon?

[benjie]

When I discovered the issue I shot Eric Muller (the author of the data) an email asking if I was doing something wrong, and he explained:

You have to realize that digital maps have a notion of scale, i.e. of precision of the data. That notion is present in paper maps, where it covers both the precision of the source data and the limits of resolution of printing and of the eye. In digital maps, because we can display them at an arbitrary zoom level, the second factor is not present, but the first is still there.

I think this explains the difference in the boundaries you observe. I used the VMAP0 boundary, which is at a scale of 1/1 million, and OpenStreetMap is probably using a higher scale (their polygons have more points). It's a bit as if VMAP0 had taken a picture with a 1 megapixel camera and OpenStreetMap had taken the same picture with a 10 megapixel camera.

As for the choice of using VMAP0: A digital map is often representing a single layer (a single king of data, e.g. tz boundaries) and is meant to be used in combination with other layers (e.g. political boundaries, or railroads, etc); then the coordination of the various layers is important. When a polygon side is both a tz boundary and a political boundary, it's almost more important that both layers use the same coordinates, rather than use more precise but different coordinates. My map/layer is meant to coordinate well with the VMAP0 layers, so it matches VMAP0 land and political boundaries, however precise those are.

Incidentally here's Paris (these were rendered by downloading Eric's tz_world.zip, running ogr2ogr -f GeoJSON tz_world.geojson tz_world.shp and then filtering just lines matching "Europe/London" or "Europe/Paris" (as necessary) and then pasting them into http://geojsonlint.com/):

[cstich]

I am not sure how relevant this is for this package, but I implemented a workaround in the python port of this package. See also this discussion.