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