Andy Allan wrote: > 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.
I think the problem here is the simple one of 'volume of data'. Apart from the problem of correctly mapping every one of the 7100 (manings figure) islands of the Philippines, trying to identify if a node is within that enormous maze of polygons is not something that any database could return quickly? That is not to say that such processing should not be done, but even drawing some of these boundaries may be impossible for some time? So an alternative agreed stepping stone seems sensible? is_in - if correctly managed using a uniquely identifiable place node hierarchy is a short term solution to the lack of boundaries, but more important, a long term solution to the possibly tera-bytes of data that may need to be processed to establish a full is_in tree? As I have already said we have the is_in tree for parish and ward information for the UK, but as yet no comprehensive set of boundary data so importing it as a tree which can be referenced and then used as is_in data for towns and villages on the map allows the information to be available. I suppose the simple question is - "Are we only producing a map?" or are we producing a database of geographically related data which we can use for many other purposes. I keep being told that I can add what ever I like to the database, and it is up to the renderers if that information is used, so I thought that information that is supplementary to the raw physical location and area information is acceptable but loading the servers with requests to calculate all the nodes in the Manhattan area of New York would be reduced if all we need to look at are nodes that are 'is_in:Manhattan' ? And simply looking at 'place:Manhattan' returns the 'New York, United States' information without any further complex processing? -- Lester Caine - G8HFL ----------------------------- Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
