Is het mogelijk om delen van een tegelpiramide opnieuw te renderen wanneer postgis-tabelupdates?

Ik heb dit idee om postgis te gebruiken in combinatie met een tegelrenderer voor het bedienen van mijn organisatie met tegelkaarten. Aangezien ik geloof dat mijn gegevens bijna dagelijks gedeeltelijk worden gewijzigd, voelt het als een prestatieprobleem als ik de hele cache elke nacht moet weergeven omdat de wijzigingen vrij klein maar nog steeds aanzienlijk zijn.

Zou het mogelijk zijn om delen van een piramide tegel of een raster opnieuw te renderen in plaats van een volledige re-rendering?

En heeft iemand geprobeerd om deze rendering uit te voeren in bijvoorbeeld mapnik van binnenuit postgresql/postgis met behulp van een databasetrigger? Ik geloof dat het eerste probleem zou zijn om te bepalen welke tegels worden beïnvloed en vervolgens specifiek opnieuw te renderen.

Om het even welke ideeën?

4
Ik gebruik geoserver om mijn kaarten weer te geven en ik vernieuw mijn volledige informatie elke 2 minuten, ik hoef alleen de geoserver-cache te verwijderen en de tegels worden on-demand gegenereerd.
toegevoegd de auteur Christian Rau, de bron
@FishHead: deel uw bevindingen alstublieft.
toegevoegd de auteur xyz, de bron

2 antwoord

Je zou dat eenvoudig moeten kunnen bereiken door:

  1. implementeer een trigger voor invoegen/bijwerken die gewijzigde functies in een werkwachtrij plaatst
  2. een werknemer die regelmatig zwaait en dingen vastgrijpt om uit de wachtrij te doen en tegels vernieuwt

Item 1 kan eenvoudig worden geschreven in pure sql in postgres door middel van een trigger. Voor item 2 hoeft u alleen maar het seed-programma (alle caches voorzien er een) te bellen met de volgende opties:

  • dwingen: tegels opnieuw genereren, zelfs als deze al aanwezig zijn in de cache
  • bbox: regenereer alleen tegels voor de opgegeven bbox, die in uw geval de bbox van de gewijzigde functie is

Tip: documentatie link voor het betreffende gedeelte van de TileCache handleiding.

Houd er rekening mee dat het misschien de moeite waard is om sommige bbox-samenvoegingen te doen voordat u het reseeding-proces start, omdat het zeer waarschijnlijk is dat veranderingen plaatsvinden in ruimtelijk nauwe/beperkte gebieden en dat u daardoor steeds opnieuw dezelfde tegel kunt regenereren.

2
toegevoegd

Het zou gemakkelijk moeten zijn om in te stellen: in een iets andere - maar eigenlijk vergelijkbare - rastercontext moest ik een aantal GeoTIFF's updaten die een hele stad bestrijken, met verschillende sets geoTIFFs op verschillende zoomfamilies vanaf 9 tot 18. De GeoTIFFs pasten ook niet netjes in TMS/Google Maps tegelnummers.

In plaats van de hele taak opnieuw te betegelen (wat 19 uur kostte voor de volledige bestandsset), heb ik het zo ingesteld dat als een geoTIFF veranderde de renderer zou

  1. identificeer de reeks GMaps-tegelverwijzingen die de 'gewijzigde' tegel heeft doorkruist op de laagste gesmolten zoomlens (dat is gemakkelijk omdat de grenzen van GMaps-tegels bij elke zoomlens worden vastgesteld - zoek de set GMaps-tegels die de grenzen van de veranderde GeoTIFF);
  2. pak alle GeoTIFFs van dezelfde 'zoomset' die de GMap-tegels van (1) hierboven sneden; en
  3. maak een nieuwe 'base' GeoTIFF door de geoTIFFs samengevoegd te verzamelen bij (2) (een vrt maken met gdal);
  4. tegel de resulterende vrt van de laagste zoom tot de hoogste zoomlens voor de geoTIFF in kwestie.

Het herbestemmen duurde nooit langer dan een paar minuten: dat is enorm veel beter dan 19 uur.

Met PostGIS-gegevens zou het eigenlijk veel eenvoudiger moeten zijn, omdat het niet nodig is om rastervergelijkingen uit te voeren en wat-niet-alleen nodig is om de basiskaarttegels te vinden die worden beïnvloed op het laagste zoomniveau, en tegels te genereren voor het omsluitende kader van die tegel en alle zijn kinderen (dwz alle hogere zoomniveaus).

Dus als ik met uw taak werd geconfronteerd (en niet wetende wat uw basiskaart is - Google Maps, OSM, Bing, aangepast), zou ik vaststellen welke basiskaarttegels werden beïnvloed door de wijziging in uw gegevens op het laagste zoomniveau waarbij de gegevens worden weergegeven en alle items in die tegel en de onderliggende items opnieuw worden geplakt.

Als u minZoom kent voor de betreffende gegevens, is het vinden van het basisteennummer eenvoudig (de geweldige code van Klokan Petr Pridal op tiles à la Google Maps waarmee je de TMS- of GTile-referentie - en de bijbehorende grenzen - kunt vinden voor een willekeurig punt ... scroll op de pagina en zoek naar een groot tekstvak. Het heeft me enorm geholpen met mijn taak).

En ja, het zou in staat moeten zijn om als een trigger te worden opgezet: triggers kunnen bijvoorbeeld Python-scripts of andere dingen die het werk voor je doen, oproepen.

In het weekend zal ik proberen mijn oude code op te graven en te tweaken om hem meer vectorgericht te maken (zoals ik al zei, dit was een op rasters gebaseerde taak).

0
toegevoegd