On Fri, Oct 18, 2019 at 1:19 PM Even Rouault <even.roua...@spatialys.com> wrote:
> On vendredi 18 octobre 2019 12:28:12 CEST Alessandro Pasotti wrote: > > Hi, > > > > I was thinking about how to better implement this feature for QGIS server > > (but it does not need to be restricted to the server). > > > > The WFS3 specs covers pretty much all use cases: you can have features > with > > a single date/datetime temporal property and a set of date/datetime > > properties, the latter case can (not "must"!) be used to define one (or > > many) date/datetime intervals. > > > > Now, the specs say that it's up to the server to decide if only a single > > property has to be considered when querying or if multiple properties > have > > to be combined together to create one (or many) intervals. But since we > > code the server it means that it's up to us to decide how to handle it. > > > > Note that the conditions need to be AND(ed) and unless properties values > > are equal this does make sense only when multiple properties are combined > > to form intervals. > > > > So, the question is how to model this in QGIS? > > > > Since this information may spread over multiple fields, I think it should > > go into the QgsVectorLayer class (or some separate temporal settings > > companion class/struct). > > Hi Alessandro, > > Hi Even, Are you thinking to scenarios like a layer would have an "eventStart" and > "eventEnd" timestamps and you would want them to be considered together > when > an incoming request with a datetime=request_begin/request_end interval > arrives, so as to only select features whose eventStart <= request_end and > eventEnd >= requestbegin ? > Yes, but not limited to a single pair of eventStart/eventEnd: we might have more intervals and since the specs talk about "overlap" operator I can imagine that it would make sense and work to search simultaneously on several intervals. > Your above proposal makes sense, but involves complication. Yes: plenty of complications :) > I think it might > be wise to wait a bit before designing this, beause filtering is going to > be > the main topic of the next OAPIF Hackathon in November ( > https://www.opengeospatial.org/events/191105apisprint ), so an extension > with > more complex/complete filtering (probably similar to what FES offers) is > likely to be created. So I can imagine that it would offer the possibility > to > explicitly filter on multiple datetime properties. Yet that wouldn't solve > the > issue with the datetime filtering capability of OAPIF core, but perhaps > for > core, we could adopt a simple solution, like use the first datetime field > of > the layer by default, unless the user (QGIS server admin) selects another > one. > And if more complex behaviour is desired, then OAPIF clients would use the > filter extension to be able to combine filters on several fields. > That makes perfectly sense to me, I'll take this route for now and take the first date/datetime field for filtering **and** allow the user to configure explicitly one (or more) filtering fields from the GUI. What I will NOT implement for now, is interval search on the target features (which is the most complicated part). And thank you for your feedback! -- Alessandro Pasotti w3: www.itopen.it
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer