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.
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.
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.
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
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]):
[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…
Du kannst das ganze auch mit osm-xml machen. Dauert dann halt nur länger. Zu dem mehrfachen Filtern: Ich hab es bisher noch nicht geschafft, osmfilter zu sagen er soll highway=… AND name=… filtern. Ich vermute mal, dass es klappt, wenn man es ihm explizit sagt. Dann könnte man sich einiges sparen. Der letzte Aufruf von osmconvert läuft nur, weil nochmal gegen das exakte Polygon geprüft wird.
Wenn du also ein germany.osm auf der Platte hast und wir das mit der Filtersyntax hinbekommen, dann brauchst du lediglich einen Aufruf von osmfilter zum Filtern der Daten und einen Aufruf von osmconvert zum Prüfen gegen das exakte Polygon. Das was dabei geschrieben wird ist aber aktuell bei mir im hohen kb-Bereich, wenn man es als xml ausgibt. Von daher eher nicht so tragisch.
Daran bin ich auch gescheitert. Ist aber kein Beinbruch, der zweite Waschgang bearbeitet ja schon eine gegenüber der ersten Stufe drastisch reduzierte Datenmenge. Und wie gesagt, die Gesamtlaufzeit des Programms ist für mich auch sonst eher nachrangig. Das Endergebnis brauche ich ohnehin in XML.
Ich habe ein .osm.bz2 herumliegen und möchte es nicht entpacken. Mit dem .osm.bz2 kann aber osmfilter nicht umgehen - also muß ich ihm einen FIFO hinstellen, der von bzcat gefüllt wird. Dann kann osmfilter diese “Datei” aber nur einmal lesen, was nur mit --ignore-dependencies funktioniert, und dann fehlen natürlich die Knoten für das Polygon-Schneiden. Um diese aus dem .osm.bz2 (statt wie zuvor bei den ersten Tests von der API) nachzuladen, habe ich mir ein Skript gebastelt, das den Wegen die Knoten hintendranhängt. Sortieren mit osmosis, anschließend Ausschneiden. Für letzteres habe ich jetzt auch wieder osmosis genommen, weil ich hoffe, daß die Option clipIncompleteEntities=true das konservative Abschneiden an der Grenze (mindestens ein Punkt außerhalb → Weg verwerfen) sicherstellt.Edit: falsch gelesen, löst das Problem nicht. Also müssen unvollständige Objekte doch noch einmal im Nachgang aussortiert werden. Erst an dieser Stelle kommt wieder die Festplatte zum Einsatz, mit der fertigen Kandidatendatei (<700 kB).
Das Skript zum Nachladen der Knoten ist im Moment die Spaßbremse. Ist auf die Schnelle in AWK geschrieben, was natürlich eher nicht so flott ist (derzeit Faktor drei langsamer als bzcat). Edit: dank Regex-Vereinfachung mittlerweile “nur noch” ein Faktor zwei. Daher die Frage oben, ob osmfilter (o.a.) effizient nach einer Liste von IDs filtern kann. Ansonsten muß ich mir da irgendwann selbst was schnelleres schreiben.
Der ganze Vorgang ist damit ein Dreizeiler (Aktualisieren des Extrakts, Einrichten der FIFOs und abschließendes Aufräumen mal außen vor)
Grundsätzlich möglich, konkret aber sehr unwahrscheinlich. Es handelt sich um den Weg 87630958, welcher umgeben ist von “Birkenstasse” (sic!), “Obere Ringstrasse” und “Untere Ringstrasse” sowie “Lindenstrasse”. Alle Namen stammen von demselben Mapper und sogar aus demselben Änderungssatz.
Komisch kommt mir bei den Straßennamen insgesamt so einiges vor. “Th.-Mü.-Str.”, “Strasse ohne Namen”, " Obere Dorfstr." (mit zehn Leerzeichen) seien als Beispiele genannt.
Auch OT: Eine Friedenstraße (fälschlicherweise oft als Friedensstraße bzeichnet) gibt es bei uns auch. Tarnung à la Bundeswehr: dort liegt ein NATO-Tanklager.
Nachtrag hierzu: das Schneideverhalten von osmosis ist in diesem Punkt für meine Zwecke vorteilhaft: Wege, die nur teilweise innerhalb des Polygons liegen, sind nach dem Schneiden unvollständig, weil die Knoten außerhalb des Polygons fehlen. Solche Wege verwerfe ich anschließend mit einem zusätzlichen Skript, 18 von derzeit 443 fliegen auf diese Weise heraus. Übrig bleiben nur solche, deren Knoten sämtlich innerhalb des Polygons liegen.
Leider scheint mein User Agent neuerdings blockiert zu werden. Auf die Spielzeug-API kann ich zugreifen, auf die echte nicht mehr. Mit JOSM geht es tadellos.
@BFX: Ist Deinen Bedenken mit der Durchsicht der “-strassen”-Liste und dem Aussparen von (vorerst nur) /[Gg]astrasse/ und /[Gg]leistrasse/ abgeholfen, oder siehst Du weiterhin Probleme?
Die Liste ist ja doch recht überschaubar und wenn was falsch umbenannt wird, wird sich über kurz oder lang schon jemand melden oder es zurückändern und du hast den way beim nächsten mal wieder drin. Das könnte man eventuell noch abfragen.
Ja, das hatte ich mir auch schon überlegt: einmal angefaßte Objekte auf eine Veto-Liste zu setzen und gegen eine erneute Korrektur des gleichen (vermeintlichen) Fehlers zu verhindern. Ist aber noch nicht implementiert.
Danke, aber wenn das so einfach wäre… Eigentlich wollte ich heute einen ersten Demolauf starten, aber die API redet nicht mehr mit Emacs.
Ich nicht. Ich habe gestern vier Änderungssätze erstellt und dabei fünf Objekte bearbeitet. Heruntergeladen habe ich zuvor genau diese Objekte; in einer ähnlichen Größenordnung bewegen sich die anderen Zugriffe in den letzten paar Wochen, seit ich Emacs erstmals auf die echte API losgelassen habe.
Die Knoten-Abfrage ist überflüssig geworden und davor nur vor etwa einer Woche eine Handvoll Male mit je <150 Stück gelaufen (aufgeteilt auf je drei nodes?nodes=…-Abfragen).
Bei den Zugriffen gestern gab es noch einen Fehler mit der UTF-8-Kodierung (die ich in einer Abfrage schlicht vergessen hatte), welchen der Server übel genommen haben könnte. Merkwürdig ist auch, daß ich selbst mit einem - nur versuchsweise! - gefälschten User Agent nicht mehr an die API drankomme. Mit der dev-API funktioniert es weiterhin problemlos. Naja, nachher mal auf dem anderen Rechner mit der aktuellen Version des OSM-Pakets versuchen.
Ich habe die Kandidatenliste räumlich beschnitten (grob mit JOSM, “Bereinigen”), um nicht gleich ganz Deutschland mit fast leeren Änderungssätzen zu überziehen; daher die regionale Verteilung. (Außerdem gibt es eine ganze Reihe leerer Änderungssätze, die wurden versehentlich bei eigentlich trockenen Läufen erzeugt. Da saß das Problem allerdings vor dem Rechner.)
Der Korrekturvorgang ist nun vollständig automatisiert und könnte in einem Aufwasch alle derzeit vorhandenen “Strassen” etc. umbenennen; dies wird derzeit durch eine Beschränkung auf fünf bearbeitete Objekte unterbunden. Sofern es keinen neuen Widerspruch gibt, würde ich nächste Woche den Probebetrieb starten mit täglich etwa einem Änderungssatz à 10 Objekte.
Die Erkennung der bisher bekannten Spezialfälle “Gastrasse” und “Gleistrasse” ist eingebaut.
Du meinst wegen der Grenze zur Schweiz? Die ist fürs Filtern der Kandidaten interessant, aber für die Ausführung der Korrekturen nicht interessanter als andere Regionen. Oder gibt es in BaWü noch andere beachtenswerte Besonderheiten, die mir nicht bewußt sind? Wenn der Filterprozeß korrekt funktioniert (wovon ich nach aktuellem Stand ausgehe), ist hauptsächlich noch der eigentliche Korrekturvorgang zu prüfen.
Hier sind die Kandidaten, die es durch den Tagfilter und das Filterpolygon schaffen: http://osmac.bplaced.net/candidates.osm (Datenstand von vorgestern oder so, aber das ist ja Nebensache.) Einige Wege, deren Knoten teilweise außerhalb des Polygons liegen, treten hier als unvollständige Wege auf.
In dieser Datei: http://osmac.bplaced.net/candidates_strict.osm sind solche unvollständigen Wege entfernt, d.h. es sollten nur noch Wege übrig sein, die vollständig (d.h. mit ihren sämtlichen Knoten) innerhalb DE liegen. Diese Datei dient als Input für das Korrekturprogramm (als Kandidatenquelle, d.h. vor tatsächlichen Bearbeitungen wird jeweils der aktuelle Stand geladen).
Soweit ich sehe, tragen diese Straßen alle ein is_in=“… Schweiz …”, wohl um sie vor xybot zu schützen. Solche Schutzmaßnahmen sollten zukünftig hoffentlich nicht mehr nötig sein.
Wie schaut es mit den Fällen aus, bei denen “Straße” Präfix und nicht Suffix im Straßennamen ist - sind die auch berücksichtigt ?
In Halle (Saale) gibt es viele “Straße der …”:
Straße der Handwerke,
Straße der Opfer des Faschismus,
Straße der Einheit,
Straße der Waggonbauer,
Straße der Befreiung,
…
(Aktualisieren des Extrakts, Einrichten der FIFOs und abschließendes Aufräumen mal außen vor)
Mit JOSM geht es tadellos.