Re: [Talk-de] Alpha: OpenGeoDB -> OSM

[Sven Anders]

Am Montag, 14. Januar 2008 00:01 schrieb Andreas Hubel:
> Martin Trautmann schrieb:
> >> ich denke die ganzen is_in Felder sollte man raus lassen. is_in kommt
> >> aus der Zeit in der es noch keine Relations gab. Ich denke das Tag
> >> sollte man irgendwie als veraltet oder so kennzeichnen.
> >
> > Im Gegenteil steckt genau im originalen part_of die Relation drin, weil
> > hier die loc_id des naechsten opengeodb-Eintrags steckt. Svens Beispiel
> > scheint das flachzuklopfen (part_of / Teil von / is_in_loc_id gegenueber
> > is_in)
>
> das is_in kommt wie gesagt aus der Zeit in der es noch keine Relations
> in OSM gab. Das heißt man konnte nicht einfach sagen dieses Element
> gehört zu diesem Gebiet/Node, weil man die IDs der OSM Elemente nicht
> kannte. Deswegen hat man sich mit dem Namen des entsprechenden
> Gebiets/Nodes beholfen. Weil aber Namen nicht eindeutig sind, hat man
> teilweise angefangen die nächst höhreren Ebenen ebenfalls mit ein zu
> bauen bis man zu den ewig langen angeben gekommen ist, die wir heute haben.

Ich denke da liegst du falsch. Bereits in der ersten Version des Proposals am 
31.August 2006 stand als Beispiel: 

isin=bedfordshire, england, UK
isin=europe,scandanavia


> Heutzutage kann man das wunderbar mit Relations ausdrücken.
Ja, aber die Tools machen es noch nicht. Solange das Feature in den 
Map_Features auftaucht und es bei OSM keinen Konsens gibt den Key zu löschen, 
möchte/werde ich den Key benutzen.


> Okay, es wäre schön wenn man den Nodes gleich ein  xx="xxx" /> mitgeben könnte, aber das ist halt nicht so vorgesehen.
>
> Ich kann verstehen das man es aus kurzer Sicht eventl. noch mit rein
> nimmt, damit die alten Tools, die is_in noch nutzen weiterhin
> funktionieren, aber eigendlich ist das der falsche Weg.

Warum? Das is_in ganz raus zu schmeißen, wenn es etwas besseres gibt, was 
funktioniert (=von Tools unterstützt wird) ist kein Problem. Dafür schreib 
ich dir in 2h einen Bot.

> Eherer sollte man die ganzen is_in's in saubere Relations umwandel und
> denn tag dann entgültig verbannen.

Ich denke der erste Schritt ist, sich zu einigen, was stattdessen kommen soll. 
Und davon sind wir im Moment noch Meilenweit entfernt. Es gibt zu dem Thema 
leider mehrere Proposals:
Relations/Proposed/Is_In
Proposed_features/House_numbers
Relations/Proposed/Postal_Addresses

die alle Ihre schwächen und stärken haben.

Mal ganz davon abgesehen gibt es eben auch Tools die dieses Tag verwenden.

Gruß
Sven

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de

Re: [Talk-de] Alpha: OpenGeoDB -> OSM

[Sven Anders]

Am Sonntag, 13. Januar 2008 23:48 schrieb Andreas Hubel:
> Sven Anders schrieb:
> >> solange beides identisch ist, reicht name. Den openGeoDB-Name wuerde ich
> >> nur bei Abweichungen nenne, so wie z.B. auch einen abweichenden
> >> wikipedia-Name:
> >>
> >>name=freiburg
> >>opengeodb:name=Freiburg im Breisgau
> >>wikipedia:de=Freiburg_im_Breisgau
> >
> > Warum nicht trotzdem alles nennen, es ist ja ne Zusatzinformation, dass
> > diese Daten in anderen Quelle auch so verzeichnet sind, also z.B.
> > name=München
> > openGeoDB:name=München
> > wikipedia:de=München
>
> Weil es einfach auf der Ebene einfach unnötig ist. Man weiß, das es zu
> jedem Ort einen Eintrag in der OpenGeoDB und in Wikipedia gibt. So mach
> man die DB nur größer als es eigendlich nötig wäre

Ja, aber ich weiß nicht, ob der Eintrag in der Wikipedia und OpenGeoDB genau 
so heißt und deshalb weggelassen wurde, oder ob noch niemand danach geschaut 
hat, wie die Einträge dort heißen. Es könnte z.B. auch sein, das jemand den 
namen ändert. In OpenGeoDB ist natürlich noch der name so drinn, wie er in 
openGeoDB vorher war.

> > Das hat auch den Vorteil, das man auch als Benutzer schnell mal einen
> > Tippfehler finden könnte.
> >
> > Wenn z.B. sowas auftaucht:
> >
> > name=Muenchen
> > openGeoDB:name=München
>
> Wie gesagt, ich hab nichts gegen doppelte Nennung wenn die Werte
> unterschiedlich sind, aber bei identischen Werten keine Doppelnennung.

Würde mich interessieren, wie das andere sehen. Am liebsten wäre mir eine 
Abstimmung darüber auf der Wiki Seite: User:OpenGeoDB


> >>> openGeoDB:version ist meiner Meinung nach mit "0.2.6.11 / 2007-12-04 /
> >>> http://fa-technik.adfc.de/code/opengeodb/dump/"; zu lang. Nur die
> >>> Version "0.2.6.11" sollte reichen.
> >>
> >> Ja, genau - wobei auf fa-technik.adfc.de beliebige zwischendumps
> >> moeglich sind, teils direkt durch Benutzerwunsch. Von daher waere
> >> 0.2.6.11_2007-12-04 oder 02611_20071204 sinnvoll.
> >
> > Warum darf der String nicht länger sein? Gibt es irgend ein Problem wenn
> > der String zu lang wird?
>
> Der braucht dann einfach zu viel Speicherplatz. Wer mehr Infos will
> findet die ja auf der Wiki Seite zu OpenGeoDB

Ich denke, das es bei OSM ähnlich ist, wie bei Wikipedia: Wir haben generell 
kein Speicherplatz-Problem.

Die Daten bei OpenStreetmap werden ja wenn man sie in Planet Files runter läd, 
gepackt über das Netz geschickt, da beträgt der Unetrschied zwischen einer 
Version mit Versionsstring und ohne (gar keine Version) gerade mal 34 kByte. 
Für den OSM Datenbestand ist dieser Import mit 50 MB sowieso unbedeutend.


> Ok, dann das feld einfach nur auf Landkreisebene Importieren. Irgendwie
> sollte man noch kennzeichnnen das das ein Deutscher car_licence_code ist
> z.B. durch car_licence_code:de=M

Nein, da bin ich gegen: 
* Ich möchte gerne alles Importieren, auch das was evtl. in OpenGeoDB falsch 
ist, nur dann haben alle die Möglichkeit das zu korrigieren. Wenn das Feld 
car_licence_code heißen würde könnte man darüber diskutieren, aber das Feld 
beginnt mit dem Prefix: OpenGeoDB und das heißt für mich: Ist aus OpenGeoDB 
so errechnet, beziehungsweise steht so drinn.
* Eine Kennzeichnung nach Ländern macht IMHO wirklich keinen Sinn. Das kann 
man ja über Relationen, über die lat und lon und andere Merkmale wirklich 
filtern. 
> Bitte soche Einträge nur dann anlegen, wenn es bereits Einträge für
>
> name=Deutschland
> name:en=Germany
> name:fi=Saksa
> name:he=גרמניה
>
> die anders lauten.

Das sehe ich anders. Auch wenn du mich immer wieder darum bittest, wird sich 
meine Meinung dadurch nicht ändern. Es sollten sich zu diesem Thema mehr 
Personen äußern, dann kann man das demokratisch lössen. Ich schlage vor 
darüber (auf Englisch) auf der Wiki Seite User:OpenGeoDB zu diskutieren und 
dann  eine Abstimmung zu machen. Ich bin bereit mich zu bewegen, aber nicht 
wenn es dort nur drei Personen gibt die etwas dazu sagen.

> Könntest du, wenn es nen neuen Dump gibt, in den die angenommenen
> Verbesserungsvorschläge eingeflossen sind, diesen hier posten, oder am
> besten Auszüge davon?

Mich würde noch interessieren, wie wichtig dir deine Meinung ist. Bist du 
sauer, wenn ich die Daten erstmal so wie hier beschrieben hochlade. Ändern 
kann man das ja bei einen späteren lauf immer noch.

Gruß
Sven

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de

Re: [Talk-de] Alpha: OpenGeoDB -> OSM

[Andreas Hubel]

Martin Trautmann schrieb:
>> ich denke die ganzen is_in Felder sollte man raus lassen. is_in kommt
>> aus der Zeit in der es noch keine Relations gab. Ich denke das Tag
>> sollte man irgendwie als veraltet oder so kennzeichnen.
> 
> Im Gegenteil steckt genau im originalen part_of die Relation drin, weil hier
> die loc_id des naechsten opengeodb-Eintrags steckt. Svens Beispiel scheint
> das flachzuklopfen (part_of / Teil von / is_in_loc_id gegenueber is_in)
> 

das is_in kommt wie gesagt aus der Zeit in der es noch keine Relations 
in OSM gab. Das heißt man konnte nicht einfach sagen dieses Element 
gehört zu diesem Gebiet/Node, weil man die IDs der OSM Elemente nicht 
kannte. Deswegen hat man sich mit dem Namen des entsprechenden 
Gebiets/Nodes beholfen. Weil aber Namen nicht eindeutig sind, hat man 
teilweise angefangen die nächst höhreren Ebenen ebenfalls mit ein zu 
bauen bis man zu den ewig langen angeben gekommen ist, die wir heute haben.

Heutzutage kann man das wunderbar mit Relations ausdrücken.

Okay, es wäre schön wenn man den Nodes gleich ein  mitgeben könnte, aber das ist halt nicht so vorgesehen.

Ich kann verstehen das man es aus kurzer Sicht eventl. noch mit rein 
nimmt, damit die alten Tools, die is_in noch nutzen weiterhin 
funktionieren, aber eigendlich ist das der falsche Weg.

Eherer sollte man die ganzen is_in's in saubere Relations umwandel und 
denn tag dann entgültig verbannen.

MfG Andi


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de

Re: [Talk-de] Alpha: OpenGeoDB -> OSM

[Andreas Hubel]

Sven Anders schrieb:

>> solange beides identisch ist, reicht name. Den openGeoDB-Name wuerde ich
>> nur bei Abweichungen nenne, so wie z.B. auch einen abweichenden
>> wikipedia-Name:
>>
>>name=freiburg
>>opengeodb:name=Freiburg im Breisgau
>>wikipedia:de=Freiburg_im_Breisgau
> 
> Warum nicht trotzdem alles nennen, es ist ja ne Zusatzinformation, dass diese 
> Daten in anderen Quelle auch so verzeichnet sind, also z.B.
> name=München
> openGeoDB:name=München
> wikipedia:de=München
Weil es einfach auf der Ebene einfach unnötig ist. Man weiß, das es zu 
jedem Ort einen Eintrag in der OpenGeoDB und in Wikipedia gibt. So mach 
man die DB nur größer als es eigendlich nötig wäre

> Das hat auch den Vorteil, das man auch als Benutzer schnell mal einen 
> Tippfehler finden könnte.
> 
> Wenn z.B. sowas auftaucht:
> 
> name=Muenchen
> openGeoDB:name=München

Wie gesagt, ich hab nichts gegen doppelte Nennung wenn die Werte 
unterschiedlich sind, aber bei identischen Werten keine Doppelnennung.

>>> openGeoDB:version ist meiner Meinung nach mit "0.2.6.11 / 2007-12-04 /
>>> http://fa-technik.adfc.de/code/opengeodb/dump/"; zu lang. Nur die Version
>>> "0.2.6.11" sollte reichen.
>> Ja, genau - wobei auf fa-technik.adfc.de beliebige zwischendumps moeglich
>> sind, teils direkt durch Benutzerwunsch. Von daher waere
>> 0.2.6.11_2007-12-04 oder 02611_20071204 sinnvoll.
> 
> Warum darf der String nicht länger sein? Gibt es irgend ein Problem wenn der 
> String zu lang wird?
Der braucht dann einfach zu viel Speicherplatz. Wer mehr Infos will 
findet die ja auf der Wiki Seite zu OpenGeoDB


>>> openGeoDB:license_plate_code = "BW" für BaWü ist irgendwie seltsam,
>> Offiziell heisst das car_licence_code. Solche gibt es eigentlich nur
>> auf Kreisebene (z.B. FR: Stadt Freiburg und Landkreis Breisgau im
>> Schwarzwald) bzw. die Ebenen darunter. Auf Bundesland-Ebene steckt in dem
>> Feld einfach nur eine Abkuerzung.
> 
> Das finde ich nicht so gut (das ein Feld auch noch für einen anderen Zweck 
> benutzt wird, denn es gibt ja kein Autokennzeichen: BW)

Ok, dann das feld einfach nur auf Landkreisebene Importieren. Irgendwie 
sollte man noch kennzeichnnen das das ein Deutscher car_licence_code ist 
z.B. durch car_licence_code:de=M

>> Die anderen Namensvarianten sind wenig interessant. Hier muss aber darauf
>> hingewiesen werden, dass es auch landesspezifische Varianten gibt, z.B.
>>
>>opengeodb:name=Deutschland
>>opengeodb:name:en=Germany
>>opengeodb:name:fi=Saksa
>>opengeodb:name:he=גרמניה
>>usw.
> 
> Ist genau so implementiert.

Bitte soche Einträge nur dann anlegen, wenn es bereits Einträge für

name=Deutschland
name:en=Germany
name:fi=Saksa
name:he=גרמניה

die anders lauten.

Könntest du, wenn es nen neuen Dump gibt, in den die angenommenen 
Verbesserungsvorschläge eingeflossen sind, diesen hier posten, oder am 
besten Auszüge davon?

MfG Andi


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de

Re: [Talk-de] Alpha: OpenGeoDB -> OSM

[Sven Anders]

Am Mittwoch, 9. Januar 2008 17:17 schrieb Martin Trautmann:
>
> > openGeoDB:sort_name würde ich rauslassen und falls openGeoDB:ISO-3166-2
> > sowas die de für Deutschland ist würde ich das als iso_contry_code oder
> > nur iso_code kennzeichnen.
>
> http://wiki.openstreetmap.org/index.php/User:OpenGeoDB nennt hier
> 50011   name

Ja, das war ein Übertragungsfehler. Ich meinte: 50010. Kann das im Moment 
nicht im Wiki ändern (gibt ne Fehlermeldung beim bearbeiten der Seite).

> Tatsaechlich steckt der eigentliche Name in 50010 (vergleiche
> 
> wo noch die Konstanten der Version 0.2.4 beschrieben werden - die 400*
> kamen mit 0.2.5 und 0.2.6 erst hinzu)
> In der "Name" (50010:NAME) steckt die vollstaendige Namensbezeichnung
> drin, wie z.B. "Freiburg im Breisgau".

Das ist IMHO für OSM der Name, weil auf einer Landkarte ja üblicherweise auch 
die Bezeichnung ausgeschrieben wird.

> Die 50011 wird derzeit nicht wirklich genutzt.
> Interessant ist eher die 50012, die 7Bit-Schreibweise, beschraenkt auf
> den Basisteil wie "freiburg" (lower case, no Umlauts, no extensions)

>
> solange beides identisch ist, reicht name. Den openGeoDB-Name wuerde ich
> nur bei Abweichungen nenne, so wie z.B. auch einen abweichenden
> wikipedia-Name:
>
>name=freiburg
>opengeodb:name=Freiburg im Breisgau
>wikipedia:de=Freiburg_im_Breisgau

Warum nicht trotzdem alles nennen, es ist ja ne Zusatzinformation, dass diese 
Daten in anderen Quelle auch so verzeichnet sind, also z.B.
name=München
openGeoDB:name=München
wikipedia:de=München


Das hat auch den Vorteil, das man auch als Benutzer schnell mal einen 
Tippfehler finden könnte.

Wenn z.B. sowas auftaucht:

name=Muenchen
openGeoDB:name=München



> > openGeoDB:version ist meiner Meinung nach mit "0.2.6.11 / 2007-12-04 /
> > http://fa-technik.adfc.de/code/opengeodb/dump/"; zu lang. Nur die Version
> > "0.2.6.11" sollte reichen.
>
> Ja, genau - wobei auf fa-technik.adfc.de beliebige zwischendumps moeglich
> sind, teils direkt durch Benutzerwunsch. Von daher waere
> 0.2.6.11_2007-12-04 oder 02611_20071204 sinnvoll.

Warum darf der String nicht länger sein? Gibt es irgend ein Problem wenn der 
String zu lang wird?

> > openGeoDB:license_plate_code = "BW" für BaWü ist irgendwie seltsam,
>
> Offiziell heisst das car_licence_code. Solche gibt es eigentlich nur
> auf Kreisebene (z.B. FR: Stadt Freiburg und Landkreis Breisgau im
> Schwarzwald) bzw. die Ebenen darunter. Auf Bundesland-Ebene steckt in dem
> Feld einfach nur eine Abkuerzung.

Das finde ich nicht so gut (das ein Feld auch noch für einen anderen Zweck 
benutzt wird, denn es gibt ja kein Autokennzeichen: BW)

Ich hatte in einer früheren Version

> Die anderen Namensvarianten sind wenig interessant. Hier muss aber darauf
> hingewiesen werden, dass es auch landesspezifische Varianten gibt, z.B.
>
>opengeodb:name=Deutschland
>opengeodb:name:en=Germany
>opengeodb:name:fi=Saksa
>opengeodb:name:he=גרמניה
>usw.

Ist genau so implementiert.

> Bei Daten wie population / 60070 muss beachtet werden, dass solche
> Daten in der opengeodb in der Regel mit einer Datumsangabe kombiniert sind
> - z.B. gültig am Stichtag 2006-12-31 (genauer: von 2006-12-31 bis
> 2006-12-31).

Guter Hinweis: den Stichtag sollte ich hier noch hinzufügen. Ich hab eben mal 
nachgesehen, warum ich das nicht gemacht habe: 

mysql> select * from geodb_intdata where valid_until<"3000-01-01";
Empty set (0.00 sec)

Ist wohl erst in neueren Versionen drin. Ich hatte gehofft, das in OpenGeoDB 
nicht mehr so viel Bewegung im Datenschema ist.

Gruß
Sven Anders

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de

Re: [Talk-de] Alpha: OpenGeoDB -> OSM

[Sven Anders]

Am Mittwoch, 9. Januar 2008 16:14 schrieb Andreas Hubel:
> Also wenn ich mir das so anschaue, würde ich nicht alle Daten der
> OpenGeoDB direkt übernehmen.

Ja, da gibt es mehrere Ansätze. Ich will gerne begründen, warum ich alle Daten 
aus der OpenGeoDB auch in OSM haben möchte.

OpenGeoDB ist im deutschsprachigen Raum sehr gut, aber leider nur dort. 
Wenn jetzt jemand von außerhalb Daten wie z.B. Postleitzahlen benutzen möchte 
muss er entweder openGeoDB kennen oder die Daten müssen in OSM stehen. 

In Wikipedia gibt es den Grundsatz: das Wikipedia kein Platzproblem hat, und 
genau das sehe ich für OSM auch, die Daten werden ja benutzt, sonst würde ja 
auch niemand OpenGeoDB nutzen, warum soll man sie nicht auch ohne Medienbruch 
gleich in OSM nutzen können.

> ich denke die ganzen is_in Felder sollte man raus lassen. is_in kommt
> aus der Zeit in der es noch keine Relations gab. Ich denke das Tag
> sollte man irgendwie als veraltet oder so kennzeichnen.

Wenn es nicht mehr genutzt wird, ist es ganz einfach es überall zu entfernen. 
Im Moment wird es z.B. bei www.openstreetmap.org in der Suche benutzt.

Und ich erzeuge ja auch noch zusätzlich Relationen, damit man auf das Tag 
nicht angewiesen ist.


> openGeoDB:type, openGeoDB:layer, openGeoDB:location sind Teilweise
> einfach redundant und sagen das selbe aus. Eigendlich sollte man das via
>   place=xyz ausdrücken.

Wenn sie wirklich redundant sind, kann sie ja jemand aus der OpenGeoDB 
löschen. Dann tauchen sie beim nächsten Update nicht mehr auf. Wenn sie doch 
irgend einen Sinn haben ist es doch schön sie direkt in OSM suchen zu können.


> Ist openGeoDB:name und name wirklich nötig? Nur name würde doch reichen.
Ja, solange der Name und der OpenGeoDB Name identisch sind. Aber ein Benutzer 
kann (uns soll ja auch jederzeit dürfen!!) den Namen ändern. Werte die mit 
OpenGeoDB: anfangen, sollte er möglischst nicht ändern, denn die kommen ja 
(in jedem Fall) aus der OpenGeoDB Datenbank, und werden beim nächsten Import 
überschrieben.

> openGeoDB:version ist meiner Meinung nach mit "0.2.6.11 / 2007-12-04 /
> http://fa-technik.adfc.de/code/opengeodb/dump/"; zu lang. Nur die Version
> "0.2.6.11" sollte reichen.

Warum? Der String wird automatisch erzeugt und für den Benutzer ist es 
angenehmer die URL zu kennen. Wer mal versucht hat mittels google auf die URL
http://fa-technik.adfc.de/code/opengeodb/dump/ zu kommen wird mir bestimmt 
recht geben, dass die Daten im Moment alles andere als einfach zu finden 
sind.


> openGeoDB:license_plate_code = "BW" für BaWü ist irgendwie seltsam,
> generell find ich die Übersetung irgendwie seltsam. Zumal das sowieso
> nur für Deutschland eindeutig ist. Ich wäre da fast für einen Deutschen
> Namensraum, z.B. de:KFZ. Analog dazu bei den Gemeindeschlüsseln de:AGS.

Nun ist OpenGeoDB ja nicht nur für Deutschland sondern auch für ein paar 
Nachbarländer aktiv und ich möchte nur eine Übersetzung einfügen.

Ich hatte auch mal Überlegt ob ich mir die Sache einfach mache und stattdessen 
einfach: openGeoDB:50060 statt openGeoDB:community_identification_number 
nehmen sollte, finde es aber besser sprechende Namen zu verwenden.

Bin gerade etwas frustiert, weil ich das Gefühl hatte, nach der letzten 
Rückmeldung (die ich im übrigen sehr konstruktiv fand!!), jetzt wirklich los 
zu legen und nicht wieder über so grundlegende Designfragen diskutieren zu 
müssen, aber laßt Euch davon nicht abhalten, denn es wird ja eher besser, 
wenn ein paar mehr Leute Ihren Sempf dazu geben! 


Gruß
Sven

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de

Re: [Talk-de] Alpha: OpenGeoDB -> OSM

[Martin Trautmann]

In-Reply-To: <[EMAIL PROTECTED]>

On 2008-01-09 16:14, Andreas Hubel wrote:
> Also wenn ich mir das so anschaue, würde ich nicht alle Daten der
> OpenGeoDB direkt übernehmen.

Das waere vor allem dann verkehrt, wenn man diese Daten direkt aus der
opengeodb holen wollte, statt sie gleich der OSM mitzugeben - das fuehrt
nur zu einer Verdoppelung der Daten und verhindert gleichzeitig, dass
Änderung zurückfliessen würden.

> ich denke die ganzen is_in Felder sollte man raus lassen. is_in kommt
> aus der Zeit in der es noch keine Relations gab. Ich denke das Tag
> sollte man irgendwie als veraltet oder so kennzeichnen.

Im Gegenteil steckt genau im originalen part_of die Relation drin, weil hier
die loc_id des naechsten opengeodb-Eintrags steckt. Svens Beispiel scheint
das flachzuklopfen (part_of / Teil von / is_in_loc_id gegenueber is_in)


> openGeoDB:sort_name würde ich rauslassen und falls openGeoDB:ISO-3166-2
> sowas die de für Deutschland ist würde ich das als iso_contry_code oder
> nur iso_code kennzeichnen.

http://wiki.openstreetmap.org/index.php/User:OpenGeoDB nennt hier
50011   name

Tatsaechlich steckt der eigentliche Name in 50010 (vergleiche

wo noch die Konstanten der Version 0.2.4 beschrieben werden - die 400*
kamen mit 0.2.5 und 0.2.6 erst hinzu)

In der "Name" (50010:NAME) steckt die vollstaendige Namensbezeichnung drin,
wie z.B. "Freiburg im Breisgau".

Die 50011 wird derzeit nicht wirklich genutzt.
Interessant ist eher die 50012, die 7Bit-Schreibweise, beschraenkt auf
den Basisteil wie "freiburg" (lower case, no Umlauts, no extensions)


> openGeoDB:type, openGeoDB:layer, openGeoDB:location sind Teilweise
> einfach redundant und sagen das selbe aus. Eigendlich sollte man das via
>   place=xyz ausdrücken.

Die wiki-Seite sollte vielleicht mit einem Beispiel gefuettert werden

type: Stadt, Landkreis, Gemeinde, Stadtviertel, Stadtbezirk, Ortsteil, ...

layer: das gibt die Hierarchie-Ebene an.

Beispielsweise gibt es Hamburg als Bundesland (AGS 02, layer 3), als
Landkreis (AGS 02000, layer 5) und als Gemeinde (AGS 0200, layer 6)

Auf layer 4 liegen die Regierungsbezirke, auf layer 7 die Orte, auf layer
8 die Ortsteile, auf 9 die Strassen, auf 10 Einzeladressen

Durch "Teil von" (part of, is_of) und "Ebene" (level, layer) wird
ausreichend genau beschrieben, wo im Baum das ganze hierarchisch haengt.

> Ist openGeoDB:name und name wirklich nötig? Nur name würde doch reichen.

solange beides identisch ist, reicht name. Den openGeoDB-Name wuerde ich
nur bei Abweichungen nenne, so wie z.B. auch einen abweichenden
wikipedia-Name:

   name=freiburg
   opengeodb:name=Freiburg im Breisgau
   wikipedia:de=Freiburg_im_Breisgau

> openGeoDB:version ist meiner Meinung nach mit "0.2.6.11 / 2007-12-04 /
> http://fa-technik.adfc.de/code/opengeodb/dump/"; zu lang. Nur die Version
> "0.2.6.11" sollte reichen.

Ja, genau - wobei auf fa-technik.adfc.de beliebige zwischendumps moeglich
sind, teils direkt durch Benutzerwunsch. Von daher waere 0.2.6.11_2007-12-04 
oder 02611_20071204 sinnvoll.

> openGeoDB:license_plate_code = "BW" für BaWü ist irgendwie seltsam,

Offiziell heisst das car_licence_code. Solche gibt es eigentlich nur
auf Kreisebene (z.B. FR: Stadt Freiburg und Landkreis Breisgau im
Schwarzwald) bzw. die Ebenen darunter. Auf Bundesland-Ebene steckt in dem
Feld einfach nur eine Abkuerzung.

> generell find ich die Übersetung irgendwie seltsam. Zumal das sowieso
> nur für Deutschland eindeutig ist. Ich wäre da fast für einen Deutschen
> Namensraum, z.B. de:KFZ. Analog dazu bei den Gemeindeschlüsseln de:AGS.

> Was haltet ihr davon?

IMHO fuer OSM wichtig ist vor allem die loc_id als Referenz zur opengeodb
selbst. Hilfreich erscheint mir die
part_of / is_in_locid / Teil von / 40010 wie auch die
AGS / community_identification_number / Gemeindeschlüssel / 50060

level / layer / Ebene / 40020 ist für die Hierarchien in der openbeodb
wichtig und steckt in Deutschland bis zur Gemeindeebene auch implizit im
AGS (zweistellig: Bundesland bis achtstellig: Gemeinde). Es gibt die
Überlegungen, den AGS auch als nicht-amtlichen oder halb-amtlichen
Gemeindeschlüssel bis ganz nach unten durchzuziehen. Beispielsweise gibt
es amtliche fünfstellige Strassenschlüssel, also 13stellige Schlüssel für
jede einzelne (Gemeinde-)Strasse in Deutschland.

Postleitzahlen sind einerseits sehr attraktiv, andererseits aber sehr
problematisch: für eine korrekte Zuordnung müsste man in der OSM eine
durchgehende Strasse tatsächlich an der PLZ-Grenze trennen. Es kann sogar
sein, dass eine Strasse zu einer PLZ gehört, die Anschriften an dieser
Strasse aber durch die postalische Zuordnung ganz anderen PLZ-Einträgen
zugeordnet sind - in Österreich scheint das gängige Praxis zu sein.

Von den Namesvarianten würde ich nur
name / 50010 verwenden, je nach Bedarf auch
NAME_7BITLC / sort_name / ASCII / 50012

Die anderen Namensvarianten s

Re: [Talk-de] Alpha: OpenGeoDB -> OSM

[Andreas Hubel]

Also wenn ich mir das so anschaue, würde ich nicht alle Daten der 
OpenGeoDB direkt übernehmen.

ich denke die ganzen is_in Felder sollte man raus lassen. is_in kommt 
aus der Zeit in der es noch keine Relations gab. Ich denke das Tag 
sollte man irgendwie als veraltet oder so kennzeichnen.

openGeoDB:sort_name würde ich rauslassen und falls openGeoDB:ISO-3166-2 
sowas die de für Deutschland ist würde ich das als iso_contry_code oder 
nur iso_code kennzeichnen.

openGeoDB:type, openGeoDB:layer, openGeoDB:location sind Teilweise 
einfach redundant und sagen das selbe aus. Eigendlich sollte man das via 
  place=xyz ausdrücken.

Ist openGeoDB:name und name wirklich nötig? Nur name würde doch reichen.

openGeoDB:version ist meiner Meinung nach mit "0.2.6.11 / 2007-12-04 / 
http://fa-technik.adfc.de/code/opengeodb/dump/"; zu lang. Nur die Version 
"0.2.6.11" sollte reichen.

openGeoDB:license_plate_code = "BW" für BaWü ist irgendwie seltsam, 
generell find ich die Übersetung irgendwie seltsam. Zumal das sowieso 
nur für Deutschland eindeutig ist. Ich wäre da fast für einen Deutschen 
Namensraum, z.B. de:KFZ. Analog dazu bei den Gemeindeschlüsseln de:AGS.

Was haltet ihr davon?

MfG Andi


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de

Re: [Talk-de] Alpha: OpenGeoDB -> OSM

[John07]

André Reichelt schrieb:
> Was ich da jetzt mal fragen will, worum geht es hier überhaupt?
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
>   
Die Mailingliste besitzt ein Archiv !?!
http://www.mail-archive.com/talk-de@openstreetmap.org/
http://lists.openstreetmap.org/pipermail/talk-de/
Gruß
Jonas

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de

Re: [Talk-de] Alpha: OpenGeoDB -> OSM

[André Reichelt]

Was ich da jetzt mal fragen will, worum geht es hier überhaupt?

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de