1ec5
commented
1 month ago For any style layer that’s already written as an expression, we should probably use the start_date and end_date properties instead of start_decdate and end_decdate, respectively. This would eliminate any possible discrepancies between the existing PL/pgSQL implementation and the simpler JavaScript implementation that I advocated for in #562 and implemented several times above.
The existing implementations all key off the decimal date fields because MapLibre’s legacy filter syntax can only compare strings verbatim. With expressions, we can parse the strings and compare them lexicographically. This not only avoids any floating point precision error but also potentially opens the door to intraday filtering, once the tiles expose the contents of start_date:edtf=* and end_date:edtf=* tags: https://github.com/OpenHistoricalMap/issues/issues/15#issuecomment-1567454126.
The timeslider library is fine if you already have a Leaflet map set up and want a full-blown UI, but a developer might be using a Mapbox/MapLibre GL JS map directly or they might only need the filtering capability without an interactive slider UI. Perhaps they want to supply their own UI with a distinctive design, or they only want to show a particular date noninteractively.
We should publish an NPM library that only contains the runtime styling code for manipulating the stylesheet’s filters using runtime styling. There are already many reimplentations of this code that could benefit from consolidation, such as:
None of these implementations follows the Leaflet timeslider plugin’s date filtering implementation, which is too complicated to use as an example: #562.
For #651, we’ll need to reimplement the timeslider to eliminate its Leaflet dependency. This would be a good opportunity to have the Leaflet timeslider plugin depend on a consolidated library.
As soon as we convert the stylesheets to use expressions (#775), we’ll need to update each of these implementations to manipulate expressions instead of legacy function-based filters, as outlined in https://github.com/gramps-project/gramps-web/pull/454#discussion_r1664621357. We might as well migrate them to this new library at the same time. The library could support either syntax for broad compatibility.