On Tue, Aug 14, 2012 at 1:52 PM, David Winslow <[email protected]> wrote:
> Hmm, that 'nearest values' behavior is interesting:
>
>
> This allows, for example, hourly data whose actual recording time is
>> precise to the millisecond to be
>> requested simply by stating the desired date and hour.
>
>
> That sounds an awful lot like the range behavior we've been discussing -
> making this behavior optional (on a per-layer basis) seems to imply that
> the default should something else (probably what Ian is suggesting.)
>
> Then it follows up with
>
> If a request includes an imprecise dimensional value, and nearest value
>> behaviour has been declared, then the
>> server shall compute and send the nearest available value. The value
>> shall be rounded, not merely truncated. If
>> nearestValue selection is not supported, then the server shall throw an
>> Exception (code="InvalidDimensionValue")
>> to indicate that a value was required.
>
>
> I don't understand what the rounding vs. truncation distinction has to do
> with this situation (since it would seem that we are going from a
> less-precise to more-precise value)
>
Could it mean that in order to determine candidate data values for the
"nearest value", the data values should be rounded rather than truncated?
This would mean that the nearest data value might actually be less than
the request value. (This is different behaviour than the "interval"
semantics under discussion.)
> but the requirement to "throw an Exception" suggests that we should just
> be requiring the precision in the request to at least match the precision
> in the data when this nearest-value behavior is not enabled.
> (Implementation-wise there's a difficulty here as we don't track precision
> after the request is parsed initially, making it hard for us to detect the
> value.)
>
And we also don't know the underlying precision in the data, right? So
this would effectively say that every request time value requires full
precision.
It's hard to see clients relying on exceptions being thrown if they fail to
heed the absence of declared nearest-value behaviour. Pretty complex
semantics for that. So maybe this doesn't stop a server from being more
lenient in what it accepts.
>
> Since the TIME parameter does not support per-layer values this would seem
> to make multi-layer requests with mixed time resolutions require a time
> range.
>
>
> --
> David Winslow
> OpenGeo - http://opengeo.org/
>
> On Tue, Aug 14, 2012 at 4:05 PM, Andrea Aime <[email protected]
> > wrote:
>
>> On Tue, Aug 14, 2012 at 9:44 PM, Ian Schneider <[email protected]>wrote:
>>
>>> I don't mean to sound disgruntled, but want to reiterate that this
>>> choice is being made to satisfy a desire to provide ease of use for a
>>> human when using a machine protocol - the effort, in my mind, should
>>> be made on creating an intuitive client (library, UI, or even
>>> documentation of proper use) to the latter.
>>>
>>
>> I don't know if this is in scope, but the WMS CITE tests for dimensions
>> demand that we are able to do a number of things, including being able
>> to setup the "nearest" behavior on a layer per layer basis, see:
>> http://cite.opengeospatial.org/test_engine/wms/1.3.0/
>>
>> The tests for dimensions also make a set of assertions regarding the
>> treatment
>> of nearest, see here:
>>
>> https://svn.opengeospatial.org/ogc-projects/cite/scripts/wms/1.3.0/tags/r3/ctl/dimensions.xml
>>
>> I'm not saying that your work must respect the above... but it would be
>> really nice if it did
>> not impede a compliant implementation.
>>
>> 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 962313
>> mob: +39 339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> -------------------------------------------------------
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
