> aber dass die OpenGeoDB > tatsaechlich ein Strassenverzeichnis hat, das war mir bislang > voellig entgangen, ich dachte immer, die machen nur Namen von > Ortschaften. Wo bekomme ich denn diese Daten her? Dieses > Opengeodb-SQL-File bei Sourceforge ist es ja nicht, oder?
Hallo Frederik, du hast richtig erkannt, dass die OpenGeoDB bisher so gut wie keine Strassennamen enthaelt. Ich habe selbst aber relativ vollstaendige und flaechendeckene Strassenverzeichnisse fuer Deutschland, wo diese Daten zur Wertsachencodierung verwendet werden. Dabei wird jeder Strasse eine Schluesselnummer zugewiesen. Mein eigener Wertsachencode lautet daher: FR00007400045MT08 - das ist meine gesamte Anschrift und Initialen in Verschluesslung nach der FEIN-Methodik (Friedberger Eigentuemer Identifikations-Nummer), wie sie seit mehr als zehn Jahren von der Polizei eingesetzt wird - heute eher unter dem Namen EIN (Eigentuemer-Identifizierungs-Nummer). -> http://adfc.de/ein Der Allgemeine Deutsche Fahrrad-Club verwendet diese Methode zur Codierung von Fahrraedern, bisher in der Regel meist durch Fraesgravur. Die Methode der Codierung kann aber universell eingesetzt werden - z.B. zur Markierung von GPS-Geraeten, Kameras, Laptops, Antiquitaeten, Werkzeugen uysw. Diese Strassenverzeichnisse sind leider nicht immer oeffentlich verfuegbar - das ist Laendersache, teils auch Aufgabe und "Eigentum" der einzelnen Gemeinde. Die Verzeichnisse umfassen in der Regel vor allem alle bewohnten Adressen (weil es oft Daten aus den Einwohnermeldeaemtern sind), teils aber auch vollstaendigere Daten der Katasteraemter. Bei Neubenennungen hinkt man natuerlich immer hinterher - und gerade in Bayern sind die Daten besonders veraltet. Von daher sind meine Zahlenangaben mit der entsprechenden Vorsicht zu geniessen und taugen eher als Orientierung, denn als 100prozentige Referenz (ich wuerde sagen, ich habe deutlich mehr als 95 %). > So eine Liste mit wieviel Prozent in welchem Gebiet: > > > Prozent : x von y Name Gemeindeschlüssel > > 92.3 : 169/183 Eggenstein-Leopoldshafen 08215102 > > 89.7 : 70/78 Iffezheim 08216023 > > 87.4 : 125/143 Linkenheim-Hochstetten 08215105 > > 85.5 : 59/69 Altdorf (Kreis Böblingen) 08115002 > > ist genau das, was wir brauchen. Fuer die Visualisierung > koennte ich mir vorstellen, dass man der Einfachheit halber > so vorgeht: Zu jeder dieser Gemeinden hast Du doch > (Punkt)-Koordinaten. Ja, so stelle ich mir das auch in etwa vor. http://www.fa-technik.adfc.de/Codierung/Codier-Anbieter.png ist eine solche Karte, die ich selbst erstellt habe - die basiert auf den Daten der Codieranbieter mit derzeit fast 800 Eintraegen. Zum Vergleich: es gibt etwa 12 000 Gemeinden in Deutschland. Bei Punkten duerfte es also eine deutliche Ueberlappung der Punkte geben. Eine solche Grafik braeuchte min. eine Groesse von 200 x 300 Pixeln: das waeren 60 000 Punkte - bei einer Flaechenabdeckung incl. Rand mit 50 % bleiben 30 000 Punkte, verteilt auf 12 000 Gemeinden. Waeren die Gemeinden recht gleichverteilt, koennte das passen. In Ballungsraeumen hingegen wird es sich ziemlich gegenseitig abdecken. Was sollte dann ganz oben liegen? Die besonders guten oder die besonders schlechten Gemeinden? Alphabetisch? Nach Gemeindeschluessel? Zufaellig? Ich wuerde daher als Groesse der Deutschland-Grafik etwa 200 x 320 empfehlen. Als Hintergrund wird landkreisweise der Durchschnitt angezeigt - z.B. in Pastelltoenen von hellgruen nach hellrot. Darueber kann man in dunkleren Farben die einzelnen Gemeinden legen - als Ansporn fuer die gezeigte Arbeit kommen die besten Gemeinden ganz nach oben. Erst mit fast vollstaendiger Abdeckung koennte man das umkehren, um die besonderen, offenen Punkte hervorzuheben. Wie ich selbst meine Grafik erstellt habe, das sollte ich besser verschweigen: Es ist ASCII-Grafik, direkt aus einer Datenbank heraus (Schriftgroesse 2, dann Screenshot). Ich mochte hier auf ImageMagic umsteigen, habe das aber noch nicht geschafft. Hier in dieser Runde vermute ich viel mehr Know-How, wie man das weit besser rendern koennte. > Was die Frage "was mach ich nun mit den Daten" betrifft, > waere es fuer mich persoenlich wesentlich wertvoller, wenn Du > auf einer Wiki-Seite das genaue Vorgehen beschriebest > und/oder die verwendeten Skripte/Programme in unser SVN > einchecken wuerdest, denn dann kann sich der versierte Nutzer > selbst jederzeit einen aktuellen Abgleich eines > interessierenden Gebiets errechnen bzw. die Prozedur auch > fuer Gebiete anwenden, die eventuell eine Aenderung an den > Skripts benoetigen. Dafuer war der erste Schuss viel zu manuell: Als erstes nahm ich die kompletten XML-Dateien: baden-wuerttemberg.osm und importierte das zeilenweise in eine Datenbank. In einer zweiten Tabelle extrahierte ich alle Way-IDs und alle referenzierten Knoten. Ausserdem enthaelt die Tabelle alle 'name'-Werte. Ergaenzt wurde es mit names, die node-ids zugeordnet waren. Ausserdem bekommen die Wege den Mittelwert der node-Koordinaten. Dann erfolgte der Abgleich mit den Strassendaten: - Suche alle passenden Strassennamen aus dem Strassenverzeichnis - Verwende fuer jede Strasse die Koordinaten der zugehoerigen Gemeinde - finde die Strasse, die am naechsten zur OSM-Strasse liegt ... was im Prinzip bedeutet: finde die naechstgelegene Gemeinde, die eine Strasse mit diesem Namen enthaelt - gib der OSM-Strasse als Attribut den Gemeindeschluessel der Gemeinde Ausserdem habe ich der OSM-Strasse die Entfernung zur Gemeinde mitgegeben. Es zeigte sich, dass damit ein Grossteil der Strassen abzudecken war - aber viele hundert Strassen wirkten fehlerhaft. Typische Erfahrungswerte zeigten, dass Entfernungen jenseits von 30 km kaum noch passen konnten. Umgekehrt waren Eintraege mit weniger als 10 km Abstand oftmals in Ordnung. Daraus kann man aber schon das Fehlerpotential ableiten: Wenn eine Strasse naeher an einer Nachbargemeinde liegt, dann wird sie entweder falsch der Nachbargemeinde zugeordnet, oder zumindest nicht richtig der aktuellen Gemeinde. Da die OSM sehr oft Strassen fragmentiert und da mein Ansatz bisher nicht Fragmente zusammenfuegt, nehme ich hier immer nur den am besten passenden Wert. Schlechter passende Partner werden verworfen. Hier koennte ich vermutlich weit bessere Daten bekommen, wenn mir jemand bereinigte Daten zur Verfuegung stellt, wo Fragmente schon bereinigt zu einer einzigen Strasse zusammengefuegt werden - denn damit habe ich bessere Rohdaten, um auch der Nachbargemeinde eine Chance zu geben. In den verbliebenen Daten hatte ich dann aber noch zwei (halb-)manuelle Vergleiche durchgefuehrt: Dabei suchte ich bei den Misserfolgen (> 30 km oder ueberhaupt kein Treffer) nach aehnlichen Schreibweisen. Durch diesen Abgleich wurdeneinige hundert Schreibfehler bemerkt, die nun als Korrektur zurueckfliessen koennten. Den Abgleich beschraenkte ich aber auf alles, was entweder im Namen auf eine Strasse hindeutete (Teilstring "str") oder was den tag "residential" mitbrachte. Es faellt auf, dass da vieles falsch getagged ist. Daher sollten mit zunehmender Vervollstaendigung Script- oder Datenbankabgleiche erfolgen, die solche potentiellen Falscheintraege zur Pruefung markieren. Ich vermute, dafuer stehen wir bisher aber noch zu sehr am Anfang. Erklaert das, was ich hier machte - und warum dafuer kein fertiges Script existiert? Vieles davon liesse sich in einem Script abbilden. Etliches davon erfordert aber manuelle Interaktion und Erfahrung, um z.B. "stasse" oder "straesslein" auf "strasse" abbilden zu koennen oder um Schreibvarianten in den Griff zu bekommen (mit/ohne Bindestrich, mit/ohne Leerzeichen, Abkuerzungen usw.). Der Aufwand dafuer ist so gross, dass ich es jetzt erst einmal exemplarisch fuer BW durchgefuehrt habe. Vielleicht findet sich hier jemand, der mir die Zuarbeit erleichtern kann und passende Rohdaten zur Verfuegung stellen kann - z.B. eine tab-getrennte Datei mit * way_id (als Referenz und Primaerschluessel) * name (direkt vom way oer indirekt ueber name-tags der nodes) * passende Koordinaten (bei mir bisher: Mittelwert, besser aber: Anfang, Ende und mittlerer Referenzknoten auf dem Weg) * evtl. hilfreiche Zusatzattribute wie "residential" bzw. was auf die Eigenschaft als Weg/Strasse hindeutet. Im Idealfall sind hier einzelne Strassenfragmente schon zu einem Gesamt-Strassenzug zusammengesetzt. Die way_id verkettet dann alle Einzelteile z.B. als Semikolon-getrennte Liste. Im Moment wurde also nur BW exemplarisch durchprobiert - wir sollten ueberlegen, was man damit anfangen kann. - Lizenzfragen: Ich gehe davon aus, dass ich die abgeleiteten Daten nicht in die opengeodb aufnehmen darf. Im Moment ueberlege ich, eine eigene opengeodb/osm-Strassendatei abzutrennen, die unter der passenden OSM-Lizenz verbleiben muss. Fuer viele Anwender wuerde die opengeodb wertlos, wenn sie komplett dieser weit restriktiveren Lizenzierung untergeordnet werden muesste als der bisherigen public domain - Abdeckungs-Listen: sind diese wirklich hilfreich und interessant? - Abdeckungs-Grafiken: wer macht sie? - Abgleichlisten: wie gut hat der Abgleich funktioniert? Passen die Daten ueberhaupt? Wie viel wurde voellig falsch zugeordnet und wie kann das verbessert werden. Wo kann ich - oder sonst jemand - in welchem Umfang Listen bereitstellen, welche Strassen noch fehlen? - Automatisierung: wie oft, wie einfach, wie umfangreich soll ein solcher Abgleich erfolgen? Soll er sich auf Strassenlisten konzentrieren? Sollte auch die Qualitaet der tags geprueft werden, z.B. mit Markierung von moeglichen Fehlern? Viele Fragen... Schoenen Gruss Martin -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
