[Feature Request] Add support for filtering layer dynamically

[aaj013]

I haven't seen any options right now within Tegola to pass on parameters from frontend to DB for filtering the input dataset. Is there any updates on that?

[ARolek]

@aaj013 it's not currently on our roadmap. Could you give a more concrete example on how you would want this to work from the frontend? It's an interesting idea though I see it conflicting with concepts like tile caching, but I'm open to exploring the possibility.

[aaj013]

I see the same functionality in another vector tile server Martin passing on parameters from client side to plpgsql (https://github.com/urbica/martin#function-sources). Wouldn't it be nice to integrate that feature?

[tomass]

One possible use case:

There is a tourism map/website allowing you to choose a number of POI types to display from a list of ~50+. It then uses a bbox strategy to request a list of poi's in a viewport (bbox), something like poi.php?bbox=12,23,45,56&type=ABC (where A, B and C are types of POI to be displayed). This works with OpenLayers.

While trying to migrate to mapbox-gl-js, there is a problem: bbox strategy is not available in mapbox-gl-js.
Putting all 50+ categories of POI's into one source of vector tiles is not nice, as there is a requirement to display POI's even on small scales (putting all POI's on small scales would make vtiles too large).

Having as many vector tile sources/layers as POI types (50+) would be too cumbersome/slow when a lot of POI types is selected. And map style file would have to include all 50+ types separately.

Solution could be to use similar request url but with parameter, say: 15/78/456.pbf?type=ABC
Argument "type" with value "ABC" could be passed to Tegola so that it does a one-time query, creates a pbf, returns it and does not save in a cache. Query could be written like this:

select ...
from ...
where instr(:type, field_type) > 0

P.S. This is just a theoretical use case. I have not tested if this would be usable in mapbox-gl-js.

[ARolek]

@aaj013 one thing about martin is that it only supports PostGIS. Tegola has more than one provider type so I'm always trying to think of how we can make the implementation provider agnostic. I have not dug into Martin too much, but do you know if it supports a tile cache along with the query feature? I think that would be an interesting challenge to tackle.

@tomass this is an interesting use case and seems to be very specific. I still think we're going to run into issues with a tile cache, but I guess in this use case there would be no tile cache. I'm not opposed to this feature, just trying to understand the use case more.

[jcallin]

Tilegarden does this by letting the client include filters in the header

[
    {
        "name":"layer1",
        "mode": "AND" // optional, operator to use to combine filters, can either be AND or OR, defaults to AND
        "filters": [ // optional, applies no filters if missing
            {
                "col":"column1", // table column you wish to filter by
                "val":"value1", // value to filter on
                "op": ">" // optional, boolean operator to use when comparing col to val, = by default
            }
        ]
    }
]

Useful if you only want to return geometry from a specific set of data. Maybe you have many data collection projects that each store geometry in the same geographic area, but you would like to view separately. A lot of tile servers (this one included) are configured to source geometry from one table specified in a config file, so you wouldn't be able to store data in separate tables and query it out based on client input.

[ARolek]

I'm starting to see more and more use cases for this. Tegola has the concept of map tiles (encodes several layers together in a single tile request) and then layer tiles (only has a single layer encoded in the tile). I think adding support for filtering on the layer requests could make sense. If this were to be implemented, support for caching individual layer caches would probably need to be dropped (not a big deal, I think this is rarely used right now).

@jj0hns0n do you have a link to what OGC came up with as a solution for this? Looks like there are several strategies tegola could adopt for layer filtering, so I would like to get that one into the conversation.

[durkie]

Just wanted to echo my interest here as well. My use case involves serving different tiles to different users, so my maps all make tile requests in the form of user_id/z/x/y

Of course, the reason I'd like dedicated tile server is to reduce the load on my PostGIS sever since many of these tiles are too complex to be rendered on the fly, so it'd be ideal if there were some way to preserve caching here.

Edit: just to add an additional note, I'm rendering primarily a single layer of custom data, which gets displayed on top of existing mapbox gl vector tiles. I have needs for upwards of 3 layers, but could manage with one.

[ARolek]

@durkie thanks for chiming in. This feature is getting requested more and more and I'm hearing a few different query strategies. I'm also aware the OGC has recently completed a testbed to standardize a spec for vector tile querying. I believe they rallied around CQL, but I could also see the simple use case of query strings.

In your use case, you're looking for caching the queried tiles. The initial idea is to not provide caching for tiles that can be queried. One way we could potentially accommodate this is to allow a user-defined cache key which would need to be provided at the time of the query. For example, in your use case, it would be user_id and the tiles could be written to that namespace.

[flyingjoe]

I'm also interested in this. I am currently using martin with postgis to create vector tiles. As I would like to decrease load on the database, I'd like to use tegola on lambda.
In my use case the frontend makes a query for multiple ids, whose linestrings martin then returns as a single layer.
The current request looks something like this: /map/item_ids=[1,2,3..]
So if filtering would be possible in tegola, it would be a perfect fit.
Are there any plans to implement something like this in the future?

[ARolek]

@flyingjoe It's something we would like to implement but it's a fairly involved feature. If I have to be honest, I think it might take a commercial use to help resource the development. We would absolutely support a PR if someone would like to lead the effort. I have some ideas on the design, but there's a lot to think about.