OpenTopoMap

Anscheinend hast du dabei einen Weg gelöscht, der Wald wird nicht mehr gerendert.

Multipolygone wie hier erschweren es Anfängern, das Objekt zu editieren. Multipolygone sollten so sparsam wie möglich eingesetzt werden. Die Wiese etwa hätte man als geschlossenen Weg mappen können, um späteren Mappern keine Steine in den Weg zu legen. Multipolygone sind nur nötig, wenn man etwas “ausstanzen” will (etwa eine Insel im See) oder bei räumlich verteilten Objekten.

Gruß 4rch

Sollte wieder in Ordnung sein. Die Wiese als geschlossener Weg verursacht ein toutching_inner, meckert der OSMI an.

Da war ein MP, welches ich nur ergänzt habe.
Räumlich verteilte Objekte sollte man auch nur in einem Mp zusammenfassen, wenn sie auch zusammengehören, z.B. gleicher Name.

A propo MPs. Schau Dir mal das hier an: https://www.openstreetmap.org/#map=15/51.1394/7.2198, da ist dieses harmlos.
Ebenso unsinnig, Gebäude per MP-Relation zusammenzufassen (findet man immer mehr).

Das is ja ma richtig Murx. Ein Renderer weiss nicht, dass eine Insel eine Insel ist? Kann ich mir in meinen verrücktesten Träumen nich ausdenken.
(Wobei ich das mit der Wiese schon ausreichend bescheuert finde. Meinem bescheidenen Verständnis nach sollten solche 08/15-Dinge immer ohne weiteres Tagging ausgeschnitten werden (Wald auf Wiese vs Wiese auf/in Wald))

Ich glaube, viele der Probleme mit überlagerten Wiesen und Wäldern könnte man in der OpenTopoMap beheben umgehen, indem man die Flächen der Grösse nach sortiert aus der Datenbank holt. So wie beim Mapnik-Stil, da steht

SELECT landuse .... ORDER BY z_order, way_area DESC

Das funktioniert allerdings nur bei Dingen, die innerhalb einer Abfrage geholt werden, also z.B. nicht bei Überlagerungen von Land und Wasser. Aber immerhin würde man dort dann das auf der Karte sehen was man beim Mapnik-Stil auch sieht und was deshalb per Definition als korrekt gemappt gilt :wink:

Grüße, Max

Genau das führt dann dazu, dass erforderliche MP-Relationen nicht mehr erstellt werden.

Geht man an der von SLA_NOK an gesprochenen Stelle etwa 3 km weiter nach Süden, so zeigt sich ein anderes Problem: Der Schlempertshof als Siedlung (=hamlet) wird nicht angezeigt, während die Karte voll ist von Flurnamen (locality). Für den Normalkartennutzer wird die Karte damit sehr unübersichtlich, denn Unwichtiges erscheint statt/zusammen mit wichtigeren Informationen.
Ursache ist aber hauptsächlich das Tagging. Frage: Sollte vielleicht ein anderes Tag für Flurstücke verwendet/erfunden werde. Was meint SLA_NOK dazu, der diese eingetragen hat?
Auf jeden Fall sollte hamlet bevorzugt vor locality erscheinen. (Bei Mapnik ist dem wohl so)
Cepesko

Das locality für Flurstücke, Gewanne, Schläge usw. hat sich bereits eingebürgert. Ich nehm’ auch gern was passenderes und tagge die von mir erfassten Bezeichnungen um. Es scheint aber kein wirklich passendes Attribut zu geben.

Ja, da besteht sicher Bedarf an einem tag auf der nächst tieferen Ebene.
Ursächlich ist sicher hier die dt. Wiki, in der von “Flur” die Rede ist. Doch beschreibt m.E. das tag=locality (nach engl. Wiki) eher eine etwas größere unbewohnte Örtlichkeit, denn einzelne Flurstücke. Vielleicht sollte man mal eine Diskussion anlegen, ob man evtl. landuse=farmland aufsplitten und jeweils mit dem name-tag versehen sollte oder andere Lösungen hier besser sind. Cepesko

Mal etwas ganz simples zwischendurch: kann es sein, dass der Datenstand der OpenTopoMap schon ein paar Wochen nicht mehr aktualisiert worden ist? Das soll keine Beschwerde sein, sondern wirklich nur eine dumme Frage :slight_smile: Tägliche Aktualisierungen sind ja auch gar nicht nötig; aber ich würde eben so gerne meine Edits aus den letzten Wochen in diesem schönen Rendering sehen … Gibt es besondere Gründe für das Anhalten der Aktualisierungen, oder muss ich nur einfach mehr Geduld haben?

Viele Grüße, Chrysopras (neu im Forum*, aber nicht ganz neu in OSM)

  • Daher seid bitte nicht böse, wenn ich trotz Lektüre der Forenregeln etwas falsch mache.

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!