Wie aktuell müssen die Daten denn sein? Reicht es tagesaktuell? Reicht es, wenn die Karte von vor drei Wochen ist?
Wenn du einen 3 km breiten Kartenstreifen “Autobahn von Flensburg nach Madrid” über die API abrufen willst, musst du arg viel Geduld mitbringen.
Entweder du zerlegst die Strecke in lauter Rechtecke und fragst die Rechtecke dann (evtl. einzeln) ab, oder du baust dir ein (sehr längliches) Polygon und holst dir die Daten, die innerhalb des Polygons liegen. Mal davon abgesehen, dass ich nicht weiß, ob die API Polgone überhaupt unterstützt, die Abfrage ist mit sehr viel Rechenaufwand verbunden und wird im ungünstigsten Fall nach ein paar Versuchen durch die Saveguards des OSM-SPI-Servers geblockt.
Da ist es unter Umständen schneller, ein europe.osm.pbf bereitzuhalten und auf Anforderung automatisch zu schneiden und in die Datenbank zu schieben.
Straßennamen inkl. der einzelnen Punkte der Straße
Die Punkte der Straßen sind am wichtigsten da ich damit verschiedene Sachen berechnen muss, aber vllt. brauch ich auch mal nen maxspeed oder so…
Ich könnte auch 3 einzelne Files runterladen:
Wöchentlich Stadt- und Landesgrenzen sowie die PLZ-Gebiete und dann je nach bedarf die einzelnen Straßen. Eine Straße die allerdings in der DB wäre würde erst nach einer Woche wieder abgefragt.
Das soll den XAPI-Server dann entlasten und ich könnte auch vor der Abfrage den Filter setzen, dass ich z.B. nur Straßen haben will. Die Grenzen können ja meinetwegen auch gedownloaded werden, hauptsache ich brauch dafür keine Erweiterungen in PHP.
Ich müsste die Route übrigens schon sowieso in Rechtecke zerteilen, da ich ja auf der Stecke Flensburg-Madrin alle 50 sekunden einen GEO-Punkt habe… dann würde ich davon immer ein paar zusammenfassen (je nach größe der fläche), daraus nen Rechteck bilden und dieses noch ein wenig größer machen und davon dann die Daten abrufen…
Vorsehen tue ich dafür eine Datenbank mit einigen Tabellen:
Tabelle Punkte mit den einzelnen Punkten und infos zu den Punkten (also hier auch die einzelnen tags)
Tabelle Straßen (straßennamen, etc)
verknüpfungstabelle für Straße <-> Punkte
verschiedene Tabellen für PLZ- und Ländergrenzen wären dann auch noch möglich…
Ok ich gebe zu der Server ist echt nicht gerade oft erreichbar… Aber das kann ich echt nicht mit den Planet-Files machen… 160 GB! das muss man sich mal auf der Zunge zergehen lassen. Wenn ich mit dem Download fertig bin kann ich direkt wieder von vorne anfangen oder was? Ok einmal die Woche reicht aber trotzdem… dafür bräuchte ich 40 (!) Tage!!!
Also Europa laden (anmachen, schlafen gehen, aufstehen, zur schule gehen, schlafen gehen, aufwachen, entpacken :D) und dann ab dem Zeitpunkt wo das Europa-File erstellt wurde immer die Updates der Planet laden und anwenden?
Ich schau mir mal grad die Updates an. Dieses .osm-Format find ich nämlich garnicht mal so schlecht, dann kann ich mir das daraus picken und in meine Datenbank holen, was ich auch brauche. Haltestellen und so sind ja uninteressant für mich…
Wenn du wirklich die ganze Welt (Europa, Nord-/Südamerika, Ozeanien, Asien, Afrika) abdecken willst, dann scheint mir die Arbeit mit einer Postgis-Datenbank und Planet-Files (wöchentlichen/monatlich) am sinnvollsten. Dann bist du weitgehend unabhängig von der Verfügbarkeit von OSM.
Ein Planet-File ist zur Zeit als PBF rund 12 GB groß (16 GB als bz2).
In der Weiterverarbeitung kannst du alles weglassen, was dich für deine Anwendung nicht interessiert. Da wären zum Beispiel:
Die Versionsinformationen eines Objektes (Version, Zeit, User, …)
Alle Häuser 36 Millionen im Vergleich zu 40 Milionenen Straßen+Wegen
Alle nicht befahrbaren Wege oder Wege geringer Ordnung (service, …)
Allein damit dürfte die Datenbank erheblich kleiner ausfallen.
Aktuell halten dieser Datenbank ist dann eine wesentlich einfachere Sache mit rund 50 MB Daten täglich resp. 300 MB wöchentlich.
Mir scheint du versuchst viele kleinere Probleme zu lösen, anstatt das grundlegende Problem anzugehen.
aber bleibt immernoch das Problem das ich das nicht rein mit PHP-Code machen kann…
Denn die 100-200 KB sprengen die 60s-timeouts, die kann ich aber umgehen, aber irgendwie muss ich ja auch die archive entpacken, oder? Wenn ich mal kurz fragen darf: wie kommt JOSM denn an die Daten ran? Das geht ja fix, und der Server antwortet einem auch im Normalfall…
Und dann kommt noch dazu das 5,6 GB (komprimiert!) entpackt riesig wären, was dann doch auch mal wieder ne Riesen Menge an Daten in der DB produziert…
Ich grenz das ganze jetzt noch mal weiter ein:
Die meißten Fahrten sind innerhalb Solingens und Umgebung. Es kommt aber öfters auch mal vor, dass einige Fahrzeuge dieses Gebiet verlassen. Das kann mal in Richtung Niederlande gehen, oder nach München… Deswegen wollte ich ja nur entlang der Fahrstrecken der Daten laden, denn die Trassen werden sicherlich weniger Speicherplatz benötigen, als ganz Europa…
Ich meine es ist ja nicht so als würde ich 30.000 Anfragen pro Tag amchen… Wenn das Auto durch Solingen fährt dann entstehen heute mal vllt. 10 Anfragen für die eine Ecke, morgen 10 für die andere und dann hat der ja erstmal Daten für die Gegend… Erst Sonntag oder von mir aus auch nur alle 2 Wochen würde er noch mal nachschauen, ob es Änderungen dort gab, bzw. ich glaub die Changesets werden ja auch als TXT veröffentlicht, dann kann ich ja schauen in welchen meiner geladenen Gebiete sich was getan hat.
Es ist jetzt nicht so als würde ich euch jetzt hier alle nur reden lassen mit PostGre usw. aber für das was ich machen muss ist das einfach nicht möglich… Ich muss es halt rein in PHP und MySQL umsetzten, OHNE etwas nachzuinstallieren…
ich habe ganz einfach keine Lust mir jedes Mal diese Files runterzuladen. Das soll automatisch klappen. Außerdem kann ich an dem Webserver nichts verändern. Das einzige was ich geboten bekomme ist MySQL und PHP…
Was ist denn daran ungeeignet? Ich mein in meinem Verständnis ist es doch logischer nur das zu laden was ich auch wirklich brauche, anstatt 1% zu nutzen und 99% da vegitieren zu lassen, oder?
At 1)
Natürlich kann man das runterladen resp. aktualisieren per Skript und Cronjobs automatisieren.
MySQL ist ungeeignet, da dort keine ausgefeilten Geo-Erweiterungen wie bei Postgres + dessen Geo-Erweiterungen existieren.
Das heißt für dich, dass du alles was du brauchst, angefangen bei einer simplen Entfernungsrechnung, selber implementieren musst. Spätestens bei einer Frage “Liegt ein Punkt in einem bestimmten Bereich” wird das aufwändig.
PHP dürfte weniger kritisch sein. Nur die Tatsache, dass hier kaum jemand PHP für OSM-Web-Anwendungen benutzt, reduziert deine Chancen auf eine fundierte Antwort.
At 2 - Punkt 1)
Um deine 1% zu bekommen, musst du eventuell 99% des Aufwandes für eine volle Lösung betreiben.
Die Flexibilität für zukünftige Erweiterungen ist bei deiner Idee nur durch weiteren großen Aufwand erreichbar. Auch wenn du nur bei 90% liegst, bist du spätestens bei zukünftigen Erweiterungen auf der Verliererseite.
Dass ein hoher Prozentsatz nicht genutzt wird, ist eine Eigenheit von Geo-Systemen. Dennoch ist eine komplette Abdeckung sinnvoll, solange du nicht beeinflussen kannst, was deine Nutzer an Anforderungen geografischer Art deinen Programmen aufbürden werden. Da immer noch etwas nachzubasteln ist keine gute Idee. Bei Software würdest du so etwas wohl kaum machen.
At 2 - Punkt 2)
Die OSM-API ist eine sehr teure Resource. Sie ist vor allem für Editoren reserviert, die ja den Zugriff auf den aktuellen Datenbestand brauchen. Andere Anwendungen sollten diese API möglichst nicht nutzen. Die XAPI die für solche anderen Anwendungen gedacht ist, läuft seit längerer Zeit weder schnell noch zuverlässig.
Auch wenn API-Anfragen im sehr geringen Umfang (z.B. bei einem Proof of Concept) toleriert werden, so ist die Grenze im normalen Betrieb schnell überschritten und führt dann leicht zu einer Sperre deiner IP oder deiner Anwendung. OSM resp. die OSMF als Betreiber der Server haben nur begrenzte Mittel zu Verfügung und sicher weniger Server-Kapazität als wir alle uns wünschen.
Bevor ichs vergesse: Das Planet-File ist inzwischen viel größer. Europa alleine hat als .pbf 5,8 GB, entpackt ca. 110 GB.
Das wird so leider nicht funktionieren. Wenn z.B. Gebäude und Fußwege nicht in der Datenbank sind und per Change-File eine Änderung in der Art kommt, dass ein Fuß- oder Feldweg zu einer Straße wird, fehlen die betreffenden Nodes. Sie sind dann auch nicht im Change-File enthalten, weil sich die Nodes selber ja nicht ändern. Das change-File enthält in diesem Fall nur das way-Objekt.
Wenn man mit solchen reduzierten Daten arbeitet, muss man trotzdem parallel die kompletten Daten für die betreffende Region vorhalten - zumindest als .osm-File. Das tägliche (oder wöchentliche) Update kann man per Dateiverarbeitung realisieren (z.B. per osmconvert oder osmchange) und anschließend einen Generalimport in die Datenbank vornehmen (geht am schnellsten per osm2pgsql).
Natürlich gibt es Alternativen, aber ich kenn keine, bei der man drum rumkommen würde, ALLE Daten der Region in die Datenbank zu schieben.
Bei der Vielzahl an OSM-Entwicklern, die sich mit solchen Themen beschätftigen, würde es bestimmt einige geben, die eine OSM-Anwendung auf der Basis “Data on Demand - just in time” geschrieben hätten.
Dass das aber nicht der Fall ist, würde mir ebenfalls zu Denken geben.
Aufgrund der vom Autor immer wieder betonten Einschränkungen (nur PHP und MySql, wenig Platz, keine Erweiterungen möglich) vermute ich, dass es sich hier um einen gemieteten, beim Provider befindlichen Server handelt. Das ist für solche Sachen ein weiteres NoGo.
Naja ich denke eher das Problem ist das der Server nicht gemietet ist, sondern kostenlos. Da muss man dann eben schauen ob man wie bei anderen Projekten die Sache aufteilt. Zum Beispiel in dem man die Berechnungen und Datenaufbereitungen auf dem lokalen Rechner macht und dann nur die Datenbank auf dem Server füttert.
Bei den Häusern kann es einem eventuell egal sein, ob dafür Wege ohne Knoten entstehen. Die Wege sollte man in der Tat nicht weglassen. Es sei denn man spielt generell (dann höchstens wöchentlich) einen neuen Planet-File ein. Wenn man kleinere Ausschnitte wie Deutschland oder nur ein Bundesland hat, geht das natürlich eher. Ab Europa wird es wieder aufwändig.
Ah, die ist von dir?
Für www.openptmap.de muss ich mich aber auch von der Aussage distanzieren. Die läuft auf einem virtuellen Server, die Daten werden dort (auf dem virtuellen Server) mit Mapnik gerendert. Das betrifft natürlich nur den ÖV-Layer. Der Standard-Kartenlayer kommt von osm.org.
Ist alles kein großes Problem, weil die Daten vorher (mit dem inzwischen betagten Programm osmfilter) deutlich reduziert und dann mit osm2pgsql in die Datenbank geschoben werden.
Sehs auch so wie wambacher, mit einem kostenlosen Server kommt man nicht weit. Allerdings sind relativ leistungsfähige virtuelle Server, bei denen man Root-Rechte hat und quasi machen kann, was man will, für um die 13 Euro im Monat zu haben.
OK also verbleiben wir schon mal dabei das ich nicht die API verwenden werde sondern mir irgendwie kleine OSM-Files laden werde (mit einem Cronjob) und den dann immer in die DB jagen werde.
Ja das mit den Polygon-Berechnungen werde ich wohl noch hinbekommen in PHP… und um ein Komprimiertes File zu entpacken wird sich wohl auch noch eine Lösung finden…
Hab ich das jetzt also richtig gelsenen, das ich mir jetzt nicht einzelne Kacheln als OSM downloaden kann, sondern lediglich z.B. NRW, Deutschland oder Europa? Weil dann wären die .osm Files ja extrem groß und würden PHP überlasten… Wobei da kann ich dann ja auch immer nur Teile davon einlesen… Lieber wäre mir aber wenn ich einfach die einzelnen Kacheln downloaden könnte… Nicht wegen meiner Spinnennetzartigen Karte sondern wegen der File-Größe…
iceWave
Edit: zum Thema Server:
nein es ist kein kostenloser, es gibt hier in der Firma mehrere PCs und probeweise soll das geanze erst mal hier laufen, das Problem dabei ist aber das wir +
a) ne endlos lahme Internet-leitung haben und da kann ich wirklich ewg auf so nen riesen File warten
b) garnicht so viel SPeicherplatz zur verfügung haben
Ok ich könnte jetzt auch irgendwie auf biegen und brechen versuchen eine OSM-Postgris DB zu erstellen aber dann muss ich dahin ja auch wieder via PHP verbinden am besten npch in irgend einer anderen Programmiersprache ne API schreiben die mir das ganze was ich will erledigt, etc…
