Vorschlag für autom. Edit: Schreibweise Straßennamen

Oli-Wan · 2012-12-04 12:04:18

Hallo,

bei dem im Vorgängerthread eingeholten Meinungsbild zeichnet sich ab, daß eine automatische Korrektur falsch geschriebener Straßennamen ("Str", "Str.", "Strasse") grundsätzlich auf weitgehende Unterstützung trifft. Wenn ich richtig gezählt habe: 17x "(+)", 2x "(-)". Daher möchte ich nun die detailliertere Diskussion zu einer solchen Korrektur eröffnen; mit der Bitte insbesondere an chris66, BFX und alle anderen, die prinzipielle Bedenken haben, sich hier einzubringen.

Noch einmal ausdrücklich die Frage: möchte jemand die Entwicklung/Ausführung übernehmen? Wenn nicht, mache ich das (vorbehaltlich des weiteren Diskussionsverlaufs). Und ebenfalls noch einmal der Hinweis: andere Aufgaben suchen auch noch jemanden, der sie erledigt.

Vorhaben (Zusammenfassung)
Automatische Korrektur falsch geschriebener Straßennamen in DE: "Strasse", "Str", "Str." in "Straße" umwandeln, analog für die Varianten mit kleinem "s"; angewandt auf Straßen, also Wege (ways) mit highway-Tag. Regelmäßige Ausführung.

Warum das ganze?
Auf "Straße" endende Straßennamen in DE werden stets mit "ß" geschrieben; bei den abweichenden Schreibweisen handelt es sich um Fehler bzw. um Abkürzungen, welche in OSM nicht verwendet werden (also nach unseren Konventionen ebenfalls "Fehler" sind).

Mögliche Einwände (falls weitere, bitte posten)
Man könnte einwenden, daß in OSM die Regel gilt "wir taggen, was wir sehen", und folglich, wenn auf einem Straßenschild "Bahnhofstrasse" oder "Poststr." steht, dies auch so in OSM eingetragen werden soll; und diese möglicherweise bewußte Entscheidung eines Mappers sollte nicht von einem Bot überstimmt werden.
Nach meinem Verständnis gilt besagte Regel jedoch nicht für offensichtliche Fehler - wir tragen ein Kino ja auch nicht als "ineplex" ein, bloß weil in der Leuchtreklame das "C" kaputt ist. Eine Straße in DE heißt eben nicht "Bahnhofstrasse" (sonst müßte das zweite "a" auch kurz ausgesprochen werden!) und auch nicht "Poststr." oder "Poststr". Wenn man einen Anwohner fragt, wie seine Straße heißt, wird er "Poststraße" antworten, ausgesprochen mit langem "a", und wenn man ihn bittet, den Namen aufzuschreiben, wird er - Beherrschung der deutschen Rechtschreibung vorausgesetzt - ein "ß" verwenden.
Bei anderen Objekten, die nach Straßen benannt, jedoch selbst keine Straßen sind, etwa Bushaltestellen, Umspannstationen, Einrichtungen der Gas- und Wasserversorgung, Telefonzellen, kommen die falschen Schreibweisen ebenfalls vor (in name oder ref). Hier mag man jedoch argumentieren, daß es sich um eine vom jeweiligen Betreiber genau so vergebene Bezeichnung handelt. Daher würde ich solche Objekte von Korrekturen ausnehmen wollen - daher die Beschränkung auf highway-getaggte Wege.

Caveats
Im Vorgängerthread wurde bereits mehrfach zurecht angemerkt, daß die geplante Korrektur unbedingt präzise auf DE beschränkt werden muß.
Ein Grund dafür ist, daß in manchen Nachbarstaaten Straßennamen (Schweiz, Belgien, Luxemburg?) tatsächlich als "Strasse" geschrieben werden.
Ferner wird die Abkürzung "Str." auch in anderen Sprachen verwendet, müßte allerdings anders expandiert werden (Niederländisch: straat).

Es genügt also nicht, einfach nur einen germany-Extrakt der Geofabrik nach Tags zu filtern und die Korrektur auf alle so erhaltenen Objekte anzuwenden, da die Geofabrik-Extrakte immer etwas zu groß sind. Stattdessen ist vorgesehen, den Geofabrik-Extrakt nur als erste Stufe zu verwenden und die hieraus erhaltenen Kandidaten anschließend durch ein grenzscharfes Polygon zu filtern (von aighes freundlicherweise zur Verfügung gestellt).

Vorgehensweise (Skizze)

Filtern des Geofabrik-Extrakts germany.osm auf Wege, die folgenden Kriterien entsprechen: highway-Tag hat einen der gängigen Werte für Straßen (path bis motorway); name passt auf den Regex /[Ss]tr(\.?|asse)$/, enthält also eine der genannten Schreibweisen.
Da im ersten Schritt die Knoten der betreffenden Wege verworfen wurden: diese vom Server aus dem Extrakt nachladen.
Filtern durch das DE-Grenzpolygon.
Bearbeitung: Die erhaltenen Kandidaten werden neu von der API geladen, da die Daten aus dem Geofabrik-Extrakt bereits veraltet sein können. Anschließend wird für jedes Objekt erneut geprüft, ob die Kriterien erfüllt sind; falls ja, wird das name-Tag geändert und das Objekt hochgeladen.

Verwendete Software
Die Filterung des Geofabrik-Extrakts übernimmt derzeit ein einfaches AWK-Programm; zugunsten höherer Geschwindigkeit wird dieses ggf. noch durch ein besser angepaßtes Werkzeug ersetzt. Das Filtern nach Tags erfolgt mit osmfilter. Das Nachladen fehlender Knoten erfolgt ebenfalls mit einem AWK-Programm, anschließend Verschmelzung und Sortieren der Datenströme mit osmosis. Das Filtern durch das Grenzpolygon geschieht mit osmosis (evtl. durch osmfilter ersetzt). Die eigentliche Bearbeitung inklusive der Kommunikation mit der API erfolgt schließlich mit GNU Emacs.

Konfliktlösung
Keine/optimistic locking. Sollte eine neuere Version existieren, verweigert die API das Hochladen des Objekts. In diesem Fall überspringt der Editor das Objekt und der Fehler bleibt ggf. bis zum nächsten Durchlauf erhalten.
Da die Objekte unmittelbar vor der Änderung heruntergeladen werden, sind Konflikte allerdings äußerst unwahrscheinlich.

Ausführungsintervall
Mir schwebt vor, die Korrektur im regulären Betrieb in Abständen von ca. 2 Wochen durchzuführen.
Im Testbetrieb (einige Wochen, bis einigermaßen sichergestellt ist, daß keine Fehler passieren) dagegen zunächst ca. tägliche Ausführung, aber beschränkt auf wenige (etwa 10) Objekte zwecks detaillierter Inspektion.

Account
Wall·E (hoffentlich werde ich dafür nicht verklagt)

Nachträge

Änderungssätze
mehrere Objekte in einem Änderungssatz,
vorgesehener Kommentar: Korrektur der Schreibweise von Straßennamen: Ersetzung Str/Str./Strasse → Straße bzw. -str/-str./-strasse → -straße
bot=yes und ggf. Verweise auf Wikiseite und diesen Thread

Dokumentation
vorläufig: dieser Thread; später Wikiseite

Zu beachtende Sonderfälle
Gleistrasse (vermutlich Gleis-trasse, nicht Glei-straße)
Gastrasse
(Ergänzung weiterer Ausnahmen jederzeit möglich)

Last edited by Oli-Wan (2012-12-10 14:41:59)

aighes · 2012-12-04 13:18:16

Hallo,
hast du schon mal einen Probelauf gemacht, was da so von der (X|j|Overpass)API geladen werden müsste?

Ich würde es evtl. anders machen. Germany-Extrakt laden, mit osmupdate auf den neusten Stand bringen (geht auf die Minute). Hier noch mit dem groben Polygon der Geofabrik. Dann Straßen (inkl. Nodes) aus dem Extrakt filtern, die geändert werden müssten. Diese dann durch den feineren Filter jagen und dann Ändeurngen vor nehmen und dann ab mit den Daten zur API.

Ich würde hier versuchen zu vermeiden, mit unterschiedlichen Datenbeständen zu arbeiten und wenn der Bot in der Nacht läuft hast du auch nicht so das Problem, dass viel editiert wird.

Oli-Wan · 2012-12-04 13:57:30

aighes wrote:

Hallo,
hast du schon mal einen Probelauf gemacht, was da so von der (X|j|Overpass)API geladen werden müsste?

Testläufe habe ich bisher immer nur für den Regierungsbezirk Köln laufen lassen. Da ist aber die "Strassen"-Dichte schon etwas reduziert, insofern ist eine Extrapolation auf DE mit Vorsicht zu genießen.
Zum Entwicklungsstand ist noch zu sagen: bisher ist die Teilkette "Filtern, Nachladen, Schneiden" realisiert und getestet, und die Editierfunktion in Emacs kann derzeit ein Objekt auf explizites Kommando laden, prüfen und ggf. bearbeiten und hochladen: Dieser Änderungssatz entstand bspw. durch "(osm-task-fix-strasse 'way 190570756)". Was noch fehlt, ist die Verbindung beider Teile: Emacs kann noch keine .osm-Dateien oder Streams lesen und verarbeiten, die Aktualisierung von Objekten ist noch nicht vorgesehen, und schlußendlich muß die Funktion noch angepaßt werden, um eine Liste von Objekten zu bearbeiten. Das sind aber vergleichsweise einfache Dinge.

Die API wird an zwei Stellen belastet: zum einen beim Nachladen der Knoten, die mein Filterprogramm mit Rücksicht auf den Speicherbedarf nicht vorhält (es spuckt nur Wege aus, aber für das Filtern nach Polygon braucht man natürlich auch deren Knoten), zum anderen beim Holen der aktuellen Daten unmittelbar vor der Bearbeitung.

Der erste Schritt erfolgt mit /nodes?nodes=...; bei den Testläufen (Köln) ging es da um die Größenordnung von 100 Knoten. DE ist etwa 20x größer, dazu die höhere Fehlerdichte: grob geschätzt müßten 5000-10000 Knoten nachgeladen werden. Sobald die Fehler erst einmal eingedampft sind, reduziert sich diese Zahl natürlich. Die Knoten könnte man alternativ noch aus dem bereits herumliegenden Extrakt holen. Das wäre auch kein Hexenwerk, aber der Weg über die API war erst einmal einfacher, als es beim Test nur darum ging, ob das Polygon-Schneiden korrekt funktioniert - und die API-Last durch die Testläufe war hierbei auch noch gering. Ansonsten könnte ich natürlich auch ganz einfach auf die Oberpfälzer-API auswandern.
Ich lasse gerade einmal germany.osm.bz2 filtern, um auf belastbarere Zahlen zu kommen. Walter und seine DB wissen die Antwort natürlich auch.
Edit: etwa 13700 Knoten müßten aktuell nachgeladen werden. Wenn das in einem Rutsch laufen sollte, wären die Ausweichalternativen wohl doch besser. Liegt wahrscheinlich daran, daß doch relativ viel Schweiz in germany.osm liegt. Eine Möglichkeit wäre natürlich noch, die IDs dieser Wege zu speichern und bei zukünftigen Läufen für ein Veto zu verwenden.

Die Aktualisierung der Kandidaten erfolgt per Einzelabfrage (das könnte aber auch noch auf ways?ways=... umgestellt werden). Hier geht es DE-weit vorerst um ein paar hundert Objekte.

aighes wrote:

Ich würde es evtl. anders machen. Germany-Extrakt laden, mit osmupdate auf den neusten Stand bringen (geht auf die Minute). Hier noch mit dem groben Polygon der Geofabrik. Dann Straßen (inkl. Nodes) aus dem Extrakt filtern, die geändert werden müssten. Diese dann durch den feineren Filter jagen und dann Ändeurngen vor nehmen und dann ab mit den Daten zur API.
Ich würde hier versuchen zu vermeiden, mit unterschiedlichen Datenbeständen zu arbeiten und wenn der Bot in der Nacht läuft hast du auch nicht so das Problem, dass viel editiert wird.

Geht natürlich auch, aber eigentlich brauche ich ja nur von den Objekten, die 1) (wahrscheinlich) korrigiert werden sollen und 2) innerhalb von DE liegen, die aktuellste Version; deswegen lade ich (nur) diese unmittelbar vor der Bearbeitung neu. Das "Nachladen" der Knoten im ersten Schritt braucht keine brandaktuellen Daten, und auch daß der Geofabrik-Extrakt per se einen bis zwei Tage alt ist, stört nicht. Hier werden ja nur Kandidaten ermittelt; die endgültige Entscheidung, ob ein Objekt bearbeitet wird, erfolgt später anhand seiner aktuellen Tags.
Die europäische Nacht wäre in der Tat die bevorzugte Ausführungszeit.

Last edited by Oli-Wan (2012-12-04 14:30:44)

aighes · 2012-12-04 14:01:46

Ich probiere mich gerade an einer Lösung über osmfilter und osmconvert mit dem Output: exakt geschnittene osm-Datei nur mit den Kandidaten. Ich schau mal wie lange es dauert.

mkgmap\bin\osmconvert.exe mkgmap\src\planet.osm.pbf -B=germany.poly --out-o5m -o=germany.o5m

mkgmap\bin\osmfilter.exe germany.o5m --drop-relations --out-o5m -o=g_norel.o5m
mkgmap\bin\osmfilter.exe g_norel.o5m --keep="name=*strasse =*str =*str. =*Strasse =*Str =*Str." --out-o5m -o=candidates_name.o5m
mkgmap\bin\osmfilter.exe candidates_name.o5m --keep="highway=path =cycleway =footway =bridleway =steps =road =track =service =pedestrian =living_street =residential =unclassified =tertiary =tertiary_link =secondary =secondary_link =primary =primary_link =trunk =trunk_link =motorway =motorway_link" --out-o5m -o=candidates.o5m
mkgmap\bin\osmconvert.exe candidates.o5m -B=germany_exact.poly --complex-ways --out-pbf -o=candidates.osm.pbf

EDIT: Ich weiß, das ist nur eine Kleinigkeit: Aber bitte nutzen allgemein verständliche Changeset-Kommentare. Einen RegEx kann nicht jeder lesen und Verstehen. Verständlich wäre bspw. Namensbestandteil zu Straße/straße geändert

Last edited by aighes (2012-12-04 15:35:08)

Oli-Wan · 2012-12-04 14:28:55

aighes wrote:

Aber bitte nutzen allgemein verständliche Changeset-Kommentare. Einen RegEx kann nicht jeder lesen und Verstehen. Verständlich wäre bspw. Namensbestandteil zu Straße/straße geändert

Einverstanden. Wie wäre es mit: Korrektur der Schreibweise von Straßennamen: Ersetzung Str/Str./Strasse → Straße, analog für Varianten von "-straße"
Ich möchte nicht wie bei den (manuell gestarteten) Einzeltests für jede Straße einen eigenen Änderungssatz aufmachen

aighes · 2012-12-04 14:39:15

Deshalb hab ich ja auch nur das Ziel (Straße bzw. straße) angegeben.

Nach anfänglichen Problemen mit der Syntax und mit osmconvert ging es recht simpel und dauerte 16min. 15min brauchte die Erstellung von germany.o5m aus dem planet.osm.pbf (mit nem Deutschland-Extrakt gehts wohl schneller), die restliche Minute ging dann fürs Filtern und erstellen der osm-Datei drauf. Finde ich akzeptabel.

Die Syntax hab ich oben angepasst. OSMconvert muss für das exakte Polygon geändert werden. Der kommt defaultmäßig nur mit 60004 Einträgen in der poly-Datei klar. Das kann man aber im Quellcode ändern, siehe: http://wiki.openstreetmap.org/wiki/Talk … _too_large. Benötigt werden knapp 80000. Wenn man es auf 100000 ändert ist man auf der sicheren Seite.

Achso, in den poly-Dateien ist auch noch ein Syntax-Fehler drin. Nach http://wiki.openstreetmap.org/wiki/Osmo … ile_Format können sehr wohl Enklaven enthalten sein, müssen aber mit einem ! vor der Nummer gekennzeichnet werden. Dann kommt osmconvert damit auch zurecht. Das josm-Plugin hat das bei mir nicht gemacht. Daher fehlen diese !.

Last edited by aighes (2012-12-04 14:52:13)

Oli-Wan · 2012-12-04 14:50:57

aighes wrote:

Nach anfänglichen Problemen mit der Syntax und mit osmconvert ging es recht simpel und dauerte 16min. 15min brauchte die Erstellung von germany.o5m aus dem planet.osm.pbf (mit nem Deutschland-Extrakt gehts wohl schneller), die restliche Minute ging dann fürs Filtern und erstellen der osm-Datei drauf. Finde ich akzeptabel.

Behält osmfilter dabei alle gelesenen Knoten im Speicher? Wie breit macht es sich dann dort?

Das Entpacken und Tag-Filtern dauert bei mir für DE aktuell 12 Minuten, dann kommt aber noch das Nachladen, Sortieren und das grenzgenaue Schneiden hinzu (was ich jetzt ausgespart habe, um nicht ohne jeden Nutzen 14000 Knoten vom Server abzufragen). Rechenzeit ist aber nicht das Problem, insofern bleibe ich vorerst bei meinen Werkzeugen (die ich besser verstehe und vor allem einfacher modifizieren kann) und werde erst einmal die Lücke in der weiteren Verarbeitungskette schließen. Aber ich behalte Deinen Tipp im Hinterkopf und werde ihn dann wahrscheinlich zu einem späteren Zeitpunkt umsetzen.

Edit: da der Speicherbedarf nicht so groß ist wie befürchtet, wahrscheinlich gestrichen.

Last edited by Oli-Wan (2012-12-04 14:58:05)

viw · 2012-12-04 14:53:18

Oli-Wan wrote:

aighes wrote:
Aber bitte nutzen allgemein verständliche Changeset-Kommentare. Einen RegEx kann nicht jeder lesen und Verstehen. Verständlich wäre bspw. Namensbestandteil zu Straße/straße geändert
Einverstanden. Wie wäre es mit: Korrektur der Schreibweise von Straßennamen: Ersetzung Str/Str./Strasse → Straße, analog für Varianten von "-straße"
Ich möchte nicht wie bei den (manuell gestarteten) Einzeltests für jede Straße einen eigenen Änderungssatz aufmachen

Du kannst ja auch eine Wiki/website oder diesen Thread hier verlinken. Für den der mit der Kurzformulierung nichts anfangen kann.

aighes · 2012-12-04 14:55:08

osmfilter nimmt sich bei mir 840mb RAM

Oli-Wan · 2012-12-04 14:56:17

aighes wrote:

osmfilter nimmt sich bei mir 840mb RAM

Oh, das geht ja. Ich hatte mit schlimmerem gerechnet.

aighes · 2012-12-04 15:05:09

Bei mir kommen mit Daten von ~ 2.12. 0Uhr 645 Wege mit 4428 Knoten raus.

aighes · 2012-12-04 15:11:02

Beim sichten der Ergebnisse bin ich auch auf einen Weg gestoßen, der "Alte Gleistrasse" heißt. Enthält auch den string "strasse", soll aber nicht in straße geändert werden, da es ja eine Gleis-trasse ist und keine Glei-straße. Jemand eine Idee?

Oli-Wan · 2012-12-04 15:17:06

aighes wrote:

Bei mir kommen mit Daten von ~ 2.12. 0Uhr 645 Wege mit 4428 Knoten raus.

Meine Zahl oben enthielt noch die Schweizer "Strassen" bzw. ihre Knoten. Insofern kein Widerspruch.

aighes wrote:

Beim sichten der Ergebnisse bin ich auch auf einen Weg gestoßen, der "Alte Gleistrasse" heißt. Enthält auch den string "strasse", soll aber nicht in straße geändert werden, da es ja eine Gleis-trasse ist und keine Glei-straße. Jemand eine Idee?

Oh ja, Weg 27245740. Da hilft wohl nur, solche Spezialfälle separat abzufangen.

Blöde Frage am Rande: Warum enthält das OSM-XML am Ende der tag-Zeilen ein Leerzeichen vor dem "/>", am Ende der nd- und member-Zeilen aber nicht?

S-Man42 · 2012-12-04 15:17:38

Also das kannste eigentlich gar nicht berücksichtigen. Das muss dann irgendwie in der Selektion als Ausnahme formuliert werden. Da das schon ein echt krasser Sonderfall ist, würde ich da nicht viel mehr Logik reinstecken als: Gib alle [Regex]. If Contains(Gleistrasse) -> Ignore...

Oli-Wan · 2012-12-04 15:24:57

In Thüringen gibt es auch noch eine Gas-trasse.

aighes · 2012-12-04 15:39:17

Ich hab noch ein Problem mit osmfilter festgestellt. Er übernimmt auch alle Wege, die Teil einer Relation sind, dessen name auf die Suchwörter anspringt.
Ein einfaches drop-relation im selben Aufruf hat leider nicht geholfen, daher einen zusätzlichen Aufruf vorne weg. Kostet dann noch etwas zusätzliche Zeit, um rund 2gb auf die Platte zu schreiben. Evtl. schaut sich ein osmfilter-Experte die drei Aufrufe an. Evtl. kann man da ja noch etwas vereinfachen.

mkgmap\bin\osmfilter.exe germany.o5m --drop-relations --out-o5m -o=g_norel.o5m
mkgmap\bin\osmfilter.exe g_norel.o5m --keep="name=*strasse =*str =*str. =*Strasse =*Str =*Str." --out-o5m -o=candidates_name.o5m
mkgmap\bin\osmfilter.exe candidates_name.o5m --keep="highway=path =cycleway =footway =bridleway =steps =road =track =service =pedestrian =living_street =residential =unclassified =tertiary =tertiary_link =secondary =secondary_link =primary =primary_link =trunk =trunk_link =motorway =motorway_link" --out-o5m -o=candidates.o5m
mkgmap\bin\osmconvert.exe candidates.o5m -B=germany_exact.poly --complex-ways --out-pbf -o=candidates.osm.pbf

BFX · 2012-12-04 16:37:44

Also meine Bedenken dabei sind, dass es doch einige Straßen gibt, die in das Suchmuster reinpassen aber die wir nicht umbenennen dürfen. Wie können wir sicher sein, dass es nur diese zwei sind?

Ist es von der Menge machbar, die Straßen vor dem ersten Botlauf einzeln zu prüfen?

aighes · 2012-12-04 17:02:23

Also dieses Problem kann nur bei "strasse" auftreten. Alle andere 5 Fälle sind eindeutig. Aktuell gibt es nur die beiden Namen, die nicht in das Raster fallen. Sollte es später weitere geben, könnte man diese ebenfalls auf die Liste setzen und ausschließen.

Ein Problem hab ich noch gefunden. osmconvert lässt die Wege, die an der Schweizer Grenze beginnen mit in Deutschland. Man bräuchte wohl eine Option, die genau das Gegenteil von --complex-ways macht. Wenn ein Node außerhalb, dann ganzer Way weg.

Oli-Wan · 2012-12-04 17:17:41

BFX wrote:

Also meine Bedenken dabei sind, dass es doch einige Straßen gibt, die in das Suchmuster reinpassen aber die wir nicht umbenennen dürfen. Wie können wir sicher sein, dass es nur diese zwei sind?
Ist es von der Menge machbar, die Straßen vor dem ersten Botlauf einzeln zu prüfen?

Völlig sicher kann man da wohl nie sein. Die Liste der Straßennamen, die einen Match ergeben, kann man auf jeden Fall vorher prüfen. Vorhin habe ich sie mal grob durchgesehen (-> Gastrasse), das könnte man auch noch einmal gründlicher machen. Aber auch da gibt es keine Garantie, wirklich gar nichts zu übersehen. Oder daß nicht später ein Straßenname hinzukommt, der jetzt nicht vorhanden war.

Was für Namen könnten einen falschen Match ergeben, d.h. welche Möglichkeiten müßte man bei der Durchsicht erkennen?

zusammengesetzte Namen aus "Trasse" und einem Wort davor, welches auf s endet, oder ein Genitiv-s erhält: so wie die gefundenen Gas- und Gleis-. Weitere sind durchaus denkbar, auch wenn mir spontan keine einfallen.
Straßennamen, wo der erste Namensbestandteil auf s (auch Genitiv-s) endet und die Abkürzung "tr" oder "tr." folgt. Allerdings sehe ich nicht, wofür eine solche Abkürzung im Kontext von Straßennamen stehen sollte (außer Trasse, aber wer würde "Gleis-trasse" als "Gleis-tr." abkürzen?)
Straßennamen, wo der erste Namensbestandteil auf st endet (Kleist, Wurst, Papst, ...) und die Abkürzung "r" oder "r." folgt. Diese könnte noch für "Ring" stehen - scheint mir aber nicht gebräuchlich.

Keine derartigen Probleme gibt es in den Fällen mit großem S.

Nachtrag zur Häufigkeit von "Trassen": Wenn man sich mal die name-Tags mit vermeintlich "echten" -trassen anschaut, also Matches von "trasse" aber nicht "Strasse" oder "strasse", finden sich in DE etwa 700 so getaggte Objekte. Dabei habe ich jetzt auf die Schnelle nicht auf den Objekttyp oder weitere Tags geschaut, d.h. wenn man auf Wege mit highway-Tag einschränkt, werden es noch ein paar weniger. Bei den meisten folgt -trasse auf -bahn-: Vennbahntrasse, Hafenbahntrasse, Erzbahntrasse, (Ehemalige) Kleinbahntrasse, Schnellbahntrasse usw. Außerdem gibt es z.B. Sambatrasse, Fernwärmetrasse, Korkenziehertrasse (?!), aber die meisten haben noch "-bahn-" vor der "-trasse". Insofern gehe ich davon aus, daß es auch nur sehr wenige "legitime" Verwendungen von -s-trassen gibt.

Last edited by Oli-Wan (2012-12-04 18:46:55)

Marqqs · 2012-12-04 18:53:56

aighes wrote:

Ich hab noch ein Problem mit osmfilter festgestellt. Er übernimmt auch alle Wege, die Teil einer Relation sind, dessen name auf die Suchwörter anspringt.
Ein einfaches drop-relation im selben Aufruf hat leider nicht geholfen, daher einen zusätzlichen Aufruf vorne weg. Kostet dann noch etwas zusätzliche Zeit, um rund 2gb auf die Platte zu schreiben. Evtl. schaut sich ein osmfilter-Experte die drei Aufrufe an. Evtl. kann man da ja noch etwas vereinfachen.

Moin!

Als osmfilter-Experte seh ich mich nicht, aber ich weiß ein bisschen über das Programm. ;-)
Hab den Thread nur überflogen, glaube aber dass das ein Fall für die Option --ignore-dependencies sein könnte...

Grüße
Markus

aighes · 2012-12-04 19:46:42

Hallo Markus,
evtl. hättest du ja Lust, deinen Schneide-Algorithmus etwas zu verbessern. Wenn ein Weg nur einen Knoten auf der Grenze des bounding-polygons hat und keinen Node in dem bounding-polygon, dann kann der Weg weg, weil er ja nicht in dem Polygon liegt.

Zu --ignore-dependencies:

Darüber hab ich auch schon nachgedacht. Das Problem ist dann, dass man gleich zu beginn alle Daten in Deutschland gegen ein bounding-polygon mit rund 80000 Punkten testen muss. Werde ich aber auch mal probieren.

EvanE · 2012-12-04 23:46:23

aighes wrote:

Ich hab noch ein Problem mit osmfilter festgestellt. Er übernimmt auch alle Wege, die Teil einer Relation sind, dessen name auf die Suchwörter anspringt.
Ein einfaches drop-relation im selben Aufruf hat leider nicht geholfen, daher einen zusätzlichen Aufruf vorne weg. Kostet dann noch etwas zusätzliche Zeit, um rund 2gb auf die Platte zu schreiben. Evtl. schaut sich ein osmfilter-Experte die drei Aufrufe an. Evtl. kann man da ja noch etwas vereinfachen.

Hallo Henning

Man kann doch --drop-relations schon bei osmconvert angeben. Irgendwie musst du die Daten ja erst einmal in das o5m Format bringen und kannst dann im selben Lauf die Relationen rauswerfen. Ich kann jetzt nicht einschätzen, ob du andere Auswertungen fährst, die Relationen brauchen. Dann passt das natürlich nicht an der Stelle.

Edbert (EvanE)

aighes · 2012-12-05 00:05:13

Ja, das würde gehen. Unterstützt das auch osmconvert?

Derzeit kämpfe ich auch noch etwas mit dem Finden der ganzen falschen Namen. Wenn sie auf Str., str., strasse, Strasse, Str und str enden ist das kein Problem. Wenn die Schlüsselworte allerdings nicht am Ende stehen gibt es Probleme.

--keep="name=*str*" trifft bspw. auch auf straße zu. Nimmt man --keep="name=*str *" interpretiert er den zweiten * als ein 'nimm alles'. Hat jemand eine Ahnung, wie man nach einem Value mit Leerzeichen drin filtern kann?

Man muss Leerzeichen mit \ escapen, dann klappt das auch.

Last edited by aighes (2012-12-05 00:52:47)

Oli-Wan · 2012-12-05 11:25:33

Was mir an der Lösung mit osmfilter ein wenig mißfällt ist, daß man mehrfach die kompletten Daten schreiben muß: Erst ein .osm.pbf herunterladen, dieses dann in ein o5m konvertieren, dann einen Zwischenstand nach der Filterung nur nach name speichern und erst dann das Endergebnis (modulo Konversion ins gewünschte Format). Ursache ist, daß osmfilter die Daten zweimal durchgeht, um die Knoten nachzuladen; d.h. es funktioniert nicht mit Pipelines.
Das Problem läßt sich mit ignore-dependencies und Verwendung von FIFOs umgehen, aber dann muß man vor dem Filtern doch wieder die Knoten nachladen. Dafür muß man nur einmal die heruntergeladene Datei speichern und anschließend das Ergebnis nach Filtern und sauberem Ausschneiden. Gibt es eine Möglichkeit, mit osmfilter effizient eine größere Anzahl von Knoten anhand ihrer ID auszufiltern? Ein --keep="@id=1 or @id=2 or @id=3 or ..." erscheint mir doch arg zäh, weil für jeden Knoten (über 100 Millionen im DE-Extrakt) sämtliche Bedingungen (einige tausend) durchprobiert werden müßten

Oli-Wan · 2012-12-05 12:12:14

Zum Problem der -s-trassen: Ich habe gerade die Kandidatenliste nach möglichen Fehlmatches durchgeschaut. Gefunden habe ich nur die beiden bereits bekannten "Gleistrasse" und "Gastrasse" sowie "An der Gastrasse". Wer selbst noch einmal durchschauen will, hier ist die Liste aller derzeitigen Straßennamen auf -strasse in DE (plus eine Handvoll in CH, siehe Problem mit dem Abschneiden grenzüberschreitender Wege [1]):

     14 Bergstrasse
     12 Ladestrasse
      6 Hauptstrasse
      6 Gartenstrasse
      4 Itterstrasse
      3 Talstrasse
      3 Rothbachstrasse
      3 Querstrasse
      3 Poststrasse
      3 Osterbergstrasse
      3 Leopardstrasse
      3 Klotzstrasse
      3 Gastrasse
      3 Friedhofstrasse
      3 Dorfstrasse
      3 Bahnhofstrasse
      3 Angerstrasse
      2 Zollhausstrasse
      2 Wirtschaftsstrasse
      2 Wiesenstrasse
      2 Siegelhofstrasse
      2 Reuthenstrasse
      2 Neustrasse
      2 Neue Kulturstrasse
      2 Meyerhofstrasse
      2 Mauerstrasse
      2 Konstanzerstrasse
      2 Kirchstrasse
      2 Hegelstrasse
      2 Haldenstrasse
      2 Geißbergstrasse
      2 Forststrasse
      2 Fischerstrasse
      2 Buskower Dorfstrasse
      2 Brückenstrasse
      1 Zehentstrasse
      1 Weststrasse
      1 Weilstrasse
      1 Wallgrabenstrasse
      1 Waldstrasse
      1 Wahlstrasse
      1 Vitalisstrasse
      1 Untere Ringstrasse
      1 Untere Kampstrasse
      1 Untere Dorfstrasse
      1 Ulmerstrasse
      1 Turmstrasse
      1 Thayngerstrasse
      1 Süesslerstrasse
      1 Steinschachtenstrasse
      1 Sportplatzstrasse
      1 Siedlungsstrasse
      1 Selmsdorfer Landstrasse
      1 Schultheißstrasse
      1 Schulstrasse
      1 Schopenhauerstrasse
      1 Schmiedestrasse
      1 Schloßstrasse
      1 Schlossstrasse
      1 Russbergerstrasse
      1 Rheinhaldenstrasse
      1 Predigerstrasse
      1 Oehningerstrasse
      1 Odenwaldstrasse
      1 Obere Ringstrasse
      1 Obere Kampstrasse
      1 Obere Dorfstrasse
      1 Nüffernstrasse
      1 Nietzschestrasse
      1 Mühltalstrasse
      1 Mühlstrasse
      1 Moorstrasse
      1 Maschstrasse
      1 Marktstrasse
      1 Lörracherstrasse
      1 Lindenstrasse
      1 Kolpingstrasse
      1 Kirchenstrasse
      1 Kaufungstrasse
      1 Kaldenbergerstrasse
      1 Kaiserstrasse
      1 Judenstrasse
      1 Jahnstrasse
      1 Industriestrasse
      1 Hofstrasse
      1 Hintere Dorfstrasse
      1 Hiltalingerstrasse
      1 Hilchenbacherstrasse
      1 Herrmannstrasse
      1 Herderstrasse
      1 Heinrichtsbrunnerstrasse
      1 Haydnstrasse
      1 Hauffstrasse
      1 Hansjakobstrasse
      1 Gryphiusstrasse
      1 Grenzstrasse
      1 Grenzacherstrasse
      1 Goldbergstrasse
      1 Gewerbestrasse
      1 Gertenstrasse
      1 Friedenstrasse
      1 Freiburgerstrasse
      1 Finsterauerstrasse
      1 Esperantostrasse
      1 Erlenstrasse
      1 Eichertstrasse
      1 Ebringerstrasse
      1 Ebersbergstrasse
      1 Dörpstrasse
      1 Domagkstrasse
      1 Diademstrasse
      1 Dahlienstrasse
      1 Cranachstrasse
      1 Büsingerstrasse
      1 Burgstrasse
      1 Bunsenstrasse
      1 Brunnenstrasse
      1 Blumenstrasse
      1 Betriebstrasse
      1 Bachstrasse
      1 Anliegerstrasse
      1 An der Gastrasse
      1 Alte Poststrasse
      1 Alte Muchenländerstrasse
      1 Alte Gleistrasse
      1 Akazienstrasse

[1] Dieses sollte sich mit osmosis --bp clipIncompleteEntities=true lösen lassen.
[1] Dieses ist mittlerweile gelöst, lediglich in der obigen Liste sind die betroffenen Wege bzw. ihre Namen noch enthalten..

Last edited by Oli-Wan (2012-12-06 14:07:41)

Announcement

#1 2012-12-04 12:04:18

Vorschlag für autom. Edit: Schreibweise Straßennamen

#2 2012-12-04 13:18:16

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#3 2012-12-04 13:57:30

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#4 2012-12-04 14:01:46

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#5 2012-12-04 14:28:55

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#6 2012-12-04 14:39:15

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#7 2012-12-04 14:50:57

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#8 2012-12-04 14:53:18

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#9 2012-12-04 14:55:08

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#10 2012-12-04 14:56:17

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#11 2012-12-04 15:05:09

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#12 2012-12-04 15:11:02

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#13 2012-12-04 15:17:06

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#14 2012-12-04 15:17:38

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#15 2012-12-04 15:24:57

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#16 2012-12-04 15:39:17

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#17 2012-12-04 16:37:44

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#18 2012-12-04 17:02:23

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#19 2012-12-04 17:17:41

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#20 2012-12-04 18:53:56

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#21 2012-12-04 19:46:42

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#22 2012-12-04 23:46:23

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#23 2012-12-05 00:05:13

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#24 2012-12-05 11:25:33

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

#25 2012-12-05 12:12:14

Re: Vorschlag für autom. Edit: Schreibweise Straßennamen

Board footer