Naja das Problem wird schlichtweg irgendwann die Performance. Postgree+PostGIS ist eine ausgewachsene Spatial-Datenbank, die gut getestet ist und jede Menge Features, Schnittstellen und Tools bietet. MySQL hat glaube ich auch eine Erweiterung für Raumbezug, aber die hat da wohl nicht den großen support.
Lirum Larum, es ist sicherlich eine bessere Lösung als CSV und vielleicht der nächste sinnvolle Schritt, bis irgendwann Geld für einen eigenen großen Server hast.
ok, muss auch mal sein. sorry, werde mich demnächst geduldiger zeigen.
Bei “meinem” webspace-Anbieter bplaced , den ich gerade teste, kosten 2Gb incl MySql+Postqresql nix und 4Gb + einige Goddies 3€/Monat.
Knackpunkte:
kein PostGIS - versuche ich gerade zu klären oder einen anderen Anbieter zu finden.
Platzt reicht nicht aus, um eine “echte” Osm-DB aufzusetzen, aber das hast du vorerst eh nicht vor. (*)
Java (für osmosis) muss ich checken
Dennoch würde ich alle Datenbank-Sachen auf postgresql aufsetzen, weil das langfristig gesehen für dich der Weg ist, den du eh gehen wirst/musst. Dann schlägst du dich nicht mit 2 unterschiedlichen Produkten rum.
Gruss
Walter
*) in dem 3€-Paket ist die Vernetzung von Datenbanken möglich. Damit möchte ich versuchen, manche Tabellen von meinem grossen OSM-Server (germany) hochzujagen, da ich diesen lokalen Server nicht 24 Stunden online lassen möchte. Wenn mir das gelingt, hat der externe Server nur das Notwendigste in der DB und braucht damit weniger Platz. Mal sehen.
Ich bin mir nicht ganz sicher, was du hier mit “Provider” meinst; ich habe auf jeden Fall die ganze Zeit einen “Webspace-Anbieter mit Postgresql” gemeint - und dabei bist du nicht an deine Landesgrenzen gebunden.
Irgendwo bei OSM? nee, kannste vergessen. Die tun sich das nicht an.
Das ist nicht die Aufgabe von OL sondern der DB - und beide können das.
Der Weg CSV → DB ist eh unstrittig. Das ist für Jan der richtige Weg.
Klar, das ist absolut nachvollziehbar. Allerdings fängt Jan gerade erst an und dafür sollte er schon auf den “richtigen Zug” springen.
Ich nehme an, dass du das ganze @Home oder @Firma macht, gell?
Das ist aber noch steigerungsfähig: ein Kollege von uns (aighes?) fährt zwei Postgres-Datenbanken. Eine (osm2pgsql) zum Rendern und eine (osmosis simple/snapshot) für andere Sachen
Und ich würde mich nicht wundern, wenn da noch ne kleine MySQL rumnudelt wie bei mir, weil Joomla! MySQL braucht.
Wenn Du Kartenprojekte mit mySQL verbindest und diese mal weitergeben willst, dann sind diese offener diese zu verwenden als PostGIS mit aufzunehmen… ggf. einen anderen Provider zu suchen.
mySQL ist bald überall vorhanden die mit Frameworks (Wordpress, Joombla etc.) arbeiten.
Nun wieder zurück zu meiner Frage - wie die mySQL am einfachsten füttern ?
Damit wird nicht weit kommen. Praktisch jeder Webhoster hat, aus Sicherheitsgründen, den externen Zugriff auf die SQL-Datenbanken blockiert. Daß heißt, er müßte also *osmosis *auf dem Webserver ausführen; und daß das mit den normalen kleinen Webhosting-Paketen möglich ist, halte ich für unwahrscheinlich.
Auf einem vServer der 20-Euro-Klasse. Aber der wird noch für anderes Zeug gebraucht, nicht nur für OSM. @Home kostet mir das Diff-Einspielen zu viel von meiner ärmlichen Bandbreite, und in der Arbeit laufe ich vor Datenbanken schnell weg, wenn ich sie rechtzeitig erkenne. Ich mag DBs eigentlich nicht
Du musst ja sowieso schon massig Skripte rumliegen haben, die csv-Dateien erzeugen. Die kannst Du ja einfach umschreiben und statt “print lon,lat,name” ein “insert into poiliste (lon,lat,name) values (…,…,…)” machen.
Für ein paar 1000 Pois ist “Pois laden → Liste in der DB löschen → Liste neue aufbauen” sicher das einfachste und in ein paar Sekunden erledigt. Wenn Du grosse Datenmengen hast, ständig aktuell und ohne Ausfallzeit sein willst, wirds vermutlich kompliziert. Aber nur für Dich. Wenn Du sauber dokumentierst und Deine Programme veröffentlichst, habens Deine Nachfolger später leicht.
Um so besser: Eine Zeile fürs Einfügen des Datensatzes in irgendeinSQL statt fürs Schreiben einer csv-Zeile, drei Zeilen am Anfang fürs Öffnen der Datenbank und Löschen der alten Werte und eine Zeile am Ende fürs Schliessen derselben.
Aber eben noch nicht weitergabefähig zumal ich an einer entscheidenden stelle noch eine Großbaustelle habe - mal sehen wann ich Lust und Zeit habe!
Jan
auch wenn es etwas spät ist, will ich meinen Senf anfügen. Zunächst: Die Idee mit einer vernünftigen Datenbank ist auf alle Fälle gut und sehr vernünftig. Trotzdem gibt es natürlich Alternativen für spezielle Fälle.
Mache ich häufig, klappt recht flott mit osmconvert und der Option “–all-to-nodes” (es werden dann sogar Relationen umgewandelt).
Bin zwar nicht Marqqs, aber ich denke, das hat durchaus Sinn dies als getrennte Programme zu haben.
1 osmconvert: Unterstützt sehr viele Formate, kann einfacher Filterungen.
2 osmfilter: Komplexe Filterungen, wenige Formate
3 osmupdate: Kann OSM-Datei per Diff aktuell halten.
Wenn man das alles in ein Programm packen wollte, würde ein komplexes, schwieriger zu wartendes Programm entstehen. Dann schlägt man sich als Anwender eventuell mit Problemen rum, die kaum etwas mit der eigenen Aufgabenstellung zu tun hat. Die Methode “Eine Aufgabe - ein Programm” hat schon ihre Vorzüge.
Danke, hätte es auch nicht besser schreiben können.
Ich glaub nicht, dass es einfacher geht. Außer, du nimmst Osmosis mit entsprechenden Plugins, dann tut es wahrscheinlich auch ein einziger Aufruf. Allerdings ist der dann eine Ecke komplizierter, und die Verarbeitung wahrscheinlich einiges langsamer als bei den einzelnen Programmen. Hat halt alles zwei Seiten.
Deine Reihenfolge ist ok. Bisher hab ich es aber immer so gemacht:
1 osmconvert, um die Daten ins .o5m-Format zu wandeln (idealerweise sind sie aber schon in diesem Format)
2 osmfilter um nach bestimmten Tags zu filtern
3 wieder osmconvert, diesmal mit –all-to-nodes und –out-csv
Mein Weg ist nicht einfacher, sondern einfach nur anders. Einfacher wirds nur, wenn du deine Eingangs-Daten generell im .o5m-Format hast und z.B. mit osmupdate aktualisierst, denn das unterstützt .o5m.
Da fällt mir gleich eine Frage ein:
Bedingt durch die Lizenzumstellung gibt es ja gelöschte Knoten, die keine Koordinaten haben. Sind deine Programme von dieser Änderung der Datenstruktur betroffen?
Oder anders gefragt:
Hast du in den Input-Daten überhaupt gelöschte Objekte? In einem Change-File könnte das ja durchaus vorkommen.
komme etwas spaet auf diesen Thread. Aber er ist sehr interessant. Dieselbe " Aufgabe " beschäftigt mich auch derzeit. OSM Poi in eine mysql DB zu bringen.
Das ist ja eine gute Nachricht - meinst du denn dass du das Script ggf. weitergeben würdest.