Re: [Tagging] Mapping time zones as geometries (relations)

[Kevin Kenny]

On Tue, Mar 7, 2017 at 1:43 AM, Frederik Ramm  wrote:

> On 03/07/2017 02:06 AM, Kevin Kenny wrote:
> > There are reasonable use cases for wanting to take a timezone name and
> > get back a multipolygon
>
> Question is, does (the core database of) OSM have to fulfil these use
> cases!
>

It at least has to hold the geodata needed for a client to satisfy them. If
it turns out that relations are The Wrong Thing, do we at least have
consensus that time zones are made up of administrative regions, whose
boundaries are a proper subject for OSM? (Time zone boundaries at the level
of detail demanded by tzdata are hard to obtain for many places; this is a
need that OSM could fill.)


> > or to get a list of name and multipolygon for
> > all the timezones (or all the timezones on a given map). That's hard to
> > do unless there are relations for the timezones. Not impossible, we
> > could query administrative boundaries for the tag, but that's likely to
> > be SLOW since the tag will at best be in hstore and not indexed.
> > Grouping disjoint items, such as "all the administrative regions in a
> > time zone" seems tailor-made for relations.
>
> In my opinion, no. We've been there - people (ab)using relations like
> some kind of bookmark, to make data retrieval easier (e.g. a relation
> "all cycleways in XY city" just because it was slow/difficult to
> retrieve them otherwise).
>

"All cycleways in XY city" is a very bad example, because PostGIS can do
that easily without relations. I do that sort of thing all the time, using
ST_Intersects queries. That doesn't work too well at the continental level,
though!


> You would typically use a relation to group things when they can be in
> more group than one, and therefore tagging the membership on the
> individual object becomes cumbersome - cycle, bus, or hiking routes are
> a prime example, since the same street/way can be part of several of them.
>
> Not so with time zones, I should hope; a region can only be associated
> with exactly one (not 0, not more than one) time zone. Hence adding a
> time zone tag to the object is the easiest way to maintain the data and
> to ensure that you don't accidentally have two!
>
> I agree it might make things a little more difficult for the consumer
> but an overpass query can quickly find every boundary relation tagged
> with a certain time zone, and I'm sure sooner or later specialist sites
> will take the data and prepare daily updated json files or whatever that
> one can overlay on a map.
>
>
Hmm... thinking here. The relation types I use most often are multipolygon
(not so much to group things, as to deal with shapes of complex topology),
route (no doubt the many-to-many example that you were thinking of) and
group - where there is a named object that is made up of components: chains
of lakes and archipelagoes come to mind. It struck me as if a time zone was
a similar thing to an archipelago: a named object made up of countries,
states, counties, whatever... non-overlapping component regions. But maybe
simply tagging administrative regions with their time zone names, and
having validators in places like JOSM to test for overlaps, will be good
enough.

As long as we have consensus that the administrative boundaries of time
zones, however structured, are proper subject material for OSM, I'm
reasonably content. I can add rules to my import of OSM data if I must, to
produce correctly-structured auxiliary tables.

Nevertheless, I think we need to consider the common use cases of:

(1) a map that wants to render time zone boundaries. I once did the
operator interface for the central control room of a very large television
broadcast network, and a map showing the locations of affiliate stations
and their timezones was a key component.

(2) a navigation system that wants to warn a driver or passenger that it's
time to change the clock.

(3) a system that can take a map click and answer the question of "what
time is it in this place?"

just as a sanity check that the data model is adequate in principle to
answer those questions.

We can presume that the rules for calculating "what time is it" are out of
scope. The question OSM has to answer is "what rule set applies in place
XXX?" and "where does the rule set named YYY apply?"
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Martin Koppenhoefer]

2017-03-07 12:42 GMT+01:00 Jaroslav Kameník :

> Personally I would compromise - leave timezone relations
> where really needed (river/meridian/territorial waters/...) and change them 
> to tagged A.B. otherwise.
>
>

+1

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Andrew Hain]

I think this idea is a winner. We have geometry  for the tricky cases but this 
can just fall through to the administrative geometry in places such as Arizona 
outside the reservations.

--
Andrew

From: Wolfgang Zenker <wolfg...@lyxys.ka.sub.org>
Sent: 07 March 2017 10:38:01
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] Mapping time zones as geometries (relations)

Hi,

* Colin Smale <colin.sm...@xs4all.nl> [170307 09:04]:
> [..]
> It is possible to have enclaves/exclaves for a territory which differs
> from the surrounding territory. Taking the US as an example, if we put a
> timezone tag on a State, there may need to be an overriding tag on a
> County or even possibly at a City level. There are also native homelands
> that cross state boundaries which have their own ideas about time. See
> [1] for more info on this.

> We need to address reality; I suggest there are the following options:

> 1) a multipolygon for the time zone, allowing for outer and inner rings,
> sharing ways with admin boundaries where appropriate, otherwise
> dedicated ways with "boundary=timezone"

> 2) tagging admin boundary relations with their timezone, allowing
> lower-level entities to override their parent

> 3) only tagging (all!) low-level entities with their timezone to avoid
> the enclave problems of option 2

> This is actually conceptually similar to the problem of territorial
> defaults for maxspeed and loads of other things.

> What about maritime TZ boundaries that don't correspond to an admin
> boundary?

As we have seen in this discussion so far, timezones in international
waters are kind of meaningless or undefined.

> I cannot believe it is beyond the abilities of OSM to represent time
> zone areas. Of course it can be done.

the question is not if OSM can represent timezones, rather if it should
and if so, in which way to do it.

Following the discussion so far it looks to me like we have a rough
consensus that the geographical extend of timezones should be in OSM
data.

I suggest following the principle of using the simplest solution that
can probably work. To me that would mean to follow your suggested
option number 2 whereever possible and in the (rare) cases where it
is not, to create multipolygons with boundary=timezone subdividing the
administrative units that sit in multiple timezones. These multipolygons
would be treated as lower-level entities overriding their parents.

There was the argument that monstrous multipolygons spanning the length
of half a continent are probably a recipe for unusable data that is
constantly broken. This would to me exclude your option 1.

Your option 3 appears to require loads and loads of redundant data
that will be permanently incomplete; I would try to avoid this.

Wolfgang

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Jaroslav Kameník]

Hi all,

this discussion has started because of me, so I would like to add few
comments:).

Should OSM contains timezone data? I think so. Some said, we should use other
sources and overlay them over OSM, but there is no direct mapping except
description in human languages, not too usable for computer. Other thing is that
available map sources use different shapefiles, so they are not aligned to OSM.
You know, I would like to see Prague timezone in my navigation walking along
Czech borders.:)

Should we use extra geometries for timezones? As Frederik wrote, there
are 80 timezone relations now.
There is about 850 other relations tagged with timezone attribute, so
timezone relations are just fraction
of the whole amount and I am not afraid that their amount will grow
(too much). Why? Timezone relations are used
in places where timezone border goes by river/meridian/territorial
waters or to split big countries instead
of tagging hundreds of counties/ We can eliminate some (most?) of
them, but not all of them. Btw. timezone tags
can be misused too - for example - I removed useless timezone tags
from hundreds of small relations in Germany during
timezones editation, there was tag at whole country, and at lots of
admin boundaries too.

Some wrote that timezones are changing. Yes, all OSM are still
changing, shops, bus stops, new buildings, forrests
cutted, we all do such editations often I think...

Some wrote that timezones are not visible. Yes, exactly as lots of
other data in OSM.

Some wrote - delete timezone relations! Thanx, guys, it took lots of
time and work to create them...


So, for me, as you can guess, timezone relations are good and usefull
solution, but I understand that there could be
problems with their sizes and dependence to other geometry. Personally
I would compromise - leave timezone relations
where really needed (river/meridian/territorial waters/...) and change
them to tagged A.B. otherwise.



Jaroslav
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Andy Mabbett]

On 6 March 2017 at 00:30, Frederik Ramm  wrote:

> you could easily build time zone
> geometries by either (a) keeping an external database that says "Time
> Zone X consists of the following administrative units" and then
> collecting the units from OSM

That database is Wikidata. make sure that the admin boundaries are
tagged with the relevant Wikidata ID.

> I still think that the mapping of time zones as geometries
> should be discouraged in OSM.

I agree.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Wolfgang Zenker]

Hi,

* Colin Smale  [170307 09:04]:
> [..]
> It is possible to have enclaves/exclaves for a territory which differs
> from the surrounding territory. Taking the US as an example, if we put a
> timezone tag on a State, there may need to be an overriding tag on a
> County or even possibly at a City level. There are also native homelands
> that cross state boundaries which have their own ideas about time. See
> [1] for more info on this. 

> We need to address reality; I suggest there are the following options: 

> 1) a multipolygon for the time zone, allowing for outer and inner rings,
> sharing ways with admin boundaries where appropriate, otherwise
> dedicated ways with "boundary=timezone" 

> 2) tagging admin boundary relations with their timezone, allowing
> lower-level entities to override their parent 

> 3) only tagging (all!) low-level entities with their timezone to avoid
> the enclave problems of option 2 

> This is actually conceptually similar to the problem of territorial
> defaults for maxspeed and loads of other things. 

> What about maritime TZ boundaries that don't correspond to an admin
> boundary? 

As we have seen in this discussion so far, timezones in international
waters are kind of meaningless or undefined.

> I cannot believe it is beyond the abilities of OSM to represent time
> zone areas. Of course it can be done. 

the question is not if OSM can represent timezones, rather if it should
and if so, in which way to do it.

Following the discussion so far it looks to me like we have a rough
consensus that the geographical extend of timezones should be in OSM
data.

I suggest following the principle of using the simplest solution that
can probably work. To me that would mean to follow your suggested
option number 2 whereever possible and in the (rare) cases where it
is not, to create multipolygons with boundary=timezone subdividing the
administrative units that sit in multiple timezones. These multipolygons
would be treated as lower-level entities overriding their parents.

There was the argument that monstrous multipolygons spanning the length
of half a continent are probably a recipe for unusable data that is
constantly broken. This would to me exclude your option 1.

Your option 3 appears to require loads and loads of redundant data
that will be permanently incomplete; I would try to avoid this.

Wolfgang

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Colin Smale]

On 2017-03-07 07:43, Frederik Ramm wrote:

> Kevin,
> 
> On 03/07/2017 02:06 AM, Kevin Kenny wrote: 
> 
>> There are reasonable use cases for wanting to take a timezone name and
>> get back a multipolygon
> 
> Question is, does (the core database of) OSM have to fulfil these use cases!
> 
>> or to get a list of name and multipolygon for
>> all the timezones (or all the timezones on a given map). That's hard to
>> do unless there are relations for the timezones. Not impossible, we
>> could query administrative boundaries for the tag, but that's likely to
>> be SLOW since the tag will at best be in hstore and not indexed.
>> Grouping disjoint items, such as "all the administrative regions in a
>> time zone" seems tailor-made for relations.
> 
> In my opinion, no. We've been there - people (ab)using relations like
> some kind of bookmark, to make data retrieval easier (e.g. a relation
> "all cycleways in XY city" just because it was slow/difficult to
> retrieve them otherwise).
> 
> You would typically use a relation to group things when they can be in
> more group than one, and therefore tagging the membership on the
> individual object becomes cumbersome - cycle, bus, or hiking routes are
> a prime example, since the same street/way can be part of several of them.
> 
> Not so with time zones, I should hope; a region can only be associated
> with exactly one (not 0, not more than one) time zone. Hence adding a
> time zone tag to the object is the easiest way to maintain the data and
> to ensure that you don't accidentally have two!
> 
> I agree it might make things a little more difficult for the consumer
> but an overpass query can quickly find every boundary relation tagged
> with a certain time zone, and I'm sure sooner or later specialist sites
> will take the data and prepare daily updated json files or whatever that
> one can overlay on a map.

It is possible to have enclaves/exclaves for a territory which differs
from the surrounding territory. Taking the US as an example, if we put a
timezone tag on a State, there may need to be an overriding tag on a
County or even possibly at a City level. There are also native homelands
that cross state boundaries which have their own ideas about time. See
[1] for more info on this. 

We need to address reality; I suggest there are the following options: 

1) a multipolygon for the time zone, allowing for outer and inner rings,
sharing ways with admin boundaries where appropriate, otherwise
dedicated ways with "boundary=timezone" 

2) tagging admin boundary relations with their timezone, allowing
lower-level entities to override their parent 

3) only tagging (all!) low-level entities with their timezone to avoid
the enclave problems of option 2 

This is actually conceptually similar to the problem of territorial
defaults for maxspeed and loads of other things. 

What about maritime TZ boundaries that don't correspond to an admin
boundary? 

I cannot believe it is beyond the abilities of OSM to represent time
zone areas. Of course it can be done. 

//colin 

[1] https://en.wikipedia.org/wiki/Time_in_the_United_States 

> Bye
> Frederik___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Frederik Ramm]

Kevin,

On 03/07/2017 02:06 AM, Kevin Kenny wrote:
> There are reasonable use cases for wanting to take a timezone name and
> get back a multipolygon

Question is, does (the core database of) OSM have to fulfil these use cases!

> or to get a list of name and multipolygon for
> all the timezones (or all the timezones on a given map). That's hard to
> do unless there are relations for the timezones. Not impossible, we
> could query administrative boundaries for the tag, but that's likely to
> be SLOW since the tag will at best be in hstore and not indexed.
> Grouping disjoint items, such as "all the administrative regions in a
> time zone" seems tailor-made for relations.

In my opinion, no. We've been there - people (ab)using relations like
some kind of bookmark, to make data retrieval easier (e.g. a relation
"all cycleways in XY city" just because it was slow/difficult to
retrieve them otherwise).

You would typically use a relation to group things when they can be in
more group than one, and therefore tagging the membership on the
individual object becomes cumbersome - cycle, bus, or hiking routes are
a prime example, since the same street/way can be part of several of them.

Not so with time zones, I should hope; a region can only be associated
with exactly one (not 0, not more than one) time zone. Hence adding a
time zone tag to the object is the easiest way to maintain the data and
to ensure that you don't accidentally have two!

I agree it might make things a little more difficult for the consumer
but an overpass query can quickly find every boundary relation tagged
with a certain time zone, and I'm sure sooner or later specialist sites
will take the data and prepare daily updated json files or whatever that
one can overlay on a map.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[wille]

I agree with deleting the timezone relations.

2017-03-05 21:30 GMT-03:00 Frederik Ramm :

> Hi,
>
>I would like to start a discussion about the mapping of time zones.
>
> There are currently 80 relations in OSM tagged as boundary=timezone
> using between them over 10,000 ways.
>
> I think that mapping these time zones as geometries has several issues:
>
> 1. It introduces yet another un-observable object type into OSM. When I
> asked about the source of the data, one person quipped "well you can
> observe it on a local clock", but the people adding time zone boundaries
> don't seem to actually do that - they copy the information from somewhere.
>
> 2. It is for the most part unnecessary noise; almost all time zone
> boundaries run along administrative boundaries, so you could just add a
> timezone tag to the administrative entity instead of mapping a whole
> separate geometry.
>
> 3. It complicates editing; anyone touching one of the aforementioned
> 10,000 ways (which are for the most part also used by admin boundaries)
> will be confronted with the time zone relation and will have to decide
> what to do with it.
>
> 4. It creates very large polygons that may be difficult to edit.
>
> Here's a list of time zones currently mapped in OSM (with relation ID)
>
> 3563652 Московское время
> 3563678 Екатеринбургское время
> 3563726 Красноярское время
> 3563727 Омское время
> 3563885 Иркутское время
> 3563886 Якутское время
> 3563937 Владивостокское время
> 4297465 Самарское время
> 6426325 Cherry County - Chicago TZ part
> 6426796 Idaho Denver TZ part
> 6426797 Idaho Los Angeles TZ part
> 6428675 Alaska - Timezone America/Adak
> 6428690 Alaska - Timezone America/Anchorage
> 6428730 Alaska - Timezone America/Yakutat
> 6428802 Alaska - Timezone America/Juneau
> 6428803 Alaska - Timezone America/Sitka
> 6428944 Canada - Timezone America/Pangnirtung
> 6430296 Malaysia - Kuala Lumpur Timezone
> 6430370 Kiribati - Kiritimati timezone
> 6430371 Kiribati - Tarava timezone
> 6430484 Greenland - timezone America/Danmarkshavn area
> 6430503 Greenland - timezone America/Thule area
> 6430514 Greenland - timezone America/GodThab area
> 6430515 Greenland - timezone America/Scoresbysund area
> 6430658 Хандыгское время
> 6440860 America/Tijuana Timezone
> 6440942 America/Merida Timezone
> 6440955 America/Cancun Timezone
> 6440975 America/Bahia_Banderas Timezone
> 6441066 America/Mazatlan Timezone
> 6442501 America/Mexico_City Timezone
> 6442514 America/Santa_Isabel Timezone
> 6442531 America/Hermosillo Timezone
> 6442686 America/Matamoros Timezone
> 6442687 America/Ojinaga Timezone
> 6442693 America/Chihuahua Timezone
> 6442726 America/Monterrey Timezone
> 6442820 America/Edmonton Timezone part
> 6442821 America/Regina Timezone
> 6442822 America/Winnipeg Timezone part
> 6445625 America/Eirunepe Timezone
> 6445626 America/Manaus Timezone
> 6445682 America/Belem Timezone
> 6445683 America/Santarem Timezone
> 6445860 Asia/Dushanbe Timezone part
> 6446092 Arizona - America/Phoenix Timezone
> 6446108 America/Atikokan Timezone
> 6446109 America/Winnipeg Timezone
> 6446170 America/Cambridge_Bay Timezone
> 6446189 America/Rankin_Inlet Timezone
> 6446190 America/Resolute Timezone
> 6451096 Atlantic/Azores Timezone
> 6451097 Atlantic/Madeira Timezone
> 6451098 Europe/Lisbon Timezone
> 6451458 America/Coral_Harbour Timezone
> 6451459 America/Iqaluit Timezone
> 6483867 Ontario - America/Toronto Timezone
> 6483978 America/Creston Timezone
> 6483979 America/Dawson_Creek Timezone
> 6483980 America/Edmonton Timezone
> 6483981 America/Vancouver Timezone
> 6485969 Asia/Sakhalin Timezone
> 6491030 America/Argentina/Buenos_Aires Timezone
> 6491031 America/Argentina/Catamarca Timezone
> 6491032 America/Argentina/Rio_Gallegos Timezone
> 6491033 America/Argentina/Salta Timezone
> 6491034 America/Argentina/Ushuaia Timezone
> 6491133 Atlantic/Canary Timezone
> 6491134 Europe/Madrid Timezone
> 6491494 America/Chicago Timezone
> 6496417 America/New_York Timezone
> 6496587 America/Indiana/Indianapolis Timezone
> 6496665 America/Boise Timezone
> 6496694 America/Los_Angeles Timezone
> 6498476 America/Menominee Timezone
> 6498563 America/Detroit Timezone
> 6498592 America/Nipigon Timezone
> 6498593 America/Thunder_Bay Timezone
> 6594626 Магаданское время
> 6594635 Камчатское время
>
> And here's them in a map:
>
> http://www.remote.org/frederik/tmp/tz.jpg
>
> Now when you overlay the administrative boundaries on levels 2 and 4,
> only very few lines remain:
>
> http://www.remote.org/frederik/tmp/tz4.jpg
>
> And when you go up to admin level 6:
>
> http://www.remote.org/frederik/tmp/tz6.jpg
>
> Assuming that these boundaries are actually correct, the only places in
> which time zone boundaries don't follow admin boundaries are:
>
> * In South America, the Western boundary of the Manaus timezone and the
> Eastern boundary of the Santarem timezone;
>
> * In North America, the line between the Hermosillo and Santa Isabel
> timezones, 

Re: [Tagging] Mapping time zones as geometries (relations)

[Mike Thompson]

On Mon, Mar 6, 2017 at 6:06 PM, Kevin Kenny 
wrote:

>
>
> It seems that having a 'group' relation for all the administrative regions
> that use a given timezone would be useful. The timezone data itself, of
> course, belongs separate, but the group relation would, to my thinking, be
> more useful than merely tagging each administrative region with the
> timezone it keeps.
>
+1

>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Kevin Kenny]

The timezone database does not map the geographic extents of timezones.
Rather, it lists them by name and gives the rules for what time they keep.
The geography is explicitly out of scope, so the tzdata maintainers really
shouldn't have anything to say about OSM mapping time zones!

There are reasonable use cases for wanting to take a timezone name and get
back a multipolygon, or to get a list of name and multipolygon for all the
timezones (or all the timezones on a given map). That's hard to do unless
there are relations for the timezones. Not impossible, we could query
administrative boundaries for the tag, but that's likely to be SLOW since
the tag will at best be in hstore and not indexed. Grouping disjoint items,
such as "all the administrative regions in a time zone" seems tailor-made
for relations.

It seems that having a 'group' relation for all the administrative regions
that use a given timezone would be useful. The timezone data itself, of
course, belongs separate, but the group relation would, to my thinking, be
more useful than merely tagging each administrative region with the
timezone it keeps.

As someone who imports tzdata into a third-party system on a very regular
basis, I can verify that while the rules for the timezones undergo constant
churn - there are 20-30 releases of the database in a typical year - the
boundaries change hardly at all, except for splits when one administrative
region goes one way and another region goes another. In those cases, we
already very likely have the administrative boundaries, and merely need to
move bits from one relation to another.

The mapping between tzdata names and geography really isn't available
anywhere else, and it's surely something that I'd use if OSM had it.



On Mon, Mar 6, 2017 at 6:30 PM, Aun Johnsen  wrote:

> >
> > On 3/6/17 11:21 AM, Paul Johnson wrote:
> >> On Mar 5, 2017 18:30, "Frederik Ramm"  >> > wrote:
> >>
> >>Hi,
> >>
> >>   I would like to start a discussion about the mapping of time
> zones.
> >>
> >>
> >>What do you think?
> >>
> >>
> >> I'm generally opposed to mapping timezones in OpenStreetMap unless the
> >> tzdata maintainers are 100% on board.  Since timezones are a royal
> >> pain to keep track of, often changing 100+ times a year, on as little
> >> as a few hours notice in some cases.
> >>
> > i agree. this a perfect example of something that belongs in its own
> > database or
> > shape file, available to be overlaid on the map when it's wanted.
> >
> > richard
> >
> > --
> > rwe...@averillpark.net
> > Averill Park Networking - GIS & IT Consulting
> > OpenStreetMap - PostgreSQL - Linux
> > Java - Web Applications - Search
> Actually, timezones are to great extent already mapped, you only have to
> find a better way to extract the data, instead of creating new relations.
> There might still be administrative relations that doesn’t have timezone
> tag set making the timezone data incomplete, but this is not a reason to
> create new relations, but rather add the missing data in existing relations.
>
>
>
>
> Aun Johnsen
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Aun Johnsen]

> 
> On 3/6/17 11:21 AM, Paul Johnson wrote:
>> On Mar 5, 2017 18:30, "Frederik Ramm" > > wrote:
>> 
>>Hi,
>> 
>>   I would like to start a discussion about the mapping of time zones.
>> 
>> 
>>What do you think?
>> 
>> 
>> I'm generally opposed to mapping timezones in OpenStreetMap unless the
>> tzdata maintainers are 100% on board.  Since timezones are a royal
>> pain to keep track of, often changing 100+ times a year, on as little
>> as a few hours notice in some cases.
>> 
> i agree. this a perfect example of something that belongs in its own
> database or
> shape file, available to be overlaid on the map when it's wanted.
> 
> richard
> 
> -- 
> rwe...@averillpark.net
> Averill Park Networking - GIS & IT Consulting
> OpenStreetMap - PostgreSQL - Linux
> Java - Web Applications - Search
Actually, timezones are to great extent already mapped, you only have to find a 
better way to extract the data, instead of creating new relations. There might 
still be administrative relations that doesn’t have timezone tag set making the 
timezone data incomplete, but this is not a reason to create new relations, but 
rather add the missing data in existing relations.




Aun Johnsen


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[L. David Baron]

On Monday 2017-03-06 14:15 -0500, Richard Welty wrote:
> On 3/6/17 11:21 AM, Paul Johnson wrote:
> > On Mar 5, 2017 18:30, "Frederik Ramm"  > > wrote:
> >
> > Hi,
> >
> >I would like to start a discussion about the mapping of time zones.
> >
> >
> > What do you think?
> >
> >
> > I'm generally opposed to mapping timezones in OpenStreetMap unless the
> > tzdata maintainers are 100% on board.  Since timezones are a royal
> > pain to keep track of, often changing 100+ times a year, on as little
> > as a few hours notice in some cases.
> >
> i agree. this a perfect example of something that belongs in its own
> database or
> shape file, available to be overlaid on the map when it's wanted.

For what it's worth, data of this sort are maintained at
http://efele.net/maps/tz/ , although the shapefiles there (based on
VMAP0) are somewhat inferior to OSM data, since a number of the
national boundaries (e.g., using the Sudanese claim for the
Egypt/Sudan border) or coastlines (e.g., Aral Sea) are quite out of
date, in ways that are noticeable when overlaying the data.

Apparently the
http://efele.net/maps/tz/world/tz_world_ingredients.zip file there
has information that could be used to rebuild the shapefiles on top
of other sources of data, but I've never attempted to do this.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Richard Welty]

On 3/6/17 11:21 AM, Paul Johnson wrote:
> On Mar 5, 2017 18:30, "Frederik Ramm"  > wrote:
>
> Hi,
>
>I would like to start a discussion about the mapping of time zones.
>
>
> What do you think?
>
>
> I'm generally opposed to mapping timezones in OpenStreetMap unless the
> tzdata maintainers are 100% on board.  Since timezones are a royal
> pain to keep track of, often changing 100+ times a year, on as little
> as a few hours notice in some cases.
>
i agree. this a perfect example of something that belongs in its own
database or
shape file, available to be overlaid on the map when it's wanted.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Colin Smale]

On 2017-03-06 17:51, Paul Johnson wrote:

> On Mon, Mar 6, 2017 at 10:42 AM, Colin Smale  wrote:
> 
> On 2017-03-06 17:21, Paul Johnson wrote: 
> 
> On Mar 5, 2017 18:30, "Frederik Ramm"  wrote:
> Hi,
> 
> I would like to start a discussion about the mapping of time zones. 
> 
> What do you think? 
> I'm generally opposed to mapping timezones in OpenStreetMap unless the tzdata 
> maintainers are 100% on board.  Since timezones are a royal pain to keep 
> track of, often changing 100+ times a year, on as little as a few hours 
> notice in some cases.

Do you mean territories switch to another timezone 100+ times a year, or
that the details of the timezone (DST dates etc) change 100+ times a
year? If it's the latter, it won't be a problem for OSM if we only store
the TZ name. Looking at the archives of the tz-announce mailing list,
there are only 1-2 actual changes per month which would affect OSM. I
think there are more changes to admin boundaries than to timezones. 

No, the maddening number of changes unrelated to DST.  Computerphile
rather accurately describes the situation [1].  I only have to deal with
it tertiarily in my line of work and it's still caused a lot of problems
for us as a company. 

Interesting video! Nothing new there for me though. The number of times
a territory changes to a new time zone is very limited. His example of
Libya where DST was cancelled with basically no notice does not put
Libya into a new TZ - it changes the definition of the TZ. So this would
not require any changes to OSM. Cyprus on the other hand would require
maintenance in OSM (last year its TZ split so TRNC now follows mainland
Turkey and can therefore be an hour different to the rest of the
island). But changes like these are "relatively rare" and well within
the capabilities of OSM and its mappers to maintain with minimal effort.
All we have in OSM is the name of the timezone, e.g. Europe/London. 

>> In what way would the tzdata maintainers need to be "on board"?
> 
> Considering that group most closely tracks this, it would be best if we 
> worked very closely together on getting this data right.  A lack of close 
> collaboration would rather render having this data in OpenStreetMap outdated 
> very quickly.

There is a mailing list for updates to tzdata -
https://mm.icann.org/mailman/listinfo/tz-announce 

//colin 

Links:
--
[1] https://www.youtube.com/watch?v=-5wpm-gesOY___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Paul Johnson]

On Mon, Mar 6, 2017 at 10:42 AM, Colin Smale  wrote:

> On 2017-03-06 17:21, Paul Johnson wrote:
>
> On Mar 5, 2017 18:30, "Frederik Ramm"  wrote:
>
> Hi,
>
>I would like to start a discussion about the mapping of time zones.
>
>
>
> What do you think?
>
>
> I'm generally opposed to mapping timezones in OpenStreetMap unless the
> tzdata maintainers are 100% on board.  Since timezones are a royal pain to
> keep track of, often changing 100+ times a year, on as little as a few
> hours notice in some cases.
>
>
> Do you mean territories switch to another timezone 100+ times a year, or
> that the details of the timezone (DST dates etc) change 100+ times a year?
> If it's the latter, it won't be a problem for OSM if we only store the TZ
> name. Looking at the archives of the tz-announce mailing list, there are
> only 1-2 actual changes per month which would affect OSM. I think there are
> more changes to admin boundaries than to timezones.
>

No, the maddening number of changes unrelated to DST.  Computerphile rather
accurately describes the situation
.  I only have to deal with it
tertiarily in my line of work and it's still caused a lot of problems for
us as a company.


> In what way would the tzdata maintainers need to be "on board"?
>

Considering that group most closely tracks this, it would be best if we
worked very closely together on getting this data right.  A lack of close
collaboration would rather render having this data in OpenStreetMap
outdated very quickly.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Colin Smale]

On 2017-03-06 17:21, Paul Johnson wrote:

> On Mar 5, 2017 18:30, "Frederik Ramm"  wrote:
> 
>> Hi,
>> 
>> I would like to start a discussion about the mapping of time zones.
> 
>> What do you think?
> 
> I'm generally opposed to mapping timezones in OpenStreetMap unless the tzdata 
> maintainers are 100% on board.  Since timezones are a royal pain to keep 
> track of, often changing 100+ times a year, on as little as a few hours 
> notice in some cases.

Do you mean territories switch to another timezone 100+ times a year, or
that the details of the timezone (DST dates etc) change 100+ times a
year? If it's the latter, it won't be a problem for OSM if we only store
the TZ name. Looking at the archives of the tz-announce mailing list,
there are only 1-2 actual changes per month which would affect OSM. I
think there are more changes to admin boundaries than to timezones. 

In what way would the tzdata maintainers need to be "on board"? 

//colin___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Paul Johnson]

On Mar 5, 2017 18:30, "Frederik Ramm"  wrote:

Hi,

   I would like to start a discussion about the mapping of time zones.


What do you think?


I'm generally opposed to mapping timezones in OpenStreetMap unless the
tzdata maintainers are 100% on board.  Since timezones are a royal pain to
keep track of, often changing 100+ times a year, on as little as a few
hours notice in some cases.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Rafael Avila Coya]

I generally agree with your view.

The wiki [1] already says: "An effective way to tag timezone information 
is to add it to administration boundaries of countries or in the case of 
larger countries smaller administrative boundaries such as states and 
territories. (Do not create stand-alone boundaries for time zones in OSM.)"


I would keep the timezone data in OSM, but doing it that way: adding the 
timezone tag to boundary relations (most countries, some states and few 
level-6), except for those very rare cases it doesn't follow an admin 
boundary.


Cheers,

Rafael.

[1] http://wiki.openstreetmap.org/wiki/Key:timezone

On 06/03/17 01:30, Frederik Ramm wrote:

Hi,

   I would like to start a discussion about the mapping of time zones.

There are currently 80 relations in OSM tagged as boundary=timezone
using between them over 10,000 ways.

I think that mapping these time zones as geometries has several issues:

1. It introduces yet another un-observable object type into OSM. When I
asked about the source of the data, one person quipped "well you can
observe it on a local clock", but the people adding time zone boundaries
don't seem to actually do that - they copy the information from somewhere.

2. It is for the most part unnecessary noise; almost all time zone
boundaries run along administrative boundaries, so you could just add a
timezone tag to the administrative entity instead of mapping a whole
separate geometry.

3. It complicates editing; anyone touching one of the aforementioned
10,000 ways (which are for the most part also used by admin boundaries)
will be confronted with the time zone relation and will have to decide
what to do with it.

4. It creates very large polygons that may be difficult to edit.

Here's a list of time zones currently mapped in OSM (with relation ID)

3563652 Московское время
3563678 Екатеринбургское время
3563726 Красноярское время
3563727 Омское время
3563885 Иркутское время
3563886 Якутское время
3563937 Владивостокское время
4297465 Самарское время
6426325 Cherry County - Chicago TZ part
6426796 Idaho Denver TZ part
6426797 Idaho Los Angeles TZ part
6428675 Alaska - Timezone America/Adak
6428690 Alaska - Timezone America/Anchorage
6428730 Alaska - Timezone America/Yakutat
6428802 Alaska - Timezone America/Juneau
6428803 Alaska - Timezone America/Sitka
6428944 Canada - Timezone America/Pangnirtung
6430296 Malaysia - Kuala Lumpur Timezone
6430370 Kiribati - Kiritimati timezone
6430371 Kiribati - Tarava timezone
6430484 Greenland - timezone America/Danmarkshavn area
6430503 Greenland - timezone America/Thule area
6430514 Greenland - timezone America/GodThab area
6430515 Greenland - timezone America/Scoresbysund area
6430658 Хандыгское время
6440860 America/Tijuana Timezone
6440942 America/Merida Timezone
6440955 America/Cancun Timezone
6440975 America/Bahia_Banderas Timezone
6441066 America/Mazatlan Timezone
6442501 America/Mexico_City Timezone
6442514 America/Santa_Isabel Timezone
6442531 America/Hermosillo Timezone
6442686 America/Matamoros Timezone
6442687 America/Ojinaga Timezone
6442693 America/Chihuahua Timezone
6442726 America/Monterrey Timezone
6442820 America/Edmonton Timezone part
6442821 America/Regina Timezone
6442822 America/Winnipeg Timezone part
6445625 America/Eirunepe Timezone
6445626 America/Manaus Timezone
6445682 America/Belem Timezone
6445683 America/Santarem Timezone
6445860 Asia/Dushanbe Timezone part
6446092 Arizona - America/Phoenix Timezone
6446108 America/Atikokan Timezone
6446109 America/Winnipeg Timezone
6446170 America/Cambridge_Bay Timezone
6446189 America/Rankin_Inlet Timezone
6446190 America/Resolute Timezone
6451096 Atlantic/Azores Timezone
6451097 Atlantic/Madeira Timezone
6451098 Europe/Lisbon Timezone
6451458 America/Coral_Harbour Timezone
6451459 America/Iqaluit Timezone
6483867 Ontario - America/Toronto Timezone
6483978 America/Creston Timezone
6483979 America/Dawson_Creek Timezone
6483980 America/Edmonton Timezone
6483981 America/Vancouver Timezone
6485969 Asia/Sakhalin Timezone
6491030 America/Argentina/Buenos_Aires Timezone
6491031 America/Argentina/Catamarca Timezone
6491032 America/Argentina/Rio_Gallegos Timezone
6491033 America/Argentina/Salta Timezone
6491034 America/Argentina/Ushuaia Timezone
6491133 Atlantic/Canary Timezone
6491134 Europe/Madrid Timezone
6491494 America/Chicago Timezone
6496417 America/New_York Timezone
6496587 America/Indiana/Indianapolis Timezone
6496665 America/Boise Timezone
6496694 America/Los_Angeles Timezone
6498476 America/Menominee Timezone
6498563 America/Detroit Timezone
6498592 America/Nipigon Timezone
6498593 America/Thunder_Bay Timezone
6594626 Магаданское время
6594635 Камчатское время

And here's them in a map:

http://www.remote.org/frederik/tmp/tz.jpg

Now when you overlay the administrative boundaries on levels 2 and 4,
only very few lines remain:

http://www.remote.org/frederik/tmp/tz4.jpg

And when you go up to admin level 6:

http://www.remote.org/frederik/tmp/tz6.jpg

Assuming 

[Tagging] Mapping time zones as geometries (relations)

[Frederik Ramm]

Hi,

   I would like to start a discussion about the mapping of time zones.

There are currently 80 relations in OSM tagged as boundary=timezone
using between them over 10,000 ways.

I think that mapping these time zones as geometries has several issues:

1. It introduces yet another un-observable object type into OSM. When I
asked about the source of the data, one person quipped "well you can
observe it on a local clock", but the people adding time zone boundaries
don't seem to actually do that - they copy the information from somewhere.

2. It is for the most part unnecessary noise; almost all time zone
boundaries run along administrative boundaries, so you could just add a
timezone tag to the administrative entity instead of mapping a whole
separate geometry.

3. It complicates editing; anyone touching one of the aforementioned
10,000 ways (which are for the most part also used by admin boundaries)
will be confronted with the time zone relation and will have to decide
what to do with it.

4. It creates very large polygons that may be difficult to edit.

Here's a list of time zones currently mapped in OSM (with relation ID)

3563652 Московское время
3563678 Екатеринбургское время
3563726 Красноярское время
3563727 Омское время
3563885 Иркутское время
3563886 Якутское время
3563937 Владивостокское время
4297465 Самарское время
6426325 Cherry County - Chicago TZ part
6426796 Idaho Denver TZ part
6426797 Idaho Los Angeles TZ part
6428675 Alaska - Timezone America/Adak
6428690 Alaska - Timezone America/Anchorage
6428730 Alaska - Timezone America/Yakutat
6428802 Alaska - Timezone America/Juneau
6428803 Alaska - Timezone America/Sitka
6428944 Canada - Timezone America/Pangnirtung
6430296 Malaysia - Kuala Lumpur Timezone
6430370 Kiribati - Kiritimati timezone
6430371 Kiribati - Tarava timezone
6430484 Greenland - timezone America/Danmarkshavn area
6430503 Greenland - timezone America/Thule area
6430514 Greenland - timezone America/GodThab area
6430515 Greenland - timezone America/Scoresbysund area
6430658 Хандыгское время
6440860 America/Tijuana Timezone
6440942 America/Merida Timezone
6440955 America/Cancun Timezone
6440975 America/Bahia_Banderas Timezone
6441066 America/Mazatlan Timezone
6442501 America/Mexico_City Timezone
6442514 America/Santa_Isabel Timezone
6442531 America/Hermosillo Timezone
6442686 America/Matamoros Timezone
6442687 America/Ojinaga Timezone
6442693 America/Chihuahua Timezone
6442726 America/Monterrey Timezone
6442820 America/Edmonton Timezone part
6442821 America/Regina Timezone
6442822 America/Winnipeg Timezone part
6445625 America/Eirunepe Timezone
6445626 America/Manaus Timezone
6445682 America/Belem Timezone
6445683 America/Santarem Timezone
6445860 Asia/Dushanbe Timezone part
6446092 Arizona - America/Phoenix Timezone
6446108 America/Atikokan Timezone
6446109 America/Winnipeg Timezone
6446170 America/Cambridge_Bay Timezone
6446189 America/Rankin_Inlet Timezone
6446190 America/Resolute Timezone
6451096 Atlantic/Azores Timezone
6451097 Atlantic/Madeira Timezone
6451098 Europe/Lisbon Timezone
6451458 America/Coral_Harbour Timezone
6451459 America/Iqaluit Timezone
6483867 Ontario - America/Toronto Timezone
6483978 America/Creston Timezone
6483979 America/Dawson_Creek Timezone
6483980 America/Edmonton Timezone
6483981 America/Vancouver Timezone
6485969 Asia/Sakhalin Timezone
6491030 America/Argentina/Buenos_Aires Timezone
6491031 America/Argentina/Catamarca Timezone
6491032 America/Argentina/Rio_Gallegos Timezone
6491033 America/Argentina/Salta Timezone
6491034 America/Argentina/Ushuaia Timezone
6491133 Atlantic/Canary Timezone
6491134 Europe/Madrid Timezone
6491494 America/Chicago Timezone
6496417 America/New_York Timezone
6496587 America/Indiana/Indianapolis Timezone
6496665 America/Boise Timezone
6496694 America/Los_Angeles Timezone
6498476 America/Menominee Timezone
6498563 America/Detroit Timezone
6498592 America/Nipigon Timezone
6498593 America/Thunder_Bay Timezone
6594626 Магаданское время
6594635 Камчатское время

And here's them in a map:

http://www.remote.org/frederik/tmp/tz.jpg

Now when you overlay the administrative boundaries on levels 2 and 4,
only very few lines remain:

http://www.remote.org/frederik/tmp/tz4.jpg

And when you go up to admin level 6:

http://www.remote.org/frederik/tmp/tz6.jpg

Assuming that these boundaries are actually correct, the only places in
which time zone boundaries don't follow admin boundaries are:

* In South America, the Western boundary of the Manaus timezone and the
Eastern boundary of the Santarem timezone;

* In North America, the line between the Hermosillo and Santa Isabel
timezones, the Phoenix timezone, a small part of the boundary between
the Los Angeles and Boise time zones in Malheur county, the Chicago
Timezone in Cherry County, a piece of the Los Angeles timezone in Idaho,
the line between Vancouver and Dawson Creek respectively Creston
timezones, two incursions into the Regina timezone for Edmonton and
Winnipeg, two micro