In-Reply-To: <[EMAIL PROTECTED]> On 2008-01-21 13:49, Ben Laenen wrote: >> I also noted that the "name=" tag has 2 values, seperated by a , >> (probably this is the dutch and french name) but in some places they >> are both the same? >> The double name is also true in ex. the is_in tag. > > It's not Dutch and French (and if that were the case there would have to > be a German name as well), it's just the same tag twice every time.
There's still a weakness within the current version of the opengeodb which always takes "de" as default for the entries, regardless of the language. There's a workaround how to delete these names, while it shall be fixed within the opengeodb itself soon. > Even in Brussels where the municipalities are bilingual it has the > French name twice (and since the already existing place tags there have > both Dutch and French names in their name key, it made duplicate nodes > to already existing ones). Yes, it probably would add both Bruxelles (assuming default German) and Bruxelles (which is tagged as french). See the data source: http://fa-technik.adfc.de/code/opengeodb.pl?locid=35698;c=BE The correct solution would be to tag it as french only (which is not possible at the moment within the so called basic data from http://fa-technik.adfc.de/code/opengeodb/BE.tab ). The workaround would be to delete every "extra" entry (which holds the correct language), assuming that it was available in German within the sql data. Example for the workaround: Base data Bruxelles -> sql_create Bruxelles,de Extra data Bruxelles, fr -> sql_delete Bruxelles,de sql_create Bruxelles,fr Brüssel,de -> sql_delete Brüssel,de sql_create Brüssel,de Sorry for the current confusion, but you get the idea of the internal trouble? Since the language is not tagged within the base data, it does assume German everywhere. The example with Bruxelles would work very well, although it would add some overhead for creation/deletion. The example with Brüssel would try to delete an sql_entry which is not available, then creating the same entry which it tried to delete. Things become even more complicated by the actual information, which differs between is_native_language (that's whih Bruxelles is within the base data) and the text locale which gives language by ISO 639-1 encoding and does add begin and end information, when this info was valid. > To keep with linguistic problems: all is_in keys in Flanders > have "is_in=...,Belgique,...". If you do want to stick with the > localized names it should be "is_in=...,België,...", > and "is_in=...,Belgien,..." in the German community. I don't see a chance for proper realisation here. opengeodb itself is organised hierarchically. Bruxelles (fr) is part of Région de Bruxelles-Capitale (fr), which is part of Belgique (fr). But Vlaams Brabant (nl) is part of Vlaanderen (nl), which again is part of Belgique (fr), where we just got België (nl) as extra information. > Better would > probably be to just stick with the English is_in=Belgium, since you > don't need to do special rules for your import script, and we mostly > use is_in=Belgium anyway already. The current implementation prefers to stick to a native language's version. I don't know how this should be handled best in OSM, but opengeodb data should be used as is. The opengeodb->OSM conversion might prefer to take the (en) version, as long as this was be available. > Next issue: the municipalities in Brussels region have "is_in=Bruxelles" > tags, which is actually quite wrong: "is_in=Brussels-Capital Region" is > better, since "Brussels" is just another municipality. Anyway, is_in > tags in Brussels may be confusing anyway to foreigners, so better > discuss it first :-) > > But I guess we could better move the discussion for the Belgian > OpenGeoDB data to the talk-be mailing list if you want to improve it, > since it probably would only bore non-Belgian users :-) I'd prefer to keep it on the international list. opengeodb in its current status is Germany, Austria, Switzerland (which has similiar problems to Belgium in de/fr/it/raeto-romanian), Liechtenstein - and I'd welcome to add data for the Netherlands next. I'm responsible for the current reference implementation. I would not like to join a Belgium list since my French is pretty limited. > (btw, did you put province and arrondissements place nodes in the data > as well? I haven't found those nodes yet) The focus on the Belgium area has been pretty limited up to now. Entries are more of a random style. For Germany, Austria and Switzerland we have a very good range of completeness due to the given data which names every more important area, from country down to community level. For Germany and Austria there's a numerical system which gives hierarchical numbers to certain levels - e.g. the keys down to Cologne: (toplevel) Germany 05 Nordrhein-Westfalen (two digits: the 16 federal states of Germany) 053 Köln (three digits for the five major areas "Regierungsbezirke) 05315 Köln (the district of Köln, five digits for its 12 districts ... all of those share the car licence plate "K") 05315000 The "community" of Cologne itself, 8 digits This may seem awkward first to have Köln several times, since there are certain districts which have the dualism of being a town and a virtual community. That's the way it's organized, differeing between towns which have no other communities below (e.g. "kreisfreie Städte") and districts which are built from many separate communities ("Landkreis"). Due to the federalism in Germany you do not need each level named here in each federal state, but you always have entries with two, five and eight digits. Austria has a similiar mechanism. Switzerland had another method of enumbering, where e.g. the number of the *Kanton* Basel is "12", the *Bezirk* of the town Basel is "1200" and Basel itself as community got the number 2701. Those numbers are not necessarily related to each other, but do follow a random number given once in time. If there's any system like this for Belgium (giving key numbers or values for certain levels), if there are any other more comprehensive lists of names, their languages and names in other languages, I'd welcome to add this info to the opengeodb and thus to OSM. Thanks, Martin -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
