Wie ich durch den thread Fehlerhafte Turn-Restrictions in DE… festgestellt habe, werden in Osmosis jene Wege nicht ausgeschnitten und exportiert, wenn das Ausschnitt-Polygon durch diesen Weg geht.
Für den Export nutze ich den Befehl:
wie muss ich den Befehl anpassen, damit auch alle Wege exportiert werden, durch die das poly-polygon verläuft? wäre clipIncompleteEntities=false richtig und diese Wege kommen dann mit in den Export?
Man merkt, ich bin ein Newbie mit osmosis…
ich hätte jetzt mit completeWays=yes und completeRelations=yes versucht.
Gruß,
ajoessen
würden damit bei bspw einer Route alle Mitglieder drinnen sein? Der Extremfall wäre eine Europastraße, die quer durch Europa geht.
ich denke auch, dass das nicht optimal ist: wenn auf dieser Europastrasse dann auch wieder members von turn-restrictions enthalten sein sollten, hat man wieder False-Positives.
muss wohl, sonst würde sie ja in den geofabrik-extrakten fehlen, oder?
gruss
walter
Was Du oben schreibst, ist nicht 100% richtig. Wenn das Ausschnitt-Polygon mitten durch einen Way geht, wird mit o.g. Befehlszeile der Teil des Wegs, der innerhalb des Ausschnitts liegt (bis zum letzten Node vor der Ausschnittsgrenze) mit exportiert; der Weg wird dabei abgeschnitten, und zwar nicht exakt an der Grenze, sondern u.U. ein kleines Stueck vorher.
Wenn Du auf clipIncompleteEntities=false (der Default) umstellst, bekommst Du in so einem Fall den kompletten Weg, un-abgeschnitten, aber die Nodes ausserhalb des Ausschnitts fehlen - Deine Datei enthaelt dann Referenzen auf Nodes, die sie nicht enthaelt. Je nach weiterem Verarbeitungsplan kann das ein Problem sein oder auch nicht.
Mit completeWays=yes (legt grosse Tempfiles an, braucht sehr lang) wuerdest Du in so einem Fall zusaetzlich auch noch die Nodes ausserhalb des Ausschnitts bekommen.
Fuer completeRelations gilt das gleiche in Bezug auf Relationen.
Fuer die Geofabrik-Ausschnitte verwende ich übrigens inzwischen nicht mehr Osmosis, sondern den “history splitter” von Peter Körner (https://github.com/MaZderMind/osm-history-splitter). Der ist schneller, insbesondere dann, wenn man viele Dateien auf einmal mit completeWays ausschneiden will; das kann Osmosis naemlich gar nicht gut, es legt dann fuer jede Ausgabedatei ein Tempfile mit allen Nodes der Eingabedatei an.
Bye
Frederik
Interessant. Das heisst für Eure Extrakte ist nun completeWays/Relations gesetzt und alle Objekte die die Grenze streifen sind komplett drin?
hmmm… sehe ich das richtig: egal mit welchen Argumenten die Daten extrahiert werden, ich bekomme überall False-Positives?
Beispiel 1: clipIncompleteEntities=true… Ein Way und auch das Via der Restriction kann fehlen und gibt ein False-Positive.
Beispiel 2: clipIncompleteEntities=false… Wenn z.b. ein Teil vom from-Element im Extrakt drin ist, aber das via und to sind ausserhalb, fehlen diese beiden und es gibt ein False-Positive.
Beispeil 3: completeWays=yes… Wenn z.b. ein Teil vom from-Element im Extrakt drin ist, aber das via und to sind ausserhalb, fehlen diese beiden und es gibt ein False-Positive.
Beispiel 4: completeRelations=yes… Ist wohl nicht gut, da wenn eine Europastrasse durch den Extrakt druchgeht, werden auch alle anderen Elemente der Europastrasse extrahiert. Und wenn dort dann auch noch Teile von Turn-Restrictions enthalten sind, gibt das wieder ein False-Positive - auch wenn dies dann ausserhalb des eigentlichen Extraktes ist.
oder habe ich da jetzt einen Fehlgedanken?
Ich denke bei completeRelations=yes tritt das Problem nicht auf, da entweder die Relation vollständig ist (mit from, via und to) oder komplett fehlt. Dein Gegenbeispiel mit der Europastarsse funktioniert eben nicht, da zar die Wegstücke und nodes der Europastrasse extrahiert werden, aber NICHT zusätzliche Relationen, denen diese Ways oder Nodes angehören, also enthält der Extrakt auch keine unvollständigen turn-restrictions.
Grüsse
mdk
Nochmal: ein Test auf die Existenz der Mitglieder einer Relation ist unnötig. Wenn ein Objekt (in der OSM-Datenbank) nicht existiert, kann es auch nicht Mitglied einer Relation sein.
Die Frage nach dem Ausschneideverfahren mag aus anderen Gründen interessant sein, aber für die Überprüfung von Relationen ist sie ohne Belang.
das sehe ich aber anders: es kommt vor, dass in der DB eine turn-restriction ist, in der z.b. nur ein “from” und ein “via” eingetragen sind. das “to” fehlt in der restriction (aus welchem Grund auch immer)… aber somit ist diese turn-restriction falsch/kann nicht funktionieren und sollte daher gefixt werden.
Das sind Fehler, kein Zweifel. Diese gibst Du als “(to|via|from) member missing” an.
Kein Fehler ist, wenn alle drei Rollen in der Relation belegt sind, aber eines der Mitglieder in Deinem Extrakt fehlt (“to|via|from member not found”). Und genau diese sind die “falsch positiven”.
ahh… jetzt verstehe ich, was du meinst… stimmt…
Oh, ein “neues” tool 
Gleich mal probier’n, Nürnberg aus Mittelfraknen auszuschneiden:
$ osm-history-splitter mittelfranken.osm.pbf output.config
WARNING! node_tracker is too small to hold id 1457530265, resizing…
TIP: increase estimation of max. node id in cut.hpp
WARNING! node_tracker is too small to hold id 1457845405, resizing…
TIP: increase estimation of max. node id in cut.hpp
Speicherzugriffsfehler31 Ways per second)
Ahja, da bleib’ ich doch bei osmconvert
osmconvert -B=polygon.62780.poly mittelfranken.osm.pbf --out-pbf > Nürnberg.pbf
da weiss man, was man hat 
Ciao,
Frank
ich stehe gerade vollkommen auf dem Schlauch und komme gerade nicht weiter…
hat mir vielleicht jemand zufällig irgend einen Code-Schnippsel um die Relationen abzuchecken, ob alle Members vorhanden sind. Der Code soll nicht das Vorhandensein der Ways checken, sondern nur eine Relation, ob ein “from”, “via” und “to” vorhanden ist (Codeschnippsel muss ja nicht Turn-Restrictions betreffen, einfach irgendwelche Relationen). wär super. vielleicht hilft mir das dann weiter.
Die Staerke des History-Splitters ist, dass er (a) sehr viele Extrakte gleichzeitig berechnen und (b) mit “full planet dumps”, also mit Dateien, die alle Versionen eines Objekts enthalten, umgehen kann. Wenn Du weder (a) noch (b) brauchst, dann brauchst Du auch den History-Splitter nicht.
Der von Dir beobachtete Coredump trat bei mir auch auf, irgendwo ist im Code die maximale Node-ID fest verdrahtet. Das ist etwas nervig, da hast Du recht
Bye
Frederik
Naja, wenn der Fehler schon länger bekannt ist, finde ich es schade, dass man ihn nicht fixed.
Für den osm-history-splitter benötigt man immerhin
Für osmconvert brauche ich
$ diff cut.hpp cut.hpp.orig
20,21c20,21
< static const unsigned int est_max_node_id = 2000000000;
< static const unsigned int est_max_way_id = 200000000;
---
> static const unsigned int est_max_node_id = 1400000000;
> static const unsigned int est_max_way_id = 130000000;
sogar noch schneller:
$ time ( osm-history-splitter mittelfranken.osm.pbf output.config > /dev/null )
opening writer for Nürnberg1.pbf
allocating bit-tracker
hardcut init
extract[0] Nürnberg1.pbf
hardcut finished
real 0m15.968s
user 0m15.105s
sys 0m0.780s
$ time osmconvert -B=polygon.62780.poly mittelfranken.osm.pbf --out-pbf > Nürnberg.pbf
real 0m7.374s
user 0m5.764s
sys 0m0.956s
Ciao,
Frank
Ach bitte, streitet euch doch nicht darum, was “besser” ist.
Der osm-history-splitter ist - wie der Name schon sagt - für einen anderen Einsatzschwerpunkt gebaut als osmconvert. Es ist also kein Wunder, dass er außerhalb des primären Schwerpunkts nicht so sehr optimiert ist wie manche anderen Programme.
Wenn es darum geht, einen Full-History-Planet ohne Verlust der einzelnen Objektversionen in Regionen aufzuspalten, ist der Splitter ganz arg viel schneller, denn sowas kann osmconvert nämlich gar nicht.
osmconvert kann den Full-History-Planet zwar lesen (auch als .osh.pbf), aber es ist nicht in der Lage, ohne ein “–merge-versions” einzelne Regionen sinnvoll zu extrahieren.
Auch ist osmconvert beim Ausschneiden festgelegt auf die Optionen, die bei Osmosis “cascadingRelations=yes” und “clipIncompleteEntities=false” heißen. Man kann allenfalls noch mit “–drop-brokenrefs” (entspricht “clipIncompleteEntities=true”) dafür sorgen, dass nicht genutzte Referenzen verschwinden. Aber sowas wie zum Beispiel “completeWays” und “completeWays” kann osmconvert gar nicht. Wenn man also genau diese Art der Ausgabe unbedingt braucht, dann nützt es gar nichts, wenn osmconvert doppelt so schnell ist.
Oder sagen wirs mal so:
osmconvert deckt 80% der Einsatzfälle ab, die man sich bei einem OSM-Enduser in Sachen Datenkonvertierung vorstellen kann. Das Programm ist recht schnell und lässt sich einfach installieren.
Osmosis deckt locker 90% der Einsatzfälle ab und ist deshalb in fast allen “OSM-Haushalten” zu finden - selbst bei denjenigen, die normalerweise osmconvert verwenden. Osmosis hat sich zu einem Standard entwickelt.
Und für die restlichen 10% der Fälle gibts spezielle Programme, die man sich genau dann besorgt, wenn man sie braucht.
Programmfehler…
…sind letztlich in jeder Software. Was macht ein “normaler” User, wenn er auf einen Fehler stößt und deswegen mit seiner Arbeit nicht weiterkommt? Er sucht sich ein alternatives Programm. Deswegen ist es auch gut, dass es mehrere Programme gibt, die das Gleiche können.
Sorry, wenn das jetzt wie das Wort zum Sonntag klang. Aber ich wollte auch mal was dazu schreiben.
Markus
Vielleicht hast Du mich missverstanden. Ich habe lediglich gesagt, dass ich den History-Splitter einsetze. Und das habe ich ausschliesslich deswegen gesagt, weil irgendjemand anders singnemaess geschriebn hatte “wenn Osmosis dies und das tut, muss das ja auch fuer die Geofabrik-Extrakte gelten” - diese nun nicht mehr richtige Annahme wollte ich richtigstellen.
Ich wollte nicht im geringsten sagen, dass man zum Ausschnieden von Mittelfranken kuenftig ebenfalls den History-Splitter einsetzen moege. Im Gegenteil, ich glaube, ich habe Dir recht deutlich gesagt, wenn Du eine Software hast, die das leistet, was Du brauchst, dann bleib doch einfach dabei. Es liegt mir fern, Dich davon abzubrignen!
In Deinem Test hast Du dem History-Splitter sogar noch einen unfairen Vorteil eingeraeumt, denn Du hast dessen “hardcut”-Modus mit dem osmcut verglichen, aber osmcut liefert immerhin die “cascadeRelations”-Funktionalitaet, die beim History-Splitter nur im langsameren “softcut”-Modus mitkommt.
Und dass man osmcut ohen jede Schwierigkeit auch auf dem Mac, auf HP-UX, auf FreeBSD und Solaris zum Laufen kriegt, hast Du auch nicht erwaehnt
Also, nochmal, wenn hier der Eindruck entstanden sein sollte, dass ich irgendjemand zu irgendwas missionieren wolle - keinesfalls. Soll doch jeder das Tool benutzen, was fuer seinen Einsatzzweck am besten funktionert. Mach ich ja auch
Bye
Frederik
Hi,
Und das mit Absicht!
Denn wenn ich den osm-history-splitter mit “–softcut” auf meinem 1 GB RAM netbook aufrufe, friert jenes instantan ein.
Hier fehlt der Hinweis im README.md “Nicht unter 8 GB benutzbar (im softcut-mode)”
und dann würde jemand wie ich gar nicht auf die Idee kommen, das Programm (im softcut-mode) zu testen.
Oder Peter verbessert das memory-management seines Programms …
Warum auch?
Verglichen wurde osm-history-splitter mit osmconvert, nicht mit osmcut.
Sowohl
osmcut.jar (das Original von Computerteddy in Java) (1)
als auch
osmcut.c (der Nachfolger, von Dir geschrieben in C) (2)
können keine Polygone ausschneiden (“nur” das OSM-file in kleine Häppchen aufteilen),
sind also für meinen Test nicht zu gebrauchen.
Vielleicht meintest Du ja auch
osm-cut (geschrieben in der Sprache Erlang) (3)
?
Alle drei verwenden *.osm und kein *.pbf, was ein weiterer Testbestandteil war.
Ciao,
Frank
(1) http://smash-net.org/openstreetmap/software/osmcut.0.5.jar.gz
(2) http://svn.openstreetmap.org/applications/utils/osm-extract/osmcut/
(3) https://github.com/partizan/osm-cut