On Sun, Jun 24, 2012 at 2:11 PM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Sun, Jun 24, 2012 at 7:17 PM, Justin Deoliveira
> <jdeol...@opengeo.org>wrote:
>
>>
>>
>> On Sat, Jun 23, 2012 at 3:47 AM, Andrea Aime <
>> andrea.a...@geo-solutions.it> wrote:
>>
>>> On Fri, Jun 22, 2012 at 9:04 PM, Justin Deoliveira <jdeol...@opengeo.org
>>> > wrote:
>>>
>>>> Hi all,
>>>>
>>>> We have a client with the following use case. They are serving up time
>>>> based hurricane data that is constantly being updated. And often the
>>>> dataset will be completely empty. In that case what they want to show is an
>>>> empty map. Currently this fails when trying to query the layer without
>>>> specifying a timestamp ,which defaults to "current". That causes a query
>>>> for the max time in the dataset and because there are no features it
>>>> chokes.
>>>>
>>>
>>> It chokes how? During the query itself?
>>> It would be nice if we could just get "null" back and handle that by
>>> returning an empty image?
>>>
>>
>> It throws an exception from WMS.getCurrentTime(). Long story short it
>> uses a MaxVisitor to figure out the max time from the dataset which thows
>> an exception from getMax() since no features are visitied.
>>
>
> This sounds like a bug to me. If I run a query in SQL asking for the max
> of an empt table I just get back a null, this should work the same.
>
Agreed. I'll see if about updating the visitor but simply returning null
from WMS.getCurrentTime() will just push the problem further down the chain.
>
>
>>
>>>
>>>>
>>>> So... how to fix. I can think of a few possibilities.
>>>>
>>>> 1. Force the client to always specify a explicit time. Not ideal for
>>>> them in this case because they rely on the fact that not specifying a time
>>>> stamp will return the "current".
>>>>
>>>> 2. Explicitly handle the empty case and when asking for the "current"
>>>> time we literally return back the current time at that instant.
>>>>
>>>
>>> Which would result in an empty response too. Wondering though, what if
>>> in the request we have two layers with time enabled, one
>>> that has a current value, one that does not?
>>>
>>
>> Hmmm... right. They would result in different times being queries. But
>> afaik we already have this issue right? Both layers are queried
>> individually for the max time and they could be different?
>>
>
> Correct, we're toast anyways, not sure even what the correct behavior
> would be:
> - if we extract a different "current" for each layer we'd get a
> representation mixing different times
> - if we extract the max of the maxes possibly only one layer would show up
>
> My worry is that grabbing a fixed time we could end up catching some data
> from other layers that would have not showed
> up otherwise (data coming from computerized simulations might refer to the
> future, so chosing "now" does not mean chosing a value higher
> than any other).
>
Right... definitely a complex issue and I don't thinking the spec is very
clear about this afaik? So I don't imagine i am going to tackle the bigger
issue here so the question is is just updating WMS.getCurrentTime() to
return the actual current time when no data is available acceptable? Or do
we feel an exception as it is now is better behaviour?
> Cheers
> Andrea
>
>
> --
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
