Discussion:
OSM kaum mehr benutzbar
(too old to reply)
Juergen Buchner
2007-09-11 18:45:26 UTC
Permalink
Hallo,

ich habe immer noch starke Performance-Probleme mit OSM:

- Up- und Downloads in Josm dauern ewig
- Das Laden der Wege in den Online-Editor ist ebenfalls sehr langsam

Vor einer Woche gab es schon mal ein paar Mails zu dem Thema, seit dem
war es ruhig. Bin ich der einzige, der das Problem noch hat? Falls
nein: Gibt es schon Aussagen, wann sich das bessert?

Viele Grüße

Jürgen
c***@public.gmane.org
2007-09-11 19:32:47 UTC
Permalink
Hallo,
ich stimme zu, heute tagsüber ging mal was, nun geht wieder nix. Das
betrifft nicht nur GPX Tracks.
Grüße
Cor
Michael Kugelmann
2007-09-11 22:13:46 UTC
Permalink
Hallo,
Post by c***@public.gmane.org
ich stimme zu, heute tagsüber ging mal was, nun geht wieder nix. Das
betrifft nicht nur GPX Tracks.
gerüchteweise werde z.B. gerade die Tiger-Daten nach OSM importiert. Das
sind nicht zu verachtende Datenmengen die in die DB rein müssen => das
macht eine sowieso ausgelastete DB (wie bei OSM) nicht ohne weitere
merkbare Performance-Verluste mit...

MfG
Michael.
Dirk-Lüder Kreie
2007-09-11 22:50:13 UTC
Permalink
Post by Juergen Buchner
Hallo,
Post by c***@public.gmane.org
ich stimme zu, heute tagsüber ging mal was, nun geht wieder nix. Das
betrifft nicht nur GPX Tracks.
gerüchteweise werde z.B. gerade die Tiger-Daten nach OSM importiert. Das
sind nicht zu verachtende Datenmengen die in die DB rein müssen => das
macht eine sowieso ausgelastete DB (wie bei OSM) nicht ohne weitere
merkbare Performance-Verluste mit...
TomH arbeitet an mehreren Performance verbessernden Veränderungen
(QuadTiles z.B.) Und es steht ein neuer Datenbankserver an.
Wann der beschafft/aufgestellt wird, weiss ich allerdings noch nicht.

Solche "Staus" gibt es immer wieder, wenn die steigende Userzahl wieder
einmal die Codeoptimierungen und Hardwareverbesserungen aufgefressen
hat. Dann passiert wieder was (soft- oder hardwareseitig) und es ist
erstmal für ein paar Monate wieder "alles schön".

- --

Dirk-Lüder "Deelkar" Kreie
Bremen - 53.0952°N 8.8652°E
Frederik Ramm
2007-09-12 21:28:13 UTC
Permalink
Hallo,
Post by Dirk-Lüder Kreie
TomH arbeitet an mehreren Performance verbessernden Veränderungen
Angeblich ist zumindest fuer die GPS-Punkte jetzt so ein QuadTiles-
artiger Zusatzindex aktiv; auf der englischen Liste berichten Leute
von deutlicher Beschleunigung beim Download.

Bye
Frederik
--
Frederik Ramm ## eMail frederik-VkTBmBTYYDUdnm+***@public.gmane.org ## N49°00.09' E008°23.33'
Frederik Ramm
2007-09-11 23:14:39 UTC
Permalink
Hallo,
Post by Michael Kugelmann
gerüchteweise werde z.B. gerade die Tiger-Daten nach OSM importiert. Das
sind nicht zu verachtende Datenmengen die in die DB rein müssen
Genau genommen wird die OSM-Datenmenge nach dem Import 20mal groesser
sein, oder anders gesagt, das, was wir noch vor einem Monat an Daten
hatten, wird nach dem TIGER-Import nur noch 5% unserer Daten
ausmachen.

Der TIGER-Import wird, wenn die aktuelle Geschwindigkeit beibehalten
wird, rund ein halbes Jahr dauern.

Das Planet-File wird dann unkomprimiert weit ueber 100 GB haben, falls
es ueberhaupt noch erstellt wird ;-)

Viele werden jetzt sagen: So ein Scheiss, wegen den unnuetzen US-Daten
muss ich hier ewig warten... aber: Erstens sind Verbesserungen in
Sicht; es ist ganz klar, dass unsere aktuelle Struktur nicht einfach
mal so 20mal so viele Daten verarbeiten kann. TIGER sorgt hier also
fuer Druck, das ganze mal auf bessere Beine zu stellen. Es gibt viele
gute Ratschlaege (ich selbst werde nicht muede, eine MySQL-Replikation
fuer die Lesezugriffe zu empfehlen), aber leider sind die, die es
machen koennen und wollen, halt doch immer nur wenige. Wenn irgend-
jemand von Euch sich mit MySQL sehr gut auskennt, noch ein bisschen
Ruby kann und sich gut auf englisch verstaendigen, der kann einfach
mal Tom Hughes anmailen - vielleicht freut der sich ja ueber tatkraef-
tige Hilfe.

Zweitens wird TIGER auch zur Folge haben, das wir uns den ameri-
kanischen "Markt" erschliessen. Da werden mit einem Mal sehr viele
Hobby-Programmierer auftauchen, die merken, dass sie ja jetzt
ploetzlich coole Karten von ihrer Stadt erstellen oder Routing quer
durch die USA machen koennen; wir werden viel mehr Leute haben, die an
unserer Software mitarbeiten. Das ist mir persoenlich den Preis wert.

Bye
Frederik
--
Frederik Ramm ## eMail frederik-VkTBmBTYYDUdnm+***@public.gmane.org ## N49°00.09' E008°23.33'
T***@public.gmane.org
2007-09-12 11:47:38 UTC
Permalink
Das Planet-File wird dann unkomprimiert weit ueber 100 GB haben, falls
es ueberhaupt noch erstellt wird ;-)

Den Nebensatz finde ich nicht lustig! Die Existenz bzw. Nichtexistenz
der Planetfiles (unkomplizierter Zugriff auf den gesamten Datensatz,
ähnlich wie die dump-files von wikipedia) entscheidet erheblich darüber
wie "offen" "open"streetmap ist.

Über größere Aktualisierungsintervalle kann man sich ja einigen, aber es
in Frage zu stellen, halte ich für projektgefährdend.


Mit freundlichen Grüßen
Thomas Schäfer
Frederik Ramm
2007-09-12 11:58:32 UTC
Permalink
Hallo,
Post by T***@public.gmane.org
Post by Frederik Ramm
Das Planet-File wird dann unkomprimiert weit ueber 100 GB haben, falls
es ueberhaupt noch erstellt wird ;-)
Den Nebensatz finde ich nicht lustig! Die Existenz bzw. Nichtexistenz
der Planetfiles (unkomplizierter Zugriff auf den gesamten Datensatz,
ähnlich wie die dump-files von wikipedia) entscheidet erheblich darüber
wie "offen" "open"streetmap ist.
Ich finde es selbst auch sehr wichtig, an die kompletten Daten
heranzukommen, und wuerde mir dafuer einen differenzierten
(filterbaren) Replikationsmechanismus und/oder inkrementelle Updates
wuenschen. Vor allem nicht bloss einmal die Woche.

Ein 100-GB-Planet-File ist allerdings nicht mehr weit von "gar kein
Planet-File" entfernt; damit koennen nur noch wenige ueberhaupt etwas
anfangen.

Zum Glueck ist Brett Henderson mit seinem "osmosis"-Tool schon recht
weit; bald wird er damit die Planet-Files erzeugen, und dann wird es
auch sehr leicht sein, taeglich oder sogar oefter Updates
bereitzustellen.

Bye
Frederik
--
Frederik Ramm ## eMail frederik-VkTBmBTYYDUdnm+***@public.gmane.org ## N49°00.09' E008°23.33'
Andreas Winckler
2007-09-12 15:47:34 UTC
Permalink
Als Alternative bleibt ja noch, das Planet-File zu komprimieren.
Außerdem könnte es auch nach Kontinenten oder Ländern in mehrere Dateien
aufspalten.


Viele Grüße,
Andreas
Post by Frederik Ramm
Das Planet-File wird dann unkomprimiert weit ueber 100 GB haben, falls
es ueberhaupt noch erstellt wird ;-)
Den Nebensatz finde ich nicht lustig! Die Existenz bzw. Nichtexistenz
der Planetfiles (unkomplizierter Zugriff auf den gesamten Datensatz,
ähnlich wie die dump-files von wikipedia) entscheidet erheblich darüber
wie "offen" "open"streetmap ist.
Über größere Aktualisierungsintervalle kann man sich ja einigen, aber es
in Frage zu stellen, halte ich für projektgefährdend.
Mit freundlichen Grüßen
Thomas Schäfer
_______________________________________________
Talk-de mailing list
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
_______________________________________________
Talk-de mailing list
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
- --
- ---------------------------------------------------------
Andreas Winckler
http://www.andreas-winckler.de

"A good plan today is better than a perfect plan tomorrow"
Frederik Ramm
2007-09-12 21:03:26 UTC
Permalink
Hallo,
Post by Andreas Winckler
Als Alternative bleibt ja noch, das Planet-File zu komprimieren.
Wird es ja auch.
Post by Andreas Winckler
Außerdem könnte es auch nach Kontinenten oder Ländern in mehrere Dateien
aufspalten.
Das ist nicht ganz trivial; ich biete ja auf meiner Webseite immer den
Deutschland-Extrakt des Planet-Files an, und der Job, der das erzeugt,
braucht jetzt schon 2 GB RAM und 3-4 Stunden. Sicher koennte man
optimieren... aber so eine Landesgrenze ist halt auch kein Rechteck ;-)

Ich persoenlich wuerde es bevorzugen - aber das ist jetzt ganz
langfristig gedacht - wenn wir von der zentralisitsichen Architektur
ganz wegkaemen. Es gibt keinen Grund, wieso jemand, der in Karlsruhe
mappt, um Server-Ressourcen mit jemand konkurrieren muss, der in Texas
arbeitet. Natuerlich muss die Software, die dann Karten erzeugt usw.,
davon abstrahieren - und wenn man will, soll man auch einen Query
ueber die ganze Welt machen koennen. Aber die "Master-Datenbanken"
koennen von mir aus ruhig regional verteilt sein.

Andrerseits hat irgendjemand mal berichtet, dass das bei der Wikipedia
versucht worden sei, und mittlerweile habe man doch wieder alles
zentralisiert, weil es zu muehsam gewesen sei ;-)

Bye
Frederik
--
Frederik Ramm ## eMail frederik-VkTBmBTYYDUdnm+***@public.gmane.org ## N49°00.09' E008°23.33'
Joerg Ostertag (OSM Munich/Germany)
2007-09-12 21:29:47 UTC
Permalink
Post by Frederik Ramm
Andrerseits hat irgendjemand mal berichtet, dass das bei der Wikipedia
versucht worden sei, und mittlerweile habe man doch wieder alles
zentralisiert, weil es zu muehsam gewesen sei ;-)
Ich vermute auch, daß der Aufwand der Dezentralisierung und Verteilung der
Datenbank zu groß ist. Ich denke man kann eher was erreichen, wenn man eine
echte oder pseudo Replikation macht und dann alle read requests von den
replizierten Servern macht.

-

Joerg
Christoph Eckert
2007-09-18 21:49:49 UTC
Permalink
Hi,
Post by Frederik Ramm
Post by Andreas Winckler
Außerdem könnte es auch nach Kontinenten oder Ländern in mehrere
Dateien aufspalten.
Das ist nicht ganz trivial; ich biete ja auf meiner Webseite immer
den Deutschland-Extrakt des Planet-Files an, und der Job, der das
erzeugt, braucht jetzt schon 2 GB RAM und 3-4 Stunden. Sicher koennte
man optimieren... aber so eine Landesgrenze ist halt auch kein
Rechteck ;-)
ich nehme an Du machst das über ein Script. Würde ein C-Progrämmelchen
noch was 'rausreißen können?

Beste Grüße,

ce
Holger Issle
2007-09-19 05:14:05 UTC
Permalink
Post by Christoph Eckert
Post by Frederik Ramm
Das ist nicht ganz trivial; ich biete ja auf meiner Webseite immer
den Deutschland-Extrakt des Planet-Files an, und der Job, der das
erzeugt, braucht jetzt schon 2 GB RAM und 3-4 Stunden. Sicher koennte
man optimieren... aber so eine Landesgrenze ist halt auch kein
Rechteck ;-)
ich nehme an Du machst das über ein Script. Würde ein C-Progrämmelchen
noch was 'rausreißen können?
Das weiterzerteilen des DE-Files sollte aber viel schneller gehen,
oder?
--
Ciao,
Holger (GUS-KOTAL, GUS#1100)

90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm
95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 50 Mm (Die Renndrecksau!)

cu @ http://www.issle.de
Frederik Ramm
2007-09-20 11:46:02 UTC
Permalink
Hallo,
Post by Christoph Eckert
Post by Frederik Ramm
Post by Andreas Winckler
Außerdem könnte es auch nach Kontinenten oder Ländern in mehrere
Dateien aufspalten.
Das ist nicht ganz trivial; ich biete ja auf meiner Webseite immer
den Deutschland-Extrakt des Planet-Files an, und der Job, der das
erzeugt, braucht jetzt schon 2 GB RAM und 3-4 Stunden. Sicher koennte
man optimieren... aber so eine Landesgrenze ist halt auch kein
Rechteck ;-)
ich nehme an Du machst das über ein Script. Würde ein C-Progrämmelchen
noch was 'rausreißen können?
Ja, vermutlich schon. Ich habe gerade auch angefangen, das Perl-
Skript mal so umzustellen, dass es Bit::Vector benutzt statt Hashes -
das wird langsamer, braucht aber weniger Speicher.

(Zu Holgers Frage - klar, wenn man aus dem Deutschland-Extrakt
ausschneidet, geht es schneller.)

Bye
Frederik
--
Frederik Ramm ## eMail frederik-VkTBmBTYYDUdnm+***@public.gmane.org ## N49°00.09' E008°23.33'
Holger Issle
2007-09-20 13:06:47 UTC
Permalink
Post by Frederik Ramm
(Zu Holgers Frage - klar, wenn man aus dem Deutschland-Extrakt
ausschneidet, geht es schneller.)
Ok, läuft das es unter Windows?

Und hast Du auch eine Anleitung dazu, was man dazu braucht (incl.
eventuell nötiger Bibliotheken), wo man es herbekommt, und wie man das
benutzt? Ok, ich frag besser, wo stehen die Antworten... ;)
--
Ciao,
Holger (GUS-KOTAL, GUS#1100)

90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm
95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 50 Mm (Die Renndrecksau!)

cu @ http://www.issle.de
Christoph Eckert
2007-10-02 22:06:36 UTC
Permalink
Hi,
Post by Frederik Ramm
Ja, vermutlich schon. Ich habe gerade auch angefangen, das Perl-
Skript mal so umzustellen, dass es Bit::Vector benutzt statt Hashes -
  das wird langsamer, braucht aber weniger Speicher.
es gibt ab Qt 4.3 fertige Klassen namens QXmlStreamReader und
QXmlStreamWriter. Die lesen XML "line by line", so dass man auch das
aktuelle Planetfile locker verarbeiten kann. Es ist so ähnlich wie SAX,
nur dass es nicht mit einem Callback arbeitet sondern man die Daten
selbst pollt.
Nachdem Qt seit Version 4 auch vollkommen ohne Gui-Elemente verwendet
werden kann, wäre das ja vielleicht eine Alternative zu Perl. Meine
ersten Basteleien, aus einem Planetfile alle Nodes innert einer
bestimmten Region zu extrahieren sahen ganz vielversprechend aus.

Der zweite Schritt jedoch, nämlich wie man alle Relations, Wege und
Nodes innert einer Region aus einer Datei zieht, übersteigt meine
Hobbyhackerkenntnisse bei weitem. Man müsste eigentlich bei Vorkommen
eines jeden Weges zuerst alle zugehörigen Nodes 'raussuchen und den Weg
mitsamt Nodes wieder 'rausschreiben, falls einer der zum Weg gehörenden
Nodes innert des gewünschten Polygones liegt. Mir ist unklar, wie man
das mit der gewünschten Performanz macht. Entweder müsste ich doch
wieder alle Nodes im Speicher halten (was man ja eben genau nicht
will), oder die Datei für jeden Weg immer und immer wieder nach allen
Nodes durchsuchen (so dass dann die Plattengeschwindigkeit zum
Flaschenhals wird).

Soweit meine bisherigen "Forschungsergebnisse".

Beste Grüße,

ce
Holger Issle
2007-10-03 08:10:06 UTC
Permalink
Hi,
Post by Christoph Eckert
will), oder die Datei für jeden Weg immer und immer wieder nach allen
Nodes durchsuchen (so dass dann die Plattengeschwindigkeit zum
Flaschenhals wird).
Soweit meine bisherigen "Forschungsergebnisse".
Ohne gscheite und wohlüberlegte Datenstruktur wird das nix wie Du grad
merkst. Ergo: Du brauchst eine Datenbank und sinnvoll aufgebaute
Suchbäume.
--
Ciao,
Holger (GUS-KOTAL, GUS#1100)

90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm
95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 50 Mm (Die Renndrecksau!)

cu @ http://www.issle.de
Frederik Ramm
2007-10-03 10:15:30 UTC
Permalink
Hallo,
Post by Holger Issle
Post by Christoph Eckert
will), oder die Datei für jeden Weg immer und immer wieder nach allen
Nodes durchsuchen (so dass dann die Plattengeschwindigkeit zum
Flaschenhals wird).
Soweit meine bisherigen "Forschungsergebnisse".
Ohne gscheite und wohlüberlegte Datenstruktur wird das nix wie Du grad
merkst. Ergo: Du brauchst eine Datenbank und sinnvoll aufgebaute
Suchbäume.
Naja, also mal immer langsam mit den jungen Pferden! Ich mache sowas
doch staendig und benutze dazu nur das Planet File, keine Datenbank.

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.

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)

Schritt 1 - Planet-File einlesen und alle Nodes flaggen und ausgeben,
die im Polygon liegen. Speicherplatzbedarf derzeit 60 Millionen Bits =
unter 10 MB.

Schritt 2 - Planet-File weiter einlesen, nun alle Segmente flaggen und
ausgeben, von denen ein Node geflaggt ist. Speicherbedarf nochmal
gleichviel.

Schritt 3 - Planet-File weiter einlesen, alle Ways ausgeben, von denen
mindestens ein Segment geflaggt ist. Kein zusaetzlicher
Speicherbedarf, da die Ways nicht gemerkt werden muessen.

Mit unter 20 MB RAM (in einer Programmiersprache, die Bitfelder
unterstuetzt, wohlgemerkt!) kommt man also durch das heutige Planet
File, und wenn man, was heute ja normal ist, 1 GB RAM zur Verfuegung
hat, geht das auch noch nach dem TIGER-Import gut.

Wenn man den Anspruch "referenzielle Integritaet" hat, wenn man also
auch noch die Segmente und Nodes ausgeben will, die von den Ways
zusaetzlich gebraucht werden, obwohl sie nicht urspruenglich
selektiert waren, muss man sich waehrend Schritt 3 eine weitere
Segmentliste aufbauen, dann diese Segmente noch rausholen
(idealerweise mit einem "seek" an die vorher in Schritt 2 gemerkte
Position) und danach das gleiche nochmal fuer Nodes machen - das
verdoppelt den Speicherbedarf auf 40 MB und verdoppelt die
Programmlaufzeit.

Aber das ist alles nichts im Vergleich zu der Zeit, die es kostet, das
Planetfile in eine Datenbank einzulesen und gescheit zu indizieren.
Das mit der Datenbank lohnt sich dann, wenn man sehr viele Exzerpte
machen will; will man (wie ich regelmaessig) z.B. nur Deutschland
extrahieren, dann geht es viel schneller, mit der o.g. Methode einmal
durch das Planet-File durchzurennen.

Bye
Frederik
--
Frederik Ramm ## eMail frederik-VkTBmBTYYDUdnm+***@public.gmane.org ## N49°00.09' E008°23.33'
qbert biker
2007-10-13 11:00:43 UTC
Permalink
Hallo,

weil ich mich gerade damit befasse, möchte ich kurz nochmal ein
altes Thema aufwärmen.
Post by Frederik Ramm
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.
Post by Frederik Ramm
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.
Irgendwie mag ich keine Einlesefilter schreiben, die auf
unfixierten Annahmen beruhen, weder was den Wertebereich der
IDs angeht, noch bei der Sortierung. Also heisst das doppelt
lesen und diese Dinge im ersten Schritt herausarbeiten.

Deshalb ein Vorschlag für eine kleine Modifikation des
XML-Formats, die in beiden Punkten Klarheit bringen würde.

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>
<node id='21104869' timestamp='2007-04....
<tag k='converted_by' v='Track2osm' />
<tag k='created_by' v='JOSM' />
</node>
<node ....
....
</node>
...
</nodes>

Der 'nodes'-Block darf nur einmal vorhanden sein, ebenso
wie die Blöcke für 'ways', 'relations' und was sonst noch
kommen wird. Wenn der nodes-Block geschlossen wird, weiss man,
dass man alle Nodes hat. Die Parameter 'min_id', max_id und
n_id können auch optional sein, aber wenn sie da sind, kann
man seine Zielstrukturen ohne Blindflug aufbauen.

So und jetzt schimpft mich Kontrollfreak! ;)

Grüsse Hubert
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
Frederik Ramm
2007-10-13 11:51:10 UTC
Permalink
Hallo,
Post by qbert biker
Post by Frederik Ramm
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.
Post by qbert biker
Post by Frederik Ramm
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.
Post by qbert biker
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.
Post by qbert biker
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.
Post by qbert biker
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-VkTBmBTYYDUdnm+***@public.gmane.org ## N49°00.09' E008°23.33'
qbert biker
2007-10-13 13:18:23 UTC
Permalink
Post by Frederik Ramm
Naja, Du wirst halt nirgends die Garantie bekommen, dass es so bleibt.
Ohne Spec keine vernünftige SW-Entwicklung. So hab ichs gelernt
und damit bin ich bisher gut gefahren. Die Sache mit den Blöcken
ist trivial zu realisieren und die Argumente sind als optional
vorgesehen, so dass es an der schreibenden SW liegt, ob sie diese
Dinge schreibt oder nicht.
Ich weiche gar nichts aus, sondern ich mache einen Vorschlag
aus der Praxis heraus. Das OSM-Dateiformat wird ja nicht nur vom
Planetfile genutzt, sondern von auch von anderen Anwendungen.
Es ist neben der API einer der wenigen Fixpunkte, an denen man
in OSM angreifen kann, wenn man ein wenig mit den Daten
arbeiten will. So nebenbei steht an jeder Ecke im Wiki, dass man
doch bitte das Planetfile für dies und das nehmen soll, um die
API, etc. zu schonen.
Post by Frederik Ramm
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!"
Ach bitte, ich habe div. Tools geschrieben, die mit dem Status Quo funktionieren und ich bin mit denen nicht sonderlich zufrieden,
und das weil ich einen hässlichen Spagat machen muss. Entweder
Annahmen treffen, die ich aus dem Quellcode eines Tools ableiten soll
oder Sonderschleifen einlegen, wenn ichs sauber umsetzen will.
Also bitte hör mit dem Schmarrn von wegen Verantwortung übernehmen
(oder auch nicht) auf.

Es ist ein Vorschlag, nicht mehr und nicht weniger. Haut ihn in
die Tonne oder setzt ihn um, aber diese Auslassungen darüber, was
meinereiner ist, macht, will oder auch nicht, dürften hier die
wenigsten interessieren...
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
Frederik Ramm
2007-10-13 13:56:54 UTC
Permalink
Hallo,
Post by qbert biker
Post by Frederik Ramm
Naja, Du wirst halt nirgends die Garantie bekommen, dass es so bleibt.
Ohne Spec keine vernünftige SW-Entwicklung. So hab ichs gelernt
und damit bin ich bisher gut gefahren.
Siehst Du, und OSM ist bislang "gut damit gefahren", keine "Specs" zu
haben (bzw. das, was an "Specs" vorhanden ist, wurde in aller Regel im
Nachhinein aus dem Code abgelesen).

OSM erlaubt also, nach Deiner Definition, keine vernuenftige Software-
Entwicklung.

Unter diesen Voraussetzungen ist es verstaendlich, dass Du, obwohl Du
dazu durchaus in der Lage waerst, keine Lust hast, selbst die von Dir
vorgeschlagenen Verbesserungen umzusetzen (und die notwendigen "poli-
tischen" Schritte zu unternehmen, dass die Verbesserungen auch genutzt
werden).

Ebenso kannst Du aber auch nicht erwarten, dass solche von oben herab
erteilten Ratschlaege von irgendjemandem anders umgesetzt werden.
Post by qbert biker
Es ist ein Vorschlag, nicht mehr und nicht weniger. Haut ihn in
die Tonne oder setzt ihn um
die gibt es nicht.

Bye
Frederik
--
Frederik Ramm ## eMail frederik-VkTBmBTYYDUdnm+***@public.gmane.org ## N49°00.09' E008°23.33'
qbert biker
2007-10-13 14:49:21 UTC
Permalink
Hallo,
Post by Frederik Ramm
Siehst Du, und OSM ist bislang "gut damit gefahren", keine "Specs" zu
haben (bzw. das, was an "Specs" vorhanden ist, wurde in aller Regel im
Nachhinein aus dem Code abgelesen).
Mit viel Aufwand schlechte Lösungen zu finden ist für dich "gut
fahren"? Für mich nicht.
Post by Frederik Ramm
OSM erlaubt also, nach Deiner Definition, keine vernuenftige Software-
Entwicklung.
Nö, man muss sich nur die Standards mühevoll herausfieseln und
wird schräg angemacht, wenn man Vorschläge dazu macht.

Im OSM-File sind die verwendeten Tags ein stabiler Standard und
XML ist als Basis gut genug um damit eine OSM-Datei schreiben
zu können, die man austauschen kann. Der Rest der Regeln, also
die aufsteigenden IDs und die sonstige Reihenfolge sind über
XML nicht gedeckelt sondern simple Programminterna. Arraygrössen
über die talk-de-Liste anzupassen, wenn ein Programm abnippelt,
ist ganz sicher auch nicht die Ideallösung ;)
Post by Frederik Ramm
Unter diesen Voraussetzungen ist es verstaendlich, dass Du, obwohl Du
dazu durchaus in der Lage waerst, keine Lust hast, selbst die von Dir
vorgeschlagenen Verbesserungen umzusetzen (und die notwendigen "poli-
tischen" Schritte zu unternehmen, dass die Verbesserungen auch genutzt
werden).
Ich kann in OSM keinen Standard setzen, aber ich kann eine
Diskussion in Gang setzen, ob die Änderung möglich und/oder
sinnvoll ist. Denn es macht keinen Sinn, wenn ich hier wild und
ohne Absprache Änderungen mache, die zu allem inkompatibel sind.

Wenn es aus der Ecke der DB-leute, der Scriptschreiber oder wer
auch immer gute Argumente gegen den Vorschlag gibt, nur her
damit! Ich versuche hier Teamwork und kein SW-Harakiri.
Post by Frederik Ramm
Ebenso kannst Du aber auch nicht erwarten, dass solche von oben herab
erteilten Ratschlaege von irgendjemandem anders umgesetzt werden.
Ich erwarte gar nix. Ich erwarte nicht mal, dass du hier die
fruchtlose Diskussion um meine Motive und was ich kann und will
abbrichst und dich dem Thema zuwendest. Ich versuche mich
einzubringen und das mit dem was ich gelernt habe und was ich kann.
Diese Pluralperson enthält alle, die es angeht, die Vorteile
daraus ziehen können oder die Argumente dagegen haben. Es geht
hier um eine einfache technische Fragestellung der
Interoperabilität.

Leider ist die wieder mal in diesem Geplänkel untergegangen...

Grüsse Hubert
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Frederik Ramm
2007-10-13 18:39:43 UTC
Permalink
Hallo,
Post by qbert biker
Post by Frederik Ramm
Siehst Du, und OSM ist bislang "gut damit gefahren", keine "Specs" zu
haben (bzw. das, was an "Specs" vorhanden ist, wurde in aller Regel im
Nachhinein aus dem Code abgelesen).
Mit viel Aufwand schlechte Lösungen zu finden ist für dich "gut
fahren"? Für mich nicht.
Andere Projekte haben mit viel Aufwand Specs erarbeitet und ordentlich
dokumentiert. Alles sauber designt, eine ordentliche Projektstruktur
aufgesetzt, in der die Entscheidungsprozesse und Verantwortlichkeiten
klar sind. Und sich dann gewundert, wieso kaum jemand Lust hatte, was
zu programmieren oder Daten zu erheben. Fuer eine "schlechte Loesung"
ist OSM erstaunlich weit gekommen.
Post by qbert biker
Post by Frederik Ramm
OSM erlaubt also, nach Deiner Definition, keine vernuenftige Software-
Entwicklung.
Nö, man muss sich nur die Standards mühevoll herausfieseln und
wird schräg angemacht, wenn man Vorschläge dazu macht.
Ich hatte Deine "Specs" in dem Sinne interpretiert, dass Du forderst,
sie muessten im Voraus ausdiskutiert und abgesegnet sein (anstatt beim
Programmieren nebenher entstehen).
Post by qbert biker
Ich kann in OSM keinen Standard setzen, aber ich kann eine
Diskussion in Gang setzen, ob die Änderung möglich und/oder
sinnvoll ist. Denn es macht keinen Sinn, wenn ich hier wild und
ohne Absprache Änderungen mache, die zu allem inkompatibel sind.
Du koenntest ja als allerersten kleinen Schritt das Planet-Skript so
modifizieren, dass es zusaetzlich zur OSM-Datei noch eine Statistik-
Datei ausgibt, die dann mit auf den Webserver gelegt wird. Damit wird
nichts inkompatibel. Dann koennten die, die das fuer ihre Weiterver-
arbeitung brauchen, diese Statistikdatei mit einlesen (und die, die es
nicht interessiert, lassen es eben). Wenn das Vorhandensein dieser
Zusatzdaten wirklich den Nutzen bringt, den Du postulierst, dann
werden Skriptschreiber ganz automatisch Support dafuer einbauen (denn
sie sind ja interessiert daran, dass ihre Skripts schnell und
effizient laufen!). Wenn irgendwann in ein paar Monaten dann praktisch
jedes Skript dieses Statistikdatei mitverarbeitet, wird es ein ganz
natuerlicher Schritt, zu sagen: "Lasst uns die Daten doch gleich mit
ins Planetfile packen". Wahrscheinlich musst nicht mal Du den
Vorschlag machen, der kommt dann schon von jemand anders.

Wenn sich, auf der anderen Seite, herausstellen sollte, dass sich
niemand fuer das Statistikfile interessiert, weil es den Leuten lieber
ist, quick+dirty ab und zu eine Konstante in ihrem Code anzupassen,
auch recht - "dann halt nicht".
Post by qbert biker
Ich erwarte gar nix. Ich erwarte nicht mal, dass du hier die
fruchtlose Diskussion um meine Motive und was ich kann und will
abbrichst und dich dem Thema zuwendest.
Wenn von Deiner Seite ein kleines bisschen mehr "wir" kaeme statt "ihr
da" und "ich hier", waere es auch einfacher, gemeinsam an einer Sache
zu arbeiten. Bei Dir hat man immer den Eindruck, dass Du Dich von OSM
so weit wie irgend moeglich distanzieren moechtest, weil praktisch
kein einziger Aspekt des Projektes Deinen hohen Anforderungen genuegt.

Bye
Frederik
--
Frederik Ramm ## eMail frederik-VkTBmBTYYDUdnm+***@public.gmane.org ## N49°00.09' E008°23.33'
qbert biker
2007-10-14 17:56:08 UTC
Permalink
Hallo,
Post by Frederik Ramm
Fuer eine "schlechte Loesung"
ist OSM erstaunlich weit gekommen.
Nicht OSM ist eine schlechte Lösung, sondern mein Programm,
wenn ich ohne Konzept und Spec draufloswerkle. Manchmal fehlt
nur eine Kleinigkeit zu einer guten Lösung und das habe ich
hier zur Diskussion gestellt.
Post by Frederik Ramm
Ich hatte Deine "Specs" in dem Sinne interpretiert, dass Du forderst,
sie muessten im Voraus ausdiskutiert und abgesegnet sein (anstatt beim
Programmieren nebenher entstehen).
Nochmal in aller Klarheit: ich fordere nichts, sondern ich
arbeite mit den Daten und Schnittstellen und gebe die Dinge,
die mir auffallen, weiter. Also bitte nichts reininterpretieren,
das gar nicht da ist. Wie die Specs entstehen, ist mir dabei
relativ egeal.
Post by Frederik Ramm
Du koenntest ja als allerersten kleinen Schritt das Planet-Skript so
modifizieren, ...
Nö, das kann ich nicht, weil ich nicht mit Skripten
arbeite. Vieles andere mache ich und das geht vom Ablaufen
der Straßen in meiner Umgebung über Übersetzungen im Wiki bis
zur SW-Entwicklung (C/C++/Qt). Datenbankdinge oder Skripte
nagle ich mir nicht ans Bein, das haben andere mehr Erfahrung.
Post by Frederik Ramm
Wenn das Vorhandensein dieser
Zusatzdaten wirklich den Nutzen bringt, den Du postulierst...
Ich postuliere nicht, sondern ich habe nur über deine
Ausführungen zu den Bitmaps ein wenig nachgedacht. Wenn man
min, max und n beim Dump aus der Datenbank rausbekommt,
wäre dieses zusätzliche Wissen ein Mehrwert, da man die
Bitmap zielgerichtet aufbauen kann. Kein verschwendeter
Speicher oder exceptions mehr, wenn der Puffer nicht passt,
oder man spart sich die Ehrenrunde beim Einlesen ein.

Finde ich schon einen Mehrwert bei einem Overhead von
absolut 9 Zahlen mehr auf 12GB ;)
Post by Frederik Ramm
Wenn von Deiner Seite ein kleines bisschen mehr "wir" kaeme statt "ihr
da" und "ich hier", waere es auch einfacher, gemeinsam an einer Sache
zu arbeiten. Bei Dir hat man immer den Eindruck, dass Du Dich von OSM
so weit wie irgend moeglich distanzieren moechtest, weil praktisch
kein einziger Aspekt des Projektes Deinen hohen Anforderungen genuegt.
Dummerweise hat vor ca. 12 Jahren meine Kristallkugel
versagt und ich musste meine ersten Schritten beim Routing
ohne das Wissen unternehmen, dass es mal OSM geben würde.
Was mir derweil alles an Kodierungsvarianten für den Graphen
untergekommen ist, geht auf keine Kuhhaut. Immerhin habe
ich eine Lösung gefunden, die alles abdeckt und zumindest
unidirektional mit allem kompatibel ist, was so kreucht und
fleucht, sowohl bei den Formaten als bei den Algorithmen.

Diese Lösung mitsamt der SW existiert und ist der Grund,
warum ich überhaupt auf OSM gestossen bin. Das 'ich' hat
also einen Hintergrund und kann derzeit kein 'wir' werden.
Meine Angebote was die Mitarbeit angeht stehen und es liegt
auch an euch, ob aus dem 'ich' noch ein 'wir' wird.

Grüsse Hubert
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
Karl Eichwalder
2007-10-13 14:18:39 UTC
Permalink
Post by qbert biker
Ohne Spec keine vernünftige SW-Entwicklung. So hab ichs gelernt
und damit bin ich bisher gut gefahren.
Allerdings sollte man in diesem fall das "schema" (DTD oder
zeitgemäß wohl das RelaxNG-schema) verfeinern. An dieses schema
müssen sich dann der planet-dump halten.

PS. Richtige XML-IDs müssen mit "Letter" beginnen; "1234" ist keine
gültige ID ;)

Karl
Frederik Ramm
2007-10-13 14:42:34 UTC
Permalink
Hallo,
Post by Karl Eichwalder
PS. Richtige XML-IDs müssen mit "Letter" beginnen; "1234" ist keine
gültige ID ;)
Richtige XML-Ids duerfen auch nicht 2x im Dokument vorkommen (sowas
wie <way id="1"> und <node id="1">). Aber immerhin haben wir jetzt
wenigstens schonmal von <seg id="123"> auf <nd ref="123"> umgestellt,
was wesentlich "richtiger" ist... muehsam ernaehrt sich das Eich-
hoernchen.

Bye
Frederik
--
Frederik Ramm ## eMail frederik-VkTBmBTYYDUdnm+***@public.gmane.org ## N49°00.09' E008°23.33'
qbert biker
2007-10-13 15:08:23 UTC
Permalink
Hallo,
Post by Karl Eichwalder
Allerdings sollte man in diesem fall das "schema" (DTD oder
zeitgemäß wohl das RelaxNG-schema) verfeinern. An dieses schema
müssen sich dann der planet-dump halten.
Find ich gut!

Und es trifft genau den Punkt. Wenn man ein Schema formulieren
kann, das die aufsteigenden IDs und node-way-relation - Regel
abbildet, dann soll mir das recht sein (wär mir aber neu). Bis
dahin kann und werde ich mich nicht drauf verlassen. Andererseits
werden sich meine Tools trotzdem an diese Regel halten und
Dateien mit aufsteigender Id und der genannten Abfolge
ausspucken. Ersteres ist aber eher Zufall, bzw. ein
Nebeneffekt des binären Baums.

Grüsse Hubert
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Frederik Ramm
2007-10-13 18:19:06 UTC
Permalink
Hi,
Wenn man ein Schema formulieren kann, das die aufsteigenden IDs und
node-way-relation - Regel abbildet,
Letzteres geht - AFAIK sogar schon mit einer DTD, erst recht mit einem
Schema. Ersteres nicht.

Bye
Frederik
--
Frederik Ramm ## eMail frederik-VkTBmBTYYDUdnm+***@public.gmane.org ## N49°00.09' E008°23.33'
Continue reading on narkive:
Loading...