You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need some way to handle expiry with Themepark. Here are some toughts about his:
The author of a theme/topic probably knows best how to configure the expiry in detail. They know which table needs boundary-only vs. full-area expiry for instance. So they need to set these. It might still be useful if it were possible to overwrite this from outside the topic, for instance if the user knows that their special map renders forests only as outline, then they might want to change this.
The user knows best where the expire list should go. Some file in their file system, or a special table in their database. Only they can know this, because the mechanism that takes this expire list and actually expires the tiles is outside the responsibility of osm2pgsql.
It is a bit more complex for the settings of zoom levels. Because the theme/topic probably knows roughly for which zoom levels a table is intended (say a POI level for 12+, a table with generalized landue data for 4-8 or whatever) but this might also depend on the rendering style and expiry policy might also be set by the user depending on available resources (only expire zoom levels X to Y once a week).
In the simplest case (for instance when for many raster tile setups) we only have one expire output. But it should be possible to have several, say different zoom level ranges or for different tables, if you have some kind of setup where different vector tile layers are expired independently or something like that.
All of the above is for the case where expire is done so that generated tiles can be expired, lets call that external expire. But there is also internal expire. That's the expire setup used for generalization, that's basically internal to the functioning of osm2pgsql. And that's completely the responsibility of the theme/topic. Both of these need to work side by side. Internal expire works already in Themepark by adding an expire setting to a table which is then added by Themepark to the geomtry column.
We already have a mechanism to define the min and max zoom of tiles for a Themepark table. This is currently only used when generating a tile server config with Themepark. But it would be nice if this can be integrated with expiry somehow, because for simpler setups this would avoid duplication.
This suggests some kind of setup where the user defines the expire outputs (for external expire ) in their main config file and gives them to Themepark/a theme/a topic in some way.
In the simplest case we only want one expire output for everything. So it should be possible to define one expire output and set this as some kind of default. For a bit more complex setup we want to set this by topic. (Or even more detailed if a topic generates multiple tables). I could imagine some kind of callback mechanism (a bit similar to how we handle names) where a function (get_expire_config) is called from the topic for each table. That function is given as parameter the theme, topic, table name, tile zoom range and/or expire config suitable for that table. By default it just returns nil, so there is no expiry. You can overwrite this function with anything you want doing arbitrary complex configurations, or choose one of two or three predefined functions that implement common use cases.
The text was updated successfully, but these errors were encountered:
We need some way to handle expiry with Themepark. Here are some toughts about his:
expire
setting to a table which is then added by Themepark to the geomtry column.This suggests some kind of setup where the user defines the expire outputs (for external expire ) in their main config file and gives them to Themepark/a theme/a topic in some way.
In the simplest case we only want one expire output for everything. So it should be possible to define one expire output and set this as some kind of default. For a bit more complex setup we want to set this by topic. (Or even more detailed if a topic generates multiple tables). I could imagine some kind of callback mechanism (a bit similar to how we handle names) where a function (
get_expire_config
) is called from the topic for each table. That function is given as parameter the theme, topic, table name, tile zoom range and/or expire config suitable for that table. By default it just returns nil, so there is no expiry. You can overwrite this function with anything you want doing arbitrary complex configurations, or choose one of two or three predefined functions that implement common use cases.The text was updated successfully, but these errors were encountered: