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).
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 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.
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?)
On Thu, Nov 21, 2013 at 1:38 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Thu, Nov 21, 2013 at 10:31 AM, Christian Mueller <
> christian.muel...@os-solutions.at> wrote:
>
>> I will give you an example:
>>
>> Given a normal select
>>
>> select * from table mytable where ....
>>
>> If this table has business time support it would be
>>
>> select * from table mytable as of business_time of '2011-01-01' where ....
>>
>> The syntax extension is in the "from" clause. The above query returns
>> only records valid at '2011-01-01'. A simple
>>
>> select * from table mytable where ...
>>
>> would return all historical versions, this is unwanted in most scenarios.
>> If the date is missing it should be
>>
>> select * from table mytable as of business_time of current time where ...
>>
>> This select returns all actual versions.
>>
>
> Hmm... seems pretty close to what GeoServer is doing when time is
> activated on vector data, without need for
> any special database support:
> * if you specify a date range in TIME, it will add that as a search clause
> * if you don't specify any, it will use the most current time in the
> database... the only thing is that it will take time to extract it, which
> is likely suboptimal
>
>
>
------------------------------------------------------------------------------
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
