Bei vielen Communities wird als Hintergrund für die Karten, wie ffmap oder meshviewer, das Angebot von Mapquest genutzt. Diese beenden zum 11.7.2016 den freien Zugriff. Dass heißt, man muss bis dahin auf andere freie Anbieter wechseln oder ein für wenige Zugriffe kostenloses Paket bei Thunderforest[2], Mapquest[3], Mapbox[4] usw. umsteigen.
Es ist ohne weiteres möglich, OpenStreetMap zu nutzen. Jedoch sollte man einen Tilecache aufsetzen um den Traffic des OSM-Projekts zu schonen, was mit nginx trivial von statten geht. Man hat dann einen nginx z.B. auf tiles.freifunk-musterstadt.de laufen, der bei Anfragen schaut ob er das Tile in den letzten 7 Tagen schon einmal heruntergeladen hat, und gibt dann entweder die lokale Kopie aus, oder lädt die vom Upstream herunter.
Die Cache-Hit-Rate ist durchaus beachtlich. Gegebenenfalls macht es Sinn, den Tilecache in gewissen Maße zu zentralisieren, damit die Hit-Rate weiter steigt. Den Effekt würde ich aber eher klein einschätzen.
EDIT: DO NOT USE. Siehe die neue und optimierte Config von @Shiva unten!
# Layout der Hashtabelle für den Cache
proxy_cache_path /var/www/tilecache/osm levels=1:2:2
# 64 MB Indexstruktur, 500 MB maximale Cachegröße.
# Wenn es voll läuft, hier tweaken.
# So teuer ist Speicher heutzutage auch nicht mehr...
keys_zone=tilecache:64m max_size=500m;
upstream osm_tiles {
server a.tile.openstreetmap.org;
server b.tile.openstreetmap.org;
server c.tile.openstreetmap.org;
}
server {
# Hier IP-Adresse und Domainname des Servers einsetzen
listen <your.ip.address>:80;
server_name <your.tile.domain.com>;
location / {
# Alle Anfragen an osm.org weiterleiten
proxy_pass http://osm_tiles/;
proxy_cache tilecache;
proxy_cache_key "$scheme$host$request_uri";
# Wann die Einträge veralten. Hier müssen immer mindestens 7 Tage stehen
# (alternativ sollen die Cache-Control header beachtet werden; ist OSM policy)
proxy_cache_valid 200 302 300h;
proxy_cache_valid 404 1m;
}
}
Hat dann auch den Vorteil, dass man die Tiles dann per IPv6 oder sogar Mesh ausliefern kann
Unsere aktuelle Config wurde von @Shiva noch gepimpt, vielleicht mag der die ja mal posten, da hab ich keinen Zugriff drauf
Ich hoffe aber mal schwer, dass die FOSSGIS sich endlich mal vom FFRL helfen lässt, und noch ein paar Tileserver aufstellt…
Aber das ist atm auf Platz 1 der Todoliste den Titleservercache bei uns aufzusetzen der dann von den Nord Communitys genutzt werden kann. Scheiterte bisher noch an der Zeit.
Ich klemm mich in der nächsten Woche mal da hinter. Damit die Schmarotzerei in Aachen aufhört.
Wir haben auch mal kurz überlegt, ob wir als Proxy die IP-Adresse des Anfragenden mit entsprechendem HTTP-Header durchreichen, damit OSM identifizieren kann, dass der Proxy-Server nur Anfragen von anderen Leuten durchreicht, aber das haben wir bis jetzt gelassen. Läuft jedenfalls schon seit drei Monaten gut bei uns klopf auf Holz
Auf der Policy-Seite wird auch https://switch2osm.org/ für weitere Info empfohlen und da wird für Seiten noch nicht einmal ein Tile-Cache verlangt…
da sich deine Anwort zwar noch auf das Posting von @yayachiken bezieht antworte ich trotzdem drauf.
Meine Config zielt genau darauf ab so wenig Requests nach „hinten“ zu machen wie möglich.
Die upstream { .. } Definition beinhaltet schon ein Round-Robin für’s Backend. Dadurch, dass das da alles GEO-DNS Auflösungen sind, werden die Anfragen schon ziemlich lokal bei OSM positioniert. (was allerdings genau für ein potentielles Blocking spricht )
Trotzdem - sollte es dazu kommen - könnte man ja mal freundlich fragen, was ihnen (OSM) lieber ist… eine IP, die jeden Request nur einmal pro Woche ausführt, oder die 50-100 Einzel-Clients die jeweils dort »einprasseln« und sich mitunter nicht an Cache-Zeiten halten…
Die originären OSM Server unterstützen durchgängig kein IPv6 …
Hast du nen Überblick was so ein Cache an Serverlast produziert? Abhängig davon würde ich es entweder auf die Webseiten/Meshviewer VM packen oder dem Titleproxy ne eigene Vm gönnen.
hmm … so wirklich Last kann ich nicht belegen oder verneinen (das fällt mir halt nicht auf und läuft einfach mit )… das ist halt Nginx - den seh ich fast nie im top… zumindest nicht in diesen Setups (ich kenn da wohl auch andere Konfigurationen… die haben allerdings auch 10-15k Zugriffe pro Sekunde …) Ergo: CPU ist schon mal vernachlässigbar.
Natürlich Platten-IO … aber die 500MB da liegen ja wohl eh komplett im Pagecache vom System (die VM hat mal »grosszügige« 2GB)
Ergo: RAM ist der Key… mehr ist da immer mehr.
Und als Webserver natürlich Netzwerk als nötiges Betriebsmittel - da liegt der aktuell bei 10GB RX / 50 GB TX pro Woche - und der Server hat nicht nur den Tile-Cache, sondern auch noch den Rest der Map als weitere vHosts, also inklusive JSON etc…
Technisch ist mir das schon klar, evtl. hatte man dort inzwischen auch ein Einsehen. Wir hatten das letztes Jahr schonmal probiert und eben dann irgendwann die „unschönen“ PNGs im Browser.
Dort wurde mir erläutert, dass es kein festes Limit für Zugriffe gibt, sondern dass gesperrt wird, „wenn es Probleme gibt“.
Mir wurde dann von einem Web-Admin empfohlen, einen Custom-HTTP-User-Agent zu setzen, in dem Kontaktinformationen angegeben sind, damit man die problematische Seite vor dem Sperren kontaktieren kann, und dann ne Lösung finden kann. Meinen Vorschlag nginx $Version tile cache for $site <$admin_email> fanden die als Schema gut.
Wir nutzt aktuell HERE die kostenlose Version und ist sehr schnell bisher. Haben maxZoom von 20 wenn man das wünscht und auch eine Hybridmap - Satellit, hilft bei Koordinaten setzten.
Eigener Tiles Server ist auch eine schoene Option, aber ich fand die vielen Icons bei der Standardmap in Innenstadt etwas viel. Der groesste OSM DE Provider hat leider kein https.
Darmstadt hat auch HERE als erste Wahl in der liste. Wollte eine Alternative vorstellen/zeigen, die schnell (Übergangs-) Lösung eingebaut werden kann. Hatte nachdem von MapQuest viele Detail Tiles nicht mehr verfügbar waren nach einer alternative gesucht und alle mit https von leaflet durchprobiert. HERE war beste Kombination aus Geschwindigkeit, Design und Infos auf der Map.