Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling expire #26

Open
joto opened this issue Feb 7, 2025 · 0 comments
Open

Handling expire #26

joto opened this issue Feb 7, 2025 · 0 comments

Comments

@joto
Copy link
Contributor

joto commented Feb 7, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant