On Tue, Mar 7, 2017 at 1:43 AM, Frederik Ramm <frede...@remote.org> 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
