Re: [Talk-de] OSM kaum mehr benutzbar
Hallo, 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. 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. 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. 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 ;) 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
Hallo, weil ich mich gerade damit befasse, möchte ich kurz nochmal ein altes Thema aufwärmen. 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 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
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 seeks 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: statisticsnodes min_id=1234 max_id=9876 n_id=2345/ways min_id...//statistics Die seekerei 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 Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
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. Du bist kein Kontrollfreak, sondern Du weichst der Verantwortung aus: 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. 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... -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
Hallo, 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. Diese Pluralperson, die Du hier ansprichst: 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 [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
Hallo, 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 [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
Hallo, 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. 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 ;) 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. 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, die Du hier ansprichst: 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
Hallo, 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
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 [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
Hallo, 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. 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). 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. 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 [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
Hi, 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
Hallo, 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 [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
Hi, 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
Hallo, 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 [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
On Thu, 20 Sep 2007 13:46:02 +0200, Frederik Ramm wrote: (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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
On Tue, 18 Sep 2007 23:49:49 +0200, Christoph Eckert wrote: 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
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 openstreetmap 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 Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
Hallo, 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 openstreetmap 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 [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
Hallo, Als Alternative bleibt ja noch, das Planet-File zu komprimieren. Wird es ja auch. 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 [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
Hallo, 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 [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] OSM kaum mehr benutzbar
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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
Hallo, [EMAIL PROTECTED] schrieb: 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. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Kugelmann schrieb: Hallo, [EMAIL PROTECTED] schrieb: 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG5xukFUbODdpRVDwRAiDgAKCtvZ5hWCf7vCy35B0plu9SiZ5gqQCgjbaz K9SMqftA8zaZsn4ZzQqTTBI= =e4sj -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM kaum mehr benutzbar
Hallo, 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 [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
