Lokaler TileGenerator mit Maperitive unter Windows

Hallo

ich habe mal bei dem MOBAC Autor angeregt eventuell eine Notlösung zur Generierung von Tiles aus einem pbf File. Es ist wohl nicht so einfach das auf MAPSFORGE Basis einzubauen. Deshalb mein Vorschlag für eine “Notnagel-Lösung” die bei mir super funktioniert. Die generierten Tiles sind dann als Mapsource für MOBAC konfiguriert.

https://sourceforge.net/apps/phpbb/mobac/viewtopic.php?f=4&t=39&p=157#p157

Ich habe einen Batchfile und einen Srciptfile für MAPERITIVE. Ferner habe ich die HIKING Rules für meine belange angepasst. Nebennwege (Track 1…4) grün hervorgehoben.

Aufruf: xx.bat 8.5,48.8,8.9,49.00

Inhalt:

Osmconvert\osmconvert bpf\baden-wuerttemberg.osm.pbf -b=%1,%2,%3,%4 >out\bbox.osm
D:\www_GPS\Maperative\Beta\Maperitive-1.1.2001\Maperitive\Maperitive.exe -exa .\Scripts\xx.mscript

Srcipt: xx.mscript:

use-ruleset alias=hiking
load-source “D:\www_MyMap\out\bbox.osm”
generate-contours
generate-tiles minzoom=5 maxzoom=15

…und es werden wunderschöne Tiles generiert und in MOBAC angezeigt…

MfG
Achim

Hallo,

sicher so kann man sich das als Notnagel-Lösung erstellen.

Ich selbst hab mir ein Excel-Sheet erstellt das mir die Batch-Dateien erstellt. (Aus Mangel an Programmierkenntnissen).

Ich möchte immer komplette Tiles da mein Gebiet recht groß (über meherere 8 Zoom Kacheln) ist und ich nicht jedesmal rendern will (mir reicht eine 4 Wöchige aktuallität völlig aus).

Da hab ich den Vorteil das ich komplette Kacheln bekommene - allerdings ohne gefilterte OSM-Daten hat Maperitive Probleme komplette Tiles kleiner der Zoomstufe 8 zu rendern (man verzeihe mir aber diese paar Tiles hab ich mir aus online Quellen geholt.)

Osmconvert und ähnliche Programme haben den Nachteil das diese die Daten einfach an der bbox abschneiden , dadurch entstehen leider fehlende Flächen an den Rändern und auch MP machen Probleme da mittleiweile grad Waldflächen gerne aus zusammengesetzten Linien erstellt werden - wenn aber vom MP Linien ausserhalb der bbox existieren werden diese nicht mitgeschnitten und das MP ist eine offene Linie die dann nicht z.B. als Waldfläche gerendert wird [obwohl in Maperitive das MP (bzw deren in der bbox vorhande Objekte) unter den Reglen gefunden wird] .

Meine Erfahrungen die bbox muß rundrum 0,2 grad größer sein als das in Mpaeritive gerenderte Gebiet.

Aber für einen halbwegs guten Programmierer ist das wahreinschlich kein Problem eine ausfürhrbare EXE zu erstellen das die Batch-Datein erstellt!

Also ich find das mit den Skript ne super Sache. Sicherlich nicht perfekt, aber wir hatten doch AFAIK erstmal so schon Probleme Mapnik überhaupt unter Windows am Laufen zu kriegen? Also erstmal vielen Dank dafür Achim :slight_smile:

Also mir ist das noch auf jedem Win-Rechner geglückt. Win7 mal aussen vor gelassen…

Gruß,
ajoessen

Ich will das nicht zerreden!

Das geht schon in die richtige Richtung = Benutzerfreundlichkeit!

Ich wollte nur Punkte aufzeichnen die man noch verbessern kann.

Und sowas von miraus aus MOBAC oder auch von Maperitive (was ich letzendlich den besseren Ansatz finde - solange MOBAC nicht selber rendern kann!!!).

Beispiel Maperitive:
Ich wähle dort die Quelle also z.B. die erueope.osm.pbf
geb den Bereich an
Maperitive frägt Breich oder komplette Kacheln (mit/ohne Rand usw.)
frägt welchen Rule usw.

Maperitie erstellt Batch für osmconvert (müsste maperitive beigelegt werden - der Vollsändigkeits halber!)
erstellt script und startet das ganze.

Ah ok, dachte das ginge immer nicht so richtig. Habe den MOBAC autor mal darauf hingewiesen: https://sourceforge.net/apps/phpbb/mobac/viewtopic.php?f=1&t=24&p=158#p158

Einklich kann der auch Deutsch und liest hier manchmal mit :wink:

Gruß,
ajoessen

Hallo

Notlösung deshalb, da sich bei Maperitive einiges tut und angekündigt ist. Ich habe auch im MaperitiveForum angefragt bezüglich der externen Batchlösung. Die wird von dort nicht unterstützt.
Aber die Beta (build2001) unterstützt schon grafisch konfigurierbare Bounding Boxen (Geometry, Druck). In einer zukünftigen Version soll das Ganze dann mit Phytonscripten programmierbar sein. Ferner soll das Speicherproblem von großen OSM Dateien mittels eine Datenbank gelöst werden…deshalb oben “Notnagel-Lösung” mit der ich übergangsweise leben kann/ muß.
Also ich erwarte da einiges, was in die richtige Richtung geht.

MfG
Achim

Ps.: MAPNIK aufsetzen ist ein ganz anderes Kaliber, aber der MOBAC Autor prüft ob er das integrieren kann. Also MAPNIK-Experten unterstützt ihn dabei und nutzt sein Forum…

…hallo ,

das mit den Flächen kann ich nicht ganz nachvollziehen. Hast du mal mit dem MAPERATIVE BUILD 2001 gerendert? Flächen hören da genau an der Grenze auf. Ich sehe da (noch) keine offenen Linien. Leider kann man hier kein Bild dranhängen

http://augilabs.de/osm/bild/bild_00.png
http://augilabs.de/osm/bild/bild_01.png

@ womisa

Gutes Beispiel !!

Guck dir mal in Karlsbad den Wald an und vergleiche z.B. mit Mapnik bzw Hikebikemaps

Da fehlt zwischen Karlsbad un Ittesbad der Wald - ursache Linie in MP die linien enthält die die Flächen schließen ausserhalb der bbox.
Auch links unten Dennach liegt eigentlich komplett im Wald!

Schneid mal nee bbox aus die nach süd/westen größer ist dann wirds gerendert!

Unterhalb von Ittesbach ist auch kein Naturschutzgebiet zu sehen (falls du es rendern läßt!).

Eine Stelle wo gut sichbar eine Fläche abgeschnitten wurde hab ich jezt grad nicht gefunden - ist aber meist in den Ecken der bbox zu finden.

PS: Bin auch auf MAPERATIVE BUILD 2001 !

hast Du das noch nicht getestet, oder funktioniert es auf Win7 nicht? - Nur interessehalber, weil auf der dev Liste eine entsprechende Frage gestellt wurde.

Falls Ihr’s nicht gelesen habt: im oben verlinkten MOBAC Thread wird die hier im Forum schon mal geäußerte Hoffnung auf ein Live-Rendering mit mapsforge auf dem PC zumindest vorerst enttäuscht:

Ich hab kein Win7, und will es auch nicht. :wink:
Never run a changing system. Oder so ähnlich…

Gruß,
ajoessen

Bei mir heißt der Spruch: Never change a running system. :slight_smile:

Deshalb hab ich meinem Rechner Schlitten verpaßt. Da können verschiedene Systeme abwechselnd “rennen” :slight_smile: Das bietet die Möglichkeit, erst mal alles Wichtige im alten System weiter laufen zu lassen und gleichzeitig eine Spielwiese mit Win7 aufzubauen. Für die Feinheiten der Installation (z.B. eine ClassicShell http://www.chip.de/downloads/Classic-Shell_39396490.html einbauen, mit der man sich schneller im neuen System Zuhause fühlt) hab ich zum Glück eine kompetente Hilfe. Darüber kann ich also keine Auskunft geben.

Nachem MapComposer, Maperitive, QLandkarte und MapSource bei mir bislang problemlos unter win7 laufen, wüßte ich auch gerne, wie man mapnik aufsetzt.
Nachdem ich hier http://mapnik.org/download/ allerdings nicht richtig durchgestiegen bin - (Was hat es mit einem GIT-Client auf sich?) - hab ich dann aber lieber erst einmal von Experimenten abgesehen und beschlossen, erst einmal bei Maperitive zu bleiben. Da gibt es noch genug zu tüfteln.

Sind Maperitive und Mapnik eigentlich irgendwie kompatibel? Oder werden die Renderregeln komplett anders aufgebaut?

Aktuell verfolge ich folgendens Konzept:
Mit den Tools von Marqqs erzeuge ich Extrakte aus europe.osm.pbf.
Mit Nops MapComposer baue ich Garmin Kacheln/Vectorkarten aus diesen Extrakten.
Mit MapSource und QLandkarte lassen sich diese Vectorkarten problemlos anzeigen. Mit MapSource schiebe ich die Karten auf das etrex VHCx.
Mit Maperitive stehe ich noch ganz am Anfang. Das Default-Style läuft gut und erste individuelle Anpassungen bekam ich auch schon hin. (Standard-Rules unter neuem Namen abgespeichert, dann am Layout geschraubt und nicht enthaltene Elemente bzw. Differenzierungen eingefügt oder Unerwünschtes ausgeblendet.) Die Erstellung der Kartenkacheln funktionierte ebenfalls. Nur wie man die von Maperitive erzeugten Rasterkartenkacheln in QLandkarte einbaut, hab ich noch nicht raus. Wenn man die Kacheln allerdings nicht für eine bestimmte Anwendung benötigt, scheint mir deren Erstellung für die Kartendarstellung am PC im Moment überflüssig. Der für begrenzte Gebiete erzeugte Kartenextrakt ist auf einer flotten Maschine schnell gerendert. Die Notwendigkeit Kacheln zu erzeugen und für die Betrachtung zu nutzen würde vielleicht sichtbar, wenn sehr große Bereiche gerendert werden. Betrachtet man die frisch gerenderten Kartenausschnitte in Maperitive, lassen sich auch mehrere Extrakte nacheinander rendern und dann als zusammenhängende Karte anzeigen. Wieviel da geht, also wo die Grenze ist, hab ich noch nicht ausprobiert. Ebenso ist es möglich, durchsichtige Overlays per vordefiniertem Script aufzurufen und vor einer Hintergrundkarte zu betrachten. Herauszufinden, welche Layouts optisch am besten harmonieren und wie sie sich am sinnvollsten stapeln lassen, ist eine nette Spielerei für lange Winterabende. Im nächsten Frühjahr werde ich dann mehr wissen. :slight_smile:

  • Kaputte/Fehlende Flächen -
    Die an den Schnitträndern zerstörten Flächen beobachte ich in verschiedenen Programmen.
    Wenn ich z.B. in JOSM arbeite, wird der Rhein, ein kurviges Gebilde mit parallell laufenden Uferlinien, extrem merkwürdig dargestellt, sobald das Download nur ein Teilstück erfaßt. Die beiden zerschnittenen Uferlinien werden offensichtlich als separate Flächen interpretiert. Wie sonst ist zu erklären, daß die Enden jeweils einer Uferlinie so verbunden werden, daß zwei Flächen entstehen? Wenn die Luftlinie vom Anfang- zum Endpunkt dann obendrein noch eine oder sogar beide Uferlinien schneidet, sieht das ziemlich verrückt aus. Der in JOSM beobachtete Effekt ist auch auf Karten zu beobachten, die mit Maperitive oder mit MapComposer (mkgmap) erzeugt werden, sofern die Rohdaten mit graden Schnitten zerteilt wurden. Welche über die definierte BBox herausragende Flächen lädt JOSM komplett und wann werden sie zerschnitten? Es sieht für mich ganz danach aus, daß die umstrittene Idee, Flächen mit mehreren aneinandergehängten Linien zu definieren, zum unvollständigen Download der Flächen führt. Die BBox für das Datenextrakt größer zu wählen, als für die Karte später benötigt wird, führt nur bedingt zum Ziel. Wenn kurvige Gebilde aus sehr langen Multipolygonen bestehen und dadurch sehr weit über die Kachelgrenze hinausragen, wird das schwierig. Was wäre wohl, wenn Flüsse wie der Rhein mit einem einzigen langen Multipolygon aus aneinander gehängten Wegen erfaßt würden?

Gruß
tippeltappel

Das war ja mal der Fall wurde aber gottseidank wieder geteilt.
JOSM lädt ja auch nicht das gesamte MP runter sondern nur die Teile die im aktuellen Ausschnitt liegen. Ich denke, dass große
Flächen generell problematischer sind als Kleine.

Die vorgehnsweise ist wohl auch für Waldgebiete recht verbreitet - deshalb fehlen machmal Teile des Harzes, Schwarzwald, Rhön, Spessart, Bayrischerwald oder auch Taunus! ganz zu schweigen von einigen Monster-MP’s aus den Nachbarländern!!!

Dies sind alles recht große MPs und da stimmt es das größere Auschnitte nur bedingt helfen!

Die einzige Alternative (ohne Datenbank [keine Option da Win7 und mir kein anderes System drauf kommt]) ist die bbox (bzw kann man da direkt die Kacheln angeben) mit OSMOSIS unter Verwendung von completRelations auszuschneiden - aber da dauert das auschneiden fast länger als das Rendern (bei mir aus der europe ca. 1,5h!!).

Ja, die ganz großen Flächen sind ein sehr großes Problem insbesondere dann, wenn gleichzeitig in diesem Bereich schon sehr detailliert gemappt wurde. Der Inhalt einer Kartenkachel darf eine bestimmte Menge nicht überschreiten. Sobald eine ein problematisches Riesenpolygon umschließende Boundingbox zu “voll” ist und in passende Häppchen aufgeteilt werden muß, muß das Polygon durchgeschnitten werden. Und schon taucht bei passender bzw. unpassender Konstellation Schrott auf der Karte auf.
Bei kleinen Polygonen ist die Chance größer, daß die beiden Schnittstellen ein und dieselbe Linie (Outer) durchtrennen. Dann verbinden Splitter oder Renderer (? wer isses? ) diese Teilpunkte mit einer geraden Linie und es entsteht am Kachelrand eine sauber abgeschnittene Fläche, wenn Kachelrand und Verbindungslinie gleich laufen. Warum nun aber bei kleinen Flächen eines der abgeschnittenen Teile verloren gehen kann, erschließt sich mir mangels Programmierkenntnissen nicht.

Mit OSMOSIS bin ich nicht zurecht gekommen. Das Programm überfordert meine Geduld :wink:
Ich schnipsele im Moment noch mit pbftoosm.

Gruß
tippeltappel

Die Binaries zum Download für die alte Mapnik Version 0.7.1 gibt es hier noch:

http://trac.mapnik.org/wiki/WindowsInstallation

Git ist die Versionsverwaltung und wird benötigt, wenn man sich den Sourcecode holen und die Binaries selbst bauen möchte. Für die aktuelle Mapnik Version 2.0 gibt es noch keinen Windows Download und das selbst bauen ist wohl nicht so einfach, sonst gäbe es den schon.

Im Normalfall benötigst du für Mapnik noch eine PostgreSQL/PostGIS Datenbank mit einem osm2pgsql Schema.

Siehe Anleitungen von ajoessen: http://wiki.openstreetmap.org/wiki/User:Ajoessen

Maperitive und Mapnik sind nicht kompatibel, die Renderregeln sind schon sehr verschieden.

Gruß,
ikonor

Mapnik unterstütz als Source auch xml Dateien! Eine Datenbank beschleunigt nur den Prozess, da hier nur kleinere Bereich abgefragt werden und nicht die ganze Datei durchsucht werden muss. Für kleine Gebiete reicht das aber vollkommen.

Das Problem ist doch aber, dass dann a) die Vorverarbeitung von osm2pgsql fehlt (Relationen, Multipolygone?) und b) die “großen” Kartenstile (z.B. “Mapnik” von openstreetmap.org und MapQuest) SQL Statements enthalten und sich deshalb nicht ohne weiteres verwenden lassen.

Gibt es denn komplette Stile für xml Dateien oder Shapefiles?