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

Lester Caine lester at lsces.co.uk
Thu Apr 10 09:24:39 BST 2008


maning sambale wrote:
> At zoom level 4, placenames for major cities appear, but no country
> names at any level.
> Perhaps, there should be one for levels 4-6.

This is part of the missing hierarchy of identification data. We do need the 
data before it can be rendered.

> I do remember that we added a node tagged as country and name
> Philippines.  Do I need to add an is_in tag for every island (7100 +
> high tide or low tide)?

There is a need for a PLACE or AREA to contain the island names, and the is_in 
tags for contained objects can then use that outer object, but the current 
inconclusive debate is whether that data should be created automatically from 
area objects or managed as relational data.

Naga City is a nice example of the need for some management of 
hierarchy/relationships since we have Naga City, Camarines Sur, Luzon, 
Philippines and Naga City, Cebu, Philippines - that is if I read wikipedia 
correctly. You certainly do not want to add 'Naga City, Camarines Sur, Luzon, 
Philippines' as an 'is_in' to every element of that particular city, so what 
is needed is some sort of unique tag for 'Naga City, Camarines Sur, Luzon, 
Philippines'

The ideal way of doing that would be to have a unique tag number for the place 
object 'Naga City, Camarines Sur, Luzon, Philippines' and 'Naga City, Cebu, 
Philippines' but the current interrupted debate relates to the hierarchy 
contained there. Cebu and Luzon are islands in the Philippines so they should 
have is_in references to the 'Philippines' place object. Camarines Sur is one 
of the six provinces of Luzon, so each province should have a place or 
boundary object with an is_in of Luzon - which then adds the Philippines 
element of the location. The two Naga City objects are then identified as 
is_in the relevant area.

Given that there ARE thousands of islands and presumably even more provinces 
on each of the larger ones? Then drawing the boundaries of every object is 
going to be a long term job, so what WE need to agree on is a method of adding 
all 7100 islands as places initially all with an is_in of the Philippines 
which can then be included for rendering at the relevant zoom level. It would 
also be nice - and hopefully perfectly acceptable - for each of those places 
to have a link to it's wikipedia information? ( I do HATE the idea of doing 
that given the wikipedia arrogance to culling perfectly rounded data as shown 
perfectly by the very page we are talking about - 
http://en.wikipedia.org/wiki/Naga_City%2C_Camarines_Sur - but in the absence 
of any alternative free source ... )

> On 4/9/08, Richard Fairhurst <richard at systemed.net> wrote:
>> Lester Caine wrote:
>>
>>> I repeat - WHERE are you getting that information by zooming out.
>>> Nothing says that this group of islands is the Philippines
>> They're just right and down a bit from Hong Kong, which is where the
>> Philippines are generally to be found.
>>
>> The easy way to distinguish them from, say, Anglesey is that Anglesey
>> is just off the coast of Wales and its capital is Llangefni, not
>> Manila. HTH.
>>
>> On a more serious note, I agree that it would be quite cool to have
>> country names displayed on the smallest scale maps, but the best way
>> to achieve this is by actually suggesting it rather than complaining
>> that the world has let you down "once again", replete with capital
>> letters and an unhappy smiley. (Actually, that's the third best way.
>> The second best way is to log a trac ticket. The best way of all is to
>> post a patch. ;) )

Richard - I have been banging on about the complete anarchy in relational data 
for over three years now and I don't think that any of the proposals to tidy 
things up have been accepted. The good practice guide that finally appeared in 
February does at least state the first principle - that there should only be 
one object for each physical element on the ground, but I think that there is 
still no agreement on 'node and area' conflicts, so the process of moving 
object data such as the islands of the Philippines from simple node tags to 
area tags can currently mean that there may be both a node and an area for an 
object.

The problem is that there is a complete block on anything that affects the 
'free format' style of all input to osm and it is that block which is 
preventing the adoption of a few simple extensions to 'good practice' that 
will allow tidy integration of some of the more abstract area information. The 
full list of every parish and ward in the United Kingdom is available, but the 
location data that goes with it is not 'open source' so while we could upload 
it without a location to put we are stuck as to how to bundle it initially.

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 :(

I am beginning to think that 'area' should simply be 'related' to a relevant 
node so that problems with moving other free format tag data between an 
earlier node:place and area:boundary:place is eliminated. The bottom line is 
we need a SINGLE type of object which which we can work rather than the 
current hassle between objects that have both node and area definitions :(

-- 
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




More information about the talk mailing list