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 [EMAIL PROTECTED] ## N49°00'09" E008°23'33" _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
