[QGIS-Developer] QGIS WFS3 Server temporal intervals

[Alessandro Pasotti]

On Fri, Oct 18, 2019 at 1:19 PM Even Rouault <even.rouault at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20191018/e7c531e7/attachment.html>