Updateinterval bei openstreetmap.de?

... und auf der Radfahrerkarte ist über alle Kacheln "API Key Required" gepinselt. 🤔

Vielleicht hier einmal nachfragen:
https://www.openstreetmap.de/impressum.html

Hallo,

opendcc wrote:

bei uns wurde eine neue Autobahn gebaut, Fertigstellung zum 1.10.2019. Eine Woche vorher habe ich die A94 von construction auf highway geändert. Auf https://www.openstreetmap.de/karte.html … ers=B000TT ist auch nach etwa 7 Wochen die Kachelansicht noch auf dem Stand vor der A94. (Höherer Zoomstufen haben es dann schon berechnet.)

Tiles auf den Zoomstufen 13 bis 19 werden per Tile-Expiry neu berechnet, wenn sich etwas geändert hat (ggf. nach dem ersten Zugriff nach der Änderung). Tiles der niederigeren Zoomstufen werden beim Serversetup vorberechnet. Für weitere Fragen musst du dich an Sven Geggus wenden, er hat den Server aufgesetzt.

Viele Grüße

Michael

Laut dieser Seite kann auch bei openstreetmap.de /status und /dirty anhängen:
https://wiki.openstreetmap.org/wiki/DE: … rt_rendern

Eine /status Anfrage funktioniert auch:
https://tile.openstreetmap.de/11/1093/709.png/status

/status (Auszug) wrote:

Last rendered at Tue Jun 11 20:35:20 2019.
Last accessed at Sat Nov 16 08:34:56 2019.

Zoom 11 scheint hier seit Juni nicht aktualisiert, bei osm.org werden Zoom 0-12 monatlich neu berechnet.

Eine entsprechende /dirty Anfrage antwortet auch mit "Tile submitted for rendering", nur getan hat sich noch nichts.

Hinter tile.openstreetmap.de scheinen die beiden Server "humboldt" und "gauss" zu stehen, die Situation scheint aber auf beiden die gleiche zu sein:
https://humboldt.openstreetmap.de/11/1093/709.png
https://gauss.openstreetmap.de/11/1093/709.png

ikonor wrote:

Hinter tile.openstreetmap.de scheinen die beiden Server "humboldt" und "gauss" zu stehen, die Situation scheint aber auf beiden die gleiche zu sein:

Das scheint nicht nur so, die beiden Maschinen haben exakt das selbe Setup sodass zum Systemupdate auch mal eine davon temporär raus genommen werden kann.

Es ist tatsächlich so, dass es derzeit keinen Cronjob gibt um die kleinen Zoomlevel neu zu rendern. Das liegt daran, dass es derzeit ziemlich teuer ist das zu tun und man da vermutlich die Indexe der Datenbank noch etwas tunen müsste damit das effizienter funktioniert. Den Aufwand habe ich bislang gescheut und mir gedacht dass sich in diesen Zoomleveln ja ohnehin wenig ändert.

Wenn sich da jemand berufen fühlt ein paar geeignete Indexe bei zu steuern, immer gerne.

Momentan hat die Datenbank folgende Indexe:
https://github.com/giggls/openstreetmap … hstore.sql

Ein manueller submit per dirty tile sollte eigentlich funktionieren. Aber wie gesagt, das Neurendern dauert ziemlich lange.

Sven

KPG wrote:

... und auf der Radfahrerkarte ist über alle Kacheln "API Key Required" gepinselt. 🤔

Oh hat sich da gerade jemand freiwillig gemeldet, der http://openstreetmap.de neu machen möchte?

Hallo Sven,

giggls wrote:

Es ist tatsächlich so, dass es derzeit keinen Cronjob gibt um die kleinen Zoomlevel neu zu rendern. Das liegt daran, dass es derzeit ziemlich teuer ist das zu tun und man da vermutlich die Indexe der Datenbank noch etwas tunen müsste damit das effizienter funktioniert. Den Aufwand habe ich bislang gescheut und mir gedacht dass sich in diesen Zoomleveln ja ohnehin wenig ändert.

Wenn sich da jemand berufen fühlt ein paar geeignete Indexe bei zu steuern, immer gerne.

Momentan hat die Datenbank folgende Indexe:
https://github.com/giggls/openstreetmap … hstore.sql

Ich habe vor etwa einem halben Jahr ein wenig Index-Tuning für OSM Carto gemacht. Viel kam nicht heraus, aber folgende Indexe könntest du noch ausprobieren (ich fand, dass sie einen Effekt hatten). Beachte bitte, dass diese für eine Datenbank mit klassischem OSM-Carto-Layout gelten, du musst sie noch an dein Hstore-Layout anpassen.

CREATE␣INDEX␣planet_osm_point_place
ON␣planet_osm_point␣USING␣GIST␣(way)
WHERE␣place␣IN␣('city',␣'town')␣AND␣name␣is␣NOT␣NULL;

CREATE␣INDEX␣planet_osm_roads_low_zoom
ON␣planet_osm_roads␣USING␣GIST␣(way)
WHERE␣highway␣IS␣NOT␣NULL
OR␣(railway␣IS␣NOT␣NULL␣AND␣railway␣!=␣'preserved'
AND␣(service␣IS␣NULL␣OR␣service␣NOT␣IN␣('spur',␣'siding',␣'yard')));

CREATE␣INDEX␣planet_osm_line_name
ON␣planet_osm_line␣USING␣GIST␣(way)
WHERE␣name␣IS␣NOT␣NULL;

CREATE␣INDEX␣planet_osm_point_capital_names␣ON␣planet_osm_point␣USING␣GIST(way)␣WHERE␣tags␣@>␣'capital=>yes';

Bei den Indexen planet_osm_hstore_polygon_military und planet_osm_hstore_polygon_water solltest du prüfen, ob da nicht noch ein "AND building IS NULL" fehlt. Die partiellen Indexe nutzt PostgreSQL nur, wenn die WHERE-Bedingung näherungsweise identisch ist.

Der originale OSM-Carto-Stil schlägt noch einen zusätzlichen partiellen Index auf planet_osm_polygon vor, der für die Zoomstufen 7 bis 10 hilfreich ist:

CREATE␣INDEX␣planet_osm_polygon_way_area_z10
ON␣planet_osm_polygon␣USING␣GIST␣(way)
WHERE␣way_area␣>␣23300;

Der Layer landcover_low_zoom lässt sich meinen Untersuchungen nach nicht mit einem weiteren Index (auf die WHERE-Bedingung + way_area-Filter) beschleunigen. Da müsste man mit vereinfachten Geometrien nachhelfen.

Je mehr Indexe man hat, desto mehr Index-Bloat hat man. Man sollte daher regelmäßig (Cronjob/Systemd-Timer) diese Indexe neu bauen und dann den alten Index per "DROP INDEX" löschen.

Die Indexe für capital und way_area halte ich für besonders empfehlenswert. Den speziellen Index für Fähren hast du schon (das ist ein Performance-Klassiker).

Viele Grüße

Michael

giggls wrote:

KPG wrote:

... und auf der Radfahrerkarte ist über alle Kacheln "API Key Required" gepinselt. 🤔

Oh hat sich da gerade jemand freiwillig gemeldet, der http://openstreetmap.de neu machen möchte?

... mit 'nem deutschen Radkartenstil? 😎

Zoom 10 und 11 sind inzwischen auf beiden Servern aktualisiert.

giggls wrote:

Ein manueller submit per dirty tile sollte eigentlich funktionieren. Aber wie gesagt, das Neurendern dauert ziemlich lange.

Danke für die Infos. Das Neurendern nach einer dirty Anfrage dauert in der Tat seeehr lange.

Das z12 Metatile auf humboldt dauerte über fünf Stunden (auf osm.org unter einer Minute), für gauss hatte ich vor drei Tagen und vor einem Tag nochmal eine dirty Anfrage gesendet, die Autobahn wird aber immer noch blass als construction (?) gerendert:
https://gauss.openstreetmap.de/12/2186/1419.png
https://humboldt.openstreetmap.de/12/2186/1419.png

Vermutlich liegt es aber nicht nur am Rendering, sondern evtl. auch an einer niedrigen Priorität für dirty Anfragen, die ggf. auch verworfen werden?

Zum Test habe ich jeweils zwei Anfragen für z18 gestellt, die auf beiden Servern alle um die zwei Stunden benötigten. Noch nie gerenderte Tiles in z18, durch Verschieben der Karte angestoßen, werden dagegen relativ zügig, zumindest im Minutenbereich, neu erstellt.

Gibt es ein öffentliches Munin, wo man die aktuelle Auslastung der Server sehen könnte? Oder legst Du schon neue Indizes an und wir sollten mit dirty Anfragen besser warten?