OSM in Datenbank kopieren

Ich hab mir vor ein paar Wochen sowas zugelegt (ein Oberbayern-Extrakt der Geofabrik und dann alle paar Stunden ein Update mit ner grosszügigen bbox um das Gebiet). Diese und diese Beschreibung waren recht hilfreich, soweit ich mich erinner praktisch alles mit copy&paste zu übernehmen.

Für den initialen und evtl. kompletten Neuimpimort gibt es vorgefertigte Extrakte z.B. unter http://download.geofabrik.de/

Ok dafür brauch ich ja immer eigene Software, aber vllt. lässt sich das ja auch irgendwie so umändern dass ich es mit reinem PHP-Skript ansprechen kann... Ich werd mich da mal durchlesen.

Danke!

icewave wrote:

Ok dafür brauch ich ja immer eigene Software, aber vllt. lässt sich das ja auch irgendwie so umändern dass ich es mit reinem PHP-Skript ansprechen kann... Ich werd mich da mal durchlesen.

Was möchtest du denn mit den Daten ungefähr machen?
Zum Rendern mit Mapnik gibt's z.B. auch eine Anleitung: http://wiki.openstreetmap.org/wiki/DE:Mapnik

Ja also zum einen brauch ich das für eine art nominatim, zum anderen muss ich auch die gefahrene strecke berechnen.

So habe ich dann also z.b. 2 Koordinaten, beide liegen jetzt auf einer Straße die eine Kehrtwende macht (z.b. serpentinen). Sie entfernung zwischen den Beiden Punkten über luftlinie wäre jetzt 10m, aber in wirklichkeit sind es 50m, weil die Kurve nicht berücksichtig worden ist.

Mit der Datenbank könte ich dann einfach diese Linie der Straße "abfahren". Generell ist das ja nchts großes aber wenn ich das tagtäglich für ne menge an Punten mache freuen sich die OSM-Server doch bstimmt riesig... Und zum anderen braucht das auch länger...

Da ist es in meinen augen einfacher einfach die punkte um die gebenen koordinaten zu holen und dann damit direkt auf meinem server zu rechnen. Deswegen will ich ja auch nicht direkt ganz deutschland holen sondern nur ie sachen die ich gerade auch brauche. So würde ich dann also beim eintreffen der neuen Daten schauen, in welchem Gebiet diese Punkte sind, die entsprechenden Daten vom OSM-Server holen, wenn diese für dieses Gebiet nicht drinnen sind bzw. nach einer gewissen Zeit updaten und dann damit meine berechnungen anstellen.

Wobei so groß sind die einzelnen gebiete ja nicht. Könnte ich da nicht wirklich einfach die Expor-API der startseite nehmen?!?

iceWave

Also willst du Routing wie z.B. http://map.project-osrm.org/ und einen Geocoder haben. Das Problem ist nur eher, das der OS-Geocoder Nominatim (http://wiki.openstreetmap.org/wiki/DE:Nominatim) wohl nicht wirklich so toll läuft auch wenn ich da keine Erfahrung damit habe, aber MapQuest hat ihn brauchbar ans laufen bekommen. http://project-osrm.org/ ist derzeit die schnellte Routing-Engine, die es für OSM gibt, die übrigen findet man auf http://wiki.openstreetmap.org/wiki/Rout … ne_routers, wobei aber nicht alle einsatzbereit frei verfügbar sind.

Ehm routing brauch ich ja nicht sooo direkt, er soll ja nicht die route selbst finden, wobei... naja egal... also ich will das ganze aber auf meinem eigenen Server machen. ich versuch das jetzt mal mit dem Export-Tool, denn ich brauch wie gesagt nur die Punkte und die Infos dazu... Und das dann auch nur für die entsprechenden Areas.... Die fertigen OSM-Zips sind dafür einfach zu groß. Wie lang soll der denn hier für nen Update brauchen? 10 Std. bei ner 768 Leitung? 😉

Gute Frage: wie steuert man das Export.-Tool denn an?!?

icewave wrote:

Gute Frage: wie steuert man das Export.-Tool denn an?!?

Entweder bei openstreetmap.org bei "Export" auf einen (kleinen) Bereich zoomen, "XML" auswählen, dann bekommt man ein XML dieses Bereichs.

Oder so wie im Wiki (Xapi) beschrieben, sich eine URL zusammenbasteln mit bbox, filter für bestimmte tags... xapi liefert grössere Bereiche, hat aber auch Beschränkungen nach Gebietsgröße und Anzahl der Elemente.

Moin Moin, IceWave,

ich hab den Eindruck, das du momentan nicht weiterkommst und hab daher einige Fragen:

icewave wrote:

... Ist es nun also möglich das ich z.B. mir alle Punkte (und evtl. Relations) für bestimmte Bereiche sozusagen in meine DB rüber kopiere?

- Was meinst du mit "alle Punkte"? Alle Nodes oder auch Ways oder gar Relationen?
- Von welchem Bereich redest du konkret? "Norddeutschland" ist zu vage. Auch Daten aus Dänemark, Holland oder Polen?
- was ist deine DB? Postgresql, Mysql, was anderes? Hast du praktische Erfahrung mit Datenbanken? Gibt es die schon?

Ich ... will dies aber auch wieder automatisieren, sodass bei eintreffen neuer Daten die Punkte in der Umgebung sozusagen aktuallisiert werden und damit dann gearbeitet wird.

Wie oft sollen die Daten aktualisiert werden? Monat/Woche/Tag/Stunde/2-3 Minuten?

Falls das noch zu umgangssprachlich war: Gibt es eine API,...

Ist dir bekannt, dass es auch ganz anders geht?

Dagegen sind mir die einzelnen Changesets wiederum zu grpß zum automatischen rüber kopieren,...

Redest du wirklich von Changsets (diff-files) von http://planet.openstreetmap.org oder meinst du die nächtlichen Extrakte von http://download.geofabrik.de/osm/europe/ (z.B. germany.osm.pbf)?

Sonstiges: Mit welchen Programmiersprachen arbeitest du auf welcher Plattform?

ach ja: Was willst du eigentlich mit den Daten machen?
- mit openlayers als Punkte über eine OSM-Karte legen?
- selber Karten erstellen (Rendern)?
- die Daten in einer ganz anderen Anwendung verwenden?
wenn ja, welche?
- alles hoch geheim? -> Ende der Diskussion.

Gruss
Walter

p.s. Hervorhebungen in den Zitaten sind von mir.

weiterhin hab ich nicht den ganzen Thread vollständig analysiert, da ich glaube, dass du dich eventuell in einer Sackgasse befindest und ich in diesem Falle ganz von Vorne anfange. Siehe meine Sig 😉

Also....

- mit "alle Punkte" sind hauptsächlich nur Straßen gemeint, ich brauche aber auch die PLZ-Grenzen, etc.... also brauche ich wohl wirklich ALLE Punkte und daten der Karte

- nein ich will mir keine Karte rendern, dafür nehme ich die fretig gerenderte OSM-Karte

- Der Bereich variiert... Ich will das ganze benutzen um GPS-Tracks zu analysieren. Die Autos schicken uns GPS-Tracks auf den Server und die werden dann mithilfe eines PHP-Scriptes von mir ausgewertet. Dabei will ich dann direkt schauen auf welchen Straßen der gefahren ist, etc... Wenn Also ein Auto mal durch Köln gefahren ist, sollen die Daten rund um die Fahrstrecke abgerufen werden, aber z.B. nicht ganz Köln...
Natürlich buffer ich die Daten, sonst wär das ja ne enorme Datenmenge jedes mal für den OSM-Server... Die zwischengespeicherten Daten werden aber natürlich in regelmäßigen Abständen (so etwa 1 mal die Woche) aktualisiert. Die "neuen" Daten werden immer dann abgerufen wenn neue GPS-tracks eintreffen, das kann im 50-Sekunden-Abstand sein oder auch mal ne ganze Woche dauern...

- Ziel des ganzen ist es, das ich wenn ich einen Punkt habe, das ich nur alles in nem kleinen Radius drumherum lade und nicht direkt die ganze Stadt.... Ok wenn ich daraus ne Karte rendern würde wäre die ein bissl löchrig aber das will ich ja garnicht.... ich brauch halt nur da Daten wo auch nen Auto langefahren ist...

- Ich arbeite mit PHP5 und MySQL

für weitere Fragen stehe ich gerne offen.

Danke schon mal für die Hilfe,

iceWave

icewave wrote:

- mit "alle Punkte" sind hauptsächlich nur Straßen gemeint, ich brauche aber auch die PLZ-Grenzen, etc.... also brauche ich wohl wirklich ALLE Punkte und daten der Karte

ok, gebont.

- nein ich will mir keine Karte rendern, dafür nehme ich die fretig gerenderte OSM-Karte

ok, kein rendern.

- Der Bereich variiert...

dennoch müsste man mal den Oberbereich kennen (Bundesländer, Kreise, Ausland, ...) Daraus leitet sich die absolute Größe der lokalen OSM-Datenbank ab.

Natürlich buffer ich die Daten, sonst wär das ja ne enorme Datenmenge jedes mal für den OSM-Server... Die zwischengespeicherten Daten werden aber natürlich in regelmäßigen Abständen (so etwa 1 mal die Woche) aktualisiert.

meinst du hier den Update der lokalen OSM-Daten?

Die "neuen" Daten werden immer dann abgerufen wenn neue GPS-tracks eintreffen, das kann im 50-Sekunden-Abstand sein oder auch mal ne ganze Woche dauern...

Bei der Lösung, die mir vorschwebt, wird nicht nach Bedarf vom OSM-Server abgerufen.
Gerade das ist der Knackpunkt: Du hast alle notwendigen OSM-Daten lokal in deiner DB. Nur die Art und Weise, wie die lokalen OSM-Daten aktuell gehalten werden, hängt davon ab, wie aktuell die jeweils sein müssen.
Und das hat auch nichts mit irgend einer API oder XAPI zu tun - das geht anders auf eine Art und Weise, die die OSM-Server nicht im geringsten belastet.

- Ziel des ganzen ist es, das ich wenn ich einen Punkt habe, das ich nur alles in nem kleinen Radius drumherum lade und nicht direkt die ganze Stadt.... Ok wenn ich daraus ne Karte rendern würde wäre die ein bissl löchrig aber das will ich ja garnicht.... ich brauch halt nur da Daten wo auch nen Auto langefahren ist...

aus meiner Sicht der total falsche Ansatz. Du schlägst dich ständig mit Problemen rum, an die jeweils aktuellen OSM-Daten zu kommen.
Sieh es mal so: Was wäre, wenn deine lokale OSM-DB immer aktuell ist. Das wär doch was - oder?

- Ich arbeite mit PHP5 und MySQL

php null Problemo - mysql Riesenproblem.
OSM-Datenbanken rennen nur vernünftig mit postgresql zusammen mit der postgis-erweiterung.
Da sind aber gleich alle Funktionen drin, die du so brauchen solltest: Abstand, Zentrum, nächstes Objekt, Umgebung eines Punktes ...

Es spricht aber technisch nichts dagegen, dass deine Anwendung mit 2 Datenbanken arbeitet.

für weitere Fragen stehe ich gerne offen.

Gruss
Walter

Also.... generell verstehe ich ja das Ihr alle wollt das ich die komplette OSM-Datenbank nehme aber das bringt auch riesen Probleme mit sich...

Der Bereich steht vorher nicht fest. Wenn auf einmal eines der Fahrzeuge nach Spanien fährt (z.B. über die Autobahn) dann brauch ich ja nicht ganz Spanien dondern nur das Gebiet um die Autobahn, stimts?

Ich dachte mir jetzt das ich das was ich brauche über die API hole und dann damit in meiner DB das anstelle was ich brauche... Ganz Deutschland wäre schlicht weg eine zu große Datenmenge, sorry^^

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.

Wenn du nicht nur geographisch, sondern auch nach bestimmten Tags filterst, schrumpft die Datenmenge deutlich. www.opengastromap.de macht das zum Beispiel auch so, wenn auch die verwendete Software nicht mehr aktuell ist. Aber das Prinzip ist geblieben: http://wiki.openstreetmap.org/wiki/Open … lanet_File

was ich brauche:
- Postleitzahlen, daher wohl die PLZ-Grenzen
- Ländernamen, daher wohl die Ländergrenzen
- 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....

iceWave

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!!!!!!!!!!

icewave wrote:

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!!!!!!!!!!

Ach so. Ich ging davon aus, dass dir Europa reicht. Dann wärens nur 5,8 GB:
http://download.geofabrik.de/osm/

Das könntest du dann täglich updaten mit ca. 50 MB/Tag:
http://planet.osm.org/daily/

Also Europa laden (anmachen, schlafen gehen, aufstehen, zur schule gehen, schlafen gehen, aufwachen, entpacken 😄) 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...

icewave wrote:

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!!!!!!!!!!

EINMAL download und danach nur noch die diffs einspielen lassen. unter 100MB / Tag oder 2-5 mb/stunde oder 100-200 Kb/5 minuten

icewave wrote:

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!!!!!!!!!!

Ich denke, du hast wirklich den falschen Ansatz.

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.

JM2C
Edbert (EvanE)

ok das is ja schon mal erträglicher...

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...

icewave wrote:

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...

Warum muss du das so machen? Wer schreibt das vor?
Warum besteht jemand auf eine suboptimale, vielleicht sogar ungeeignete Lösung?

Edbert (EvanE)

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?

icewave wrote:

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.

Edbert (EvanE)

icewave wrote:

Aber das kann ich echt nicht mit den Planet-Files machen... 160 GB!

Bevor ichs vergesse: Das Planet-File ist inzwischen viel größer. Europa alleine hat als .pbf 5,8 GB, entpackt ca. 110 GB.

EvanE wrote:

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.

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. :-(

Marqqs wrote:

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.

Gruss
Walter

wambacher wrote:

Marqqs wrote:

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.

Gruss
Walter

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.

Openptmap und bahnradwandern.bplaced.net verfolgen einen solchen Ansatz für die Rasterkarten.

Sorry, da bin ich in den falschen Thread gekommen.

viw wrote:

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.

Openptmap und bahnradwandern.bplaced.net verfolgen einen solchen Ansatz für die Rasterkarten.

Bei mir gibts keine Datenbank auf dem Server!. Alles nur Dateiablage. Ist aber auch nicht für den produktiven Einsatz gedacht.

gruß,
ajoessen

Marqqs wrote:

EvanE wrote:

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.

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.

Uuups. Da habe ich nicht zu Ende gedacht.

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.

Edbert (EvanE)

ajoessen wrote:

viw wrote:

Openptmap und bahnradwandern.bplaced.net verfolgen einen solchen Ansatz für die Rasterkarten.

Bei mir gibts keine Datenbank auf dem Server!. Alles nur Dateiablage. Ist aber auch nicht für den produktiven Einsatz gedacht.

gruß,
ajoessen

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...

Daher wollte ich einfach alles in MySQL machen...

Das Problem ist wie gesagt nicht die Datenverarbeitung. Das lasst mal meine Sache sien, ich denke sowieso immer sehr komliziert...

Das Problem was ich habe ist die Datenbeschaffung in kleinen Häppchen...

Aber schon einmal vielen lieben Dank für die große Hilfe von euch!

Schluss jetzt - Ich lad grad die Germany.osm von Geofabrik runter...

jetzt weiß ich also wann diese das letzte mal aktualisiert wurde... dementsprechend kann ich also dann ab diesem Zeitpunkt dnn alles mit den Planet-daily-Updates in Ordnung halten, oder? Was ist wenn ein neues Obekt erstellt wurde? ist das dann auch in den Updates drinnen oder kommt das erst wenn ich die neue Germany.osm runter lade? Rein von der logik her würd ich jetzt sagen es ist in den Updates enthalten...

So dann hab ich also endlich meine Daten und zum entpacken von gz2 werde ich schon noch ne vernünftige Klasse für PHP finden...

icewave wrote:

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.

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...

Also es gibt eine große OSM Datenbank. Diese Datenbank gibt es sowohl als Server (API) als Spiegel (XAPI JAPI) und als Dump (osm pbf)
Da die Daten immer mehr zunehmen, gibt es die Möglichkeiten auch nur teile aus dem Planetfile herunterzuladen. Sprich nur Europa oder nur Deutschland oder sogar nur ein einzelnen Bundesland.
Bei der Geofabrik hast du die Wahl zwischen osm.bz2 (gepackte osm Datei) PBF (neues binäres Dateiformat) oder shp (vor allem von Gis anwendung unterstütztes Format)
Wenn diese Extrakte immer noch zu groß sind, hast du die Möglichkeit daraus weitere kleine zu machen. Dafür gibt es das Universalprogramm osmosis. Das kann die Daten dann auch direkt in eine Postgis Datenbank einschleusen oder als PBF oder osm File ausgeben. Gleichzeitig kannst du damit nach bestimmten tags(keys) filtern und die Region mittels BBox oder Polygon einschränken.
Für das Aussschneiden und Filtern sowie das einlesen in Datenbanken gibt es aber auch jeweils Spezialtools, welche mitunter erheblich schneller sein können oder andere Dinge erledigen.
Der Nachteil von kleinen ausgeschnittenen Regionen ist, dass diese sich nicht wieder zusammensetzen lassen. Da die Daten an der Grenze getrennt werden und kein Verweis auf die Benachbarten Daten existiert, führt das dazu, das die Wege und andere Objekte nicht aus zwei aneinander Grenzenden Kacheln nicht wieder zu einem Objekt zusammengesetzt werden. Für das Rendern einer Karte mag dies keine Bedeutung haben, sehr wohl aber für das Routing. Daher sollte man hier sehr gut abwägen, ob und wo man schneidet.
Eine Idee wäre Beispielsweise mit einem loaklen Server ohne Zeitbeschränkung die Datenbank aufbauen und dann den SQL Dump auf den Server zu übertragen. Bzw. gleich mit anderen Tools den Import in die MYSQL Datenbank vorzunehmen und dabei nicht auf php zurückgreifen.

icewave wrote:

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...

Daher wollte ich einfach alles in MySQL machen...

gib doch bitte einfach mal "postgresql php" in google ein und lese den ALLERERSTEN Treffer.

Ein wenig Grundlagenforschung sollte man schon bei so einem "Projekt" betreiben.

Ich habe 3-4 Monate und drei Anläufe gebraucht. bis ich alles zusammen hatte und kannte, was ich "zum Leben" brauchte.
Du willst hier alles vorgekaut und genau auf deine dürftige Ausgangslage zugeschnitten haben.

Und das noch bei einem kommerziellen Projekt für deine Firma!

Exkurs Plattenplatz: 2TB (zweitausend Gigabyte!) kosten zur Zeit NEU noch! 70€

zum Thema Entpacken: warum nimmst du nicht das kleinere germany.osm.pbf und als ersten Schritt osmosis? Der macht alles - vom Download, Entpacken, Aufba der DB, Downloads der Diffs und Update der Datenbank - und noch viel viel mehr.

siehe: http://wiki.openstreetmap.org/wiki/Osmo … iled_Usage

ist am Anfang nicht einfach, da reinzukommen aber du hast ja erst zwei Tage von den 3 Monaten Vorbereitung verbraucht.

Ich will dich hier nicht unbedingt in eine bestimmte Richtung drängen - bei der Verwendung von Datenbanken für OSM-Projekte gibt es mehrere Ansätze - aber die ganz grobe Richtung stimmt schon.

Gruss
Walter

Wäre es vllt. Sinnvoller einen eigenen Server für die OSM-Daten aufzubauen?

Also ein unabhängiges System, welches dann meine ganzen Berechnungen macht....

Eigentlich reicht ja Nominatim aber das gibt mir ja nur Infos zum nächsten Objekt und nicht präzise die PLZ z.b.

UNd das mit den Routen.... es würde reichen wenn mir irgend ein skript genau jeden node der strecke als Koordinaten zurückgibt... mehr ist das nicht...

nur um jetzt das ganze hier auf einem localhost aufzubauen, auf einem privaten Rechner habe ich ehrlich gesagt keine Resourcen noch Lust das zu tun. Soll mir hier etwa dank ner Serverüberlastung mein PC abfackeln oder was? naja ganz so extrem wärs etzt auch nicht, aber wenn die Platte voll wäre dann wär der heir extrem lahm...

Gibt es das nicht schon irgendwo, das ich nur sagen muss ich will von a über x,y zu b und der gibt mir ne Liste mit Punkten zurück?!? Aber dann wäre ich auch wieder abhängig von anderen....... mist 🙁

Notfalls belasse ich es jetzt erst einmal bei Nominatim und einer nicht ganz so genauen Fahrstreckenberechnung...

edit: was ich mir lediglich - egal wie - bauen müsste, wäre dieses Spinnennetz aus Straßen + Landes & PLZ-Grenzen. Häuser, Bushaltestellen, etc. interessieren mich ja nicht...

icewave wrote:

Wäre es vllt. Sinnvoller einen eigenen Server für die OSM-Daten aufzubauen?

Also ein unabhängiges System, welches dann meine ganzen Berechnungen macht....

Eigentlich reicht ja Nominatim aber das gibt mir ja nur Infos zum nächsten Objekt und nicht präzise die PLZ z.b.

UNd das mit den Routen.... es würde reichen wenn mir irgend ein skript genau jeden node der strecke als Koordinaten zurückgibt... mehr ist das nicht...

nur um jetzt das ganze hier auf einem localhost aufzubauen, auf einem privaten Rechner habe ich ehrlich gesagt keine Resourcen noch Lust das zu tun. Soll mir hier etwa dank ner Serverüberlastung mein PC abfackeln oder was? naja ganz so extrem wärs etzt auch nicht, aber wenn die Platte voll wäre dann wär der heir extrem lahm...

Gibt es das nicht schon irgendwo, das ich nur sagen muss ich will von a über x,y zu b und der gibt mir ne Liste mit Punkten zurück?!? Aber dann wäre ich auch wieder abhängig von anderen....... mist 🙁

Notfalls belasse ich es jetzt erst einmal bei Nominatim und einer nicht ganz so genauen Fahrstreckenberechnung...

edit: was ich mir lediglich - egal wie - bauen müsste, wäre dieses Spinnennetz aus Straßen + Landes & PLZ-Grenzen. Häuser, Bushaltestellen, etc. interessieren mich ja nicht...

Es gibt schon sehr sehr viel. Aber es gibt wie im wahren Leben keine Eierlegende Wollmilchsau.
Derzeit ist es so, dass PGrouting eine andere Datenbank erfordert als osm2pgsql und diese wiederum anders ist als die für nominatim.
alle Datenbanken beruhen zwar auf den OSM Daten, manipulieren diese aber für ihre Spezielfälle
damit sie dann auch leistungsfähig sind.
Ob du mit dem Heimrechner baden gehst, weiß ich nicht. Aber ich bevorzuge den direkten Zugriff auf den Rechner anstatt das irgendwo remote zu erledigen. Vor allem wenn es um die Einrichtung des Systems geht.
Aber das ist sicher Geschmackssache.
Anleitungen für das ein oder andere gibt es genug.

WObei ich könnte mir ja auch die Postgre-Erweiterung für pHP holen und dann meine Daten (MySQL) mit der Postgre OSM-DB kombinieren, oder? also das ich z.B. meine Routen einlese und dann in der MySQL nur noch Verweise auf die Way-Ids (in der OSM-DB) lege, oder?

Dann hätte ich ein PHP-Skript was das ein oder andere nach meinen Vorlieben ausführt und das wird dann von Skript B weiter genutzt... oder?

icewave wrote:

WObei ich könnte mir ja auch die Postgre-Erweiterung für pHP holen und dann meine Daten (MySQL) mit der Postgre OSM-DB kombinieren, oder? also das ich z.B. meine Routen einlese und dann in der MySQL nur noch Verweise auf die Way-Ids (in der OSM-DB) lege, oder?

Dann hätte ich ein PHP-Skript was das ein oder andere nach meinen Vorlieben ausführt und das wird dann von Skript B weiter genutzt... oder?

Was ist denn eine Postgre-Erweiterung? Muss du nicht eh alle SQL Commands in PHP programieren? Die Kommandos werden einfach nur an eine andere Datenbank geschickt. Und wenn du dann eh schon Postgre auf dem Server hat spricht nur wenig dafü parallel eine MYSQL Datenbank zu pflegen. Es sei denn das CMS verlangt das explizit. Aber sonst kann man alles was man mit MYSQL anstellt auch mit Postgre machen.
Die Datentypen unterscheiden sich etwas auch einige Befehle, aber ansonsten...

icewave wrote:

WObei ich könnte mir ja auch die Postgre-Erweiterung für pHP holen und dann meine Daten (MySQL) mit der Postgre OSM-DB kombinieren, oder? also das ich z.B. meine Routen einlese und dann in der MySQL nur noch Verweise auf die Way-Ids (in der OSM-DB) lege, oder?

ich zitiere mal aus einem meiner alten Kommentaren:

Es spricht aber technisch nichts dagegen, dass deine Anwendung mit 2 Datenbanken arbeitet.

viw's Vorschlag, gleich alles auf Postgresql umzustellen, wäre langfristiger wohl besser; ist aber nicht zwingend notwendig.
Gerade dann, wenn man erst mal kurz reinschnüffeln will.

Gruss
Walter

Wieso sollte ich denn mein CMS komplett auf Postgre umstellen? Also das CMS bleibt auf jeden Fall in MySQL, wo die OSM-DB ist ist mir inzwischen egal....

icewave wrote:

Wieso sollte ich denn mein CMS komplett auf Postgre umstellen? Also das CMS bleibt auf jeden Fall in MySQL, wo die OSM-DB ist ist mir inzwischen egal....

joomla? oder was selbst geschriebenes?

nur so aus reiner Neugier etwas Wissensdurst 😉
Gruss
Walter

Ich tanze ja auch auf beiden Hochzeiten, weil jede DB ihre Vor- und Nachteile hat.

Was selbst geschriebenes.... Ich bau da halt so meine kleinen Skripte rein, die möglichst viel Lerneffekt für mich bringen sollen. Daher nehme ich auch kein fertiges CMS sondern mach was eigenes...

Auch für die GPS-Auswertung gibt es was fertiges was wir auch schon seit mehreren Jahren nutzen aber das ist sooooo grottig das ich daran mal was ändern wollte.

Generell nehme ich als DB immer MySQL weil ich mich zum einen bisher mit nichts anderem befasst habe, zum anderen aber auch weil ich das mal eben mit einem localhost drauf habe 8inkl. PhpMyAdmin) und das auch auf so gut wie jedem (auch kostenlosem) host installiert ist....

Edit: Das CMS steckt übrigens noch in den Kinderschuhen....

Ich hab mir vor ein paar Wochen auch sone Postgres-DB zugelegt und mit OSM-Daten meiner Gegend gefüttert (die HowTos dazu hab ich oben schon getippt). Läuft auf einem schwächlichen vServer, der nebenbei aber noch richtige Arbeit erledigen muss... Z.B. läuft daneben noch ein MySQL, weil nur zum Spielen trenne ich mich nicht von einem DBS, mit dem ich mich halbwegs auskenne, was z.B. Backup und Replikation betrifft...

Meine Programmierkenntnisse sind eher eingerostet und meine SQL-Fähigkeiten eher begrenzt. Trotzdem hab ichs im Laufe des Abends geschafft, eine Umkreissuche nach Strassennamen und Gemeindegrenzen um den Kartenmittelpunkt hinzubekommen (PLZs muss ich erst finden...). Das ist wirklich mit fünf Zeilen PHP erledigt. Also ich würde schon auch zu Postgres/Postgis raten...

Grüße, Max

PS: Code nicht klauen, ich kann wirlich kaum programmieren und weiss kaum, was ich tu... 😉

Also kann ich die OSM-DB dann genau so (mit anderen functions) wie eine MySQL ansteuern und dann da z.B. sagen "suche mir die Straße in der Nähe des Punktes x und gebe mir dazu alle nodes aus? Wäre ja eigentlich ne stink normale JOIN-Abfrage wo ich nur schauen muss welche Straße am nächsten ist...

Also ist das ganze eigentlich nur eine andere Form der Datenbank, die sich aber genau so ansteuern lässt?

Dann wollte ich noch wissen:
Muss ich jetzt für XAMPP Tools für Postgris nachladen oder ein extra Programm oder wie? Habe jetzt die germany.osm.pbf hier aufm Rechner und weiß jetzt nicht so wirklich weiter....

Mir fällt grad übrigens noch so ein: mit PHP lässt sich ja auch die Windows-Komandozeile ausführen, mit der ich dann wiederum auch Osmosis aufrugen kann.... 🙂 )

Wäre es dann eigentlich auch sinnvoll mir eigene Kartenbilder zu rendern oder soll ich die mal lieber schön vom OSm-Server nehmen? ich meine so 1 mal die Woche neu rendern würde ja reuiichen wenn ich das auf meinem eigenen Server mache, oder?

icewave wrote:

Also kann ich die OSM-DB dann genau so (mit anderen functions) wie eine MySQL ansteuern und dann da z.B. sagen "suche mir die Straße in der Nähe des Punktes x und gebe mir dazu alle nodes aus? Wäre ja eigentlich ne stink normale JOIN-Abfrage wo ich nur schauen muss welche Straße am nächsten ist... Also ist das ganze eigentlich nur eine andere Form der Datenbank, die sich aber genau so ansteuern lässt?

Ja, wenn Du SQL kannst, wirst Du Dich kaum umstellen müssen von My- auf PostgreSQL. Der Witz ist halt, dass Postgres so fragen wie "liegt dieser Punkt in diesem Polygon?" korrekt beantwortet. MySQL interpretiert aus Bequemlichkeit die Frage in "liegt dieser Punkt in der bounding box dieses Polygons?" um und liefert die Antwort darauf. (zumindest ist das mein letzter Kenntnisstand, ich hab auch nur Postgres gewählt, weil alle sagen, das sei besser und ich das dann glaube...)

icewave wrote:

Also kann ich die OSM-DB dann genau so (mit anderen functions) wie eine MySQL ansteuern und dann da z.B. sagen "suche mir die Straße in der Nähe des Punktes x und gebe mir dazu alle nodes aus? Wäre ja eigentlich ne stink normale JOIN-Abfrage wo ich nur schauen muss welche Straße am nächsten ist...

Also ist das ganze eigentlich nur eine andere Form der Datenbank, die sich aber genau so ansteuern lässt?

NEIN, es gibt gravierende interne Unterschiede, die man nicht auf SQL-Ebene sehen kann. Es geht da um Locking, Transaktionen, Rollback und ähnliche Sachen. Aus diesen und anderen Gründen, die ich jetzt nicht parat habe, hat sich OSM schon vor ewigen Zeiten gegen MYsql entschieden. Weiterhin baut osmosis direkt auf postgresql auf und kann diese DB direkt "füttern". Dazu kommt noch die PostGIS-Unterstützung.
Vergiss bitte für ein GIS-Projekt mysql als geo-datenbank. das bringt nix.

Dann wollte ich noch wissen:
Muss ich jetzt für XAMPP Tools für Postgris nachladen oder ein extra Programm oder wie?

keine Ahnung.

Habe jetzt die germany.osm.pbf hier aufm Rechner und weiß jetzt nicht so wirklich weiter....

Du wolltest die Daten in einer DB haben, also pack sie da rein. z.b. mit osmosis.

Mir fällt grad übrigens noch so ein: mit PHP lässt sich ja auch die Windows-Komandozeile ausführen, mit der ich dann wiederum auch Osmosis aufrugen kann.... 🙂 )

Für deine ANWENDUNG; die irgendwann mal mit PHP auf die DB zugreift, brauchst du kein Osmosis.
Osmosis ist nur für den Import der Rohdaten und das Einspielen der Diffs notwendig. Und das macht man in ganz normalen Batch-Files, wenn es unbedingt Windows sein muss.
Schau dir mal diesen aktuellen!!!! thread an, da steht viel drüber drin. Wer lesen kann, ist echt im Vorteil.

gruss
Walter

p.s. ich mache jetzt mal für einige Tage Schluss, bis ich den Eindruck durch entsprechende Fragen deinerseits bekomme, dass du dich wirklich mit der Sache auseinandergesetz hast.
Bisher glaube ich, das ich dir hier das Denken abnehme - und dazu hab ich wirklich keine Lust Zeit mehr.

icewave wrote:

Also kann ich die OSM-DB dann genau so (mit anderen functions) wie eine MySQL ansteuern und dann da z.B. sagen "suche mir die Straße in der Nähe des Punktes x und gebe mir dazu alle nodes aus? Wäre ja eigentlich ne stink normale JOIN-Abfrage wo ich nur schauen muss welche Straße am nächsten ist...

Also ist das ganze eigentlich nur eine andere Form der Datenbank, die sich aber genau so ansteuern lässt?

Dann wollte ich noch wissen:
Muss ich jetzt für XAMPP Tools für Postgris nachladen oder ein extra Programm oder wie? Habe jetzt die germany.osm.pbf hier aufm Rechner und weiß jetzt nicht so wirklich weiter....

Mir fällt grad übrigens noch so ein: mit PHP lässt sich ja auch die Windows-Komandozeile ausführen, mit der ich dann wiederum auch Osmosis aufrugen kann.... 🙂 )

XAMPP ist lediglich eine Verwaltung für viele einzelne Server. Wenn du also ein XAMPP laufen hast, brauchst du dir nur den Postgresserver laden. Am Besten in der Version 8.4 nicht in 9.0 und dazu die Erweiterung Postgis installieren. Postgis ist im Prinzip nichts anderes als die Erweiterung der DB um zusätzliche Funktionen und Datentypen. Damit hast du dann die besagten Vorteile, was die geografischen Abfragen angeht.
Solltest du eine Bibliothek in der Nähe haben, empfehle ich dir wärmstens das Buch PostgreSQL Installation, Grundlagen, Praxis
Du wirst sehen die ersten Kapitel kennst du alle schon von MYSQL. Spannend wird es wenn du zu den Kapiteln Funktionen und Prozeduren kommst. Im Prinzip kannst du die Datenbank nämlich selbst programmieren. Du bist dann nicht mehr auf Validierung in PHP angewiesen, sondern das übernimmt der in der Regel schnellere Datenbankserver für dich. Genauso wie die Konsitensprüfung der Daten.
In der letzten Zeit hat MYSQL wirklich viel aufgeholt. Es gibt mit INNODB auch dort jetzt Transaktionen. Sogar eine Geoerweiterung gibt es. Aber wie Wambacher schon sagte. OSM begann einmal mit MYSQL.
So lange wie Wambacher meint ist es auch noch nicht her, das OSM auf Postgre umgestellt hat. Noch die Version 0.29 von Osmosis hat MySQL unterstützt. Wie man hier im Artikel von 2008 lesen kann: http://goblor.de/wp/2008/09/25/howto-op … portieren/
und 2009 gab es offenbar auch noch MySQL. Hier das Shema der Datenbank: http://goblor.de/wp/2009/10/16/openstre … -einlesen/

Das was Du wissen willst kannst du mit dem XAPI abfragen. OSM-Dateien sind nur XML und das kann man mit PHP sehr einfach einlesen: http://php.net/manual/de/function.simpl … d-file.php