On Fri, May 30, 2008 at 3:57 PM, Andy Allan <[EMAIL PROTECTED]> wrote: > Yes, for rendering decisions like X >=5. That doesn't imply it's the > best approach for storing the data. Don't tag for renderers etc.
It's not tagging for renderers. It's tagging for anything that wishes to programmatically extract administration-type data from the OSM database. > So how can one admin level be globally defined, but another one isn't? > "Within a country" is a farcial statement, since this entire > conversation has shown there is no global equivalence to the meaning > of the word "country". You don't need a passport to travel from Wales > to England, nor from Belgium to Luxembourg, and the United Arab > Emirates adds a whole new level of complexity... Easy, because "country" is one of the few things in the world there is a broad concensus over: if you can issue a passport or not is a pretty good test. Not perfect, but as long you can settle on a definition that matches the criteria I set down below then I don't particularly care. No idea about Wales vs England but travelling from Belgium to Luxembourg you most certainly need a passport or ID card. You don't need to *show* it to anybody, but that's a different issue entirely. Let me tell you how I see the boundary/admin_level data being defined: - Every point on the globe should be, for each value of admin_level, either in exactly one boundary at that level, or be outside all boundaries at all levels greater than or equal to this one. - At any single boundary level, the sets of boundaries at that level, together with the set of points outside any area cover the entire globe (there are no gaps). - admin_levels nest, so that the area covered by an admin_level=X is also covered by areas with admin_level > X With these constraints we can implement an is_in system. You can pick any point on the earths surface and find all the boundaries it is inside. Other GIS systems can do this, so why shouldn't OSM? I think the problem is that you're trying to derive other non-geographic information from this, like whether you need a passport or not. If you want that, please go invent a new set of tags because that's a completely different problem. > You miss the point entirely, I think. Each renderer would choose the > number of boundary types it wants to distinguish between, and would > have a rule for each. My point is that you're proposing creating hundreds of boundary types and then requiring every renderer to know about all the types. We don't have hundreds of highway types so we should use the same idea here: encode an approximation of the most important useful feature and use additional tags to describe the details. > not some kind of small minded kludge where someone stood up one day > and said "there can only be 10 types of border in OSM". Or do we > accept floating point values? We havn't said there can be only 10 types, we've said that we only expect there to be upto 10 levels of nesting. What the boundary means politically is completely orthoginal. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
