On Mon, Feb 10, 2014 at 10:31 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
>
>
> Hi IIkka, yes, this is what I had in mind. Thanks for the screenshots and
> the configuration examples.
>
The amount of changes is large, we'll need a GSIP, I'll help preparing one
> once the feature freeze is over (less than 10 days now)
>
Sounds good. The refactoring of my original proposal into a more generic
solution with Spring-injectable strategy implementations resulted in quite
a few new classes, and the presentation of default values in the
capabilities meant that a few changes also had to be made in those parts.
However, I think the end result fits well into the Geoserver architecture
and makes it easier to extend the dimension support in the future.
BTW: I believe that the changes made here, namely in finding the nearest
and "current" values from the dimension domain, would also make it
relatively easy to implement support for the "current" and "nearestValue"
attributes in WMS 1.3.0 Dimension elements ("current" and "nearestValues"
for WMS 1.1.1 Extent elements). This is obviously another issue to be dealt
with and it may not make sense to mix this in the soup at this point.
>
>>
>> I see one possible performance problem in this solution: as the default
>> values for each layer and dimension is now resolved using the actual domain
>> values in most cases, this might make the GetCapabilities request slower to
>> produce if the values have to be retrieved form the disk/database.
>>
>
> Yes, unless the administrator uses only FIXED strategies of course.
>
Using the NEAREST strategy for TIME dim and "current" as the reference
value should also be as fast as before for producing capabilities, as it's
not resolved at this point.
> I have not looked at the code yet, but for database usage one can get it
> to work "quick" using two queries, one that selects
> the max of the values lower than the reference, and one that selects the
> min of the values highest than the reference, and then
> pick the closes of the two (which I believe could be expressed with a
> single complex query to, but we don't have the luxury
> of writing direct SQL, whilst query + min/max visitors can be encoded
> against all data sources... and it would be good to
> know if we are playing against a db or not too, since a single pass
> through all the data if faster against any other data source
> instead, especially those that cannot do sorting...)
>
Ok, waiting for your input (and that of the other core developers) in this
matter. I've not tried to to do any new optimizations in the code yet.
Ilkka
--
Ilkka Rinne
Founder, Chief Technology Officer, Spatineo Oy
Email: ilkka.ri...@spatineo.com
Skype: ilkka.o.rinne, phone: +358 50 523 8974
Linnankoskenkatu 16 A 17, FI-00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
Google+ google.com/+Spatineo
www.linkedin.com/company/spatineo-inc
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
