Hei,
mit 7Zip kann ich dach_pc.zip öffnen und entpacken. Es werden 379 img-Dateien entpackt, Ich bekomme einen Fehler bei Datei 36130119.img, diese wird aber trotzdem mit entpackt.
Nachtrag: die zip-Funktion vom Betriebssystem selbst weigert sich die zip-Datei zu öffnen.
Umgebung: Win10 64bit (Version 1903), 7-Zip Version 19.0 64bit).
Sven
Hi Sven,
das ist 100%-ig genau so wie bei mir. Wenn ich die 379 Dateien dann in die OTM-Win-Datei reinkopiere, kommt
sowas
raus . Da müssen wir jetzt auf eine baldige Lösung durch das OTM-Team hoffen.
Ciao und vielen Dank
tracker51
…ja ich hatte das mitverfolgt… Ich hatte dach_pc.zip auch nur zum Test hier runtergeladen… Im Detail habe ich mir die Kacheln aber nicht angeschaut… Wenn, dann lade ich mir aber nur germany für Garmin-Geräte gelegentlich runter… für mein Oregon brauche ich nicht stets die neueste Karte…
Sven
Hi,
das habe ich soeben gemacht: hat alles wie erhofft funktioniert !
Es grüßt und hofft auf baldige Lösung
tracker51
Hallo,
ich habe ein paar Fragen… Die online Darstellung von der Karte gefällt mir sehr gut! Aber leider bekomme ich auf meinem Garmin Gerät, als auch in Basecamp die Ansicht so nicht hin.
Wäre echt nett, wenn mir bei den ganzen Fragen jemand weiter helfen könnte 
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 
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) …