Ich habe mich mal an den Versuch gemacht die Karte mit Quantum GIS anzuzeigen. Leider kommt bei dem Schritt alle Tabellen (planet_line, planet_point, planet_polygon, planet_roads) mehrfach folgende Fehlermeldung:
Die Tabelle verfügt über keine als Schlüssel verwendbare Spalte.
Quantum GIS erfordert, dass die Tabelle entweder eine Spalte des
Typs int4 mit einer Eindeutigkeitsbedingung (die den Primärschlüssel
einschließt), eine PostgreSQL-oid-Spalte oder eine ctid-Spalte
mit einer 16bit-Blocknummer hat.
Bei den Versuchen die Stadt Kassel als Karte zu rendern ist es leider nicht ganz gelungen, da Kassel anscheinend direkt an der Grenze von Thüringen liegt. So kamen am rechten Rand von Kassel nur noch Empty Tiles.
Obwohl ich die Deutschlandkarte importiert hatte?
Dann habe ich glaub ich einen Fehler gemacht und habe mir die Daten von Thühringen heruntergelanden und diese mit oms2pgsql ebenfalls in die Datenbank importiert. Nun scheint es so, das NUR noch Thühringen in der Datenbank vorhanden ist.
Ich habe nämlich erneut versucht in Quantum GIS die Tabellen nochmal hinzuzufügen. Diesmal klappt es. Aber es wurde nur Thüringen angezeigt.
Ich habe den extend auf -20037508,-20037508,20037508,20037508 gesetzt (also die Komplette Welt)
Wow, ich hab jetzt 5 min nach der Version 1.8 gesucht und bin leider nicht fündig geworden… Also wenn du nicht gesagt hättest es gibt eine Version 1.8 dann hätte ich behauptet das 1.7.3 die aktuelleste ist
Ich nutze Windows 7 - 64Bit.
Wäre nett, wenn du mir einen Link zur 1.8er Version zukommen lässt
Dann hat sich osm2pgsql wohl doch beim Erzeugen des Index verschluckt. War eben doch zu wenig RAM für ganz Deutschland
Dann ist der Index wohl zwischen Kassel und Thüringen abgestürzt…
Ohne Index weiß die Datenbank nicht, welche Knoten innerhalb einer angeforderten bbox leigen, und wenn sie dann erst anfängt, alle Knoten durchzusuchen, wirst du von der Performance nicht begeistert sein.
Ja, das ist richtig so. osm2pgsql löscht die Datenbank komplett, um keine Konflikte mit vorhandenen Daten zu bekommen. Man kann aber mehr als eine Datenbank innerhalb von Postgresql anlegen. Bei mir tummeln sich osmdb, bboxdb, powerdb und srtmdb. Muss dann bei jedem Rendern halt in den Datasource-settings eingestellt werden.
Wenn es dir nur ums Rendern geht, kannst du natürlich DE in Nord und Süd zerlegen, und jeden Teil komplett rendern. Die Überlappung der Grenzen muss natürlich breit genug sein. Länderweise klappt da leider nicht.
Mhh leider konnte ich keine Fehlermeldung sehen, da sich das Konsolenfester geschlossen hatte.
Ich bin grade dabei ein zweites mal Deutschland zu importieren, diesmal mit 3GB Ram als Startparameter.
Das würde natürlich dann einiges erklären. Kann man nicht nochmal im Nachhinein Indexieren?
Gut zu wissen. Sollte der Import von Deutschland erneut nicht funktionieren, würde es doch dann so gehen das ich eine DB für Hessen und eine für Thüringen mache und dann jeweils den renderer drüber laufen lasse. Die möglicherweise erstellten Empty Tiles dürften ja dann überschrieben werden.
EDIT:
Ja PostgreSQL 9.1 32 Bit (9.1 deshalb weil diese schon installiert war und noch für etwas anderes genutzt wird)
Hat auch funktioniert, bis auf die Erweiterungen hstore, diese habe ich dann über pgAdmin nachinstalliert.
Nur bei _int habe ich keine extension gefunden. Vielleicht ist das eine der Fehlerquellen? Vor dem 2. durchlauf habe ich die Extension “intarray” noch installiert.
Ja, das ist leider der Nachteil von Windows. Ich behelfe mich da mit OpenCommandWindowHere, aber das gibts vermutlich nur für XP.
Du kannst aber auch einen pause-Befehl am Ende deiner Batch einfügen.
Ja, mehr kannst du nicht tun. BTW: ganz am Anfang schriebst du noch Windows 2008 Server, jetzt Windows 7 64-bit. Zu letzterem kann ich wenig sagen.
Möglich, aber vermutlich mit dem selben Speicherplatzproblem. Das müsste dann innerhalb von PostgreSQL gestartet werden, und ich weiß nicht, ob und wie er mit dem abgebrochenen Index klarkommt.
Nö, beim zweiten Diurchlauf überschreibt er die vollen Tiles des ersten mit leeren Tiles. Aussedem gibts ja noch massig Tiles, die halb voll sind.
Unter Windows kommst du nicht ums Kompilieren rum, aber da muss ich passen. Ich würde es auch an deiner Stelle lassen und eventuell eine virtuelle Unix-Maschine aufsetzen.
Dummerweise will das neue qgis nicht starten, weil eine spatialindex1.dll nicht gefunden wurde. 8-(
Ich benutze das vorkompilierte osm2pgsql, und das verwendet nach wie vor int4-keys. Funktioniert heute noch so wie damals, als ich den Wiki-Beitrag erstellt habe. Ausserdem ist Postgis für Windows auch nur 32-bit:
Das es bei mir nicht lief, wird vermutlich an den nicht indexierten Tabellen liegen und Version 1.7.3 hat ja funktioniert, als ich Thüringen importiert hatte.
Aber nunja nun weiß wambach, das es mitlerweile schon updates gibt
Wenn du dich erst mal durch die plugins gewühlt hast, willst du nichts anderes mehr machen.
Da gibts z.B. ein openlayers-plugin, mit dem du OSM-Tiles, bing und google Luftbilder einblenden kannst zu deinen Datenbankdaten. Und bevor jemand nach tile usage policy schreit: geht auch mit http://localhost und file:///
Für Konturerzeugung und hillshade gibts auch was. Nur der Mapnik support tuts erstmal leider nicht, weil Qgis mit Python 2.5 daher kommt, mein Mapnik aber schon bei 2.6 ist.
ich habe mir mal die Hilfe osm2pgsql.exe angeschaut. Darunter fand ich auch den Parameter:
-a|--append Add the OSM file into the database without removing existing data.
Also habe ich die Karte von Hessen mit --create importiert und die Karte von Thüringen mit --append. Aber leider hat das nicht so funktioniert und ich erhielt folgenden Fehlermeldung:
Einen Parameter um vorhanden Daten zu überschreiben habe ich leider nicht gefunden.
Jetzt bin ich dabei mit dem Parameter --bbox aus der Kompletten Deutschlandkarte einen Teil in die Datenbank zu importieren.Mal schauen wie das klappt.
Nein, das kann auch nicht funktionieren, weil es Knoten im Grenzbereich gibt, die in beiden Extrakten drin sind. Da weiß osm2pgsql nicht, was es mit denen machen soll.
Dieses -append ist dazu da, um Änderungsdatensätze einzupflegen. Dazu gibt es spezielle diff-Datensätze.
Dabei wird aber erwartet, dass die Version eines Elements in dem diff neuer ist (eine höhere Versionsnummer hat) als in der Datenbank vorhanden. Nur dann wird die alte Version eines Knotens/Wegs/Relation mit derjenigen aus dem Änderungsdatensatz überschrieben.
Du kannst auch nicht zwei mit bbox “scharf” ausgeschnittene Extrakte zusammenfügen, weil ein grenzüberschreitender Weg immer in beiden Teildatensätzen enthalten ist. Je nach Schneideoption komplett oder amputiert.
Die bbox Koordinaten sind ein grober Ausschnitt von Kassel. Sollte es dann jetzt nicht auch weniger Zeit beanspruchen, die Daten in die Datenbank zu schreiben? Hab ich evnt etwas wichtiges übersehen?
Ich denke mal, das sollte so klappen. Ich verwende allerdings die wesentlich kleineren pbf-Extrakte und schneide mir die mit osmosis oder osmconvert zu, bevor ich das Ergebnis an osm2pgsql übergebe.
