[Talk-de] OSM kaum mehr benutzbar

[Frederik Ramm]

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 frederik at remote.org  ##  N49°00.09' E008°23.33'