Portale wandern zu OSM?

EHm sagt mal wollt ihr ROuting-Probleme nicht mal in einem eigenen Thread diskutieren? :slight_smile: Das findet doch sonst keiner mehr bei dem Titel.

Bei OSM kann man nicht von generell schlecht oder unschlagbar gut sprechen.
Die Erfassungsqualität unterscheidet sich nun mal stark von Gebiet zu Gebiet.
Ich gehöre zu denen, die bereits so manche weiße Fläche gefüllt haben. … und dann als “Dank” tatsächlich eine “Meckermail” bekamen.

DAS Routing mit OSM scheint es nicht zu geben. Sonst würden die Tests ja nicht unterschiedlich ausfallen.
Für mich sieht es so aus, als hätten verschiedene Teams oder Einzelkämpfer eine mehr oder weniger gute Routingsoftware aufgesetzt, die in der Lage ist, OSM-Daten zu interpretieren.
Die Vergleiche zeigen, daß für die Qualität der Routingsoftware zwei Komponenten zusammenspielen:

  1. Die Karte
    In ihr müssen die Daten so hinterlegt sein, daß sie von einer Routingsoftware sinnvoll interpretiert werden kann. Diese Kartendaten unterliegen bei OSM einem permanenten Wandel. Das birgt sowohl positives wie auch negatives Potential. In anderen Karten sind die Daten wesentlich statischer. Auch das hat Vor- und Nachteile. OSM-Befürworter sehen den großen Vorteil in OSM vor allem in der Möglichkeit, daß die Daten von jedermann sofort korrigiert werden können. Es ist allerdings auch zu beobachten, daß es auch viele Nutzer gibt, die fleißig irgendwo “Kekse” eintragen, die “ewig” vor sich hin trocknen.

  2. Die Routingsoftware
    Unter welchen Voraussetzungen es für ein Routenportal, das eine große Routensammlung organisiert und präsentiert, auch noch möglich sein könnte, einen den Bedürfnissen seiner Nutzern angepaßte Navisoftware selbst zu entwickeln, kann ich nicht beurteilen. Ich gehe mal davon aus, daß die Navisoftware “zugekauft” (egal in welcher Form) werden muß. Fragt sich dann, welche. Denn wie schon festgestellt: DIE OSM-Routingsoftware gibt es nicht.

Wenn jemand ein Portal mit Karten aufzieht, gibt es also auch bei der Nutzung von OSM eine Menge abzuwägen.

Für OSM geworben wurde und wird vor allem durch Portale, die eine auf OSM-Daten basierende Karte nicht nur anzeigen, sondern auch Möglichkeiten bieten, diese aktiv zu nutzen. Lücken in der Karte wurden und werden dadurch kompensiert, daß man auf Satellitenbilder umschalten kann. Kartenfenster mit dieser Konstellation sind in ganz unterschiedlichen Angeboten verbreitet. Der Hinweis: Hey, Du kannst die Karte vervollständigen, wenn Du einen Track aufzeichnest und in wenigen Tagen sieht sie wieder ein Stück besser aus, war und ist für viele eine große Motivation bei OSM aktiv mitzumachen. Ohne diese Routenportale oder Trainingssoftware oder …, die OSM-Karten in ihr Angebot einbeziehen, wären diese Mapper nie geworben worden.

Wenn nun jeder, der OSM-Mapnik in so ein umschaltbares Kartenfenster (ohne Downloadmöglichkeit!) integriert, aufgefordert wird, seinen eigenen Kartenserver aufzusetzen, könnte das bedeuten, daß der Aufwand für so manchen Anbieter zu hoch ist und OSM dann halt eben rausfliegt. Denn welche Karten man in sein Portal bzw. auf seiner Webseite einbindet, ist wie eigentlich immer im Leben eine Kosten-/Nutzen-Frage. Und zu den Kosten zählen auch Zeitaufwand, Entwicklerpower, Infrastruktur …

In einem Routenportal eine Autoroutingfunktion anzubieten ist eine ganz andere Geschichte.
Da braucht’s Knowhow, Geld oder einen Sponsor.

Ich lernte GPSies zu einer Zeit kennen, in der die Seite völlig werbefrei war und ein dezenter Spendenbutton Geld für die Bereitstellung der hinter der Seite stehenden Infrastruktur einwarb. Das ging sich aber offensichtlich nicht wie gewünscht aus. So entschied sich der Macher irgendwann dann doch dafür, Werbung einzubauen. An verschiedenen Stellen sind Hinweise zu lesen, daß die Seite als Hobbyprojekt entstand und auch immer noch so geführt wird. Im Blog findet man in unterschiedlichen Zeitabständen Berichte über Neuerungen auf der Seite. Ich bin gespannt, was dort als nächstes zu lesen sein wird.

Ich bin dafür, daß bei Massendownloadern die Bremse gezogen wird.
Die Anwendungen der Routenportale und deren Auswirkungen auf die OSM-Server müßte mal sachlich/statistisch unter die Lupe genommen werden, damit man sieht, welche Belastung diese Portale für OSM-Server tatsächlich darstellen.

Gruß
tippeltappel

Hallo,

um einige Geheimnisse um GPSies.com zu lüften, will ich hier mal die Gelegenheit nutzen, direkt zu antworten :wink:

Ja, GPSies.com ist noch ein Hobby. Ich bin völlig alleine und arbeite tagsüber in einer Internet Agentur in Berlin Mitte (hat nichts mit GPSies zu tun). Nachts und am Wochenende arbeite ich an GPSies. Meine Frau und meine beiden Kinder haben großes Verständnis für mein Hobby. Daneben bin ich noch ein begeisterter Läufer.

Die Werbung finanziert meine 4 Server. Ich muss mir in den nächsten Tagen 2-3 neue Server mit je 48 GB RAM besorgen. Ratet mal für was :slight_smile: - ja, GPSies wird eigene OSM Kartentiles rendern.

Der Entschluss, Google zu verlassen, kommt natürlich aufgrund der neuen Lizenzbestimmungen. Wenn ich so weiter machen würde, müsste ich 3.000 Dollar im Monat an Google bezahlen, das kann ich natürlich nicht. GPSies kann und will auch nicht von den Benutzern Geld verlangen, das geht nicht. Spenden kommen zwar ab und zu rein, aber das reicht auch nicht.

Ein weiterer Grund für die OSM Karten ist, dass die GPSies+ iPhone App (nicht die Webkarten!) so viel Traffic erzeugt: http://www.openstreetmap.org/user/!i!/diary/15190

OSM hatte mich deshalb angeschrieben und mir auch eine Frist gesetzt. Da ich nicht mal so von heute auf morgen die 2-3 Kartenserver aufsetzen kann, habe ich Geld an OSM gespendet und hoffe damit, dass ich noch ein paar Wochen Zeit habe. GPSies ist übrigens ein sehr großer Unterstützer des OSM Projekts, das sollte man auch nicht vergessen: http://www.openstreetmap.org/stats/data_stats.html

Als neue Javascript API werde ich NICHT OpenLayers benutzen. Ich gehe das Risiko ein und werde die neue Javascript API von CloudMade benutzen: http://leaflet.cloudmade.com/

Zur Zeit arbeite ich also gerade mit Hochdruck an der Ablösung der Google Karten und an den neuen Kartenservern. Falls es jemanden interessiert, unter jeder Karte bei GPSies findet ihr ein grünes Blatt mit dem Schriftzug “Leaflet”. Das ist zur Zeit meine “Spielwiese”.

Wer will, kann sich gerne in die neuen GPSies-Karten-Styles einbringen. Ich werde auf jeden Fall auch Höhenprofile als weiteren Layer rendern lassen. Zur Zeit gefällt mir eine Mischung von OpenCycleMap und HikeBikeMap. Ich möchte auch gerne Wanderwege mit dabei haben. Hat jemand mit den Styles und der Streckenklassifizierung Erfahrung und kennt sich jemand damit aus? Das würde mir enorm helfen! Kontakt entweder hier oder per PM. Merci!

Ich bin mittlerweile gar nicht mehr so traurig, dass sich die großen Strecken Communities von Google trennen müssen. Für OSM wird das ein Wahnsinnsschub sein. Darauf freue ich mich besonders!

Wenn Google umstellt, dann werden die Server von OSM Anfang des Jahres 2012 schwer erreichbar sein. Wer da keinen eigenen TileServer hat, der hat verlosren. OSM wird wahrscheinlich auch restriktiver mit der Serverlast und dem Traffic umgehen müssen. Aber auch das wird sich selbst regulieren und in einem Jahr hat OSM mehr Verbreitung denn je. Ich freue mich darauf!

Das Routing von GPSies läuft noch komplett auf Google. Das wird dann auch nächstes Jahr umgestellt werden. Das kann noch einige Zeit mit Google weiterlaufen, weil ich mit dem Streckeneditor nicht über 25.000 Abrufe am Tag komme. Ich muss also zuerst die Pflicht machen, dann kommt die Kür :slight_smile:

Viele Grüße aus Berlin!

Klaus, GPSies.com

Na dann erstmal herzlich willkommen im Forum der verrückten Datensammler.

Chris

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