<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>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.<br>
<br>
--<br>
Andrew
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Wolfgang Zenker <wolfgang@lyxys.ka.sub.org><br>
<b>Sent:</b> 07 March 2017 10:38:01<br>
<b>To:</b> Tag discussion, strategy and related tools<br>
<b>Subject:</b> Re: [Tagging] Mapping time zones as geometries (relations)</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi,<br>
<br>
* Colin Smale <colin.smale@xs4all.nl> [170307 09:04]:<br>
> [..]<br>
> It is possible to have enclaves/exclaves for a territory which differs<br>
> from the surrounding territory. Taking the US as an example, if we put a<br>
> timezone tag on a State, there may need to be an overriding tag on a<br>
> County or even possibly at a City level. There are also native homelands<br>
> that cross state boundaries which have their own ideas about time. See<br>
> [1] for more info on this. <br>
<br>
> We need to address reality; I suggest there are the following options: <br>
<br>
> 1) a multipolygon for the time zone, allowing for outer and inner rings,<br>
> sharing ways with admin boundaries where appropriate, otherwise<br>
> dedicated ways with "boundary=timezone" <br>
<br>
> 2) tagging admin boundary relations with their timezone, allowing<br>
> lower-level entities to override their parent <br>
<br>
> 3) only tagging (all!) low-level entities with their timezone to avoid<br>
> the enclave problems of option 2 <br>
<br>
> This is actually conceptually similar to the problem of territorial<br>
> defaults for maxspeed and loads of other things. <br>
<br>
> What about maritime TZ boundaries that don't correspond to an admin<br>
> boundary? <br>
<br>
As we have seen in this discussion so far, timezones in international<br>
waters are kind of meaningless or undefined.<br>
<br>
> I cannot believe it is beyond the abilities of OSM to represent time<br>
> zone areas. Of course it can be done. <br>
<br>
the question is not if OSM can represent timezones, rather if it should<br>
and if so, in which way to do it.<br>
<br>
Following the discussion so far it looks to me like we have a rough<br>
consensus that the geographical extend of timezones should be in OSM<br>
data.<br>
<br>
I suggest following the principle of using the simplest solution that<br>
can probably work. To me that would mean to follow your suggested<br>
option number 2 whereever possible and in the (rare) cases where it<br>
is not, to create multipolygons with boundary=timezone subdividing the<br>
administrative units that sit in multiple timezones. These multipolygons<br>
would be treated as lower-level entities overriding their parents.<br>
<br>
There was the argument that monstrous multipolygons spanning the length<br>
of half a continent are probably a recipe for unusable data that is<br>
constantly broken. This would to me exclude your option 1.<br>
<br>
Your option 3 appears to require loads and loads of redundant data<br>
that will be permanently incomplete; I would try to avoid this.<br>
<br>
Wolfgang<br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
Tagging@openstreetmap.org<br>
<a href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</div>
</span></font>
</body>
</html>