[Talk-de] OpenGeoDB-Import

Frederik Ramm frederik at remote.org
Mi Jul 23 17:42:31 UTC 2008


Hi,

> * opengeodb bietet voellig offene Daten - es bleibt dir ueberlassen, 
> was du damit machen willst

Das finde ich persoenlich (!) besser als unsere Share-Alike-Lizenz, die 
sich "frei" nennt, dem Benutzer aber viele Vorschriften macht.

Die Nutzung der OpenGeoDB-Daten fuer unsere Zwecke ist also problemlos
moeglich, wenn man mal davon absieht, dass...

> * opengeodb ist urspruenglich abgeleitet von geonames-Daten. 

... unsere britischen Freunde sind da zuweilen sehr empfindlich und
neigen dazu, alles, was Gefahr laeuft, letzten Endes irgendwie von
Google abgezeichnet zu sein, zu verdammen, so auch Geonames. Ich sehe
das etwas relaxter; Geonames sammelt seine Daten aus sehr vielen
Quellen, und wenn darunter mal irgendwer ein Google-Luftbild nutzt, um
einen Ort zu platzieren, was solls.

> * Daten aus der OSM duerfen nicht in die opengeodb zurueckfliessen, 

Das stimmt (leider).

> Aenderungen von opengeodb-Daten sollten daher nicht ueber die 
> OSM-Oberflaeche erfolgen, sondern direkt in der opengeodb erfolgen, 
> um dann wieder in die OSM einzufliessen

Das ist ein voellig hoffnungsloses Unterfangen. Wir koennen in OSM 
keine Daten gebrauchen, die nicht aenderbar sind bzw. wo man dem
Benutzer sagt "aender das nicht hier, sondern irgendwo anders". Das
macht keiner, das kriegen wir nicht vermittelt.

Ich sehe zwei Moeglichkeiten:

1. Wir importieren den OpenGeoDB-Kram und kuemmern uns nicht drum
was mit OpenGeoDB wird. Das ist sehr egoistisch, aber so ist das eben
mal mit Public Domain-Daten: Man muss sich nicht drum kuemmern. Was wir
"fuer" OpenGeoDB tun koennen, ist, zumindest irgendeine ID von denen
mit zu speichern, so dass OpenGeoDB regelmaessig einen "diff" laufen
lassen kann und auf die Weise rausfindet, welche Objekte in OSM seit dem
Import geaendert wurden. Diese darf OpenGeoDB dann zwar nicht direkt aus
OSM herauskopieren, aber zumindest mal die Herstellung einer Liste a la
"die folgenden Dinge sollten mal ueberprueft werden, denn die OSM-Leute
waren da anderer Meinung" ist ja zulaessig.

2. Wir gehen vor wie bei (1), fuegen jedoch an jeden aus OpenGeoDB
importierten Node eine Notiz an, die besagt: "Wenn Du diesen Node
aenderst, stimmst Du einem Re-Import in die Public Domain-OpenGeoDB zu.
Wenn Du nicht einverstanden bist, entferne diese Notiz." - Dies wuerde
OpenGeoDB in die Lage versetzen, diese Nodes aus OSM wieder auszulesen.
Rechtlich ist das auf jeden Fall machbar, denn Urheber ist ja der
Einzelne, der etwas aendert, und derjenige hat die Moeglcihkeit,
beliebige zusaetzliche Lizenzen zu vergeben; in diesem Fall wuerde er
also an OSM die CC-BY-SA-Rechte geben plus zusaetzlich noch den Node
PD lizensieren. OpenGeoDB koennte nun all jene Nodes, bei denen diese
Notiz noch intakt ist, jederzeit wieder exportieren. Umgekehrt wuerden
wir regelmaessig Importe aus OpenGeoDB machen, um Aenderungen von dort
mitzubekommen. 

Das mit (2) ist so ein bisschen eine Cowboy-Methode, aber ich finde sie
den Umstaenden entsprechend eigentlich ziemlich gut; jeder hat was
davon, keiner steht nachher schlechter da als vorher. 

> Daher kennt opengeodb z.B. strukturiert das Bundesland Hamburg, den Kreis Hamburg (Kfz-Kennzeichen "HH") und die Gemeinde Hamburg (unterste, bundesweit einheitlich genormte Strukturebene). [...]

Das ist im Moment zu kompliziert fuer uns, finde ich. Lasst uns bei
einfachen Nodes bleiben - wie heisst der Ort, wieviele Einwohner hat er,
dann noch eine Id, und das wars. Keine 50 Tags umfassende Replikation
der OpenGeoDB-Strukturen.

> + opengeodb verwendet auch Langformen der Ortsnamen, gerade weil Ergebnisse in Textform praesentiert werden. Auf Landkarten sind solche Zusaetze wie "Freie und Hansestadt Hamburg" oder "Aumühle bei Hamburg" unüblich, da die Zuordnung offensichtlich ist.

In der Tat, das war ziemlich bloed. 

> + Beim OSM-Import der Daten wurde nur zur passenden Kurzform des Namens abgeglichen. Daher kamen unerwuenschte Doppel-Eintraege in Langform hinzu.

Das auch.

> + Beim OSM-Import wurden alle Zwischenebenen mit importiert. Fuer OSM relevant ist eigentlich erst alles ab der Gemeinde-Ebene.

Mich interessieren vor allem Staedte und deren Einwohnerzahl, damit ich
endlich vernuenftige priorisierte Rendering-Rules machen kann, auf denen
nicht ploetzlich Muenchen von einem zufaellig nebenan liegenden 50.000-
Seelen-Dorf verdraengt wird. Alles andere, zum Beispiel Ortsteile oder
sowas, halte ich fuer verzichtbar, das koennen die Leute vor Ort machen,
wenn sie die Stadt erfassen.

> * opengeodb bietet weit mehr als geonames: Postleitzahlen, Einwohner, Hierarchisierung, Flaeche usw.

Wie gesagt... Einwohner. Alles andere (ob man die Hierarchien geeignet
in Relationen packen kann) wuerde ich spaeter machen.

> Wann der naechste OSM-Import erfolgt, das haengt von den OSM-Leuten ab. opengeodb steht dazu jederzeit zur Verfuegung.

Wer hat denn damals das fehlerhafte Import-Skript gemacht, und ist das
inzwischen alles verbessert, oder wird jemand gesucht, der sich dessen
mal annimmt?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"





Mehr Informationen über die Mailingliste Talk-de