On Thu, Apr 10, 2008 at 9:24 AM, Lester Caine <[EMAIL PROTECTED]> wrote:
> Looking at the growing mess of wiki pages relating to > place/is_in/boundary/relations and the rest I think that I would not be > wasting my time now putting together a 'proposal' for good practice for > handling the simple hierarchy of is_in but it does need a means of > identifying > different 'Naga City' objects other than adding 'Camarines Sur, Luzon, > Philippines' to every use of it :( is_in is a short-term kludge. It's almost completely unnecessary when - and only when - we have boundaries for whatever the larger area is. Sometimes it's useful* when you don't. The key fact that everyone forgets is that everything we deal with has geographic coordinates. If you can give me a bounding polygon for a country (whether derived from OSM or VMAP0 or wherever) then I can tell you if a given amenity=pub is in that country. No need for any relations or is_in tags AT ALL. If we weren't talking about map data, then yes, we'd need a hierarchy. organisation=society,name=RNIB would need is_in=UK, for example, since there can't be coordinates for something that doesn't have a physical location. But we're not worried about that because we're talking about OpenStreetMap. If you want a list of islands in the Philippines, it's really quite straightforward. Give all the islands coastlines, define the boundary of the country, and hey presto the rest is just a SELECT statement. If you want to tag every island, ney every node in the database with what regions they lie within (via is_in or relations) then you're wasting your time. Cheers, Andy * Not sure to who, to be honest, but maybe the namefinder uses it? _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
