On Mon, Nov 25, 2013 at 11:19 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:

> On Mon, Nov 25, 2013 at 7:34 PM, Martin Davis <mtncl...@gmail.com> wrote:
>
>> Andrea,
>>
>> If I understand the GeoServer/OGC TIME model, then it is actually quite
>> different to the temporal model in SQL:2011 (which is similar to what IBM
>> and Oracle provide).
>>
>> In GeoServer, is the case that the TIME request parameter defines a time
>> instant or a time range, which is then used as a filter against a single
>> timestamp column in the underlying datastore?  In this case, this allows
>> filtering records which occur at a single point in time (such as
>> observations, which is probably the original use case addressed by the OGC).
>>
>
> Yes and no. We support both single time and interval.
> If you filter against an instant, we use it to extract all records
> matching that instant (more than one could apply), or all the records with
> a interval containing that time.
> If you provide an interval for filtering , then all the ones with a time
> in that interval (or with an interval overlapping that interval) will be
> returned.
>

OK, great. I missed that (because it isn't in the docs, and I hadn't
noticed that the Layer def screen allows you to enter both a start and end
time).

>
>
>>
>> In SQL:2011 the model is richer, since it supports modelling and querying
>> records which occur over a time period.  To model this *two* timestamp
>> columns are required, START_TIME and END_TIME, Queries can filter records
>> based on their period intersecting an instant or another period.  An
>> important case of this is querying current records (which are typically
>> modelled by having a null value for END_TIME.  The queries get a lot more
>> complicated because of the multiple columns involved, which is why the DBs
>> are starting to provide sugar to make this simpler.
>>
>
> It's not actually that complicated to implement, and we already have it :-)
>

I meant it's complicated/error-prone if a table is bi-temporal, and even
more complicated to create temporal queries across joins - for a human.
 But agreed, creating the queries automatically for a single time dimension
isn't too hard.

>
>
>>
>> It would be interesting if GeoServer started to move towards supporting
>> this model.  It should be possible to implement this kind of query in the
>> middle tier, as long as the start and end time columns were providing in
>> the layer metadata.  Of course, in this case it would be ideal to push the
>> query down into the DB whereever it is supported natively.
>>
>
> I'm still confused about what this actually buys us.
> What I could see is that the db is in charge of ensuring data integrity
> (something that GeoServer does not care about in fact), but at the price of
> making
> the code to deal with the db actually more complicated than it is now
> (since we have to support the plain model, and the one with temporal
> support enabled)
>

Yes, the code will be more complicated.

As for what it buys, I'm not sure. There might be some performance
improvements if the underlying DB temporal system is used.  There's less
metadata required (although that's a wash, since it's already in place).
 Also, in Oracle the actual timestamp columns for a valid time period I
think are hidden columns (using a new feature in Oracle) - so not sure how
this will work with GeoServer.

I'm going to try the current GeoServer TIME implementation with our data.
 If it works and performs, then I'm happy....  8^)


>
>
>>
>> There's an additional wrinkle with Oracle's temporal model, which I'll
>> describe in a followup email.
>>
>> BTW, in the GeoServer manual the TIME request syntax is well described,
>> but it would be nice to have a description of the the GeoServer TIME query
>> model semantics as well (or at least, I wasn't able to find it).  Perhaps
>> this should go with the description of how to enter the Dimension
>> parameters in the Layers page (also missing?)
>>
>
> Read the WMS specification, time/elevation support, we implement that,
> with no extensions
>

Well, sure, but we all know how easy the OGC specs are to read...
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Reply via email to