OpenTopoMap

Bin kein Experte für die OpenTopoMap, aber vielleicht hilft es:

Wenn ich das richtig sehe, hat die OpenTopoMap immer noch keine DEM Daten, die werden für die Schattierung gebraucht.

Wenn Höhenlinien vorhanden sind, dann sollte Basecamp zumindest ein Höhenprofil daraus berechnen können. Wo genau vermisst Du die Höheninformationen? In einer Route werden nur die Wegpunkte abgespeichert. Ich habe es nicht mit der Karte für D ausprobiert, aber bei den kleineren (z.B. Estonia) sind m.E. in der *.exe KEINE Contourdaten. Falls Du dein GPS per USB angestöpselt hast, liest Basecamp die Daten aber evtl. von dort. In den Downloads “PC” und “Garmin” sind die Contourdaten drin.

Ja, ist aber eigentlich nicht sinnvoll, zumindest nicht für das GPS. Die Höhenlinien ändern sich nur alle paar Jahre, braucht man also nicht jedesmal mit zu kopieren. Man kann mit GMapTool eine gmapsupp.img in ihre Einzelteile zerlegen und mit mkgmap die Einzelteile zu einer neuen gmmapsupp zusammenkleben. Einzelheiten bei Bedarf.
http://www.gmaptool.eu/en/content/gmaptool
http://www.mkgmap.org.uk/
http://www.javawa.nl/anderstalig.html

Edit: Siehe auch https://opentopomap.org/about#faq

Hallo,

Mir ist aufgefallen, das dieser path in OTM nur als praktisch unsichtbare, graue Linie angezeigt wird. Woran liegt das? Der geringen eingetragenen Breite des Weges? Den beiden im Konflikt liegenden eingetragenen sac_scale-tags? (Das ist ja auch ein tagging-Fehler und sollte nicht so verwendet werden?) Oder soll das so sein?

Das hier spricht, wenn ich es richtig deute, ja dafür, dass width keinen Einfluss auf die Darstellung eines path hat, oder?

Danke aufjedenfall für euer großartiges Projekt!

Das nehme ich stark an.

Nein, das ist ein Fehler. Ein Weg kann nicht zu zwei Schwierigkeitsgraden gleichzeitig gehören. Reduzier das mal auf den höheren.

–ks

Ja, width=* ist für die Darstellung von Fusswegen egal, trail_visibility=* und sac_scale=* und via_ferrata_scale=* hätten Einfluss. Was man da sieht, ist die “Grundierung” des Weges, danach werden je nach sac_scale noch Pünktchen auf die Linie draufgemalt. Weil der Renderer den Wert von sac_scale nicht kennt, fehlen die Pünktchen. An fehlende sac_scales wurde natürlich gedacht, an unbekannte Werte nicht…

Das ergibt Sinn!

Ich werde es nach Erkundung auf T1 setzen, imo hat er nirgends T2. “Etwas steinig” (nicht verblockt oder ähliches) im westlichen Aufstieg sollte kein T2 rechtfertigen. Im Mittelgebirge wäre ein T1+ oder T2- teils nützlich, die tags größer T2 werden dort – zumindest im Schwarzwald – teils sehr frei verwendet.

Hallo,

am Sonntag war die OpenTopoMap für einige Stunden offline. Grund sind zwei ausgefallene Lüfter, wodurch der Server sich automatisch heruntergefahren hat. Das Regionale Rechenzentrum Erlangen (RRZE) hat die Lüfter am Montag getauscht - vielen Dank.

Übrigens haben wir über 120.000 Nutzer täglich. Würde jeder Nutzer nur 1 Cent zahlen, könnten wir einen Vollzeitentwickler einstellen - nur mal so am Rande. Dafür, dass quasi nur Max (maxbe) und ich alle paar Wochen etwas machen, läuft der Server ziemlich gut. Auf Mails kann ich übrigens aus Zeitgründen nur selten antworten - die Prioritäten im Leben haben sich halt stark verändert.

Gruß
Stefan

Hallo,

in erster Linie vielen, vielen Dank für Eure tolle Karte und das damit verbundene Engagement!

Leider habe ich nach wie vor Probleme mit der DACH-Ausgabe: Bisher war es so, daß 7zip zwar entzippte, aber Fehler meldete und die enthaltenen Dateien “uralt” waren.

Heute rödelte 7zip nach dem Entzip-Start “stundenlang” ergebnislos solange rum, bis man auf “Abbrechen” klickte.

Der Windows-eigene Entzipper fand in der über 2 GB großen Datei erst gar keinen Inhalt:


Ich kann es zwar nicht ausschließen, glaube aber wg. sonstiger problemloser Entzip-Funktionalität eher nicht, daß es an meinem PC (W7/64 pro) liegt …

Es wäre wirklich klasse, wenn Ihr der Sache mal nachgehen könntet - aber vielleicht weiß auch ein anderer der hier mitlesenden Cracks Rat.

Hofft und dankt für Hilfe im voraus

tracker51

Hallo,

über die URL “https://{a-c}.tile.opentopomap.org/{z}/{x}/{y}.png” kann man ja die einzelnen Kacheln beziehen und sich selbst zu einer entsprechenden Karte zusammenbasteln. Wenn ich Kacheln aus Russland oder Japan lade, sind auch die Beschriftungen in der jeweiligen Landessprache. Das ist nett, aber kann ich das irgendwie beeinflussen? Das alle Texte beispielweise in der englischen Version sind?

Danke!

Sorry, nein.

Eine Beschriftung in der Wunschsprache des Nutzers wäre sicher wünschenswert, (oder sogar wie bei Google Maps: Eine zielgruppenorientierte Grenzziehung). Das wäre aber auch viel Arbeit an der Forschung und Umsetzung. Interessantes Thema, könnte mal jemand machen :wink:

Grüße
Max

Solange man beim Rendern Text und Sonstiges zusammen lässt, geht da nicht viel …
Bissele was geht, wie man im Vergleich osm.org / osm.de sieht.
Aber selbst, wenn mehr ginge, stünde man vor Problemen …
Mal angenommen, den Namen einer beliebigen chinesischen Stadt ㄨ gäbe es nicht in deutsch, aber in englisch oder französisch … Welche von beiden bevorzugen? Welche von beiden, wenn’s sie nur in spanisch oder dänisch gibt?
Welche von beiden, wenn es sie nur in baskisch oder russisch gibt? “Irgendwas in lateinischen Lettern ist allemal besser” oder “ein alter Ossi sollte kyrillisch entziffern können”? Etc.

Tendentiell ginge mehr bis alles, dazu müsste bräuchte aber einen Rechner mit 32Gig Ram und 1TB SSD und viel Zeit, opentopomap selber aufzusetzen und die entsprechenden Namen anzupassen.

Wenn man mit name:en zufrieden ist, sollte das doch reichen. Keine Ahnung, ob und wie es in mapnik Überschreibregeln gibt etwa nach Schema: [name:de][name:en][name:irgendwas][name]

Verstehe, danke für die schnellen Antworten und Ideen!

Ich wollts erst als Antwort auf das Thema da drüben tippen, aber die Update-“Stategie” der OTM ist vielleicht eher hier interessant: Bis zum Sommer hat der Server nur Updates bekommen, wenn mal jemand Zeit und Lust hat, das manuell zu tun und oft war das lange Zeit nicht der Fall. Jetzt probieren wirs automatisch, während das Bedienungspersonal frei hat und bestenfalls dabei zusieht.

Das Datum, das in opentopomap.org/about angegeben ist, ist falsch nur halb richtig…

Das Update der Datenbank läuft dort in 2 Teilen ab. Zum einen das für OSM-Karten übliche differentielle Update, wo alle Änderungen seit dem letzten Update eingespielt werden. Zum anderen noch ein Update, bei dem ein paar Sachen in der gesamten Datenbank nachbearbeitet werden.

Das differentielle Update geht im Hintergrund, bremst zwar alles aus, lässt aber alle wichtigen Prozesse aktiv. Das sollte nicht allzu selten gemacht werden (viele machens jede Minute…), weil die Änderungen stauen sich ja. Übern Daumen braucht der OTM-Server für die Änderungen eines Tages 3-4 Stunden zum Einspielen, wenn er nebenbei noch sein Tagesgeschäft, das Ausliefrn von Kacheln, verrichten soll.

Die Nacharbeiten gehen nicht im Hintergrund, weil währenddessen gibt es keine Datenbank. In dieser Zeit können alte Kacheln ausgeliefert werden, aber weder veraltete neu gerendert noch fehlende Kacheln erzeugt werden. Die Nacharbeiten dauern immer gleich lang ein paar Stunden und sollten eher selten gemacht werden um den Betrieb nicht zu stören.

Wenn ein differentielles Update eingespielt wurde, aber noch keine Nacharbeiten stattfanden, hat man einen Schiefstand in der Datenbank. Es könnte z.B. sein, dass ein Gewässer gelöscht wurde, aber seine Beschriftung noch in der Gegend rumhängt. Man sollte also nicht zu lange warten mit den Nacharbeiten.

“Häufige Diffs”, “Zeitnahe Nacharbeiten” und “Server steht stundenlang bei den Nacharbeiten” ergibt natürlich einen Zielkonflikt. Derzeit laufen die Diffs 1x/Woche und die Nacharbeiten 2x/Monat. Wenn heute auf der Info-Seite steht “Stand der Datenbank: 30.10.2019”, heisst das, dass mit den Daten vom 30.10. das letzte Mal Nacharbeiten stattfanden. Seitdem liefen aber schon 2 weitere differentielle Updates, nur ohne Nacharbeiten. Auf der Karte könnte man auch schon Dinge sehen, die am 13.11. eingetragen wurden. “Daten vom 13.11., manches aber noch vom 30.10. und die Küstenlinien sind vom 3.11.” wäre aktuell die richtige Angabe. Um niemanden zu verwirren, wird halt nur eines der Daten ausgewählt und das ist eben der 30.10.

Ob dieser Takt “jede Woche Diff, alle 2-3 Wochen Nacharbeiten” beibehalten wird, oder obs andere Intervalle gibt, muss man noch sehen, auch wie lange alte Kacheln im Cache hängen sollen (derzeit 4 Wochen) und ob/wie schnell sie bei Änderungen aktualisiert werden.

Grüße,
Max

Hallo Max,

danke für die Erläuterungen.

Ciao

tracker51

Hallo,

ich hab’ mir heute die aktuellen Ausgaben von DACH für PC und Garmin runtergeladen. Das Entzippen der PC-Datei ging problemlos und ergab die Dateien dach.img und dach_contours.img.

Beim Entpack-Start der dach_garmin.zip-Datei poppte sofort die Meldung auf, ob ich die o. g. Dateien durch gleichnamige/-große ersetzen wolle. Hä? Trugen die PC- bzw. Garmin-Dateien nicht immer verschiedene Namen oder trügt mich mein Gedächtnis?

Um Klärung bittet

tracker51

Nachtrag 1: Es handelt sich offenbar um die Garmin-Karte, die sich hinter beiden Download-Dateien verbirgt: konnte sie auf meinem GPSmap abspeichern und darstellen.

Nachtrag 2: Die Bahn fährt sowohl lt. Garmin-Karte als auch lt. PC-Karte immer noch virtuell durch Förste bei Osterode (Harz) …

Opentopomap Kacheln werden nicht mehr dargestellt.
Hallo,
ich benutze QLandkarteGT weil damit die Opentopomap-Karte und Waypoints mit diversen Icons darstellbar sind.
Leider werden seit einiger Zeit die neu herunter geladenen Opentopomap Kacheln nicht mehr dargestellt. Das bedeutet die Karte hat weisse Flecken. Ältere Kacheln (im Ordner gespeichert) sind ok. Die neuen Kacheln sind im Ordner vorhanden - aber in der Karte nicht sichtbar.
Weiss jemand den Grund? Wäre sehr dankbar!
Die Alternative Qmapshack hat den Nachteil, dass ich die Opentopomap-Karte nicht einbinden konnte.
Vielen Dank!

http://www.mtb-touring.net/wordpress/wp-content/uploads/Onlinemaps.zip runterladen, in QMS-Kartenordner entpacken, Rechtsklick → Karten neu einlesen.

–ks

Danke! Aber geht leider trotzdem nicht. Die Kacheln werden herunter geladen, aber nicht angezeigt.
Die GoogleMaps Karte z.B. wird angezeigt - allerdings offensichtlich nur Layer 0 (also ohne Satellit …).
Mache ich vielleicht was falsch beim “tms-Karte hinzufügen”? Ich kopiere die Angaben aus der Datei OpenTopoMap.tms und füge die Daten in die 3 Eingabefelder ein.

Du musst nur die tms-Datei in eines der Kartenverzeichnisse von QMapShack legen (Datei → Kartenverzeichnisse angeben) und dann im Kartenauswahlpanel „Karten erneut laden“ durchführen. Da müssen keine Einzeldaten in Eingabefelder kopiert werden.

Dann musst du die gewünschte Karte dort in der Kartenauswahl nur noch aktivieren.

Aber die OTM scheint momentan wirklich Kachelauslieferprobleme zu haben.

–ks

Hier auf mtb-touring.net kannst du dir eine Sammlung von TMS-Dateien von Online-Rasterkarten herunterladen. Da ist auch die OpenTopo dabei. Bei mir lädt die übrigens flüssig.