Hallo, > > Wir haben derzeit ziemlich genau 40 Millionen Nodes; die hoechste > > verwendete Node-Id ist ungefaehr 60 Millionen. Etwa gleichviele > > Segmente, und etwa ein Zehntel dieser Zahl an Ways. > > Schade eben nur, dass man das beim Einlesen nicht schon > vorher weiss.
Die Elemente sind noch dazu aufsteigend nach Id sortiert, man kann also per binaerer Suche mit "seek"s durch die Datei stapfen und sehr schnell die maximale Id rausfinden. > > Die Standard-Vorgehensweise fuer einen einfachen Polygon-Ausschnitt > > kommt mit einem einzigen Pass durch das Planet-File aus (weil es > > nodes/segments/ways sortiert ist) > > Ich bin bisher davon ausgegangen, dass es zufällig sortiert > ist, eine bindende Vorschrift dafür habe ich nirgends gefunden. Es gab nie ein Meeting, auf dem eine bindende Vorschrift erstellt wurde: "So sollen planet files aussehen, bitte programmiert mal jemand was, was dieser Spezifikation genuegt". Stattdessen hat jemand einfach ein Tool geschrieben, das Planet files erzeugt, und das wird jetzt eingesetzt. Man kann sich den Source angucken und die gewonnene Information zur Optimierung eigener Arbeit nutzen, oder eben nicht. > Irgendwie mag ich keine Einlesefilter schreiben, die auf > unfixierten Annahmen beruhen, weder was den Wertebereich der > IDs angeht, noch bei der Sortierung. Dann lass es lieber gleich bleiben, denn niemand bei OSM wird Dir versprechen, dass die Struktur der Datei morgen noch gleich aussieht wie heute. Wenn Du die Latte so hoch legst, musst Du ein anderes Projekt suchen, das da drueberspringt, OSM wird es nicht sein. > Wenn man die einzelnen Datentypen jeweils in einer > eigenen Ebene unterbringt, ist die Datei deutlich besser > zu handhaben. > > <nodes min_id=1234 max_id=9876 n_id=2345> Sowas waere sicherlich machbar (etwas kompliziert, weil der Exporter derzeit selber nicht weiss, wieviele Nodes er erzeugen wird, wenn er anfaengt, aber man kann ja erstmal XXX in die Datei schreiben und spaeter mit seek wieder an die Stelle springen und nachtragen). Eventuell sind Leute ungluecklich mit der zusaetzlichen Tiefe des Files (und der resultierenden Inkompatibilitaet mit den API-Antworten), aber dann koennte man ja statt Deines Vorschlags auch einfach eine Art "Statistik-Block" an den Anfang der Datei stellen: <statistics><nodes min_id=1234 max_id=9876 n_id=2345/><ways min_id.../></statistics> Die "seek"erei koennte man dann sogar umgehen, indem man die Statistik in eine Extradatei schreibt und spaeter dann beim bz2-Erzeugen mit dem eigentlichen Output konkateniert. > So und jetzt schimpft mich Kontrollfreak! ;) Naja, Du wirst halt nirgends die Garantie bekommen, dass es so bleibt. Du bist kein Kontrollfreak, sondern Du weichst der Verantwortung aus: Anstatt ein Tool zu schreiben, das mit dem Status Quo funktioniert (und bei einer Aenderung desselben nicht mehr, woraufhin die Leute zu Dir sagen: Dein Tool geht nicht mehr), willst Du lieber, dass irgend- jemand fuer Dich die Verantwortung uebernimmt, indem er Dir eine bestimmte Struktur garantiert, auf die Du dich dann verlassen kannst; wenn Dein Skript dann nicht mehr geht, kannst Du sagen: "Das liegt aber an denen, die halten sich nicht mehr an die Spezifikation, mein Skript funktioniert perfekt!" Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
