Alleine das Anzeigen des Kommentars wäre schon hilfreich. Flohoff hatte den Kommentar eingerückt in eine zweite Zeile geschrieben. Das war auffällig genug.
Der Kommentar hilft einem zu erkennen, was bereits eingeordnet ist und worum man sich noch kümmern sollte.
Beispiel fehlende Straßen: Nachdem ich einige Nachträge (Schreibweise korrigiert) ergänzt habe, sollten dort nur noch falsch erkannte Grenzwege drin sein. Mit Kommentar sehe ich das, ohne muss ich mühsam kontrollieren.
Für die Zukunft habe ich den Vorschlag, eine zweite Liste mit den Straßen, die nicht in der ‘offiziellen’ Liste sind aber geprüft existieren plus ihre Einordnung zu verwenden. Das sollte (hoffentlich) deine Auswertung vereinfachen. Die Mühe die Liste einmal neu zu sortieren nehme ich gerne auf mich. So wäre es auch übersichtlicher als heute, wo diese Straßen über die ganze Liste verteilt sind.
ich habe jetzt die Straßenlistenauswertung auf dem Toolserver aktiviert [1]
Die Daten sollten aktuell sein (von Sa früh), es steht noch aus, daß die Auswertung vorauss. einmal am Tag neu erstellt wird.
Es gibt auch seltsamerweise machmal eine unvollständige Anzeige der html-Seite einer Gemeinde, wenn diese eine größere Anzahl Straßen hat (bisher nur in Mozilla aufgetreten). Ein und dieselbe Seite wird etwas später vollständig dargestellt oder im IE bisher in so Fällen immer direkt. Am html-Code sollte es nicht liegen, keine Ahnung, was das soll (sind statische html-Seiten).
Umfang der Daten:
die bisherigen Daten von Florians Liste, wie ich sie im Januar heruntergezogen hatte (Bayern, BaWü, Bremen, Hamburg, Berlin, Brandenburg, Teile von Hessen).
Luxemburg ist drin
Rheinland-Pfalz komplett drin
Die Straßenlisten, die von mir und ein paar anderen im osm wiki bisher erstellt wurden (werden auch noch nicht automatisch zyklisch neu geholt).
Noch fehlend sind die Straßenlisten von Sven Anders.
Als nächstes werde ich erstmal den Server auf täglichen automatischen Abgleich einstellen und dann noch Kleinigkeiten an der Geocodingseite durchführen zwecks Ausdruck und einzelnes wählen/abwählen von unbekannten Straßen.
Und danach werde ich mich um das wiki-Thema kümmern (müssen).
wie kann man Deine “Grenzhierachie” ändern?
Denn die von “Weiden in der Oberpfalz” (wie der Name schon vermuten lässt ist keines falls “unbekannt”, sondern gehört in
den Regierungsbezirk “Oberpfalz” (kreisfreie Stadt!)
Ebenso sollte “Regensburg” als kreisfreie Stadt eine Hierachie höher und nicht in den “Landkreis Regensburg” gesteckt werden.
Nürnberg hab ich überhaupt nicht mehr gefunden
erstmal danke für deine tolle Arbeit. Dass die Straßenliste wieder verfügbar ist, ist eine große Hilfe.
Ein Problem scheint es noch mit den Links auf Seiten zu geben, die eine Klammer im Namen tragen: Zum Beispiel bekomme ich eine Fehlerseite (404, Page not found), wenn ich auf der Seite zu Schwaben die Seite für Kempten (Allgäu) oder Lindau (Bodensee) anklicke.
erstmal die ausführliche, für alle vielleicht interessante, Vorgehensweise für die Hiearchieermittlung
Ich versuche in dieser Reihenfolge:
an der Grenzrelation sind is_in:country, is_in:state, is_in:region mit einigen Tags (kommt bei Luxembourg vor)
an der Grenzrelation gibt es de:amtlicher_gemeindeschluessel und innerhalb des Gemeindegebiets gibt es ein Place-Objekt mit dem Wert in openGeoDB:community_identification_number
innerhalb des Gemeindegebiets gibt es ein Place-Objekt mit identischem name wie bei der bei der Grenzrelation
api-Anfrage bei Mapuest Nominatim, um die Hiearchie zu bekommen (seit kurzem filtere ich die Ergebnisse noch bzgl. innerhalb Gemeindegebiet).
Einige Gemeindenamen haben keinen gleichnamige Ort, z.B. Kaltental im Ostallgäu oder Oy-Mittelberg, Oberallgäu: in einigen Fällen habe ich dann ein place=municipality ergänzt, das ist zwar nicht offiziell dokumentiert (es gibt einen Proposal-Request), wird aber weltweit über 2000mal angewandt.
Konkret
Weiden in der Oberpfalz: Gemeinderelation 62554 name=“Weiden i.d.OPf., Stadt” Place-Objekt 487224833 name=“Weiden i.d.OPf.”, also Name nicht identisch.
Das “, Stadt” bei Gemeinderelation stört, ich empfehle Dir name:prefix=Stadt zu nehmen, das habe ich öfters gesehen, dann passt mein Matching Fall 3.
Die Hierarchie is_in im Place-Objekt ist bereits korrekt.
Regensburg: am Place-Objekt 240120926 ist is_in=Regensburg,Oberpfalz,Bayern,Bundesrepublik Deutschland,Europe
Oft verbreiterter Fehler bei einer kreifreien Stadt, die Auflistung der Stadt ist falsch.
Nürnberg: da ist ein Problem in der osm-Datenbank, die ich verwende. Zu 89 Gemeinden/Städten habe ich als einen Datensatz zur Gemeinderelation gefunden. Das ist im osm2pgsql-Schema möglich und ich habe eben auch einen aktuellen Post gefunden, der das Thema aufgreift, das muß ich mir noch durchlesen. Alle Tags sind identisch, die Geometrie des Gemeindegebiets aber nicht. Daher fallen diese aktuell bei der Auswertung raus und werden auch nicht angezeigt.
Der einzige Vorteil der früheren, flachen, Übersichtsseite war die direkte Sichtbarkeit aller falschen Hierarchie. Da ist ne Menge verekehrt in der osm-DB.
ja, die Klammer-Fehler sind mir gestern kurz aufgefallen, das werde ich kurzfristig (heute oder morgen vorauss) lösen. Unter Windows wurde das anders codiert, ich rufe hier eine offizielle Java-Fkt. zum url-codieren auf, aber die führt wohl zu plattformspezifischen Unterschieden.
Möp, Einspruch
Diese Schema (in den Grenzrelationen) kommt bei uns recht häufig vor:
Nürnberg, Stadt
Regensburg, Stadt
Fürth, Stadt
Ansbach, Stadt
weil es u. a. gleichnamige Landkreise gibt (ok, in Falle von N wär es “Nürnberger Land” aber die ersten 8 Buchstaben stimmen überein. Ditto “Erlangen” mit “Erlangen-Höchstadt”)
Hab’ deshalb “Weiden (als node)” die openGeoDB:community_identification_number verpasst.
Mal schauen, wie es morgen ausschaut
Klar, hab ich vergangene Woche gefixt
Fixed.
Der Fehler könnte evtl. aus Übernahme des Schemas aus der GeoDB kommen,
denn dort gibt es Regensburg et al. zweimal, einmal als “Landkreis” Level 5
und einmal als “Stadt” Level 6
Ciao,
Frank
PS
Hurra, Nürnberg, das ist da
Fällt mir gerade bei N auf, dass Du wohl Brücken und Plätze nicht auswertest.
Bsp: Ludwig-Erhard-Brücke: Die ist bei uns als “bridge-Relation” definiert, da der Weg,
welcher drüber geht, oft anders heißt als das Bauwerk selbst, in diesem Fall “Flußstraße”.
Ich hatte nicht alle Details geschrieben. Wenn im Place-Objekt bei Name der Ort am Anfang steht und danach direkt
" im ", " ob ", " bei " oder “, Stadt” folgt, nehme ich die Hierarchie vom Tag is_in von dem Objekt.
In Rheinlandpfalz ist noch einiges im Argen. Der Kreis Neuwied taucht zweimal in deinen Listen auf:
Einmal direkt unter RLP (nur zwei Orte)
Einmal unter Koblenz (der überwiegende Rest)
Ähnlich ist es mit dem Rhein-Lahn-Kreis.
Hintergrund ist möglicherweise, dass in RLP die Regierungsbezirke vor einigen Jahren im Zuge der Verwaltungsvereinfachung abgeschafft wurden. Möglicherweise waren die jetzt falschen Zuordnungen noch in den OpenGeoDB-Daten der Orte, Gemeinden, Kreise usw. enthalten und haben so Einzug in die is_in-Taggs erhalten.
PS: Schade dass Bonn/Straßenliste noch nicht neu gerechnet wurde.
Das Ergebnis hätte mich doch sehr interessiert.
Ich habe mir nur Erpel (place Knoten osm-id #240089653) angeschaut, da ist im Tag is_in die Hierarchie “Neuwied,Rheinland-Pfalz,Bundesrepublik Deutschland,Europe” und damit wohl laut Wikipedia richtig (da schaue ich mir als Referenz die Verwaltungsstruktur immer an, hier konkret [1] oder die einzelne Gemeindeseite).
Koblenz ist gemäß WP kreisfrei und ist kein Regierungsbezirk (edit: war Landkreis), also müssten die große Anzahl falsch strukturierte Gemeinden im is_in Tag korrigiert werden.
Ich gehe da allgemein so vor: ich gehe auf die Gemeinde-Detailseite, hole mir dort die Gemeinde-Realtions-ID, lade die Gemeinderelation in Josm und hol mir dann einen kleinen Ausschnitt um den Gemeindenamen und korrigiere dann den falschen Eintrag.
Das mache ich selbst aber auch nur für einige Gemeinden in meinem näheren Umfeld. Ich baue darauf, daß intressierte Mapper das jeweils in ihrer eigenen Gegend erledigen. Das trägt ja nicht nur der besseren Struktur der Straßenlistenauswertung bei, sondern auch der sonst korrekten Verwaltungsstrukturanzeige in anderen Anwendungen.
Gestern nachmittag habe ich eine Auswertung gestartet, bei der nur etwa 650 von mittlerweile 3091 Gemeinden gelaufen sind. Beim Rest kamen unerwartet DB SQL-Fehler auf. Entweder die DB war nicht erreichbar zwischendurch oder der Auswertung wurde der Zugang zur DB kurzzeitig abgewürgt.
Es läuft jetzt (Mo 08:40h) eine neue. Mal schauen, ob die durchläuft.
Mein Lohoff-Download von Januar 2011 ging in Deutschland und da Bundesland-alphabetisch, Hessen zuletzt und nur zu einem kleinen Teil. Danach ist gar nichts. Wenn jetzt andere Bundesländer wie z.B. Sachsen auftauchten sind das einzelne Straßenlisten, die falsch zugeorndet waren. Rheinland-Pfalz konnte ich flächendeckend von einer öffentlichen Quelle her impotieren.
Wenn Niedersachsen bei den Sven Anders Daten dabei waren, habe ich die bei mir und könnte sie importieren, wenn die Beschränkungen nicht da sind/wären. Bei einigen/vielen Listen von Sven sind andere Beschränkungen in der Veröffentlichung vorhanden.
Ich habe Florian Lohoff mehrfach gebeten, mir die Daten zuzusenden. Vor einigen Wochen hat er dann zugestimmt, mir diese zu senden, passiert ist aber noch nichts. Wer damals Listen in sein System importiert hat, kann ja mal bei ihm selbst nachfragen, das hilft vielleicht.
Deine Auswertung ist doch heute erneut gelaufen?
Ich dachte, ich hätter"Weiden i.d.OPf.", “53533”, “Althornbach” et al. gestern in der Hierachie geändert.
ich habe heute einen neuen Lauf gemacht, stimmt. Wichtig war mir erstmal, einen kompletten Durchlauf zu bekommen, nur ein Teil war zuvor problemlos durchgelaufen. Ich hatte noch einen Fehler, der zu DB-Abstürzen führte, das musste ich erst noch beseitigen.
Es läuft jetzt eine Vorstufe los, die die aktuellen Grenzpolygone und die Hiearchien neu setzt. Später läuft dann eine neue Auswertung. Zusammen wird es noch einige Zeit heute laufen.
Zu Rheinland-Pfalz: da habe ich heute zwischendurch bei einer großen Anzahl den früheren Regierungsbezirk Koblenz entfernt, das sollte dann heute spät auch hoffentlich weitgehend passen.
Meine Änderungen haben eine deutliche Reduzierung der Fehler ergeben.
“Fehlen in OSM” sind im wesentlichen Grenzstraßen, die früher Bonn falsch
zugerechnet wurden (6 von 7). Das muss ich gelegenlich einzeln kontrollieren.
Ein Weg ist vorübergehend nur als old_name eingetragen (Komplett-Sanierung).
Bei “nur in OSM” sind die Mehrzahl die bekannten Feld-/Waldwege, lokalen Namen
usw. Es sind aber auch ein paar neue Straßen/Wirtschaftswege dabei.
Haltestellen mit highway=platform werden weiter falsch als Straßenname erkannt.
Bei den ersten zwei Punkten wäre die Anzeige des Kommentars hilfreich.
Insgesamt ist das aber alles auf einem guten Weg.
Die Einordnung der Kreise in RLP leidet immer noch unter der nicht mehr korrekten Zuordnung zu Regierungsbezirken. Kontrolliert habe ich den Kreis Neuwied und den Rhein-Lahn-Kreis.
Was wertest du aus, nur den place-Knoten oder auch die Grenz-Relation? Benutzt du nur is_in=* oder auch openGeoDB:is_in=*? Das wäre wichtig zu wissen, wenn man etwas korrigieren will.
Hallo Dietmar,
ich habe vor einer Woche und letzten Montag Straßen in zwei neuen Baugebieten erfasst und die sind selbst bei der neuesten Aktualisierung (29.7) noch nicht in der Straßenliste mit aufgeführt.
An was könnte das liegen?
Hast du schon eine ungefähre Vorstellung ab wann man zu falschen oder nicht vorhandenen Straßennamen selbst Anmerkungen zufügen kann damit die nicht mehr als fehlend angezeigt werden?
sorry, das ich mich eine Zeit lang nicht gemeldet habe, aber ich bin gerade beruflich unerwartet stark eingebunden.
Ich hatte letzte Woche ein Ticket auf dem toolserver-System erstellt und erst vor kurzem eine Antwort erhalten, daß die dort verwendete Datenbank seit 24.7. oder einige Tage zuvor bereits nicht mehr aktualisiert wird. Ein Admin macht einige Tests, danach wird die DB wieder an den aktuellen osm Stand gebracht.
Das ist der Grund, warum die Änderungen bei Weiden an der Oberpfalz von einem User oder auch meine Regierungsbezirk Koblenz vom 24.7. immer noch nicht in der DB drin sind.
Mit dem Umzug auf den toolserver hat sich ja die DB-Struktur geändert; dort wird die osm2pgsql-Struktur zum rendern eingesetzt. Diese Version setze ich bei mir lokal nicht ein, daher müssen wir einfach warten, bis dort die DB wieder aktuell gehalten wird.
Ich habe von zwei User Zusendungen erhalten, die ich aus Zeitgründen noch nicht eingespielt habe, das versuche ich am Wochenende nachzuvollziehen.
Die Einführung eines Wikis zur Verwaltung der Listen ist etwas in die Ferne gerückt, das wird wohl erst im September was werden, sorry.
Vor etwa einer Woche habe ich nochmal Florian Lohoff wegen des gesamten DB-Abzugs angemailt, aber von ihm kommt keine Rückmeldung. Mittlerweile glaube ich nicht mehr daran, daß er bereit ist, die Daten rauszurücken.
Die zur Zeit nicht mehr aktuelle DB ist natürlich bedauerlich. Aber immerhin kann man jetzt nachvollziehen, wenn Änderungen in den OSM-Daten sich nicht auf die Liste auswirken.
Ich habe die Liste von Bonn aktualisiert, indem ich die Veränderungen seit März 2010 geprüft und nachgetragen sowie Fehler in den OSM-Daten bereinigt habe. Kannst du daher bitte Bonn bei Gelegenheit mal mit in die Auswertung nehmen.
Wie kann ich eine Liste aus Rheinland-Pfalz ergänzen/korrigieren? Dort sind gelegentlich Fehler enthalten, da bei langen Namen Straße mit Str. abgekürzt wird. Ohne Wiki kann das schwierig werden.
Konkret geht es um die “Freiherr-vom-Stein-Str.” / “*-Straße” in Nassau oder die “Gebr.-Grimm-Straße” (OSM=“Gebrüder-Grimm-Straße”) in Rheinbreitbach. Andere Abkürzungen wie “Friedr.-Ebert-Straße” statt “Friedrich-Ebert-Straße” (Stadt Linz) kommen ebenso vor. Auch scheinen in der Straßenliste immer mal wieder Ortsbezeichnungen, die wahrscheinlich keine Straßen sind, aufzutauchen. Beispiel Stadt Linz: “Gemarkung Laubheck”
Für ein amtliches Straßenverzeichnis finde ich solche Ungenauigkeiten ziemlich beängstigend.
Gib die Hoffnung wegen Florian nicht auf.
Die Kommunikation mit ihm war auch früher schon sporadisch eingeschränkt.
Versuche das bitte schnellstmöglichst hinzukriegen. Definiere zumindest ein Layout für die Daten, auch wenn eventuell noch unklar ist, wo das Zeug landen soll.
Solange da nix passiert, werden die wenigsten dich mit aktuellen Daten versorgen und die Basis für deine Testumgebung bleibt relativ schmal.
Gruss
Walter
p.s. zwei Tippfehler in einer Zeile vom Copyright: “Bei OpenSreetMap gibt es in deutsch u.a. folgende OpenStreetMap Lizenzinformatioen”
ist keines falls “unbekannt”, sondern gehört in
