Updateinterval bei openstreetmap.de?

opendcc · 2019-11-16T08:39:04.000Z

Hallo,

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?zoom=11&lat=48.21126&lon=12.11377&layers=B000TT ist auch nach etwa 7 Wochen die Kachelansicht noch auf dem Stand vor der A94. (Höherer Zoomstufen haben es dann schon berechnet.)

Und das gibt dann z.B. diesen Hinweis eines Nutzers: https://www.openstreetmap.org/note/1996254

In welchen Intervallen wird das Kachelbild auf www.openstreetmap.de berechnet und kann man das irgendwie anstoßen (Attribut ‘dirty’ ?).

KPG · 2019-11-16T09:06:45.000Z

… und auf der Radfahrerkarte ist über alle Kacheln “API Key Required” gepinselt.

geri-oc · 2019-11-16T09:08:57.000Z

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

Nakaner · 2019-11-16T09:22:04.000Z

Hallo,

opendcc:

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?zoom=11&lat=48.21126&lon=12.11377&layers=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

ikonor · 2019-11-16T10:51:29.000Z

Laut dieser Seite kann auch bei openstreetmap.de /status und /dirty anhängen:
https://wiki.openstreetmap.org/wiki/DE:Featured_tiles/Updates#Sofort_rendern

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

/status (Auszug):

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

giggls · 2019-11-16T17:59:22.000Z

ikonor:

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-carto-de/blob/master/indexes-hstore.sql

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

Sven

giggls · 2019-11-16T18:00:54.000Z

KPG:

… 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?

Nakaner · 2019-11-16T19:37:42.000Z

Hallo Sven,

giggls:

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-carto-de/blob/master/indexes-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

Mueck · 2019-11-17T12:17:36.000Z

giggls:

KPG:

… 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?

ikonor · 2019-11-22T15:58:50.000Z

Zoom 10 und 11 sind inzwischen auf beiden Servern aktualisiert.

giggls:

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?