OpenTopoMap

Bis auf die Tatsache, dass in dem südlichen Gleis die ICE-Route IC87 bei der Brücke im Westen unterbrochen ist, fällt mir auch nix auf.
Hab es nicht korrigiert, da ich eure Feinheiten nicht kenne.

Gruss
walter

edit: Schaut doch mal in eurer Render-DB nach, (ich nehme mal an, sowas habt ihr), ob die Gleise drin sind.

Thema: Pfeile der Fliessrichtung von Flüssen

Die an Flüssen/Bächen vorhandenen Pfeile werden von riverbank verdeckt. Liegt der way des river/stream nahe des Randes der riverbank wie, z.B. hier, dann erscheint der Pfeil teilweise.
Kann der Pfeil eine Ebene über der riverbank und damit immer sichtbar bleiben?
Cepesko

https://opentopomap.org/#map=16/49.65670/9.43163

Kann mir jemand einen Hinweis geben, weshalb die Wiesen, Äcker und Siedlungen im Erftal ignoriert werden?

Ich rate mal: Weil sie von einem grossen Wald überlagert werden.

Diese Teile müssen ausgestanzt werden, sprich als inner in die Wald-Relation eingefügt werden.
Done.

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