ich habe bisher immer meine Daten in CSV-Dateien hinterlegt und immer wieder wird mir durch die Blume gesagt ich solle mir doch einen GisServer anlegen.
Dafür fehlt mir leider die nötige Hardware und auch ansonsten ist mir das Thema etwas zu groß für das was ich mache.
Deshalb hatte ich eine andere Überlegung und nun wollte ich Euch fragen, ob es gewisse Grundlagen dafür gibt.
Was mache ich in der Regel. In der Regel frage ich in den OSM-Daten nur bestimmte POI ab und mache daraus eine thematische Karte. In der einfachsten Anwendung wären das nur Nodes und bei Flächen wird ein Punkt generiert der dann die Daten bekommt - quasi eine Flächen->Node-Konvertierung.
Meine Überlegungen gehen nun dahin diese Daten nicht mehr in einer CSV vorzuhalten sondern in einer mySQL-Datenbank auf meinem Webspace.
In einem ersten Schritt müßten alle erforderlichen Daten für den Wirkungsbereich durchgearbeitet werden und die Daten in tabelleform abgebildert werden. Dann ab damit in die Datenbank.
Dann stellt sich die Frage des Update - entweder wird im Intervall X die DB gelöscht oder es wird immer nur eine Differenz eingespielt wobei neue Daten ergänzt und alte entfernt werden. So ähnlich macht glaube ich das die Wanderkarte von Sarah.
Bei dem Update wird sicherlich das Differenzfile verwendet und abgearbeitet das auch für die GisServer verwendet wird. Hierbei wäre allerdings zu bedenken das der Rechner, der die Auswertung betreibt, nicht permanent im Netz hängt und daher kleinere und größere Datenintervalle verarbeitet werden müssen.
Bevor ich das Thema weiterspinne jetzt die Frage an Euch - gibt es soetwas schon ?? oder hat einer Gedanken die ich vielleicht hier nicht niedergeschrieben habe ?
such dir einen Provider, der Postgresql+PostGIS anbietet. Damit bist du langfristig auf der sicheren Seite.
Kleinigkeiten gehen natürlich auch mit MySql aber irgendwann ist dann Schluß. Alle in OSM benutzten Programme verwenden Postgresql. Alle Scripts, Dokus, … bauen darauf auf.
OSM-Support ist auch dicke gegeben.
kurz und bündig - es gibt auch wichtigere Dinge im Leben!
Wenn Du Dich geknickt fühlst, ich kann es nicht ändern. Trotzdem danke für den Hinweis - insbesondere den letzten auf den freien Server.
Derzeit gebe ich ca. 4 Euro im Monat bei 1und1 aus und mehr ist derzeit auch nicht drin. Ansonsten kosten diese Pakete sicherlich >20 Euro (so meine Gedanken) und das wäre nicht drin.
Ich stehe genau am gleichen Punkt wie Lübeck, Webspace mit MySQL ist vorhanden, Postgresql+PostGIS jedoch nicht. Eine Provider dafür zu suchen ist zumindest in der Schweiz ein Ding der Unmöglichkeit, so etwas auf einem Webspace selber aufzusetzen, ist hoffnungslos kompliziert. Dein Tipp ist somit praktisch nutzlos.
IMO die einzige Lösung wäre eine Proxy-DB auf Basis von MySQL, zumindest wenn es nur um POI’s geht. Aber scheinbar hat einfach niemand ein Interesse daran, obwohl genau das die ODM-DB ziemlich entlasten würde.
@Lübeck: Ich sehe für dich nur die Lösung die POI-Daten statt in einem CSV-Datei in einer eigenen DB abzulegen und von dort zu lesen. Ich weiss nicht, ob dies von OpenLayers irgendwie unterstützt wird, wahrscheinlich eher nicht. Frag doch mal dort an, ob es Unterstützung gibt.
Einfache POIs mit OpenLayers aus MySQL zu ziehen geht schon, da kann man sich ja einfach ein PHP-Skript tippen, das MySQL fragt und dann CSV o.ä. ausgibt, muss man ja bei Posgres auch. Kompliziertere Sachen gehen auch (wenn man hier auf “Karte erstellen” klickt, kommt alles aus MySQL, einschliesslich der Shapefiles für die Grenzen, der Farben und der “POIs” der Städte). Ich hab das bei mir so laufen, weil ich MySQL schon für andere Dinge brauchte und nicht umsteigen konnte/wollte.
Inzwischen hab ich auch Postgres, weil da mehr Unterstützung durch andere Entwickler da ist. Informationsbeschaffung über Diff-Einspielen, Rendern… ist kein grosses Problem, wenn man Google und Wikisuche bedienen kann. Zur Strafe muss ich mich jetzt um zwei Datenbanken kümmern. Also falls es irgendwie geht, würde ich mir gleich postgres installieren.
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
