Portale wandern zu OSM?

Hallo Klaus!
Freut mich sehr, hier von Dir zu lesen!

Ob mein Wissen um Wanderrouten für Deine Bedürfnisse reicht, weiß ich nicht. Da ich aber mit Nops Composer von Zeit zu Zeit experimentiere und mir neben Reitwegen auch die Darstellung der Wanderwege sehr wichtig ist, hab ich mich damit etwas beschäftigt. Mach einfach einen entsprechenden Thread auf, wenn Du das Thema anpackst. Es gibt hier sicherlich mehrere Leute, die sich mit dem Thema Wanderrouten mit unterschiedlicher Sichtweise auseinander setzen.

Im OSM-Wiki gibt es verschiedene Seiten, die ebenfalls verschiedene Aspekte dieser Thematik verfolgen. Das Thema ist ziemlich komplex, da die Wanderwegnetze in den verschiedenen europäischen Ländern auf verschiedene Weise geordnet und markiert werden. Doch damit nicht genug. In Deutschland ist die Markierung der Wanderwege besonders vielfältig. Regionale und überregionale Wandervereinigungen entwickelten im Laufe vieler Jahre ganz unterschiedliche Zeichnungssysteme, die zumindest teilweise bereits im OSM-Wiki dokumentiert werden. Dazu kommen dann noch die Tourismusverbände, die in attraktiven Wandergebieten neue Routenkonzepte entwickelt und ausgezeichnet haben.

Um diese Vielfalt in OSM in den Griff zu bekommen, klassifiziert man die Wege beim Anlegen einer Routenrelation ihrer Reichweite entsprechend. (örtliches, regionales, nationales, europäisches … Wegenetz bzw. Fernwegenetz) Darüber hinaus gibt es dann noch die Möglichkeit, zwischen Wanderrouten und Pilgerrouten zu unterscheiden. In manchen Gegenden gibt es auch ausgewiesene Reitrouten. Die Fahrradrouten, Radwanderrouten, Mountainbikerouten und Radwegenetze können sich mit Wanderrouten überlagern, sind aber prinzipiell ein eigenes Wegenetz.
Das ruft geradezu nach unterschiedlichen Routenlayern.

Cool wäre natürlich, diese verschiedenen Wegenetze dergestalt rootbar zu machen, daß z.B. Wanderwege beim Wanderrouting oberste Priorität haben und der Rest des Wegenetzes mit einem den Bedürfnissen von Wanderern gerecht werdendem Gewichtungssystem untergeordnet wird.
Leider habe ich vom Erstellen einer Routingsoftware nicht den blassesten Schimmer. Aber wenn Du mal Leute brauchst, um so etwas zu testen, bin ich mit den mir zur Verfügung stehenden Mitteln dabei.

Wiki-Linksammlung zum Thema
http://wiki.openstreetmap.org/wiki/Wanderwege
http://wiki.openstreetmap.org/wiki/Category:Walking
http://wiki.openstreetmap.org/wiki/Category:Hiking
http://wiki.openstreetmap.org/wiki/Bike_routes
http://wiki.openstreetmap.org/wiki/Category:Cycle_routes

Viele Grüße aus dem Rheinland :slight_smile:
tippeltappel

openrouteservice kann das zumindest für Radrouten. Meiner Meinung nach funktioniert das auch relativ gut.
(Fahrradrouting, Option “prefered Cycleway/-route Beta”)

Viel Erfolg!

+1

Super!

Hallo Tippeltappel,

danke für deine ausführliche Mail! Ich merke, dass das ein Riesenfass ist, was ich da gerade aufmache.

Ich will ganz offen sein, denn ich habe ganz wenig Zeit, das alles in den nächsten Tagen hinzu bekommen (ich weiß auch nicht, ob das alles noch zu diesem Thread passt).

Gerade bin ich mit Providern im Gespräch, um neue 2-3 Server zu beauftragen (“Für einen Live-Server mit komplett Welt-Abdeckung wird ein Server mit 8 CPU-Kernen und mindestens 48 GB RAM empfohlen.”). Ich denke, dass ich 2-3 Server davon bestelle. Ich habe keine Ahnung, was den Plattenplatz betrifft. Reichen da 1 TB pro Server? Als Traffic rechne ich erst mal mit 2 TB / Monat (wird in den ersten Wochen nur für Zugriffe aus GPSies.com geöffnet, muss erst mal Erfahrungswerte sammeln).

Was die Layer betrifft, finde ich deine Idee mit den einzelnen Layern super. Da stelle ich mir vor, erst mal nur einen Layer ala OpenCycleMap (nur die Radwege) einzubinden. Nachträglich können dann noch weitere Layer, wie Wanderwege gerendert werden.

Auch die Höhenlinien sollen wie bei der der Wanderreitkarte (http://www.wanderreitkarte.de/) als SRTM3 Layer mit Höhenlinien gerendert werden (nur die Schattierung ein bisschen dezenter).

Als Kartengrundlage gefällt mir http://hikebikemap.de/ am besten, denn diese sind dezent und sehr gut lesbar (da kann ich gut die Strecken und Icons auf die Karte bringen).

Heute Abend treffe ich mich mit meinem Admin und wir werden die Serverarchitektur besprechen. Ich habe einen Provider aus Berlin gefunden (auch ein Läufer :slight_smile: ), der mir bei ein Angebot macht. Dann geht es los. Ich lade jeden ein, mir mit Tipps oder konkreten Styles zu helfen. Ich kann mich leider nur zu 30% um dieses Thema kümmern, da ich parallel das ganze Javascript von GPSies umbauen muss (Google fliegt raus).

Danke im Voraus!

Viele Grüße aus Berlin!

Klaus, GPSies.com

Gibts alles schon:
http://wiki.openstreetmap.org/wiki/User:Ajoessen/myMapnik
Nur hab ich keine leistungsstarken Server, und will selber sowas auch nicht anbieten.

Gruß,
ajoessen

Hallo Ajoessen,

danke für deine tolle Dokumentationen und Erfahrungen! Darüber bin ich auch schon gestolpert und hatte mir schon einen Bookmark gesetzt. Ich werde von meinen Erfahrungen berichten und dich gerne bei Fragen fragen dürfen :wink:

Merci!

Viele Grüße aus Berlin!

Klaus, GPSies.com

Darfst du :wink:

Gruß,
ajoessen

Hallo Klaus,

vielen Dank für die Informationen. Hört sich alles sehr gut an. Ich will Dich von nichts abhalten, nur eine Info: Google erlaubt das Darstellen von Resultaten des Google-Geocoders nur auf Google Karten. Das wird vermutlich beim Routing ähnlich sein. Daher könnte es vielleicht Probleme geben, wenn Du Google-Routing auf OSM Karten darstellst. Wie gesagt, ist nur ein Tipp, mir persönlich ist es egal

Sind die 2-3 Server nur fuer OSM-tileserver gedacht? Mit wieviel traffic wird so im Durchschnitt gerechnet?

Sollte das “nur” fuer OSM-tileserver benoetigt werden wuerde ich vermuten das das etwas ueber diminsioniert ist.

OSM z.B. hat fuer das Rendering nur einen einzigen Server ( die Specs findet man unter http://wiki.openstreetmap.org/wiki/Servers/yevaud ) und kommt damit zur Zeit fast locker aus. Es sind zwar noch zwei reverse Proxy Server davor geschaltet ( http://wiki.openstreetmap.org/wiki/Servers/konqi http://wiki.openstreetmap.org/wiki/Servers/albi ), die werden aber zum Teil eher gebraucht da der Bottleneck die 100 mbit/s Netzwerkanbindung die der rendering Server hat als das die Hardware des Servers nicht ausreicht.

Es macht moeglicherweise also Sinn erst einmal mit einem Server zu beginnen und zu sehen ob der ausreicht und dann je nach dem wo der Bottleneck ist dann entsprechend aufzuruesten.

Ich halte auch die Angaben fuer etwas hochgegriffen (wobei wenn man es sich leisten kann die 48Gb sicherlich hilfreich sind). Je nach dem kann man wohl auch mit 24Gb Ram auskommen. OpenCycleMap wurde z.B. auf einem Server mit 24Gb betrieben (weis nicht ob das immer noch der Fall ist). Vielleicht der groesste Vorteil ist wenn man sich leisten kann die postgres datenbank auf eine SSD zu packen.

Speicherplatzmaessig benoetigt die ganze Welt fuer die Datenbank ca. 300 - 400Gb. Fuer die Tiles ist es recht schwer abzuschaetzen. Je nach dem wieviel Speicherplatz man hat werden eben mehr oder weniger tiles gecached. Ich wuerde mal grob schaetzen das die Hitrate des caches sich nicht mehr gross aendert ab einer Groesse von ca. 600 Gb, moeglicherweise sogar eher darunter. Aber das sind nur sehr grobe schaetzwerte.

Je nachdem was fuer einen Kartenstil man verwendet, koennen sich die Anforderung etwas aendern. Ein Kartenstil z.B. ist aufwaendiger zu berechnen und zu speichern als z.B. der default Stile auf osm.org

Hallo amm,

danke für die wertvollen Hinweise! So langsam bekomme ich ein Bild. Nebenbei habe ich schon mit einigen anderen gemailt und es wird langsam klarer. Es scheint tatsächlich auf weniger RAM, aber dafür auf eine größere SSD für die Datenbank hinzudeuten, das habe ich jetzt auch schon von einer anderen Stelle gehört. Ich werde gleich mal Andy von OpenCycleMap fragen, welche Erfahrung er gemacht hat.

GPSies läuft derzeit auf 3 Servern (plus ein Backupserver) und hat im Sommer ca. 25-30 tausend Besucher mit ca. 150.000 Seitenaufrufen (Karten) pro Tag. Wenn man annimmt, dass auch mal die Karte bewegt wird, dann kommt schon einiges an Traffic zusammen. Leider wächst GPSies jedes Jahr um 25% :wink:

Wahrscheinlich wird es nur einen einzigen Tilesserver geben, der nicht anderes macht, als diese Tiles zu rendern. Die Tiles werden dann nach außen von anderen Server ausgeliefert. So, das klingt ja schon mal gut.

Vielen Dank!

Viele Grüße aus Berlin!

Klaus, GPSies.com

Wenn ich die Ressourcen hätte würde ich Postgresql/PostGIS auf einen DB-Server und das Rendern/Web auf einen anderen Server legen.
Die kannst du dann jeweils getrennt skalieren. (*)
Und nach Bedarf 'nen weiteren Renderer “einfach” dazupacken.

Gruss
Walter

*) DB-Server viel Memory/SSD/Raid - Renderer viele CPUs

Hallo Klaus

Denke an den alten Spruch Hauptspeicher ist durch nichts zu ersetzen
außer durch mehr Hauptspeicher
Solange noch mehr Speicher in deine Server passen, behältst du diese Option ja.

Neben der SSD für die Datenbank, kannst du auch über eine SSD für den Swap nachdenken. Das hilft zwar nur der allgemeinen System-Performance, aber gerade wenn irgendwann der Hauptspeicher mal eng wird, ist der Swap der Engpass.

Eventuell reicht es auch aus, statt der ganzen Datenbank nur die Index-Tabellen auf eine SSD auszulagern. Auf die wird ja eigentlich immer zugegriffen.

Edbert (EvanE)

Ich bin mir nicht sicher ob das die Ideale Loesung ist. Das rendering benoetigt (abgesehen von den DB zugriffen) hauptsaechlich CPU leistung, jedoch kein disk I/O und nur relativ wenig RAM. Der Datenbank Zugriff hingegen benoetigt verhaeltnissmaessig wenig CPU, aber jede menge RAM und noch mehr IO-performance. Insofern koennen die beiden Prozesse relativ gut auf dem gleichen Server laufen. Abgesehen davon verliert man moeglicherweise wohl eine Menge Performance, da die Latency zwischen Renderer und DB deutlich ansteigt wenn es ueber das Netz laeuft und selbst bandwidth wird wohl zum Teil zu einem Problem da relative grosse Mengen an Daten zwischen Mapnik und Postgres ausgetauscht werden.

Wenn man tatsaechlich nicht mehr genug CPU Leistung fuer das rendering hat, kann man schon auf verteiltes Rendering umsteigen. Dafuer hatte ich mal vor einer Weile den Code geschrieben. Aber ich weis nicht ob der noch funktioniert und wie weit es Sinnvoll ist, denn er wurde nie eingesetzt da er nicht gebraucht wurde.

Wahrscheinlich geschickter ist eine Trennung von Rendering zu Auslieferung. Das reine Serving der Tiles benoetigt auch nicht zu vernachlaessingde IO-last wenn man viele gleichzeitigen Zugriffe hat (hunderte tiles/sekunde). Jede Ausgelieferte Kachel verursacht moeglicherweise einen zufaellig verstraeuten Festplattenzugriff. Hier hilft mehr Ram fuer Disk caching auch.

Das will GPSies_com ja machen.
Die Menge an Tiles, die angefordert werden, kann er ja selbst bestimmen, da seine Webseite wohl die einzige ist, die Tiles anfordern wird.

Wenn ich mich recht erinnere, ist z.B. Openlayers so eingestellt, dass es zwei Reihen Tiles an jeder Seite mehr anfordert, als es für den aktuellen Bildausschnitt notwendig ist. Das erfolgt, damit ein Verschieben des Kartenausschnittes möglichst flüssig geht. Ich vermute, dass es bei Leaflet ähnlich eingestellt ist. Das könnte man auf eine Reihe je Seite reduzieren, so dass ohne Verschieben weniger (dann nicht notwendige) Tiles angefordert werden.

Es ist natürlich eine Frage, wieviel das ausmacht, also ob dadurch das Laden eines Ausschnitts spürbar schneller geht. Auf der anderen Seite steht die Frage, wie stark davon das Verschieben, vor allem in hohen Zoom-Leveln, langsamer wird.

Edbert (EvanE)

Da er eh mehrere Server einsetzten will, schlage ich dennoch die klassische Trennung zwischen DB-Server und Application-Server vor.
Ansonsten müsste er ja die ganze Kette (DB, Renderer und Webserver) jeweils komplett auf allen Servern installieren.

Gruss
Walter

der Datentransfer zwischen Anwendung und DB ist nicht so riesig, wie man auf den ersten Blick meint:
die Anwendung schickt Queries, der DB-Server malocht und schickt dann die Ergebnisse zurück - that’s all.

Hallo,

vielen Dank für eure Hilfe! Gestern Abend habe ich mich mit dem GPSies-Admin getroffen und wir werden die nächsten Tage einen Termin beim Hoster machen. Ich werde die Hardware Konfiguration und die Architektur hier mal posten (sobald alles fertig geplant ist).

Viele Grüße aus Berlin!

Klaus, GPSies.com

Dazu gehört IMHO vor allem ein konsistentes Tagging, was derzeit wohl nicht der Fall ist. Das Motto ‘jeder kann machen, was er will’ oder die Mehrdeutigkeit im Wiki sind da nicht unbedingt hilfreich.

@ Klaus / GPSies

Der normale Mapnik Style hat durchaus seine Vorzüge gegenüber der “Radfahrkarte” (auf openstreetmap.org), man kann nämlich unter anderem die verschiedenen Typen von Wirtschaftswegen/Forstwegen (highway=track) auf den ersten Blick unterscheiden. Bei der Radfahrkarte werden mehrere "tracktype=grade’x’ "gleich dargestellt und so geht mir als Radfahrer ein großteil der Infos über den Wegzustand gleich flöten. Denn anhand des tracktype kann man schonmal eher abschätzen ob man nicht doch besser die eine (asphaltiert, gut geschottert) statt der anderen Route (schlecht ausgebaut) nimmt. Es hat auch Jahre gedauert bis auf der Radfahrkarte mal highway=path angezeigt wurde. Deswegen verzeiht mir den Ausdruck, aber die Radfahrerkarte ist in der Beziehung einfach Mist und ich verwende zu 95% die standard mapnik Karte.

Wenn du schon ‘selbst’ renderst, dann mach bitte nicht so einen Blödsinn nach. :wink:

Was ich bei der http://hikebikemap.de/ nicht vertsehen kann ist wie man auf die Idee kommt Wiese dunkler zu rendern als Wald, irritierender geht ja nicht mehr.

Naja, viel ist auch Gewöhnungssache. Mir gefällt allerdings auch der Mapnik Standardstyle am besten.

Wie funktioniert das eigentlich bei Cloudmade mit den tausenden von Styles, wird das alles on-the-fly
gerendert?

Chris

snip - vertan