OpenTopoMap

Nicht wirklich, aber ich würds mal versuchen. Allerdings könnte ich mir vorstellen, dass das case den Ausführungsplan nochmal durchnanderbringt und evtl. die Performance einbricht, aber das kann man (also ich :wink: ) nur im Test sehen.

In einem anderen(oder hier?) Thread wurde ja auch mal über ein neues “OpenTopoMap selbst rendern”-Tutorial berichtet - gibts da nen aktuelles Skript/HowTo zu?

Sieht gut aus:

https://maposmatic.osm-baustelle.de/results//018231_2018-04-18_18-56_test-opentopo-merge.8bit.png

Nehme alles zurück, man sollte die Funktion natürlich nach einem git pull auch neu einspielen …

Jetzt habe ich ein Performance-Problem mit Query-Laufzeigen von mehreren Minuten.
Ich vermute mal ihr habt da einen Index auf der leisure-Spalte?

Das ist bei hstore-only ein klein wenig schwieriger, aber machbar …

:frowning:

Tut mal wieder direkt aus psql, aber Mapnik rennt nun in:


RuntimeError: Postgis Plugin: ERROR:  Shell is not a line
CONTEXT:  SQL statement "SELECT osm_id FROM planet_osm_polygon
              WHERE planet_osm_polygon.way && ST_EXPAND(myway,trackdist/labelsizefactor) 
              AND   leisure='track' 
              AND CASE WHEN  ST_ISCLOSED(planet_osm_polygon.way)
                     THEN ST_CONTAINS(ST_MakePolygon(planet_osm_polygon.way),myway) 
                     ELSE FALSE 
                  END
              LIMIT 1

Nö, OTM ist eine praktisch indexlose Datenbank: gist(way) und btree(osm_id) sind die einzigen für planet_osm_polygon -line und -point. An der Performance hab ich bei mir nichts gemerkt, offensichtlich sind unsere Datenbanken unterschiedlicher Ansicht, wie rum man das optimieren sollte.

Hat wima75 freundlicherweise verfasst.

Ich hätts auch nur bei der Abfrage nach planet_osm_line ersetzt (der PR dazu). In planet_osm_polygon liegen ja nur Polygone. Wobei… naja… man weiss ja nie, welch wunderlichen Gebilde einen erwarten… :wink:

So, jetzt sieht es gut aus und ist auch wieder flott:

https://maposmatic.osm-baustelle.de/results//018245_2018-04-18_20-14_test-opentopo-merge-8.8bit.png

https://maposmatic.osm-baustelle.de/results//018246_2018-04-18_20-16_test-opentopo-merge-9.8bit.png

Kurz zur Unterhaltung der Mitleser. Hier gehts drum, dass die OTM Sportfelder in Zoom 13 und 14 unterschiedlich rendert. Das hängt davon ab, ob sie nur ein Fussballplatz sind oder eine Rennbahn aussen rum haben. Diese Rennbahn kann eine geschlossene Linie sein, oder eine Fläche. Die Funktion, die hier abschmiert ist das Teil, das eben prüft, ob so ein Ding (a) in der Nähe ist und (b) ein leisure=track ist und (c) ein geschlossener Ring ist und (d) den Sportplatz umschliesst (weil “in der Nähe” kann ja auch eine Bahn daneben sein)

Beim Programmieren ging ich davon aus, dass (a)…(d) in dieser Reihenfolge abgearbeitet wird. “Umschliesst?” ist also die letzte Frage, die beantwortet wird. Ist ein blöder Fehler, weil man weiss ja, dass Postgresql das noch optimiert und wenn es das für gut hält auch gerne die Frage (d) zuerst abarbeitet. Allerdings funktioniert “umschliesst das Ding den Platz?” nicht, wenn die Frage (c) “ist das überhaupt ein geschlossener Ring?” nicht zuvor mit “Ja” beantwortet wurde.

Der Full-Planet-Import hat 48 Stunden gedauert und belegt schlußendlich 231 GB. Die drop-Option wird erst am Ende des Imports wirksam, sodass zwischenzeitlich die DB-Größe auf circa 630 GB angestiegen ist. Die temporäre DB-Größe fällt etwas ‘happig’ aus, da ich die (empfohlene) flat-nodes-Option nicht verwendet habe.

nohup ./osm2pgsql --username postgres --multi-geometry --hstore --slim --drop --create --cache 48000 --number-processes 8 --database osmtest --style openstreetmap-carto.style --tag-transform-script openstreetmap-carto.lua planet-latest.osm.pbf 1>load_osmtest.out 2>&1 &

Jetzt fehlen mir für Printmaps nur noch weltweite Höhendaten. Aber diesbezüglich sieht es nicht so schlecht aus.

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