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 <[EMAIL PROTECTED]> 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 _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
