[OSM-talk] Naga City in OSM Re: GML to OSM

[Lester Caine]

Andy Allan wrote:
> On Thu, Apr 10, 2008 at 9:24 AM, Lester Caine <lester at lsces.co.uk> 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