OpenTopoMap

http://opentopomap.org/about

Datenstand
Die Datenbasis wird täglich mit der OpenStreetMap-Datenbank synchronisiert. (Angehalten seit 03/2015)

@Chrysopras: Erst einmal Herzlich Willkommen im Forum. Freundlich und sachlich ist so der Stil hier. Dann kann nix schiefgehen :slight_smile:
…auch von mir fehlen da tolle Änderungen… :expressionless:

Grüße,
G.

Die OpenTopoMap ist sehr, sehr angenehm fürs Auge. Großes Lob & Dankeschön!

An meinem aktuellen Monitor (1920x1080 bei 21") ist die jeweils kleinste Schriftgröße zwar schwer lesbar, aber auch das mindert meine Begeisterung nicht.

Gerade wenn es den "alten Stil"bei den amtlichen TK nicht mehr gibt (eigentlich nur in Bayern oder bundesweit?), umso besser, wenn er hier weiterlebt.

Hallo zusammen,

unglaublich, wie viele Vorschläge wieder zusammengekommen sind! Ich werde versuchen, alles zu beantworten:

Das ist komisch. Vermutlich ist da was beim Import kaputt gegangen. Beim nächsten Import sollte es wieder passen. Aber mehr dazu siehe unten.

Danke für den Hinweis! Ist erledigt.

Sehr guter Tipp! Ist erledigt.

Genau das Problem, das Maxbe, RadFr usw. ansprechen. Die OpenTopoMap rendert Flächen nicht so schlampig wie osm.org und verlangt saubere Multipolygone. Denn eine Wiese und ein Wald übereinander ergeben wenig Sinn, auch wenn die Sache soweit eindeutig ist. Die Darstellung auf osm.org nimmt zwar den Leidensdruck, saubere Landuses zu kartieren - wir halt nicht. Übrigens ist die Wiese ein transparentes Bild mit den grünen Punkten - die Renderreihenfolge verbessert’s also nicht.
Zu place=locality kann ich relativ wenig sagen.

Leider ja. Der Festplattenbedarf wächst mit jedem täglichen Update unverhältnismäßig (10 GB pro Tag, obwohl diff-File nur wenige MB). Das erfordert einen Neuimport, der mehrere Tage dauert. Da wir evtl. bald eine neue SSD für den Server bekommen, warten wir mit dem Neu-Import noch etwas. Übrigens bereiten wir Schummerung&Höhenlinien auf weltweite Abdeckung vor - das kommt aber sicher erst nach der Speichererweiterung.

Das Problem kenne ich auch von Retina-Displays. Geht mit unseren heutigen Technologien leider nicht anders. (Google Maps macht Vektorkarten.)
Den übersichtlichen Kartenstil mit dem hohen Kontrast zu bewahren ist die Intention für die OpenTopoMap. Selbst Vermessungskundler kommen auf uns zu und loben den Stil, den sie selbst nicht mehr produzieren dürfen.

Herzlichen Dank für Eure Antworten!

Vielen Dank für die herzliche Begrüßung!

Ah, vielen Dank für die Erklärung! Dann ist natürlich alles klar …

Nur so 'ne Idee: Vielleicht könntet Ihr in Zukunft (ich meine, wenn der Server aufgerüstet ist) einen größeren, aber regelmäßigem Import-Intervall einrichten, z.B. jeden Monat (oder notfalls jedes Quartal)? Das hätte den Vorteil, dass die Aktualität der OpenTopoMap (im Verhältnis zu den OSM-Daten) klar definiert wäre und wir OpenTopoMap-liebenden Mapper uns immer schon im Voraus freuen können – sozusagen dreimal werde ich noch wach, dann kann ich meine letzten Edits endlich auf OpenTopoMap kontrollieren :slight_smile:

Beste Grüße und natürlich v.a. vielen Dank für die wunderschöne Karte –
Chrysopras

Es bietet sich natürlich an, die Incremential Updates (Diffs) sehr zeitnah zu importieren. Bei genug Ressourcen und einem passenden Script, der vom Cron gestartet wird, sind Abweichungen von den Live-Daten im Minutenbereich machbar.

Ist aber nicht ganz so einfach und falls nach einem Update auch noch Datenmanipulationen in der DB notwendig sind, bringt das hier natürlich nicht viel.

Beim Scripting für Linux kann ich was anbieten.

Gruss
walter

Hallo,

bis zum Stop haben wir tägliche Diffs eingespielt. Diese bekommt man von der Geofabrik. Zukünftig ist natürlich mindestens täglich geplant.

Sind nicht für die ganze Welt, sondern für einige Länder, richtig? Und die gibt es mWn nur täglich. Dann machen die Minuten-Diffs natürlich keinen Sinn, da die alle Änderungen weltweit enthalten und eure DB unnötig aufblähen würden.

Macht ihr auch schön brav Autovacuum?

Gruss
walter

Hallo derStefan,

die OpenTopoMap ist nur geil! (Ich glaube so muss man heute sagen, wenn man von einer Sache extrem begeistert ist. ;-))
Was muss ich machen, wenn ich dies “Garmin Edition” auch für Ecuador, Peru und Cuba haben möchte?

LG derFred

Die Ausrichtung der Pässe und Sättel hat mir keine Ruhe gelassen…

Mit der Ausrichtung an der Strasse kommt man nicht sehr weit. Bei grossen Alpenübergängen ist es tatsächlich oft so, dass nur eine wichtige Strasse rauf- und wieder runterführt und vielleicht noch ein paar kleine Strassen am Sattel abzweigen.

Bei kleinen Sätteln gibt es diesen einen Hauptweg oft nicht. Manche Sättel haben gar keinen Weg, bei vielen befindet sich auf dem Sattelpunkt eine Abzweigung zum nahegelegenen Gipfel, oder eine Kreuzung zwischen einem Weg am Grat entlang und der Passüberquerung, oder der Sattel wird nur vom Gratweg erschlossen…

Aussichtsreicher scheint mir ein Drehen in die Richtung, in die sich das Gelände biegt: Man nimmt im Umkreis von z.B. 100m ein paar Höhenwerte und bestimmt die Ausrichtung des Sattels, indem man schaut, wo es vorne/hinten am weitesten runter und links/rechts am weitesten rauf geht. Funktioniert anscheinend gut bei “üblichen” Sätteln, scheitert manchmal bei ungewöhnlichen Geländeformen (ein stark gebogener oder verzweigter Grat z.B. oder eine im flachen 100m-Umkreis nicht deutliche Einkerbung) oder an Stellen mit kaputten Höhendaten.

Habs mal im Wiki zusammengeschrieben und das Karwendelgebirge als Testgebiet gerendert (für Zoom>16 und für andere Gebiete gibts noch alte Cache-Kacheln mit ungedrehten oder falsch gedrehten Icons). Lage, Anzahl und Gewichtung der ausgesuchten Höhenwerte ist noch Gegenstand der Forschung von Versuchen und Irrtümern…

Grüße, Max

Schaut echt Spitze aus, mit perfekter Ausrichtung des Symbols!

Hallo Max,

genau so hatte ich es mir vorgestellt! Deine Arbeit ist und bleibt immer beeindruckend. Klasse finde ich auch, dass du es immer schön im Wiki dokumentierst.

Bisher bin ich vor Präprozessierungsmethoden in der Datenbank zurückgeschreckt, weil ich die Leistungseinbußen fürs Rendern nicht einschätzen kann. Lässt du die Funktionen nach jedem Datenbankimport automatisiert durchlaufen? Oder im Falle der Ausrichtung von Pässen nur für Objekte, deren Richtung noch nicht berechnet wurde?

Gruß
Stefan

PS: Wenn dein Server nicht zu klein ist und du dich nicht vor den Tile Grabbern fürchtest [1], könntest du dir auch mal überlegen, ein größeres Gebiet zu rendern. Ich würde mich mindestens über Franken freuen. :slight_smile:

[1] Tile Grabber machen bei der OTM fast 50% der Serverlast aus, obwohl wir diese ab einer gewissen Kachelanzahl stark drosseln. :rage:

Hallo Fred,
danke für das Lob! Wir planen tatsächlich die weltweite Abdeckung. Aber mach dir bitte keine Hoffnung auf schnelle Umsetzung. Die Datenmengen sind immens und unsere zwei Server sind speicherplatztechnisch im Moment schon gut ausgebucht. Wenn’s schnell gehen muss: Baue es dir selber! Das ist mit Anleitung nicht allzu schwer - alles Nötige findest du in der Hilfe auf Github.

Danke für die Info
werde ich machen. Merci

Danke fürs Lob, schön dass es gefällt.

Ja… Vorberechnen oder nicht ist eine schwere Entscheidung. Ich habe entschieden indem ich mich auf den Standpunkt stelle, dass ich mit meiner Ausstattung ordentliche Leistung eh nicht schaffe und deshalb Performance für mich einfach kein Kriterium darstellt. Wenn der Rechner sich des nachts ein paar Stunden mit sich selbst beschäftigt, ist das ok, solange er die Updates einer Woche innerhalb einer Woche einspielen kann, Kacheln nicht älter als ein paar Wochen werden lässt und er nebenbei noch mich und 100 andere Nutzer pro Tag halbwegs bedienen kann.

Der Job fürs Präprozessieren läuft einmal täglich gleich nach dem mitternächtlichen Update der Datenbank. Während er läuft werden keine Diffs eingespielt, ansonsten wird alle paar Stunden geupdatet. Es kann also sein, dass man um 23 Uhr schon die Fläche eines neu gemalten Hauses sieht, aber erst einen Tag später das Icon für die Kneipe darin zu sehen wäre. Ein paar Kleinigkeiten ändere ich auch gleich im Anschluss an den Update zwischendurch. Z.B. brauche ich Zahlen zum Rechnen und Vergleichen in “ele” und muss alles andere (“c.a. 500 Meter”) schnell korrigieren oder löschen, bevor sich der Renderer daran verschluckt.

Alle POIs werden in eine eigene Tabelle neu geschrieben oder zumindest die alten POIs geupdatet. Ich hab auch mal mit “nur ansehen was sich geändert hat” anhand von diffs experimentiert, aber das ging schief: Ein POI kann bei auch aus einer Fläche entstehen. Wenn die Ecken eines Hauses verschoben werden, stehen im diff die Ecken, aber nicht der Way des Hauses.
Danach werden auf die POIs ein paar Skripte losgelassen (z.B. das fürs Pässedrehen. Nicht wundern, da steht dann “nature=mountain_pass”, wo in OSM “mountain_pass=yes” steht und den Winkel stecke ich ins Feld population, weil das war da und wird nicht gebraucht).

Wenn ich mir allerdings ansehe, wie andere Karten ganz ohne Vorverarbeitung Fussballplätze mit korrekt gedrehten und skalierten Linien bemalen, denke ich mir, ich könnte mich auch mal mit PL/pgSQL anfreunden, auch wenns schwer fällt. Da könnte man sowas wie Pässerotieren vielleicht auch erledigen.

Franken: Mal sehn in welche Richtung ich expandiere, vielleicht beim nächsten Serverumzug… :wink:

Grüße, Max

Wäre es nicht auch möglich einfach bei Pass und Saddle ein zusätzliches direction tag in Grad dazuzugeben?
Bei allen bestehenden Pässen und Satteln ohne direction tag könne man ja mittels des Algorithmus von Max das tag ergänzen.
Vorteil wäre dann, falls der Algorithmus für einen Sattel mal nicht 100% klappt, man die direction manuell anpassen könnte.

Der Renderer hätte so auch keine große Last und müsste nur das tag auslesen und das Symbol entsprechend darstellen.

Und bei neu angelegten Saddles ohne direction tag, könnte man ja immer wieder mal eine Auswertung machen saddle ohne direction.

Die Ausrichtung eines saddles / passes sollte sich ja äuserst selten ändern (vielleicht bei großer Naturkatastrophe)…

Klar, das tun fast alle GIS operator wenn es ein Punkt Symbol gibt das direction benötigt. Der GIS Software erfasst dann die Drehung mittels ein Attribut.

Ich denke, ein (mechanischer/manuelles) edit dass den Auskunft des Algorithmus von Max nutzte wäre effizienter. Auch gibt es jetzt kein Höhe data in OSM Standard, und macht es gerade unmöglich.

Neu in der OpenTopoMap sind Campingplätze und verbesserte Farben für Waldflächen auf Zoom 9-11.

Hier stimmt was nicht mit den Höhenlinien: Sie gehen durch den See, haben Überschneidungen und hören plötzlich auf.

http://opentopomap.org/#map=15/47.79252/6.35362

Gruß,
Zecke

Hallo Zecke,

das liegt daran, dass die normalerweise eckigen Höhenlinien absichtlich abgerundet werden. Bei solch kleinen Artefakten geht das zwar bisschen in die Hose, im Mittel sehen die Höhenlinien trotzdem besser aus. Schlechter Zufall ist außerdem, dass die Höhenlinie genau auf einem See liegt. Maxbe zeigt, wie man es machen könnte.