Digitale Kartografie, GPX-track und QGIS, usw

Hallo,

gibt es hier Enthusiasten, die selbst Karten generieren? Ich würde mich über Austauschmöglichkeiten freuen.

Konkret erarbeite ich mir derzeit die Einzelschritte, eine Radtourenkarte eines GPX-Tracks im Stil der "guten alten Illustrationen" zu generieren: Details entlang der Strecke, "fast leere Fläche" abseits davon.
Stelle mir vor, das dann als Web-Karte zu exportieren. So in der Art "zoombare Marco-Polo-Karte.

Die grundlegenden Umwandlungen von Geodaten klappen schon (Buffer um Track, als POLY mit boundingbox in osmosis, osm-Import ausgewählter Attribute in QGIS). Schnell bin ich bei meinen Projekten aber eh nie. Und farbliches Styling fällt meist hintenrunter *g*

Die Visualisierung von GPX-Dateien ist nicht so verbreitet in der Szene der Geodatenvisualisierer. Vielleicht kann man sich ja hier gegenseitig anregen...

Mein Tipp wäre erstmal: Beschreib mal deutlich genauer, was du haben möchtest. Dann kann man auch sehen, wie man da hinkommt. Je nach Output unterscheiden sich die Schritte meiner Ansicht nach recht deutlich.

Ohne Anglizismen verwenden zu duerfen, ist die Beschreibung halt etwas schwierig!

Deshalb der Versuch eines Bildes:

http://i.imgur.com/P1o0omp.png

Zu sehen ist die gefahrene Strecke, in einem Uebersichtsmaszstab.
Um die Strecke herum ist eine Zone, in der ich Details darstellen will.
Ansonsten soll die Karte relativ leer sein, nur ein paar Anhaltspunkte wie "Berlin", "Moskau" oder "Atlantis".

Das ganze dann mit HTML und Javascript garniert, um hineinzuzoomen (ich denke mit der Bilbiothek von leafletjs.com).
In den Detail-Zoomstufen dann mehr Inhalte (Ortsnamen, Tagesetappen, Strassen etc pipapo).


Momentan kompiliert das Programm Mapnik, und aus dem OSM-Download "Asien" der Geodatenfabrik habe ich schon das relevante Teilgebiet herausgeschnitten (mit osmosis), der Download von Europa jedoch ist noch nicht fertig.
Die Umrisse aller durchfahrenen Laender sind bereits zu einem Gesamtvieleck zusammengefuegt und im "POLY"-Format umgewandelt (damit kann das Kommadozeilen-Programm osmosis Teile heruasschneiden).

Letzte Woche konnte ich in QGIS noch nicht mehr als das Anfaengerbeispiel nachahmen, deswegen bin ich mit dem Fortschritt soweit zufrieden. Bewege mich auf der Linux-Kommandozeile und in Systemadministration aber auch sehr sicher, das hilft.


Meine groesste Huerde wird wohl sein, in den OpenStreetMap-Attributen herauszufinden, was ic hwirklich extrahieren will, und dann einzelne Geodaten (evtl mit den IDs in JOSM?) zu identifizieren. Letzteres waere aber nur einmalige Fleissarbeit, bsw um die ID des Ortsnamens "Berlin" zu finden. Denn ich wuerde den Ortsnamen "Berlin" natuerlich nicht selbst platzieren, sondern das sollte schon auf den OSM-Daten basieren.


Mir reicht es aus, wenn das Ganze auf dem lokalen Rechner laeuft, das nimmt etwas Komplexitaet aus der Sache raus.

Obwohl ich immer noch nicht komplett verstanden habe, wo genau du hin willst, und ich wahrscheinlich auch nicht hilfreich sein könnte, wenn ich es komplett verstanden hätte, interessiert mich das Thema schon.
Möchtest du sowas wie Radweit in digital und zum Selbermachen? Sowas suche ich nämlich auch noch. Karten (gedruckt oder digital), die nur einen definierten Korridor entlang eines vorgegebenen Tracks darstellen. Den Grad der angezeigten Details möchte ich vor dem Druck bzw. am Anzeigegerät (Garmin, Smartphone) definieren.
Ich hab mich da vor einiger Zeit mal laienhaft dran versucht. Einen gpx-Track in Josm geladen und alle Daten entlang des Tracks runtergeladen. Aus dieser Datei wollte ich dann eine Garmin-Karte generieren, hat aber nicht geklappt. Ich hab dann beschlossen, dass die Nummer für digitale Anzeigegeräte eh nicht sehr sinnvoll ist, es sei denn, man muss Speicherplatz sparen. Für Kartendrucke sehe ich da aber durchaus Bedarf.

Karten kann man aber schon jetzt entlang eines Tracks ausdrucken (z. B. Outdooractive). Das nutze ich, um mir ein Tourenbuch zu erstellen, welches ich auf Tour mitnehme.

Genau! Und außerhalb des Korridors nur ein paar "grobe Striche", damit man es einordnen kann.

Das ist halt recht komplex, wenn du das mit einer Online-Kachelkarte machen möchtest. Das verschlingt unmengen an Speicherplatz und Rechenleistung und -zeit.

Kannst du dir hier ausrechnen lassen, was ein Bereich an Speicherplatz frisst. Selbst deine teilweise komplett leeren Tiles müssten gerendert werden und fressen min. 4 kByte.

Je nach dem, für welchen Zweck die Karte sein soll, würde ich mich ernsthaft fragen, wo da der Nutzen ist im Vergleich zum Nutzen von vorhanden Tiles?

Ich würde mir eine detailarme Karte für den Hintergrund suchen (OSM-wiki bspw.) Und dann schauen was du noch drauf bringen möchtest. Das kann man dann wahrscheinlich am einfachsten direkt über leaflet einbinden als Punkt/Linie und muss nicht über Bilddateien gehen.

Ah, an das Vorhandensein von sowas hab ich gar nicht gedacht! Ich schau mir das mal an.

Es gibt ja einen ganz großen Haken an den üblichen Javasccript-Bibliotheken: Ich habe keine gefunden, wo ich die links-rechts-oben-unten Darstellungsgrenzen (setMaxBounds bei Leaflet) dynamisch pro Zoomstufe setzen kann. Ich müsste also jede Menge 'tiles' generieren, die inhaltlich nutzlos sind -- und die Benutzerfreundlichkeit ist auch nicht gegeben.

Allgemein stellt sich mir die Frage, wozu der unterschiedliche detailgrad? Warum ist es schlimm, dass 20km entfernt von deinem Track auch jede Bushaltestelle angezeigt wird?

Das hatte ich gemeint mit: Beschreibe, was du haben möchtest. Das es eine Kachelkarte zur Onlinenutzung werden soll, hast du auch nur durch die Erwähnung von Leaflet und Mapnik verraten.

So etwas in der Art habe ich letztes Jahr bereits für mich programmiert. Ziel war eine druckbare Kartensammlung entlang eines gpx-Tracks mit ein paar Zusatzwünschen, siehe diesen Thread für mehr Details. Aus unterschiedlichen Gründen (u.a. zu komplexe Installation und *hüstel* mangelnde Codequalität) habe ich mich damals dagegen entschieden, den Code zu veröffentlichen. Für eigene Zwecke bin ich aber mit dem Resultat recht zufrieden.

Wie der Zufall es will, bin ich aber im Moment dabei, das Ganze nochmals anzugehen. Inwischen kenne ich mich in der Materie etwas besser aus, vielleicht kommt es diesmal zu einer Veröffentlichung...

Ein interessanter Thread, danke!

Er bestätigt mich darin, mich erstmal weiter damit zu beschäftigen, was mit momentan echt Spaß macht: Die Datenbasis zu automatisieren.
Ich schreib das alles sofort als Script, und derzeit als "download.sh" (wget) und "transform.sh" (osmosis und ogr2poly etc), das kann dann halt rödeln, wenn ich auf der Arbeit bin.

Unter Ubuntu 16.04 hab ich übrigens die Python-Bindings für Mapnik nicht zum Laufen gebracht, irgendwas mit libboost, das ich nicht verstehe. Aber dann hab ich das dockerfile von den Leuten von switch2OSM gefunden (nachdem ich die MTU runtergesetzt hab, klappte es auch mit docker pull, dauerte nur 1 Stunde, um das rauszufinden *grrr*)
Jede Art von dependency hell lässt sich aber mit Gentoo umgehen, muss ich evtl mal probieren...


Eine starke Vereinfachung ist bei mir, mit dem Europa-Export von 2014-01-91 und dem Asienexport 2015-01-01 zu arbeiten. Aktuelle Changes nachzuziehen ist glaub eine Herausforderung...

Momentan teste ich meine beiden Scripte parallel mit den 140km Wochenendpendeln und halt dem Bereich bis zum Schwarzen Meer.

Ich verwende GitHub als Backup, und stelle eine Scripte im Laufe der Woche dort ab. Die müssten sich verallgemeinern lassen, um die Beschaffung der Daten zu automatisieren (in der bash).

Manches wird einem selbst erst im Verlauf klar

Die Changes sind recht simpel. Im Prinzip gibt es 2 Wege. Ich habe mir den Planet einmal heruntergeladen (das sind erstmal ein paar GB) und dann wird der immer mit osmupdate aktuell gehalten. Auf einer SSD dauerts rund 1h + Downloadzeit (aus China ist das leider recht zäh). Anschließend würde bei dir dann das ausschneiden deines Extraktes kommen mit osmconvert und dann in deine weiteren Scripte.

Wenn du die Extrakte der Geofabrik nutzt, kannst du natürlich auch diese mit den diffs von der Geofabrik updaten und dann wieder mergen zu deinem Extrakt. Was besser ist, kommt drauf an.

Ich finde es über den Planet angenehmer und problemloser.

Aber wie gesagt: Das was du vorhast ist meiner Einschätzung nach sehr hoher Aufwand für recht wenig Zusatznutzen. Zumindest meiner Einschätzung nach.

Wenn ich es einmal mühsam mache probiere, dann hab ich es danach wenigstens verstanden. Als ich letzens zu einem holzverarbeitenden Betrieb kam, um mir eine Arbeitsplatte abrichten zu lassen, haben die auch gefragt, warum ich kein fertiges Leimholz nehme. Aber weil ich dieses eine Mal mir die Kanthölzer selbst verleimt hab, ist mir der Werkstoff Holz jetzt ganz anders "begreifbar"…

Nur mal als Benchmark:
Was für Rechenleistung ist eigentlich für die Verarbeitung eines planet files notwendig und wieviel Arbeitsspeicher?
Ist die Festplatte der wichtigste Faktor?
Arbeitest Du auf der Basis von osm Dateien oder gegen eine Postgres-DB?

(Ich hab noch eine ungenutzte CAD-Workstation, mit 2x Xeon Quad Core 2,5GHz und 16 GB Arbeitsspeicher, aber eine SATA-Festplatte. Mich würde interessieren, was ich davon erwarten könnte.)

Das kann ich durchaus verstehen.

Ich arbeite mit dem kompletten Planet im o5m-Format. Das sind derzeit rund 60gb. Für das Updaten brauchst du eine schnelle Platte und CPU-Zeit. Ram ist nicht sooo wichtig. Ich verarbeite das alles auf einem Notebook mit einem i7-4720, 16GB RAM und einer 256GB SSD. Für die Garmin-Karten, die ich für mich noch rechne, kommt das gut hin.

Bei einer Postgres-DB kann ich dir nicht wirklich helfen. Da würde ich wahrscheinlich einfach mal bei OSM nachfragen an deiner Stelle. Da gibt es ja einige, die eine solche DB betreiben. Ich denke dein Flaschenhals wird die HDD sein. Im Wiki gibts auch ein paar ältere Benchmarks: http://wiki.openstreetmap.org/wiki/Osm2pgsql/benchmarks

Du berechnest direkt aus den Rohdaten im o5m-Format deine Garminkarten? Kannst Du da etwas mehr zu sagen? Ich bin eigentlich davon ausgegangen, daß alle Projekte, die nicht nur eine winzige Fläche, also Daten, abdecken, um den Datenbankimport nicht herumkommen.

Sachen erstmal selber machen, um sie zu verstehen, kann ich sehr gut nachvollziehen. Vor allem wenn es auch noch um Karten geht, daß macht ja auch einfach Spaß.

Ich habe momentan Deutschland, Frankreich und die Schweiz in meiner Datenbank importiert. Das hat auf meinem mickrigen Rechner (2 Kerne, 2.4Ghz, 6GB RAM, keine SSD) recht lange gedauert, >3 Tage. Aus den Auslastungswerten währendessen würde ich folgern, daß im ersten Teil des Importiertungsprozesses der zu geringe Arbeitsspeicher Schuld trägt, Swappen bremst wahnsinnig aus. Im zweiten Teil war es dann die langsame Festplatte. Grundsätzlich denke ich aber, daß bei ausreichend großem Swapfile und sehr viel Zeit alles möglich ist. Der Zugriff auf die Datenbank selbst ist beansprucht den Rechner kaum. In Zeiten, in denen man zumindestens grundsätzlich problemlos auch mal 50GB runterladen kann, fände ich fertige Datenbanken ja ne schöne Sache. [Edit: problemlosen Hinzufügen weiterer Daten wäre auch dufte. Also zB jetzt noch Spanien dazu...)

Ja, das ist der übliche Weg, um Garminkarten aus OSM-Daten zu erstellen. AFAIK gibt es auch keine Tool-Chain, die Datenbanken unterstützt, da es im Prinzip kaum Vorteile bringt.

Den Update-Prozess ahb ich ja schon erleutert. Nach dem Update geht der o5m-Planet in den splitter von mkgmap rein. Der Erstellt für jede spätere Garmin-Kachel eine kleine o5m-Datei. Das ist im Prinzip der Grund, warum eine Datenbank sich kaum lohnt. Die o5m-Datei kommt dann so im Schnitt auf 15-20mb. In einem Durchlauf lasse ich alle benötigten Kacheln anhand einer vorgefertigten Schnittliste zerkleinern. mkgmap bekommt dann je Karte die jeweils benötigten Kachelnummern übergeben und macht dann die Karten.

Achso o5m nutze ich, weil es schneller durchläuft als pbf und ich noch ausreichend Platz auf der SSD habe.

Ich bin beim Hype um (Docker-)Container zwar zurueckhaltend, aber https://github.com/openfirmware/docker-osm2pgsql/blob/master/TUTORIAL.markdown beschreibt ganz unten auf der Seite einen echt eleganten Anwendungsfall:

$ sudo docker export postgres-osm > ~/postgres-osm-dump.tar
$ sudo docker import ~/postgres-osm-dump.tar

Das ist dann nicht nur eine Datenbank, sondern ein fix und fertige quasi-virtuelle-Maschine mit Port offen zu einer mit osm2pgsql gefuellten PostgreSQL Datenbank.

---

Ich denke auch schon, dass sich in einem Radreise-Forum der Austausch zu dem Thema deswegen lohnt, weil die Langstreckenradler andere Anforderungen an Karten haben als der Rest. Vielleicht haben noch die Motorrad-Tourer aehnliche Anforderungen: Grosser Radius, schmaler Korridor.

Ich seh es an meiner Tour nach Armenien (das Land meiner zukuenftigen Frau, soviel zur Motivation, Geodaten von-hier-bis-dort zu beherrschen *g* ) deutlich: Entweder planet-file oder europe mit asia mergen. Es gibt bsw bei der beliebten Quelle geofabrik keinen Armenien-Export. Gut, ist mit osmosis kein Problem! Aber das wusste ich vorletzte Woche noch nicht! *g*

Keine Frage haben Radfahrer andere Ansichten von der Karte als andere Nutzer. Wobei es ja auch da eine recht große Auswahl fertig gibt.

Dein Ansatz ist in meinen Augen aber nicht zielführend. Mit deinem Plan musst du für jeden Track, den du auf einer Karte darstellen willst seperate Tiles rechnen, weil jedesmal der Buffer anders ist. Im Prinzip heißt das dann für dich für jeden Track eine neue DB importiere und Mapnik die Kacheln rechnen lassen. Wenn du gleich ganz Europa rechnest in detailiert, reicht dir eine DB vollkommen aus und du musst auch nur einmal Mapnik bemühen.

Ich hab auch noch herauszufinden, was ich mit osmosis/mapnik/... machen kann und was in QGIS, welches ich ebenfalls in Grundzuegen lernen moechte. Ich glaub, an der Stelle bin ich noch ziemlich "anfaengerblind".

Ich lese Tutorials, mache manche selbst als Finderuebung, und schaue YouTube-Tutorials. Irgendwann "schnackelt" es dann.

---

Zumindest den Download mit wget hab ich in https://raw.githubusercontent.com/cprior/cycletourmap/master/app/bin/download.sh fertig als Script, will zwar auf curl umsteigen, ist aber funktionsfaehig.
Ich uebergebe eine Konfigurationsdatei https://raw.githubusercontent.com/cprior/cycletourmap/master/app/configuration/config.sh und die Dateien von den Geofabrik-Servren werden heruntergeladen.

Mit wget schlaegt aber der Download von -latest.osm.pbf Update-Dateien fehl, weil ich nur auf das Vorhandensein des Dateinamen teste. Mit curl ist das IIRC aber moeglich.

Schritt 1 ist: Sub"planet"-OSM-Daten herunterladen und mergen.
Schritt 2 ist dann extrahieren von definierten "poly"-Ausschnitten, (todo)
Schritt 3 dann tags daraus filtern. (todo)

Hallo Christian,

dein Projekt lässt sich in drei Stufen aufteilen: 1) Zusammenstellen der Daten in geeigneter Form, 2) Erzeugen des Kartenbilds ("Rendern") und 3) Anzeige der Karte.

zu 1): Wenn du wirklich abhängig von der Entfernung zum Track unterschiedlich rendern willst (worin ich wie andere keinen rechten Sinn sehe), dann geht das am einfachsten, wenn die Daten in einer Geodatenbank hältst, also entweder in PostgreSQL/PostGIS oder SQLite/SpatiaLite. Der Vorteil einer solchen Datenbank ist, dass man die Objekte anhand ihrer geografischen Position und Ausdehnung sowie ihrer räumlichen Beziehungen zueinander selektieren kann. Wenn sowohl die OSM-Daten als auch der Track in einer Geodatenbank abgelegt sind, dann kann man sich beim Rendern auf relativ einfache Weise alle Objekte ausgeben lassen, deren Entfernung vom Track einen bestimmten Wert überschreitet.

Die OSM-Daten in eine PostGIS-Datenbank bekommt man mit osm2pgsql, in eine SpatiaLite-DB mit ogm2ogr, bei QGIS mit der integrierten OSM-Import-Funktion. Um den GPX-Track in die DB zu importieren, findet sich sicher auch eine Lösung, notfalls auf dem Umweg über das OSM-Format.

zu 2): Zum Rendern von Karten auf OSM-Basis gibt es im wesentlichen drei Tools: Maperitive, Mapnik und QGis.

Maperitive hat den großen Vorteil, dass es eine integrierte Entwicklungsumgebung enthält. Der Nachteil ist, dass es weder PostGis noch SpatiaLite unter stützt.

Mapnik unterstützt PostGIS, bei SpatiaLite bin ich mir nicht sicher. Der Knackpunkt bei Mapnik ist aus meiner Sicht die XML-Beschreibungssprache. Die XML-Datei von Hand zu erstellen ist eine echte Sisyphosarbeit. Einfacher geht es mit CartoCss, einer CSS-ähnlichen Beschreibungssprache. Für CartoCss gibt es ein Kommandozeilentool, welches eine CartoCss-Datei in eine Mapnik-XML-Datei umwandelt. Es gibt auch grafische Entwicklungsumgebungen, bei denen Änderungen quasi in Echtzeit gerendert werden. Tilemill war lange Zeit die Standardentwicklungsumgebung für CartoCss, wird aber leider nicht mehr aktiv weiter entwickwelt. Ich habe es auch unter Linux irgendwann nicht mehr zum Laufen bekommen (node.js grrr...). Kosmtik ist eine Entwicklungsumgebung für Cartocss, die im Browser läuft (mit lokalem Server im Hintergrund). Frisst leider eine Menge RAM. Ich habe mir daher eine eigene Umgebung gebastelt auf der Basis von Tilestache.

QGIS kann m.W. PostGis und SpatiaLite verarbeiten.

Mit Maperitive und Mapnik kann man sowohl einzelne Kartenausschnitte als Grafik erzeugen als auch Kacheln für eine interaktive Karte. Ob QGIS auch zum Erzeigen von Kacheln geeignet ist, weiß ich nicht. Einen Vorteil von QGis sehe ich allerdings darin, dass man Daten aus vielen verschiedenartigen Quellen verwenden kann und somit auch eigene Objekte von Hand oder aus einer CSV-Datei hinzufügen kann.

zu 3): Leaflet ist sicher eine gute Wahl für deine Anwendung. Ich nutze selbst OpenLayers, das ist aus meiner Sicht mächtiger aber auch komplexer zu handhaben.

Grüße
Rainer

Mir ist nicht klar, was das Ziel ist, insbesondere ob es um ein bestimmtes Reiseprojekt von dir geht oder um ein Tool, das für einen beliebigen Track funktionieren soll. Je nachdem kann es günstiger sein, sich lokal eine Kopie der Geofabrik-Dateien für ein sehr großes Gebiet zu halten oder sich bei Bedarf nur die aktuellsten Daten entlang des Tracks herunterzuladen. Letzteres könnte mit dem Overpass-API oder direkt per API von openstreetmap.org, so wie es in JOSM für einen geladenen Track gemacht werden kann.

Wenn du wirklich nach Tags filtern willst (und nicht die von mir im vorigen Post angesprochene Vorgehensweise mit einer Geodatenbank umsetzst), dann schau dir mal osmfilter an.

Generell sind deine Fragen eher etwas für das OSM-Forum bzw. das deutsche Unterforum.

Danke für die Tips! Bei jedem neuen Sachgebiet ist es doch immer gut, mal erfahrene Sichtweisen zu bekommen.

In der Tat schwebt mir nur vor, das Ganze zwei oder drei Mal zu machen.
Das erklärt vielleicht, warum mich "rendern" nicht (zunächst nicht) abschreckt.

QGIS macht mir sogar richtig Spaß!

Dann würde ich es auch mit QGis machen. Bis auf die unterschiedliche Darstellung in Abhängigkeit von der Entfernung vom Track geht das recht einfach. Mir haben dieses und jenes Tutorial viel geholfen. Dort wird jeweils eine von zwei Möglichkeiten beschrieben, OSM-Daten in eine für QGis geeignete SpatiaLite-Datei zu importieren.

Ich habe etwas freie Zeit fuer dieses Projekt, und bin momentan sehr interessiert in der "Phase 1" nach axurit, dem "Zusammenstellen der Daten in geeigneter Form".

Einen netten Trick habe ich gefunden, den ich schon jetzt berichtenswert halte, fuer alle die unter Linux arbeiten:
- Unter debian jessie-backports https://packages.debian.org/source/jessie-backports/osmium-tool gibt es das fast aktuelle Paket osmium-tools in der Version 1.5.1-1 (1.6 ist von vor ein paar Tagen auf GitHub http://osmcode.org/osmium-tool/ getagged worden, wird gewiss bald nachgezogen)
- ich arbeite zwar mit keinen Debian Jessie, aber mit systemd-nspawn (ich habe ja bekanntermassen keinerlei https://programm.froscon.de/2016/events/1706.html
Beruehrungsprobleme mit systemd *g*) kann man leicht eine leichtgewichtige Virtualisierung erzeugen, bsw unter https://lindenberg.io/blog/post/debian-containers-with-systemd-nspawn/ beschrieben.
- der Clou ist, dass systemd-nspawn auch --bind= Paramter entgegennimmt, ich also im Container ohen Probleme Verzeichnisse aus dem Hostsystem einhaengen kann.
- daher arbeite ich unter einem non-Debian gerade mit `osmium`, ohne muehsam selbst komplilieren zu muessen (mit eine laaangen Liste an Abhaengikeiten).

Man braucht die Container (siehe vorigen Link zu https://lindenberg.io/blog/post/debian-containers-with-systemd-nspawn/ ) uebrigens nicht zu booten, es reicht, wenn man einen Befehl im Container ausfuehren laesst, zB (angelehnt an eben diesen Blogartikel) `sudo systemd-nspawn -D /var/lib/container/jessie --bind=/mnt/backup osmium fileinfo /mnt/files/europe-latest.osm.pbf`. Container sind "nur" ein Kernel-Features mit Namespaces und controlgroups, man kann also sehr leichtgewichtig "virtualisieren".

Ein gaaaaaanz vorsichtige visuelle Annaeherung an das, was ich mir vorstelle, hab ich in 10min in QGIS zusammengeklickt: http://imgur.com/a/i66V5

Das sind "nur" naturalearth-Daten http://www.naturalearthdata.com/ und QGIS kann auch "clipping", ohne dass ich OSM-Daten selektieren muste fuer dieses "Mockup-Beispiel".
Den GPX-Track hab ich von Line in Polygon umgewandelt, dann gebuffered und als Shapefile gespeichert -- dieses war dann die Ausgangsbasis fuer das "clipping".

Ich taste mich dann auch beim Farbschema weiter vor, bsw anhand von http://fredgibbs.net/tutorials/qgis/overlaying-historic-maps-with-qgis.html .

Ich weiß, ein alter Thread, aber nach einigen Jahren Pause habe ich das Vorhaben wieder aufgegriffen.
Ziel ist unverändert: Eine eigene Karte zu erstellen ("eigen" insbesondere im Sinne von Copyright) mit Kartendetails ausschließlich entlang eines (GPX-)Tracks.

Die aktuell stabile QGIS Version 3.28 Firenze hat mittlerweile eine Exportfunktion für Animationen, unter dem Namen "3D Map".

Vor einigen Jahren hatte ich mich schlichtweg zu blöd angestellt, die Operationen "buffer" und "clip" anzuwenden. Dabei wäre schon damals das Filtern der (frei verwendbaren) "NaturalEarth" Geodaten vollkommen trivial gewesen. *grrr*
(osm Daten verwende ich momentan gar nicht.)


Hier meine Checkliste (denn bei der Recherche stieeß ich auf diesen meinen uralten Thread):

basemap on NaturalEarth basis created
GPX tracks loaded
GPX tracks processed to line with Plugin Points2One
Track "expanded" with Geoprocessing Tool > Buffer
global populated places filtered with Geoprocessing Tools > Clip
map labels of filtered layer styled
for each layer visibility zoom level set
project spatial bookmarks created with zoom level and extends
3D map created
3D map follows 2D configured
3D map show labels configured
3D map play keyframes set to spatial bookmarks
3D map exported to sequence of jpg
sequence combined to video


Das Resultat ist:
https://www.youtube.com/watch?v=qDcR8j9NOyo

Hat noch kleinere Schwächen (aber für ein Hobbyprojekt ist mir das schon gut genug):
- nicht nur wiederholt QGIS labels wie "North Rhine Westphalia", schneidet diese aber manchmal ab
- manche Kartensymbole werden nicht korrekt gerendert, bsw ist ein Teil von "plan 2023" unscharf dargestellt
- ich müsste mir die Mühe machen, treffende Illustrationen einzufügen
- und das Video würde von sanfteren Animationen profitieren.


Bei Gelegenheit werde ich einen "screencast" erstellen, der die Vorgehensweise dann auch bildlich nachvollziehen lässt.

Hallo Christian,

Danke für das Update. Ich bin schon gespannt auf das ScreenCast. Ich habe vor vielen Jahren auch mal eine GPX-Trackanimation mit QGis gemacht, damals mit dem Plugin TimeManager. Da interessiert mich natürlich, wie man so etwas mit der aktuellen QGis-Version machen kann.

Grüße
Rainer

Noch ist es bei mir "vor der Tour", und in der Nachbearbeitung wird erst die Zeit&Muße für die Dokumentation der Erstellung eigener Karten sein.

Aber schon jetzt sammle ich Material und erste Screencast-Aufnahmen auf https://www.crazyguyonabike.com/doc/page/?o=3qE&page_id=654460&v=38

Im eingebetteten Video zeige ich zwischen ~7:30 und 7:50, wie mit wenigen Klicks die weltweiten UNESCO World Heritage Sites gefiltert werden auf die entlang meiner Strecke.

Jetzt in der Tour-Vorbereitung bin ich total begeistert, dass mir von solchen Geodaten "nix durch die Lappen gehen kann", ich also "unterwegs nix verpasse".

Oder visuell zu sehen, wo meine Strecke über Wasserscheiden führt.

Oder wann ich an einem Atomkraftwerk vorbeikomme.

Oder Eisenbahn-Strecken ein-&ausblenden (macht ja auch irgendwie ruhiger, wenn man weiß, wo man umsteigen _könnte_)

Hab also in den letzten Wochen noch viel mehr Anwendungsfälle von Geodaten-Verarbeitung mit QGIS https://www.qgis.org/en/site/ gefunden als nur die Animationen.