
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>

<p><br /></p>

<p>On 2017-03-07 07:43, Frederik Ramm wrote:</p>

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Kevin,<br /><br /> On 03/07/2017 02:06 AM, Kevin Kenny wrote:

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">There are reasonable use cases for wanting to take a timezone name and<br /> get back a multipolygon</blockquote>

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

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">or to get a list of name and multipolygon for<br /> all the timezones (or all the timezones on a given map). That's hard to<br /> do unless there are relations for the timezones. Not impossible, we<br /> could query administrative boundaries for the tag, but that's likely to<br /> be SLOW since the tag will at best be in hstore and not indexed.<br /> Grouping disjoint items, such as "all the administrative regions in a<br /> time zone" seems tailor-made for relations.</blockquote>

<br /> In my opinion, no. We've been there - people (ab)using relations like<br /> some kind of bookmark, to make data retrieval easier (e.g. a relation<br /> "all cycleways in XY city" just because it was slow/difficult to<br /> retrieve them otherwise).<br /><br /> You would typically use a relation to group things when they can be in<br /> more group than one, and therefore tagging the membership on the<br /> individual object becomes cumbersome - cycle, bus, or hiking routes are<br /> a prime example, since the same street/way can be part of several of them.<br /><br /> Not so with time zones, I should hope; a region can only be associated<br /> with exactly one (not 0, not more than one) time zone. Hence adding a<br /> time zone tag to the object is the easiest way to maintain the data and<br /> to ensure that you don't accidentally have two!<br /><br /> I agree it might make things a little more difficult for the consumer<br /> but an overpass query can quickly find every boundary relation tagged<br /> with a certain time zone, and I'm sure sooner or later specialist sites<br /> will take the data and prepare daily updated json files or whatever that<br /> one can overlay on a map.</div>

</blockquote>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">

<p>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.</p>

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

<p>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"</p>

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

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

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

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

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

<p>//colin</p>

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

</div>

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><br /> Bye<br /> Frederik</div>

</blockquote>

</body></html>