OpenTopoMap

Hm, ok. Dann war ich wohl knapp danach :smiley: Danke!

Wo kann man derartiges denn erfahren, außer hier im Forum?
Es wäre schön, wenn es sich alle Autoren von Karten mit Zeitversatz angewöhnen würden, den Stand der Dinge anzugeben. Also z.B. statt
“Kartendaten: © OpenStreetMap-Mitwirkende …”
einafach:
“Kartendaten: © OpenStreetMap-Mitwirkende, Stand 2017-11-30 …”

Und nein, dass ist kein Problem der OpenTopoMap oder von OSM …

Fände ich auch schön - vor allem, weil man nicht sicher ist, ob evtl. neues Tagging so richtig umgesetzt ist.

Unter https://opentopomap.org/about gibt es ja seit langem dem Punkt „Datenstand“ – aber da steht ebenfalls seit langem nur „Stand: ?“. Die OpenTopoMap wäre schon noch ein bisschen toller, wenn man das etwas präzisieren könnte … :wink:

Update: jetzt steht „Stand: 30.11.2017 (vielleicht)“ dran. Danke! :slight_smile:

Hui, hab jetzt erstmals den Viewpoint gesehen mit angegebener Direction. Sehr nett! :slight_smile:

Was ist den an dieser Stelle in Nordnorwegen mit dem Rendering der Opentopomap los:
https://www.opentopomap.org/#map=11/70.0925/18.8113

Und warum sind dort Höhenlinien teilweise vorhanden? Ich weiß das es für sehr nördliche Gebiete keine SRTM Daten gibt, aber von daher würde ich erwarten, das die Höhenlinien ab einem bestimmten Breitengrad einfach aufhören, aber nicht das es manchmal welche gibt und manchmal nicht.

Schöne Grüße
unixasket

Das sieht so aus wie: In den Bereichen gibt es genau Null Daten, also wird da nichts gerendert…

Zumindest hier: https://www.opentopomap.org/#map=15/69.71466/18.56462 gibt es null Daten, an den (OSM-)Daten kann es also nicht liegen.

Es liegt sicher an den Höhendaten, nicht an OSM. An den grauen Flecken steht da 0 drin (nicht -32k, was hiesse “keine Ahnung”, sondern 0, was heisst “auf Meereshöhe”), das könnte schon bei viewfinderpanoramas.org so sein oder später beim Umrechnen passiert sein. Bei 70.xN, 18.xE ist wohl eine ganze 1x1° grosse Kachel kaputtgegangen, weil… weiss nicht…

Dass es weisse Flecken gibt, finde ich nicht tragisch. Wo es keine Höhendaten gibt, gibts halt keine. Allerdings sollten die Flecken eher weiss als dunkelgrau sein. Die verlorene Kachel muss man mal suchen gehen.

Leider gibt es von dem kleinen Land mit den größten Reliefenergie der Erde (rd. 100 - 8848 m) noch keine Garmin-Edition der OpenTopoMap - ist da evtl. was zu machen?

Gruß
geow

Inzwischen wurde die DEM Struktur der Garmin Karten entschlüsselt. Somit sind nun auch freie OSM Garmin Karten mit Geländeschummerung verfügbar zB http://www.speichenkarte.de/

Ist die Integration der Geländeschummerung auch für die OpenTopoMap Garmin-Edition geplant?

Hier gäb‘s Software um die DEM Schummerung zu erzeugen:
https://github.com/FSofTlpz/Garmin-DEM-Build

Diese Angabe darf aktualisiert werden – Ihr habt offenbar klammheimlich :wink: neue Daten eingespielt. Vielen Dank dafür! :slight_smile:

Stimmt, danke für den Hinweis. Der Datenstand ist nun der 29.03.2018. Da die vollständige Datenbank nicht mehr auf unsere SSD passt, liegen die slim-Indices nun auf den HDDs. Das ist nicht weiter schlimm, da wir diese ja sowieso nicht mehr benötigen (keine laufenden Updates mehr geplant).

Offtopic: Laufende Updates sind aus Datenbank-Betreibersicht extrem aufwändig (für Privatprojekte nahezu nicht umsetzbar). Für das Printmaps-Projekt habe ich mich auch davon verabschiedet. Das hat die DB (Europaextrakt) von 428 GB auf 130 GB geschrumpft. Auch die Importzeit hat sich mit nur noch 20 Stunden nahezu halbiert. Könntest du etwas zur resultierenden DB-Größe nach einem Planet-Import sagen? Hintergrund der Frage: Möglicherweise könnte Printmaps demnächst auch eine Planet-Datenbank bereitstellen.

Wie hattest du denn bisher deine Update gemacht? http://download.geofabrik.de/europe-updates/ oder http://planet.openstreetmap.org/replication/minute/ oder nochmal anders?

Vermutlich können die OTM-Kollegen die Ausgangsfrage zur DB-Größe gar nicht beantworten, denn die Slim-Indizes existieren ja noch. Heißt für mich, dass die drop-Option (noch?) beim DB-Import gar nicht verwendet wird. Der Verzicht auf die regelmäßigen Updates dürfte auch eher fachliche als technische Gründe haben.

@mmd: Ich hatte die täglichen Updates der geofabrik verwendet. Die Laufzeit auf einem HDD-basierten Server betrug so um die 10 Stunden. Für eine weitere Diskussion schlage ich einen eigenen Thread vor.

Das hat “damals” - als ich die Diffs der alten Printmaps noch “betreut” hatte, daran gelegen, dass die regulären Diffs für der ganzen Planeten verwendet wurden. Die nehmen alles rein, auch was ausserhalb des “Wunschgebietes” liegt - also auch die neueste Hütte in Papua Neuguinea.

Inzwischen gibt es allerdings bei der GeoFabrik geclippte Diffs, die z.B. für Europa nur die notwendigen Daten enthalten. Dadurch hält sich die DB in der übliche Größe, da ja im Prinzip die selben Daten drinstehen, die ein Import erzeugen würde. Nur halt sehr zeitnah :wink:

Gruss
walter

btw: nun weiss ich zumindest endlich, wieso du auf meine Vorschläge bzglich Diffs für die neue Printmaps nicht oder nur knapp ablehnend geantwortet hast.

Mit folgendem Befehl wurde die Datenbank importiert, nachdem der Tablespace “hdd” zuvor auf eine HDD gelegt wurde:

osm2pgsql --slim -d gis -C 12000 --tablespace-slim-data hdd --tablespace-slim-index hdd --number-processes 10 --flat-nodes /mnt/database/flat-nodes/gis-flat-nodes.bin --style ~/OpenTopoMap/mapnik/osm2pgsql/opentopomap.style ~/data/planet-latest.osm.pbf

Dadurch liegen nur noch ca. 280 GB auf der SDD, die Slim-Indices auf der HDD benötigen dafür 340 GB! Mit dem Parameter “drop” (und Slim-Index-Tablespace unverändert auf SDD) bricht der Import ab. Das lässt darauf schließen, dass die Indices erst vollständig angelegt werden müssen, um dann wieder gelöscht zu werden. Weil HDD-Platz nicht Mangelware ist, haben wir bisher auf “drop” verzichtet.

Natürlich würden wir gerne laufende Updates einspielen! Wir können es aber nicht mehr. Für mich ist das halb so schlimm - allerdings bekomme ich ständig E-Mail-Nachfragen, wann denn endlich wieder aktualisiert wird… :confused:

Das Problem hab ich noch nicht richtig verstanden. Warum könnt ihr das nicht?

Und warum überhaupt die Slims erzeugen, wenn ihr die eh nicht verwenden wollt?

Macht entweder einen Import ohne Slim - dann müsst ihr den nur immer wieder machen. Der dauert beim Full-Planet allerdings Tage und zu der Zeit ist die DB offline.

Oder ihr macht einen Differential Update, dafür braucht ihr aber den Platz für die Slim-Files. Meiner Erfahrung nach könnt ihr den allerdings vergessen wenn die Slim-Files auf HDD liegen.

ym2c
walter