Re: [tz] Fixing GeoNames timezone error
I’ll post a more detailed comment on GitHub later, and link to my own code where I’m trying to use your boundaries to solve some of these issues. For the example of Walpole Island, Ontario, when I try to find a zone that contains the lat/long of this location, I oddly get the match for America/Nigipon rather than America/Toronto (at least it’s not America/Detroit, as GeoNames has it). I get several matches, in fact, for America/Nigipon that don’t make sense, given that this zone should have a very small area. I’m using the @turf/turf npm library to parse the shape files, and booleanPointInPolygon() to check if a particular zone contains a specific lat/long point.
Evan Siroky <evan.siroky@yahoo.com> writes:
Hello, I'm the maintainer of?https://github.com/evansiroky/timezone-boundary-builder?which is a project that?extracts data from Open Street Map (OSM) to build shape files of the boundaries of the world's timezones. If you find inaccuracies with the data generated from this project, I'd love to know about these problems. Feel free to submit an issue in the GitHub project noting any problem that you see. Evan
The Nipigon/Toronto is a pet peeve of mine. It is the result of some questionable data inside Openstreetmap (OSM). Nipigon is a small township in Northern Ontario with a population of 1473 and an area of 108 square km. To put this into perspective: -Nipigon contains 0.01% of Ontario's total population. -Nipigon makes up 0.01% of Ontario's total land area. Inside OSM, somebody moved 73% of the land in Ontario into the *America/Nipigon* timezone. It was done with about 120 separate changesets between February and June of 2020. Some of the changesets have no source; others list "Shanks" as a reference. After following this mailing list for 15 years, I am very skeptical of the work published by Shanks, but I am in no position to prove it is wrong. I am also skeptical that anybody travelling directly by car from Windsor to Montreal (post 1970) would have had to pass through multiple time zone regions. The OSM relations are listed below. Note that if you click on the OSM links, the colour orange is used for both inner and outer boundaries thus the inner polygons are "holes" or "excluded areas". Without shading, it is not always simple to recognize this. The relations are large and may take some time to load in your browser. OSM America/Toronto relation: Includes most of Quebec and most urban centres in Ontario. Area: 1,546,844.1 square km. https://www.openstreetmap.org/relation/6483867#map=5/53.592/-73.135 OSM America/Nipigon relation: Includes most rural areas of Ontario east of 90°W Also includes a few populated centers such as Sarnia (pop: 72,047) and Barrie (pop: 147,829). Area: 787,493.2 square km. https://www.openstreetmap.org/relation/6498592#map=6/45.982/-81.573
From a daylight saving standpoint, both zones have been the same since 1974.
It would be very helpful if somebody could accurately determine when Barrie and Sarnia started using daylight saving (without using Shanks or OSM as a reference). -chris On Thu, 7 Jul 2022 at 15:11, Kerry Shetline via tz <tz@iana.org> wrote:
I’ll post a more detailed comment on GitHub later, and link to my own code where I’m trying to use your boundaries to solve some of these issues.
For the example of Walpole Island, Ontario, when I try to find a zone that contains the lat/long of this location, I oddly get the match for America/Nigipon rather than America/Toronto (at least it’s not America/Detroit, as GeoNames has it). I get several matches, in fact, for America/Nigipon that don’t make sense, given that this zone should have a very small area.
I’m using the @turf/turf npm library to parse the shape files, and booleanPointInPolygon() to check if a particular zone contains a specific lat/long point.
Evan Siroky <evan.siroky@yahoo.com> writes:
Hello, I'm the maintainer of? https://github.com/evansiroky/timezone-boundary-builder?which is a project that?extracts data from Open Street Map (OSM) to build shape files of the boundaries of the world's timezones. If you find inaccuracies with the data generated from this project, I'd love to know about these problems. Feel free to submit an issue in the GitHub project noting any problem that you see. Evan
I agree with Chris. I'm adding a reference to the GitHub issue that Kerry created. https://github.com/evansiroky/timezone-boundary-builder/issues/131 Evan On Friday, 8 July 2022 at 04:22:26 am GMT+2, Chris Walton via tz <tz@iana.org> wrote: The Nipigon/Toronto is a pet peeve of mine.It is the result of some questionable data inside Openstreetmap (OSM). Nipigon is a small township in Northern Ontario with a population of 1473 and an area of 108 square km.To put this into perspective: -Nipigon contains 0.01% of Ontario's total population.-Nipigon makes up 0.01% of Ontario's total land area. Inside OSM, somebody moved 73% of the land in Ontario into the America/Nipigon timezone. It was done with about 120 separate changesets between February and June of 2020. Some of the changesets have no source; others list "Shanks" as a reference.After following this mailing list for 15 years, I am very skeptical of the work published by Shanks, but I am in no position to prove it is wrong.I am also skeptical that anybody travelling directly by car from Windsor to Montreal (post 1970) would have had to pass through multiple time zone regions. The OSM relations are listed below.Note that if you click on the OSM links, the colour orange is used for both inner and outer boundaries thus the inner polygons are "holes" or "excluded areas". Without shading, it is not always simple to recognize this.The relations are large and may take some time to load in your browser. OSM America/Toronto relation: Includes most of Quebec and most urban centres in Ontario. Area: 1,546,844.1 square km. https://www.openstreetmap.org/relation/6483867#map=5/53.592/-73.135 OSM America/Nipigon relation: Includes most rural areas of Ontario east of 90°W Also includes a few populated centers such as Sarnia (pop: 72,047) and Barrie (pop: 147,829). Area: 787,493.2 square km. https://www.openstreetmap.org/relation/6498592#map=6/45.982/-81.573
From a daylight saving standpoint, both zones have been the same since 1974.
It would be very helpful if somebody could accurately determine when Barrie and Sarnia started using daylight saving (without using Shanks or OSM as a reference). -chris On Thu, 7 Jul 2022 at 15:11, Kerry Shetline via tz <tz@iana.org> wrote: I’ll post a more detailed comment on GitHub later, and link to my own code where I’m trying to use your boundaries to solve some of these issues. For the example of Walpole Island, Ontario, when I try to find a zone that contains the lat/long of this location, I oddly get the match for America/Nigipon rather than America/Toronto (at least it’s not America/Detroit, as GeoNames has it). I get several matches, in fact, for America/Nigipon that don’t make sense, given that this zone should have a very small area. I’m using the @turf/turf npm library to parse the shape files, and booleanPointInPolygon() to check if a particular zone contains a specific lat/long point.
Evan Siroky <evan.siroky@yahoo.com> writes:
Hello, I'm the maintainer of?https://github.com/evansiroky/timezone-boundary-builder?which is a project that?extracts data from Open Street Map (OSM) to build shape files of the boundaries of the world's timezones. If you find inaccuracies with the data generated from this project, I'd love to know about these problems. Feel free to submit an issue in the GitHub project noting any problem that you see. Evan
I mentioned earlier in this email thread that a large portion of Ontario (including the city of Barrie) is currently within the America/Nipigon boundary in Openstreetmap (OSM). I am 100% convinced the boundary is completely wrong. e.g. #1: The city of Barrie has been using daylight saving (during summer months) since at least 1930 which means it should be included within the America/Toronto boundary instead of the America/Nipigon boundary. Here are some newspaper pages containing Barrie daylight saving announcements for several different years that I picked at random: 1930: https://news.ourontario.ca/2760660/page/1835517 1946: https://news.ourontario.ca/2909650/page/13 1960: https://news.ourontario.ca/2919309/page/2280030 1970: https://news.ourontario.ca/2914181/page/2325462 1972: https://news.ourontario.ca/2917630/page/2349924 e.g. #2: I found documented proof that Prince Edward County was using daylight saving in 1970 which means it too should be moved from America/Nipigon to America/Toronto. Realistically it has probably been using daylight saving since WWII or earlier. The Kingston Whig Standard published this blurb on April 25, 1970:
PICTON — Clocks go ahead one hour here Saturday night or Sunday morning, whichever you prefer, as Daylight Saving Time takes over in Prince Edward County.
OSM mapper "ArcticGnome" claims to have based the OSM boundaries for America/Nipigon and America/Toronto on Shanks and Pottenger's International Atlas without realizing that much of the Shanks & Pottenger data was fake. Both myself and ArcticGnome are now pondering whether the inaccuracy of the data warrants eliminating the following zones from OSM. America/Nipigon America/Rainy_River America/Thunder_Bay America/Glace_Bay I believe that that decision should depend on whether Paul decides to continue maintaining them as dedicated zones in the TZ database. In my opinion, none of the data for these zones is trustworthy. *America/Nipigon*: Currently the TZ database shows that America/Nipigon adopted daylight saving in 1974. I don't have a complete history of daylight saving for Nipigon, but I did find a page from the Nipigon Gazette that clearly shows daylight saving ending for the 1972 season on October 29, 1972. https://news.ourontario.ca/npl/122271/page/2 The implication is that Nipigon has been using daylight saving since at least 1972 and therefore the data we are using for America/Nipigon is bogus. *America/Rainy_River*: I could not find any useful information to prove that the data for this zone is either correct or incorrect. *America/Thunder_Bay*: The TZ database shows that Thunder Bay and Toronto have been in sync since 1970 except for the year 1973. The database shows Thunder Bay skipped daylight saving in 1973. However, a relatively recent article in the Bayview Magazine seems to indicate that Thunder Bay did not actually skip daylight saving in 1973: http://www.bayviewmagazine.com/article/2022/03/great-springing-forward-debat... I sent an email to both the author of that article and one of the Thunder Bay archivists. In the email I asked for clarification about 1973. I will post here if I actually get a response. *America/Glace_Bay*: The TZ database shows Glace Bay adopted daylight saving in 1972. It is possible that this data is correct, but I am a bit skeptical. Glace Bay is a small town about 10km from Sydney. According to this document, Sydney was observing daylight saving in the year 1969: https://articles.adsabs.harvard.edu//full/1970JRASC..64..129T/0000135.000.ht... There is no compelling reason to believe that Sydney would have abandoned daylight saving in 1970 and 1971. And there is no compelling reason to believe that Glace Bay would have kept its clocks out of sync with Sydney during the summers of 1970 and 1971. The truth about Glace Bay (and other communities in Cape Breton) will likely exist in the archives of the Cape Breton Post which are maintained on microfilm at the Cape Breton Regional Library in Sydney and at the Nova Scotia Archives in Halifax. -chris On Fri, 8 Jul 2022 at 05:33, Evan Siroky <evan.siroky@yahoo.com> wrote:
I agree with Chris.
I'm adding a reference to the GitHub issue that Kerry created. https://github.com/evansiroky/timezone-boundary-builder/issues/131
Evan
On Friday, 8 July 2022 at 04:22:26 am GMT+2, Chris Walton via tz < tz@iana.org> wrote:
The Nipigon/Toronto is a pet peeve of mine. It is the result of some questionable data inside Openstreetmap (OSM).
Nipigon is a small township in Northern Ontario with a population of 1473 and an area of 108 square km. To put this into perspective: -Nipigon contains 0.01% of Ontario's total population. -Nipigon makes up 0.01% of Ontario's total land area.
Inside OSM, somebody moved 73% of the land in Ontario into the *America/Nipigon* timezone. It was done with about 120 separate changesets between February and June of 2020. Some of the changesets have no source; others list "Shanks" as a reference. After following this mailing list for 15 years, I am very skeptical of the work published by Shanks, but I am in no position to prove it is wrong. I am also skeptical that anybody travelling directly by car from Windsor to Montreal (post 1970) would have had to pass through multiple time zone regions.
The OSM relations are listed below. Note that if you click on the OSM links, the colour orange is used for both inner and outer boundaries thus the inner polygons are "holes" or "excluded areas". Without shading, it is not always simple to recognize this. The relations are large and may take some time to load in your browser.
OSM America/Toronto relation: Includes most of Quebec and most urban centres in Ontario. Area: 1,546,844.1 square km. https://www.openstreetmap.org/relation/6483867#map=5/53.592/-73.135
OSM America/Nipigon relation: Includes most rural areas of Ontario east of 90°W Also includes a few populated centers such as Sarnia (pop: 72,047) and Barrie (pop: 147,829). Area: 787,493.2 square km. https://www.openstreetmap.org/relation/6498592#map=6/45.982/-81.573
From a daylight saving standpoint, both zones have been the same since 1974.
It would be very helpful if somebody could accurately determine when Barrie and Sarnia started using daylight saving (without using Shanks or OSM as a reference).
-chris
On Thu, 7 Jul 2022 at 15:11, Kerry Shetline via tz <tz@iana.org> wrote:
I’ll post a more detailed comment on GitHub later, and link to my own code where I’m trying to use your boundaries to solve some of these issues.
For the example of Walpole Island, Ontario, when I try to find a zone that contains the lat/long of this location, I oddly get the match for America/Nigipon rather than America/Toronto (at least it’s not America/Detroit, as GeoNames has it). I get several matches, in fact, for America/Nigipon that don’t make sense, given that this zone should have a very small area.
I’m using the @turf/turf npm library to parse the shape files, and booleanPointInPolygon() to check if a particular zone contains a specific lat/long point.
Evan Siroky <evan.siroky@yahoo.com> writes:
Hello, I'm the maintainer of? https://github.com/evansiroky/timezone-boundary-builder?which is a project that?extracts data from Open Street Map (OSM) to build shape files of the boundaries of the world's timezones. If you find inaccuracies with the data generated from this project, I'd love to know about these problems. Feel free to submit an issue in the GitHub project noting any problem that you see. Evan
I'm reminded of the situation in Arizona with the Navajo and Hopi nations and adjacent towns, some of which have DST rules not necessarily in keeping with what you might expect for their locations: https://www.timeanddate.com/time/us/arizona-no-dst.html . There may be some other oddities in towns bordering Nevada and/or Idaho, IIRC. On Thu, Jul 7, 2022 at 12:11 PM Kerry Shetline via tz <tz@iana.org> wrote:
I’ll post a more detailed comment on GitHub later, and link to my own code where I’m trying to use your boundaries to solve some of these issues.
For the example of Walpole Island, Ontario, when I try to find a zone that contains the lat/long of this location, I oddly get the match for America/Nigipon rather than America/Toronto (at least it’s not America/Detroit, as GeoNames has it). I get several matches, in fact, for America/Nigipon that don’t make sense, given that this zone should have a very small area.
I’m using the @turf/turf npm library to parse the shape files, and booleanPointInPolygon() to check if a particular zone contains a specific lat/long point.
Evan Siroky <evan.siroky@yahoo.com> writes:
Hello, I'm the maintainer of? https://github.com/evansiroky/timezone-boundary-builder?which is a project that?extracts data from Open Street Map (OSM) to build shape files of the boundaries of the world's timezones. If you find inaccuracies with the data generated from this project, I'd love to know about these problems. Feel free to submit an issue in the GitHub project noting any problem that you see. Evan
-- Alan Mintz <Alan.Mintz@gMail.com>
participants (4)
-
Alan Mintz -
Chris Walton -
Evan Siroky -
Kerry Shetline