OpenTopoMap

Wahrscheinlich offtopic, aber wenn ihrs schon von Sportplätzen habt: Ich finde Sportplätze wie diesen https://opentopomap.org/#marker=17/48.17417/11.60795 immer ein wenig suspekt (Höhenliniendarstellung) da ich eigentlich erwarte, dass sie relativ eben sind :).

Das ist sicher auch der Grund dafür dass er aufgegeben wird. Is halt immer das gleiche Problem: Keine guten Höhendaten. Nebenan gibts nen Fluss, der die 500m-Linie 5x schneidet…

Es liegt aber auch an der Zeichenreihenfolge… so müssten Gewässerflächen (Standgewässer und Fließgewässer) sowie Sportplätze und Gebäude über den Höhenlinien gerendert werden. Straßen werden ja über den Höhenlinien gerendert…

Ob das aber hier so ohne weiteres geht, vermag ich nicht zu sagen.

Sven

Ja genau, die Zeichenreihenfolge kann leider nicht so einfach geändert werden. Wir müssen leider erst einmal damit leben. Dass z.B. bei Donauwörth (https://opentopomap.org/#marker=12/48.6901/10.7608) so hässliche Artefakte sind, liegt nicht grundlegend an einem schlechten Höhenmodell. Dort befindet sich eine Ebene, die vielleicht um wenige Meter rauscht - das muss nicht unbedingt ein Fehler im Höhenmodell sein, sondern tatsächlich die Landschaft. Unglücklicher Zufall ist, dass die mittlere Höhe dort 300,0 Meter beträgt, deshalb erscheinen die Artefakte.
Man müsste™ also die Höhenlinien intelligenter erstellen als nur für jede Isohypse nachzuzeichnen. :expressionless:

Würde es nicht reichen, wenn man feststellt, dass die eingeschlossene Fläche klein ist und keine weitere Höhenlinie “drin” ist?
Linien, die diese Kriterien erfüllen, könnte man dann unterdrücken.

Gerd

Das ist auch die Beschreibung der obersten Höhenlinie jedes Berge… Nö, reicht nicht. Da gehört noch irgendwas dazu wie “und die Nachbarhöhenlinien haben die gleiche Höhe”, was dann wenigstens nur tatsächlich freistehende Buckel als Fehler übrig liesse (den da z.B. gibts echt als kleinen Hügel in der Ebene). Und wir haben ja nicht nur das Problem der kleinen runden Höhenlinien, es gibt ja auch noch die unrealistisch umherirrenden

Also einfach isses nicht, viel Luft zum Filtern und Auswerten ist da auch nicht bei einem 30 oder 90m-Raster. Wir warten einfach auf das globale freie Höhenmodell im 0.1-5m-Raster. In Zeiten von open data und open government erwarte ich stündlich die Veröffentlichung :wink:

Ja, Du hast Recht, ist leider nicht so trivial :frowning:

Wegen Höhenmodell: Ich weiss ja nicht, ob die Daten schon irgendwo vorliegen, aber ein Download dürfte bei 0.1 m Raster noch recht lange dauern, zumindest mit dem hgt Format :wink:

Gerd

Du musst einfach mit deinem Einhorn und der 3EB-Platte zum Bundesvermessungsamt reiten und die Daten direkt draufziehen. Vergiss nicht, dein W-Lan-Kabel mitzubringen. Parkplatz für Einhörner vorhanden.

Max hat mal wieder gezeigt, was er in SQL drauf hat: Seit Kurzem werden die Beschriftungen von Seen vorberechnet und gedreht. Hier ein Beispiel:

Hier findet sich eine Dokumentation des Algorithmus: https://wiki.openstreetmap.org/wiki/User:Maxbe/Beschriftung_von_Seen

In den nächsten Tagen und Wochen werden wir weiter am Algorithmus und der Darstellung feilen.

Das mit der Medialen Achse ist eigentlich schon der richtige Ansatz für einen Beschriftungsalgorithmus für Seen. Jedoch benutzt PostGIS nur eine Näherung über das Straight Skeleton. Zielführender wäre hier stattdessen über das Voronoi-Diagramm zu gehen.

Für den Chiemsee erhält man dann:

Und daraus die zum See topologisch identische, vereinfachte Liniendarstellung (der Chiemsee hat 8 Inseln!) mit dem blau dargestellten, optimalen Beschriftungspfad:

Bei den einzeln liegenden Seen sieht das schon sehr schön aus. Bei der Beschriftung mehrerer benachbarter Seen jedoch kann das bisweilen unruhig aussehen, weil (außer mit dem Programmierwissen) nicht klar ist, warum Beschriftungen mal horizontal, im Winkel oder kurvig erscheinen.
Auch ein Doppel- oder Mehrfachbogen wirkt bei kleinen Seen (großen Lettern) eher unruhig, während z.B. bei großen, langgezogenen Schweizer Seen (kleinen Lettern) der Zeichenabstand/die Laufweite der Buchstaben vergrößert werden könnte.
Aber mal wieder: Danke für die schöne Karte!!
Cepesko

Jo, das war das Problem (vielleicht sollte ich doch mal Python lernen)… Ich brauche massig Funktionen “liegt dieses Ding in dieser Fläche” und “schneide die Linie mit diesem Rand” und die habe ich nur in Postgis (und dann fluche bei jeder Zeile, weil das nicht mal 2-dimensionale Arrays kann und überhaupt PLpgSQL ganz ganz schlimm ist;)). Das nächste Problem war die Performance. Bei ner halben Million Seen kann man nicht ne Sekunde pro See vertrödeln…

Lustigerweise kann ich durch ansehen auch nicht sagen, warum ein See so beschriftet wird, aber ich hab ein Bild mit Hilfskästchen dafür:

(Vilstalsee, Kreutweiher, Pilsensee, Kleinhesseloher See)

  1. Zuerst wird geschaut ob der See rund ist oder in W-O-Richtung liegt und mittig horizontal beschriftet werden kann.
  2. Dann wird geschaut ob der See irgendwo anders als in der Mitte horizontal beschriftet werden kann
  3. Dann wird eine Diagonale gesucht
  4. Dann wird eine Schlangenlinie gesucht
  5. Wenn alles nichts hilft, nehmen wir doch was mittig horizontals.

Hinter jeden Punkt steht noch eine Abfrage ob “das Ergebnis gut ist”. “Gut” ist ein dehnbarer Begriff und heisst z.B. “die Beschriftung reicht über 2/3 des Sees”. Das ist willkürlich und änderbar. Wenn wir nach 1. oder 2. schneller zufrieden sind (“1/3 des Sees”), gibts mehr horizontale Linien und ein ruhigeres Bild bei benachbarten Seen. Mal sehn…

Ein weiteres Problem ist, dass die Schriftgröße und -Länge beim rechnen gar nicht berücksichtigt wird. Ein langgestreckter See, der “Oberer Dingsstädter Stausee” heisst, braucht eine längliche Beschriftung. Hiesse er “Kuhsee” würde für die 6 Buchstaben auch eine Beschriftung quer zum See reichen… Auch mal sehn… :wink:

Grüße
Max

Ein kleines, aber feines Detail sind die neuen Beschriftungen von Höhenlinien - diese werden nun entsprechend Richtung des Gefälles gedreht:

Das ist ein wirklich hübsches Detail! An solchen Details merkt man, dass eine Karte (ein Kartenstil) wirklich mit Liebe und Sachkenntnis gezeichnet (gerendert, programmiert) wurde. Danke!

Ein Wunsch:
Kamine, wie dieser in Istrien mit 340m Höhe, sind oft weithin sichtbare Orientierungspunkte und auf Carto dargestellt. In der OpenTopoMap wären sie m.M.n. auch ein wichtiges Detail. Ab welcher Zoomstufe sollte vielleicht in Abhängigkeit zur Höhe stehen, wie das bei den Bergen in der OTM ja auch toll umgesetzt ist.
Gruß und Dank an Max, Stefan & co.
Cepesko

falls es euch interessiert, eure Tiles werden hier kommerziell genutzt https://www.gpswerk.de/tourenplaner.

Das ist eine Frage des Symbols, glaube ich … Der Kamin ist das kleine Kringel auf der Karte, was auch etwa der Darstellung auf topographischen Karten entspricht (oder entsprach). Wird ab Zoom=13 angezeigt, aber vielleicht wäre ein fetterer Kringel für echt hohe Kamine gut…

Hallo,

Sehe ich das richtig, dass Meerengen und Buchten mit Namen angezeigt werden, Insel-Namen bzw. islet und Kaps nicht?

Ja. Die natural=strait/bay kamen so als Beifang dazu, als wir die Seen beschriftet haben (was noch nicht fertig ist, zieht sich alles…).

Die place=Island/islet/archipelago werden nicht gerendert. Mit Kap meinst Du natural=cape?

Nachtrag: Kap wird auch nicht gerendert und ich sollte erwähnen, dass es sich bei beschrifteten natural=strait/bay um Flächen oder Linien, nicht um Punkte handelt.

Ja