OpenTopoMap

Gratulation und – herzlichen Dank! Endlich ist mein Lieblings-Rendering der OSM-Daten wieder aktuell …

Aber das Rendering (oder wie man das Erstellen der Tiles nennen soll) braucht dann immer noch eine Weile, oder? Jedenfalls sehe ich die Änderungen der letzten Tage (noch) nicht (überall), trotz Browser-Cache-Löschung … hier z.B. (Stadt in Sizilien) ist Zoomstufe 15 einigermaßen aktuell (ca. 1 Woche alt), Zoomstufe 14 und 16 dagegen (noch) auf dem Stand vor ca. 1 Monat oder so. Oder hinken die da die Geofabrik-Extrakte hinterher? Oder ist da irgendein Tiles-Cache schuld?

(Das soll keine Beschwerde sein! nur eine Nachfrage zum bessern Verständnis :))

Edit: ergänzt; Typo und Denkfehler gestrichen.

Ja, sehr gerne!

Einerseits braucht der Renderer relativ lange, um die Kacheln neu zu rendern. Dies geschieht nur, wenn jemand die Kacheln aufruft. Derjenige bekommt dann erstmal die veraltete Kachel, während der Server diese neu rendert. Im Vergleich zu den großen Renderservern (z.B. tile.osm.org) ist unsere Maschine um Größenordnungen langsamer.

Andererseits ist unser Renderer am 01.06. in den Morgenstunden ausgestiegen. (Die Inode table usage ist explodiert. Keine Ahnung, warum!). Nach einem kompletten Neustart heute Abend hat sich der Renderer an den kleinen Zoomstufen festgebissen und 60 GB RAM benötigt. (Warum ist mir auch unklar. Alle Zoomstufen kleiner 12 werden normalerweise getoucht, damit sie nie neu gerendert werden.) Jetzt läuft der Renderer wieder wie vorgesehen.

Mit einem Renderserver hat man ständig Arbeit. Wie ein kleines Kind darf man ihn nie aus den Augen lassen, sonst stellt er irgendeinen Unfug an. :open_mouth:

@derstefan:

Vielen Dank für die Erklärung! Und viel Glück mit dem Renderer, dass jetzt eine Weile alles gut geht …

Thema Multipolygone. In der Praxis zeigt sich aber dass zum Beispiel in meiner Region kaum Gelegenheitsmapper oder Anfänger aktiv sind. Wenn schon sich diese kaum an Polygonen sondern eher an Straßen und Gebäuden sowie Flurbezeichnungen versuchen. Praktisch erschweren überlagerte Polygone flüssiges verfeinern komplexer Strukturen bis hin zur Unmöglichkeit. Sofern ein regionaler Anfänger Interesse hat gebe ich diesem gerne eine umfassende Einführung und Einschulung. geocodec

Die nächsten Tage könnte der OpenTopoMap-Hauptserver längere Zeit nicht erreichbar sein. Wir führen wichtige Erweiterungsarbeiten aus. :slight_smile:

Der Garmin-Server bleibt weiter erreichbar: http://garmin.opentopomap.org

Ergänzung: Wenn alles glatt läuft, wird unser Zweitserver für Zoom 0-15 einspringen und auch das Webinterface zur Verfügung stellen.

Update: Das System wird für längere Zeit noch im Notbetrieb weiterlaufen: Ein kleinerer Server verteilt die fertig gerenderten Kacheln von Zoom 0 bis 15 und es wird nichts neu gerendert. Zoom 16 bleibt nicht verfügbar.

Die neue 1,2 TB große PCIe-SSD funktioniert zwar, dennoch kommt entweder gar nichts aus dem Renderer raus oder nur unglaublich langsam. Da meine Freizeit weiter spärlich sein wird, könnte es noch mehrere Wochen dauern, bis wieder alles rund läuft.

Hallo,

ich möchte die Entwickler, welche hier offensichtlich mitlesen, bitten zu erwägen, folgende Keys zusätzlich zu Rendern:

  1. Heide - natural=heath - Vielleicht ähnlich natural=scrub nur mit spitzen Nadelbaumsymbolen.
  2. Obstplantage - landuse=orchard
  3. Baumreihen - natural=tree_row

Außerdem sind Rückhaltebecken landuse=basin, basin=detention bzw. infiltration normalerweise nicht mit Wasser gefüllt. Vielleicht sollten sie dann auch nicht so prominent wie beispielsweise Seen, Teiche, Staubecken etc. gerendert werden. Häufig handelt es sich bei solchen “Becken” um Kulturland (Weide, Ackerland) entlang eine Baches/Grabens, welches nur bei dauerhaft sehr ergiebigen Niederschlägen gefüllt wird (Damm). Man könnte etwa die Außenlinien blau gestrichelt zeichnen.

Hallo SLÅ_NOK,

danke für die nützlichen Hinweise! Sobald der Hauptserver wieder normal läuft, werde ich deine Vorschläge umsetzen. Wegen akuten Zeitmangels wird die OpenTopoMap aber voraussichtlich noch mehrere Wochen im Notbetrieb weiterlaufen - um danach noch besser und weltweit zurückzukehren.

Das ist m.E. ein besonders wichtiger Punkt. Der Umstand, dass auch im Default-Stil von OSM (Carto) basins als Wasserflächen dargestellt werden, führt manche Mapper schon zu seltsamen Formen des Mappings bzw. Taggings für den Renderer: in Baden wird z.B. an mehreren Stellen landuse=_basin benutzt, nur um die Darstellung als Wasserfläche auszuschalten. :frowning: Insofern vielen Dank an Stefan schon für die Absicht, das in OpenTopoMap zu ändern! Dann wäre die Darstellung in OpenTopoMap in dieser Hinsicht deutlich besser als in OpenStreetMap, und ich hätte eine schöne Vergleichsdarstellung, mit der ich den badischen Mapper vielleicht dazu überreden könnte, dieses Tagging für den Renderer aufzugeben … :wink:

Gute Idee, aber ich halte das übliche Symbol für Heide für geeigneter: ähnlich einem kleinen Graspuschel, siehe auch hier z.B. https://www.lgl-bw.de/lgl-internet/web/sites/default/de/07_Produkte_und_Dienstleistungen/Galerien/Dokumente/Legende_TK50.pdf

Gruß aus Neuwied

Moin derStefan,

ich weiß, wenn man was Gutes macht, gibt es tausende, die weitere Ansprüche haben. :wink: Ich würde mich freuen, wenn auch die Andenregionen auf Deiner Karte so schön dargestellt würden, wie die Alpen. Was könnte ich zur Realierung dazu beitragen?

Da sich die Opentopomap an den amtl. Karten orientiert, ist das natürlich die bessere Signatur.

Vielen Dank. Auch für das “weltweit zurückzukehren”. Ich halte die Opentopomap für die beste aus OSM generierte Karte wegen ihrer besonderen Vorteilen in hellen Umgebungen auf Displays. Weiter so…

Dem möchte ich mich anschließen. Ich habe topografische Karten immer “viel lieber gehabt” als Straßenkarten und es, als ich bei OSM neu war, sehr bedauert, dass OSM “nur eine Straßenkarte” sei und keine topografische Karte.(*) Als ich zum ersten Mal OpenTopoMap gesehen habe, war ich begeistert …

(*) Ja ja, inzwischen weiß ich, dass OSM eine Geodatenbank ist, aus der man ganz verschiedene Karten erstellen kann! :slight_smile: Als Anfänger denkt man eben immer: Carto-Stil = OSM …

Genau. Und optimal wäre es, wenn man den Stil der OpenTopoMap als Kartenebene in die Hauptseite aufnehmen würde (und die Resourcen z.B. der “Humanitarian” dafür nutzen würde). Ich weiß: Der Erlanger Server würde für die Last nicht tragen können/wollen.

Schön, dass für meine Lieblingskarte eine weltweite Abdeckung geplant ist. Nicht nur im Zuge der Internationalität hätte ich mal folgende Bitte:

Für D ist das Kreuz als Symbol für (allgemeine) Friedhöfe aus Traditionsgründen der topographischen Karten sicher OK. Wenn die Karte aber international wird, sollte für andere Länder das Religionssymbol entweder angepasst oder neutral werden.
Bereits jetzt in D nicht passend: der jüdische Friedhof in Obernau, in Mapnik richtig dargestellt.
cepesko

Konsequenterweise müssten dann auch die Religion-Tags von historic=wayside_shrine, welche auch mit einem Kreuz symbolisiert werden, ausgewertet und entsprechend gerendert werden. Es gibt ja auch Hinduschreine …

Wenn auf dem gesamten indischen Subkontinent etwa 20 wayside_shines erfasst sind und davon wiederum 3 denomination=catholic aufweisen, sind wayside_shrines sicher zunächst ein marginales Problem. Aber die Fläche eines Friedhofs in Ankara oder Tel Aviv mit Kreuzen darzustellen, könnte mindestens einige Verwirrung stiften und der Akzeptanz der Karte abträglich sein, ganz abgesehen vom faktischen Fehler.

Wie bereits gesagt, zur europäischen (Topokarten-)Tradition gehört die verwendete Darstellung mit den Kreuzen auf jeden Fall, sofern nicht explizit eine andere Religion getaggt ist (wie in meinem gezeigten Beispiel).

Ein Render-Regel-Vorschlag wäre: Die vorherrschende Religion in einem Land/Kontinent sollte das Friedhofssymbol definieren, sofern nicht ein besonderes ‘religion’ oder ‘denomination’ getaggt ist.

cepesko

Das fände ich natürlich auch phantastisch. So würde dieser hervorragende Kartenstil auch angemessen gewürdigt.