enable time filtering when metadata contains a timeInfo object

[ButchGis]

When timeInfo object was defined in provider metadata and (esri) client then sends query with time = 'epochsecondsStart, epochsecondsEnd'. I am doing a cached provider and was surprised that while I had defined the timeInfo object my returned results where not filtered for time.

It looks like the time option is not being handled by FeatureServer.

So I wonder where we would best handle time as passed in from an esri client when a provider sets a metadata timeInfo object?

I found the easiest place to 'monkey patch' it in was actual on the cache and not on FeatureServer. However this may not be the best or most koop way to design this.

Here's what I did to get this working in a fork of the cache project: koop-cache-memory.

[rgwozdz]

Yeah, I would not want to put this on cache. It would then have to be implemented on every cache-plugin. Also, the cache plugin shouldn't be responsible for filtering. This should be a part of FeatureServer/Winnow.

If you want your cache to store filtered data you need to do that filtering in your provider before the geojson is passed on to the callback. You can either have the remote API do such filter, or do the filtering yourself once you get the remote data. Some providers use Winnow library to do this; if you properly set the filtersApplied property, then FeatureServer won't try to filter the data a second time.

[ButchGis]

Rich, it seems right to me not to do at cache level. But the filtering in FS is not doing anything about time = '<>,<>' query parameters that are sent in from wab, and portal arcgis clients. The parameter is there in the options object but never acted on. There's also no filtersApplied for time only. You'd have to take on the entire where clause. Even though the time piece seems to be distinct element in ArcGIS and is parameterized outside the where element. When data is pulled from a cached provider the provider createkey method is called but when data is already cached nothing else from provider is called. Client expects time to be filtered when they send time='<>,<>' parameter but FS is not doing this. I don't want my cache to store each time slice in a new set that includes time='<>,<>' in the key. But otherwise I can not affect the required out come in a cached provider. Approached as a '3rd party' fix, a cache plugin can be used to tackle this issue and not have to monkey patch core koop modules. I have this in place but would like to contribute to core so that no fix is required. I guess winnow needs to handle options.time. I think the filtering I implemented on the cache retrieve could be placed in the winnow module. Butch

…

________________________________ From: Rich Gwozdz <[email protected]> Sent: Friday, January 31, 2020 1:21 PM To: koopjs/FeatureServer <[email protected]> Cc: Anthony Fragale <[email protected]>; Author <[email protected]> Subject: Re: [koopjs/FeatureServer] enable time filtering when metadata contains a timeInfo object (#175) Yeah, I would not want to put this on cache. It would then have to be implemented on every cache-plugin. Also, the cache plugin shouldn't be responsible for filtering. This should be a part of FeatureServer/Winnow. If you want your cache to store filtered data you need to do that filtering in your provider before the geojson is passed on to the callback. You can either have the remote API do such filter, or do the filtering yourself once you get the remote data. Some providers use Winnow library to do this; if you properly set the filtersApplied property, then FeatureServer won't try to filter the data a second time. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_koopjs_FeatureServer_issues_175-3Femail-5Fsource-3Dnotifications-26email-5Ftoken-3DAH2TAV7EP722YO4DWAETZJLRART3VA5CNFSM4KLSK6KKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKPRD5I-23issuecomment-2D580850165&d=DwMCaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=CjzKn4LMK8XMlUn2RqpGT4XBjFCdyudPrnhO5cbl08k&m=ULwialWCVffEgWCKINeTLkiim3rbqh1gWlU3NC4Mwgw&s=ycyXE4T04aCpydIxW9avqe6VTl0LaA8FnrHkDQcXkxU&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AH2TAV7FZT4QRAVXOMPVFG3RART3VANCNFSM4KLSK6KA&d=DwMCaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=CjzKn4LMK8XMlUn2RqpGT4XBjFCdyudPrnhO5cbl08k&m=ULwialWCVffEgWCKINeTLkiim3rbqh1gWlU3NC4Mwgw&s=CDdWr3LzQR2p-ZS1k1xTf4AX_UXL6Ku5N08pbv8X55E&e=>.