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.
>
> 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 :-)
>
> 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)
>
> 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
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
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