We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Wanderwege weltweit

00:00

Formal Metadata

Title
Wanderwege weltweit
Subtitle
Ein Karten-Overlay aus OpenStreetMap-Daten
Title of Series
Number of Parts
24
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Wanderwege erfreuen sich auf der ganzen Welt wachsender Beliebtheit. Projekte reichen vom mehrere tausend Kilometer langen Transcanada-Trail über die historischen Jakobswege in Europa bis zu wenige Kilometer langen Stadtrundgängen. OpenStreetMap (OSM) erlaubt zum ersten Mal, diese meist lokal vorangetriebenen Projekte in einer Datenbank zu sammeln und vor allem gemeinsam darzustellen. Das wiki-artige Konzept von OSM bietet theoretisch die besten Voraussetzungen zur Herstellung von Karten für spezielle Interessen. In der Praxis bestehen jedoch einige Hürden: das Erstellen eines eigenen Kartenstils ist sehr aufwändig und das Rendern von Karten für den ganzen Erdball stellt hohe Anforderungen an die Hardware. Um diese Schwierigkeiten zu umgehen sind wir bei der Erstellung der weltweiten Wanderkarte einen anderen Weg gegangen und erstellen anstatt einer vollständigen Karte nur einen Overlay. Eine spezielle Anwendung leitet dafür aus den OSM-Daten eine spezialisierte Wanderdatenbank ab, die dann benutzt wird, um genau die Gegenden zu rendern, für die Karte von Interesse sind. Auf diese Weise kann auf einem Standard-PC eine täglich aktualisierte, weltweit verfügbare Karte hergestellt werden. Der Vortrag gibt einen Überblick über die Entwicklung der weltweiten Wanderkarte. Er beleuchtet etwas näher die Herausforderungen, die sich bei der Verarbeitung so heterogener Daten ergeben und erklärt dann ausführlich den Erstellungs- und Aktualisierungsprozess des Overlays von der Datenaufbereitung bis zur Darstellung im Browser.
Overlay-NetzCalculationSpeciesOverlay-NetzRouter (computing)Hard disk driveSmart cardTV-KarteDatabaseServer (computing)VolumenvisualisierungUpdateQuery languageInformationGeometryZusammenhang <Mathematik>DepictionRAMChain rulePolygonGeschachtelte RelationAdaptive behaviorDatabaseInternationalization and localizationTerminal equipmentTable (information)MAPPERSQLGeometryVector graphicsDurchschnitt <Mengenlehre>SoftwareHausdorff spaceAlgorithmBoom (sailing)Gebiet <Mathematik>Plane (geometry)ForestWordComputer scienceGrand Unified TheoryMilitary rankTotal S.A.Lattice (order)Punched cardBus (computing)PoserDecision tree learningQuoteHauptspeicherOperatorPROBE <Programm>TrailComplete metric spaceWeb browserZahlState of matterProzessorMechanism designPropositional formulaProteinScale (map)Computer animation
Transcript: German(auto-generated)
Okay, also der nächste Vortrag ist ein etwas praktischeres Thema, draußen, outdoor. Hier geht es um Wanderwege weltweit, Entwicklung einer Overlay-Karte aus USM-Daten. Also ja, für die Hobbywanderer unter uns vielleicht sehr interessant.
Sarah Hoffmann stellt das Thema vor. Ja, viel Spaß. Vielen Dank. Also ja, mein Name ist Sarah Hoffmann. Ich bin also jetzt seit mehr als drei Jahren bei OpenStreetMap. Und mal abgesehen davon, als ich angefangen habe, sah die Schweiz nicht so aus, sondern war ein ziemlich weißer Fleck.
Das heißt, das ist schon eine Motivation mitzumachen. Aber was mich wirklich interessiert hat in OpenStreetMap, ist, dass man eigentlich zum ersten Mal die Möglichkeit hatte, große, also weltweite Kartendaten zu haben und auch Karten zu haben, die mehr darstellen als einfach nur Straßen, Parkplätze und ja, alles, was der Autofahrer braucht. Also zur Nischen-Daten ist halt in OpenStreetMap viel Platz.
Nehmen man Fahrräder. Öffentliche Nahverkehr haben wir heute schon sehr, sehr viele Vorträge gehört. Was mich persönlich interessiert, sind markierte Wanderwege. Und ich war auch neugierig, okay, was ist da in der Welt? Und einer der ersten Sachen, die man lernt bei OpenStreetMap, ist, wenn man eine spezialisierte Karte haben will, dann muss man das selber machen. Die zweite Sache, die man lernt, wenn man das das erste Mal probiert,
ist der einfache Rechner zu Hause. Da wird es schon ziemlich knapp. Also wir haben heute Leute gehört, die ganz stolz verkündet haben, ihre Software braucht nur 32 GB RAM. Das war also bei mir damals auch eine Sache, die eigentlich nicht vorhanden war. Eine Möglichkeit, seine eigene Karte zu machen, ist deswegen, anstatt einer vollständigen Karte, eine Overlay-Karte zu machen, die also nur die Informationen enthält, die man wirklich selber darstellen will.
Also zum einen hofft man, dass man die schneller Verarbeitung machen kann, weil man weniger Daten braucht. Der Renderaufwand sollte geringer werden, weil viele Kartenteile einfach leer sind. Die muss man gar nicht erst rendern. Und die Hoffnung ist natürlich auch, dass es sein der Karte selber leichter ist, wenn man einfach weniger Daten auf die Karte bringen muss.
Okay, also daraus ist dann entstanden die Idee, also eine Wanderkarte zu machen. Im Groben werde ich jetzt also, wird sich der Vortrag in zwei Teile gliedern. Der erste Teil ist mehr so die technische Realisierung. Wie schafft man es also, so eine Overlay-Karte auf einem eher schwachfristigen Server zu realisieren?
Also der Server, auf dem die Karte läuft, ist ein Dual-Core, also Rechner mit 2 GB RAM und 500 GB Festplatte. Also nach heutigen Maßstäben veraltet. Aber die Karte läuft da also noch ordentlich. Im zweiten Teil werde ich dann noch ein bisschen was sagen über das Design der Karte selber.
Okay, diejenigen, die das schon mal probiert haben, werden das wissen. Die klassische Art, zu einer Webkarte zu kommen, ist, man startet also mit dem Planeten, importiert das Ganze mit OSM2PSQL in eine PostGIS-Datenbank. Und dann rendert das Ganze mit MAPNIC die Kartenteile und stellt das mit OpenLayers klar.
Das hat also vom Performance-Standpunkt drei Probleme. Also zum einen das große Problem ist OSM2PSQL. Also vor zwei Jahren, als ich das das erste Mal auf dem Server gemacht habe, hat also ein Update der Daten eines Tages mit OSM2PSQL so 12 bis 14 Stunden gedauert,
was natürlich viel zu lang ist. Also heute würde das wahrscheinlich mehr als einen Tag dauern. Und das Problem dabei ist nicht so sehr, die Daten in die Datenbank zu schreiben, sondern dass für alle OSM-Objekte Geometrien berechnet werden. Und das ist, was wirklich viel Zeit braucht. Für ein Overlay braucht man das eigentlich nicht, weil man wesentlich weniger Daten wirklich verwendet.
Das nächste Problem ist die Größe der PostGIS-Datenbank. Abfragen werden dadurch sehr langsam, was dann MAPNIC beim Rendering der Teile sehr, sehr langsam macht. Das dritte Problem ist dann, dass die Kartenteile selber natürlich sehr viel Festwartenplatz brauchen. Aber wie ich schon gesagt hatte, wenn man Overlay macht, kann man das natürlich dadurch erledigen, dass man viele Teile einfach nicht rendet, die sowieso leer sind.
Was ich also gemacht habe, ist diese Kette leicht verändern, und zwar indem ich einfach die Datenbank aufgesplittet habe. Also zum einen existiert immer noch eine Datenbank mit den Open-Street-Mit-Daten, komplett, der ganze Planet, aber ohne die Geometrien. Und daraus wird abgeleitet eine Datenbank für das Overlay, die dann benutzt wird für MAPNIC zum Rendern.
Und das ist dann so klein, dass MAPNIC also wirklich schnell genug ist, um die ganzen Daten eines Tages ohne Probleme rendern zu können. Ok, schauen wir das uns im Detail an. Also die erste Frage ist natürlich, ok, warum dann immer noch den ganzen Planeten in der Datenbank halten? Also dafür gibt es mehrere Gründe.
Sobald man weltweites Rendering machen will, hat man das Problem, dass man auf jeden Fall mit dem Planeten irgendwie Hand haben muss. Und der hat inzwischen eine Größe erreicht, wo es einfacher ist mit den täglichen Updates oder stündlichen Updates umzugehen als mit dem Planeten selber. Also man möchte eigentlich einen Neuimport so viel wie möglich vermeiden. Das andere Problem ist, wenn man sagt, ok, ich nehme den Planeten, filtre nur meine Daten raus, die ich wirklich brauche,
dann passiert es relativ schnell, dass man feststellt, ok, die und die Daten haben mir jetzt noch gefehlt und dann fängt man wieder mit einem Neuimport an. Das möchte man eigentlich auch vermeiden. Also ich habe jetzt seit einem Jahr wirklich einen Planeten auf meinem Server laufen ohne Probleme und habe auch öfter mal das Overlay verändert und das läuft relativ gut.
Ok, statt OSM2PSQL bietet es sich dann an, Osmosis zu nehmen, weil das wirklich den kompletten Planeten in eine PostGIS-Datenbank importieren kann, ohne die Geometrien zu berechnen. Das heißt, es kommen wirklich nur Knotendaten und Detektdaten und so weiter rein, zusammen auch mit den User-Daten, wer sich für sowas interessiert, aber es wird noch nichts weiter berechnet.
Und man hat natürlich, wie gesagt, die vollständigen Daten, sodass man dann auch selber bei der Overlay-Entwicklung mal schauen kann, ok, was man eigentlich für Text benutzt und so weiter. Das macht sich manchmal auch ganz praktisch. Ok, wenn man jetzt also den Planeten hat,
auf dem Server wird er zurzeit täglich aktualisiert, das könnte man sicher auch kleiner machen. Dann ist die Frage, ok, wie kommt man zu seiner Overlay-Datenbank? Die einfachste Variante ist, mit einer einfachen SQL-Abfrage, zurzeit wird das für die Wegweiser so gemacht, die auf der Karte erscheinen. Also, wer jetzt nicht SQL versteht, das ist einfach das Raussuchen der Notes,
die als Wegweiser geteckt sind und dann einfach Namen und L und die Geometrie selber wird in eine abgeleitete Tabelle übernommen. Was jetzt wichtig ist, die Abfrage dauert immer noch sehr, sehr lang, ist, dass man tatsächlich die Update-Information benutzt. Und es ist so, dass man von Osmosis die Information erhalten kann, welche Daten wurden verändert beim letzten Update und was wurde mit denen gemacht.
Und wenn man das dann benutzt, in seiner SQL-Antragung, wenn man ein spezielles Update-Script hat, und man einfach sagen kann, also im ersten Teil, ok, alle Noten, die geändert wurden, werfe ich aus meiner Overlay-Datenbank raus. Und im zweiten Teil nimmt man dann die Daten, die entweder zugefügt wurden oder geändert wurden,
wieder aus dem Planeten in das Overlay rein. Und diese Abfrage ist natürlich wesentlich schneller, womit das Update selber auch relativ schnell wird. Das kann man machen, aber wenn man sowieso einmal abgeleitete Datenbanken macht, bietet es sich eigentlich an, die Daten gleich vorzuverarbeiten. Also diese Idee, dass man OSM out of the box verwenden kann und Karten malen, es wird eigentlich immer schwieriger.
Und gerade bei Wanderwegen, wo dann Relationen noch involviert sind, ist es eigentlich fast unmöglich, einfach die Daten zu übernehmen eins zu eins. Und also ich habe da zu Python-Script geschrieben, die das machen. Die können inzwischen schon relativ viele Sachen, also zum einen Text, komplizierter auswerten, also wer sich mit Wanderwegen auskennt, da gibt es dieses komplizierte OSMC-Symboltag,
was man erst auseinandernehmen muss, um dann die Markierungen daraus zu bauen. Das wird in dem Python-Script gemacht. Inzwischen kann es auch Geometrieberechnungen, um herauszufinden, ob ein Weg in einem gewissen Land ist, kann ich also auch Landesgrenzen, also dann in Polygone umwandeln.
Es ist außerdem in der Lage, Wege zusammenzufassen, also dass Wege ziemlich oft getrennt werden in den OSM-Daten, um Relationen eintragen zu können. Und so weiter ist natürlich auch immer relativ schlecht, weil dann die Overlay-Datenbank auch größer wird mit Wegen, die eigentlich nicht getrennt werden müssen. Deswegen werden die zusammengefasst, um das auch schneller zu machen.
Und schließlich, im Endeffekt, was ich schon sagte, Wanderwege sind Relationen. Das muss auch nochmal extra ausgewertet werden, weil es auch inzwischen verschachtelte Relationen gibt, wo denn Leute die Relationen in zwei Teile getrennt haben und dann eine Überrelation gemacht haben. Das wird also auch ausgewertet. Zurzeit ist das alles noch ein bisschen ein spezielles Skript für genau diese Datenbank.
Die Idee wäre, das in Zukunft in einer allgemeinen Bibliothek auszulagern, sodass man auch verschiedene Overlay-Datenbanken für relativ einfacher stellen kann. Okay, damit sind die Daten in der Datenbank nun zum Rendering.
Wie ich schon gesagt hatte, der Vorteil von dem Overlay ist eigentlich, dass man viele Teile überhaupt nicht zu rendern braucht. Und damit muss man natürlich den Rendermechanismus ein bisschen anpassen. Also was mit der Wanderkarte zurzeit gemacht wird, ist, dass alle Teile statisch vorgerendert werden. Die Wanderkarte selbst braucht zurzeit, glaube ich, zwei Gigabyte etwa.
Das heißt, es ist vom Speicherplatz her überhaupt kein Problem. Und um zu verhindern, dass man jetzt alle Teile wirklich durchrendern muss, funktioniert der Prozess so, dass man iterativ vom kleinsten zum höchsten Zoomlevel vorgeht. Man fängt also im kleinsten Zoomlevel an, nimmt sich das Teil, schaut, ob überhaupt irgendwelche Daten drin sind. Sind Daten drin, wird das gerendert.
Und dann geht man einen Zoomlevel runter und schaut sich genau die vier Teile an, die diese Ebene abdecken. Und genau da wieder das Gleiche. Wenn, also wie hier, man feststellt, okay, in dem Teil sind überhaupt keine Daten, hört man dann auf mit dem Runtergehen und geht zum nächsten Teil.
Und wenn man da also feststellt, es sind Daten, geht man weiter runter und so weiter. Und dadurch kann man relativ effizient wirklich nur die Teile rendern, die Daten haben. Okay, ganz zum Schluss dann die Darstellung in OpenLayers. Möchte ich jetzt aus Zeitgründen nicht zu genau drauf eingehen. Das funktioniert im Prinzip wie jeder andere Webkarte,
wenn man also die OpenStreet-Map-Karte selber, die Mapnik-Karte selber darstellt. Das Einzige, was man beachten muss, ist, dass jetzt natürlich Teile fehlen und da liefert der Web-Server einfach einen FileNotFound zurück. Und das muss man entsprechend abfangen und ein transparentes Teil im Prinzip dann im Web-Processor darstellen.
Also wenn man das nicht macht, dann kommt so ein komisches Kreuzchen mit Teil nicht gefunden. Das ist relativ hässlich. Okay, das ist im Prinzip der ganze Prozess. Vielleicht mal ein paar Zahlen, um klar zu werden, wie lange das eigentlich dauert. Also wie gesagt, das ist ein Dual Core mit zwei Gigabyte RAM.
Im Durchschnitt braucht es zur Zeit, also für das OSM-Update, das ist das rote, etwa drei Stunden, dann noch eine Stunde, um die Daten in der Overlay-Datenbank zu aktualisieren. Also das ist sehr unterschiedlich zwischen einer und sechs Stunden, um die neun Teile zu rendern. Was ein bisschen interessant ist, also wenn man schaut, hier im November,
sieht man ganz deutlich, ist die Renderingzeit hochgegangen und das war nämlich, als die Bing-Bilder freigegeben wurden, das ist also was, was ich auf meinem Server ganz extrem gemerkt habe. Und interessanterweise ist auch die Motivation nicht mehr gesunken. Also es ist seitdem konstant mehr gemacht worden.
Okay, also soviel zum technischen Teil. Jetzt mehr zum grafischen Teil sozusagen, die Entwicklung des Overlays selber. Eigentlich hofft man, dass man ja relativ wenig darstellen will, ein paar Wanderwege, dass das einfach sein sollte, aber in der Tat gibt es beim Overlay-Design auch einige Sachen zu beachten.
Das allererste Problem ist die Farbwahl. Also es wurde mal ein bisschen kritisiert, dass die Mepnik-Karte zu blass wäre und alles, aber wenn man versucht, ein Overlay auf dieser Mepnik-Karte darzustellen, stellt man relativ schnell fest, dass sie relativ viele Farben hat.
Also mit Rot kommt man noch recht gut hin, Blau auch, aber danach bleibt eigentlich nur noch solche Sachen wie Pink und Türkis übrig, was man noch gut sehen kann. Also das ist ein großes Problem, das heißt, wenn man seinen Overlay-Designs sollte man so wenig wie möglich Farben benutzen. Das andere Problem ist die Beschriftung. Dadurch, dass man keinerlei Informationen hat, wie die unterliegende Karte aufgebaut ist,
basiert es natürlich relativ häufig, dass man Beschriftungen der unterliegenden Karte überschreibt. Und das ist auch etwas, wo man eigentlich relativ wenig gegen machen kann, das heißt, das Einzige, was da möglich ist, ist die eigenen Beschriftungen so gering wie möglich zu halten. Oder wenn man dann wirklich solche Informationen draufbringen will,
ist es vermutlich besser, da einen Vektor leer oben drauf zu legen. Das gilt allgemein für Oversleys. Eine Spezialität der Wanderwege sind die überlappenden Routen. Wanderwege sind als Relationen in der Datenbank und es passiert halt relativ häufig gerade in Deutschland,
dass mehrere Routen über einen Weg gehen. Also der Rekord hält irgendwo in Bayern ein Wegstück mit zwölf Routen, die über das gleiche Wegstück gehen. Also wie dann die Bäume dort aussehen, möchte ich gar nicht wissen. Das Problem in der Karte dann ist, also um die Wege verfolgen zu können,
habe ich also die Markierungen der Routen jeweils drin. Und da hat man natürlich das Problem, dass zum einen man genug Markierungen haben muss, damit man den Weg noch folgen kann. Zum anderen möchte man die Karte nicht überladen. Und um das zu erreichen, habe ich also die Relationsdaten nicht so importiert, wie sie direkt aus OSSM kommen,
sondern wirklich die Wege zusammengefasst. Das heißt, der Algorithmus sucht zuerst immer die längstmöglichen linearen Segmente, die die gleichen Routen haben. Also wenn wir hier uns die Karte angucken, ist also hier zum Beispiel ein Segment, wo in dem Fall glaube ich der Däumer- und Rennsteigweg zusammenlaufen. Das ergibt also einen Weg in meiner Oberleh-Datenbank.
Aber auf der anderen Seite dieser Weg, der rote, der hier so lang ist, das ist auch nur ein Weg. Und dann kann man halt dem Rennlager sagen, okay, mach die pro Weg die Symbole so weit wie möglich auseinander. Aber wenn ein neuer Weg anfängt, dann möchte er natürlich wieder ein Symbol sein. Und damit hat man jedes Mal an der Kreuzung,
ist man sicher, dass danach wieder ein neues Symbol anfängt. Das funktioniert meistens gut, außer wenn der Wanderwegverein wirklich sehr fleißig ist, wie hier in Franken. Und da ist natürlich eigentlich nichts mehr zu machen mit einer ordentlichen Rudendarstellung. Das heißt, was man hier eigentlich machen muss,
ist dann interaktive Daten benutzen, wo man wirklich auswählen kann. Okay, eine Route auswählen kann und die wird dann angezeigt. Eine andere Sache ist, was das hier noch zeigt, ist, dass die Daten sehr, sehr, sehr heterogen sind in OSM. Also Franken sieht so aus. Auf der anderen Seite, wenn man dann in Ruhrpott guckt,
da sind plötzlich alle Routen national. Und es ist sehr schwierig da eine one-fits-all-Lösung zu finden für den Renderer. Das heißt, was hier eigentlich besser ist, sind Regionalisierungen. Und zum Teil unterstützt die Karte das schon. Zwei Beispiele. Also eine ist jetzt nicht bewunderlich die Schweiz.
Da ist also so, in der Schweiz haben wir ein lokales Wegesystem, das im Prinzip nur drei Arten von Wege hat, die nach Schwierigkeiten also unterschieden sind. Also man sieht das relativ schlecht. Es gibt also durchgehende rote Routen und gestrichelte rote Routen. Und ja, der Schweizer ist das auch von seinen Karten gewöhnt,
dass das genauso dargestellt ist. Das heißt, man macht also auch noch eine Lokalisierung der Route, stellt fest, okay, das ist eine lokale Route in der Schweiz, und dann wird die entsprechend anders dargestellt. Andere Regionalisierungen, die ich gemacht habe, sind in den Niederlanden. Die haben also auch ein Wegenetz, das allerdings Knoten hat jeweils. Das heißt, was man dann da macht,
ist Markierungen auf den Wegen weglassen und dafür die Routen, also die Wegpunkte, die die Knoten darstellen. Ist natürlich in diesem Fall einfacher, weil die Knoten spezielle Texte haben. Das heißt, man muss nicht lokalisieren, okay, das ist jetzt in den Niederlanden. Aber im Prinzip ist beides möglich.
Okay, kurzer Zukunftsausblick. Es ist inzwischen eine neue Serverntanung. Also interessanterweise ist dabei nicht das Problem die CPU oder der Hauptspeicher, sondern was inzwischen passiert ist, dass die Festplatte vollgelaufen ist. Das heißt, die OSM-Daten sind inzwischen so gewachsen, dass es eine größere Festplatte braucht.
Außerdem wäre noch schön, kürzere Updatezeiten zu haben. Also zurzeit wird das einmal täglich abgedatet. Aufs minütliche Update oder stündliche Update umzustellen wäre dann auch noch ein Ziel. Und dann in dem Zusammenhang auch umzustellen von vorgerenderten Karten auf Karten, die auf Anfrage gerendert werden.
Wie man das dann genau machen muss, damit auch die Karten, die keine Daten haben, nicht gerendert werden. Das müssen wir noch sehen. Außerdem, was natürlich schön wäre, wäre eine interaktivere Karte, wie ich das gerade im Beispiel von Franken gezeigt hatte. Dass also man wirklich Routen anklicken kann und dann jeweils sieht, wo die lang laufen,
um noch eine bessere Übersicht zu kriegen. Und vielleicht auch in der Zukunft seine eigenen Routen zusammenklicken kann und dann mehr Informationen darüber erhalten kann. Vielleicht das Schlusspunkt ist, also zumindest von meiner Warte, ich bin natürlich Informatiker, dass die technische Seite eigentlich weniger das Problem ist, sondern das wirklich große Problem ist,
wie zeichnet man gute Karten, wie macht man eine gute Darstellung. Und also wenn man da noch mehr Leute finden, die so ein bisschen eine grafische Art haben, das wäre natürlich wirklich schön. Das war's.
Vielen Dank für den Vortrag. Fragen? Inwiefern ist denn die Technik auf Radfernwege übertragbar? Müsste eigentlich, oder?
Ohne Probleme. Also könnte man gleich komplett nehmen und müsste halt... Also da gibt es eigentlich ja noch nichts so, also zumindest ist mir nichts bekannt, was so als Radwege und Netz-Overlay... Ja, nicht als Overlay. Also man hat natürlich die Ofen-Cycle-Map und die ist sehr gut.
Ja, aber mit all den Problemen, die die halt so hat, die gefällt mir nicht besonders gut. Okay, also... Andy Elm war wahrscheinlich nicht... Also so Overlay-Tiles wären, glaube ich, schon nicht schlecht zu haben. Ja, aber also an sich wäre das kein Problem. Also... Es ist halt...
Der Sourcecode ist zurzeit nicht das hübscheste, aber im Prinzip ist er auf jeden Fall verfügbar. Er steht theoretisch unter CC by SA. Und wenn jemand da eine andere Karte aufsetzen will, dann kann ich da gerne behilflich sein. Okay, komme ich vielleicht darauf zurück.
Ist dabei auch eine Möglichkeit vorhanden, auf Richtigkeit zu prüfen. Also es gibt so einen Fall in Deutschland, da war... Nein, es war ein Wanderweg da, der wurde in den USM auch übernommen, so wie er vor 20 Jahren mal war. Dummerweise ist da heute eine Autobahn.
Also da geht der Wanderweg dann wirklich über die Autobahn oder vielleicht ist einfach eine Autobahn gelöscht worden oder so wird sowas überprüft, ob da überhaupt ein Wanderweg sein kann, weil da vielleicht auf der drunterliegenden Karte was anderes ist. Das ist dann relativ schwierig. Also, weil... Weil ich doch relativ viele Daten wegwerfe.
Also gerade die Wegdaten. Ich meine, es gäbe noch andere interessante Sachen von den Wegdaten. Also zu wissen, okay, ist das jetzt asphaltiert oder nicht. Aber zurzeit bearbeite ich das eigentlich noch überhaupt nicht. Was könnte man machen, würde wahrscheinlich den Aufwand recht erhöhen. Aber interessant wäre es auf jeden Fall, ja. Ich denke, das löst sich doch mit Sicherheit durch die Community,
weil es hängt ja von den Daten einfach ab. Und wenn der Wanderweg, das ist halt der Vorteil, den man bei VGI hat, wenn da jemand sieht, da ist eine Autobahn, wo ich gerade wandere, dann trage ich es halt einfach bei USM ein und am nächsten Tag ist es halt auf der Karte drauf.
Der nächste, der die Autobahn eingezeichnet hat, hat natürlich nicht die Korrektur des Wanderwegs übernommen. Den Wanderweg hat ja der Wanderverein dann umgelegt wegen der Autobahn, sondern der Wanderweg ist da einfach mal unterbrochen jetzt. Das glaube ich bis heute nicht nachgezeichnet, aber...
Ja, aber da muss ich dann natürlich auf die lokalen Mapper vertrauen. Also mehr als eine Karte darstellen kann ich natürlich nicht. Aber ich hoffe halt dann, dass die Karte hilft, sowas zu finden. Weitere Fragen?
Okay, da oben ist noch eine.
Hier? Wie weit macht es denn aus deiner Sicht Sinn, dass man sozusagen von der Community her auch mal eine Mappen-Karte ohne Labels oder eine dezente Mappen-Karte macht,
die wirklich dafür geeignet ist, dass andere Leute da ein Overlay drauflegen? Es ist relativ schwierig. Also es gibt ja den Versuch, vom Toolserver die Schwarz-Weiß-Karte zu machen. Also ich hatte ja hier auch das Beispiel. Hier war es glaube ich.
Also ich weiß nicht. Also es war die Karte in Schwarz-Weiß als Unterlage da. Das Problem an der ganzen Sache ist, dass gerade mit dieser Schwarz-Weiß-Karte
man halt dann weniger die Informationen drunter sieht und die Leute, die jetzt nach Wanderrouten gucken, wollen unter Umständen halt auch wissen, ja wo sind die Bushaltestellen und so weiter. Und gerade das sieht man dann schlecht. Und eigentlich ist es auch so, mit dem Karte die und die Informationen will ich zusätzlich sehen. Und
da speziell den Lehrer zu finden, der das macht, ist wahrscheinlich schwierig. Gibt es vielleicht auch Anfragen
von DAV oder von irgendwelchen Wandervereinen, die sich dafür interessieren? Das wäre ja auch eine Möglichkeit, sowas dann mal auf andere Endgeräte auch mal zu übertragen oder aufs Handy. Wenn man eine Bergtour macht am Wochenende oder eine Wandertour.
Also Anfragen speziell gab es keine. Wir hatten mal Kontakt mit dem Schweizer, also es gibt einen Schweizer Dachverein, der sich um alle Wanderwege kümmert. Aber die haben natürlich wiederum ihre Abmachung mit Swiss Topo. Und im Prinzip kann man da nicht viel machen. Also Swiss Topo selber ist Teil von dem Verein, das heißt
die nehmen natürlich diese Karten und es ist ja wie bei den ganzen behördlichen Daten immer etwas schwierig. Also viel Politik hat da drin. Und ich weiß nicht, wie das in Deutschland aussieht. Da kann vielleicht...
In Deutschland gibt es einen deutschen Wanderverband und die sind sehr aktiv. Die haben regionale Wandergruppen, die schildern die ganzen Wege aus und die haben die ganzen Routen auf Papierplänen.
Und die sind jetzt gerade dabei, die Routen digital zu erfassen und ein eigenes System zu entwickeln. Also ich könnte mir vorstellen, wenn du denen dein System anbietest, dann sind die froh. Dann müssen sie es nicht mehr selber entwickeln.
Noch Fragen?
Ich habe noch eine Frage. Wie ist das mit grenzübergreifenden Wanderwegen?
Also in den offenen europäischen Gebieten. Also es gibt ja Wanderwege, die durch Holland, durch Belgien und Deutschland gleichzeitig wandern. Oder die auch durch mehrere Bundesländer und so weiter gehen. Ist das ein Problem oder? Nein, nein, überhaupt nicht. Also ich betrachte das wirklich komplett global. Also die Karte
ist quer durch die Welt. Also inzwischen gibt es auch in Amerika da entsprechende Wanderwege. Also die werden halt speziell gerendert. Also wenn die Leute sie natürlich eintragen als grenzübergreifende Wanderwege. Aber ansonsten, also das ist überhaupt kein Problem, weil wirklich der komplette Planet da gerendert wird.
Okay, falls dann keine Fragen mehr sind. Nochmal herzlichen Dank für den Vortrag.