[Geoserver-devel] Managing default value in wms dimensions, starting to get a number of ad-hoc solutions

GeoServer GeoServer Developer
1

Hi,
right now we have two pull requests related to the management of the default
value in WMS dimensions:

  • jwood106 pull request https://github.com/geoserver/geoserver/pull/377 allows the
    specification of a specific value for elevation dimension over raster data.
    It changes the DimensionInfo API to store a specific value for the selected default.
  • ilkkarinne pull request https://github.com/geoserver/geoserver/pull/430 adds two
    different strategies to handle the default value of the time dimension, either choosing
    the latest value in the sequence, or the closest one to the time the WMS request was made.
    There is not configuration in this case, a system variable drives the choice instead.

The two pull requests could coexist, but it seems to me things would be rather messy
if we merged them, with a few ad-hoc solutions to the problem of choosing the
default value for a dimension, and possibly others to come, including;

  • fixed value for vectors, time and custom dimensions too
  • min/closest to the zero (or other reference point) as the default value for elevation

I’m wondering about having a more general solution then, one in which the two above
patches could be seen as plugins, delivering exactly the same functionality, but
with the option to grow the set of “default value selectors” without having to also grow
the number of ad-hoc changes around.

Idea:

  • Following pull 430 approach, but making it more general, create a new DefaultValueStrategy,
    which can be used to compute the default value for a given combination of dimension type and layer.
    The interface would look something like the following:
    interface DefaultValueStrategy implements Serializable {

/**

  • Gets the actual value given the resource, the dimension, and the selected values for the already processed dimensions
    */

Object getDefaultValue(ResourceInfo resource, DimensionInfo dimension);

/**

  • Returns the capabilities representation of the default value. For example, it could be “current”
    */
    String getCapabilitiesRepresentation(ResourceInfo resource, DimensionInfo dimension);
    }

These objects would become part of the DimensionInfo, and would be serialized with XStream along with
all the state they need to perform the computation:

interface DimensionInfo {
…

DefaultValueStrategy getDefaultValueStrategy();
void setDefaultValueStrategy(DefaultValueStrategy);
}

and the xml could end up looking something like (having the proper xstream aliases registrations)
for fixed value choice:

true att LIST EPSG:5030 m 123

or something like this for represting current with the nearest value to the time of the request (which
does not need any inner field):

true att LIST EPSG:5030 m
  • In order to locate and create the strategies depending on the current combination of resource and
    layer we’d have factories registered in the app-context:

interface DefaultValueStrategyFactory {
/**

  • Returns a strategy, or
    DimensionDefaultValueStrategy getStrategy(ResourceInfo resource, DimensionInfo dimension);
    }

The code implemented by the two pull requests could keep on working as it does now, being layer
specific, or dimension specific, but this would leave us the option of adding more and increase the
generality in the future

  • Finally, have the GUI use the above factories to locate the strategies usable for the current resource
    and dimension, presenting a drop down, and go back in the app context to find panel implementations
    that can handle the configuration of a certain strategy, if a GUI is needed at all:

interface DefaultValueStrategyPanelFactory { // all right, ugly name, suggestions??
FormComponent createUIForStrategy(ResourceInfo resource, DimensionInfo di, DefaultValueStrategy strategy);
}

Opinions?

Cheers
Andrea

–

== GeoSolutions will be closed for seasonal holidays from 23/12/2013 to 06/01/2014 ==

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

2

I agree that considering a unified approach for these two WMS dimension pull requests could add value. And as you mention, it could be good for later similar pull requests as well.

Jeffrey Wood

Software Engineer

Geocent

Email: jeffrey.wood@anonymised.com

Ph (BR): 225-214-4346

···

Hi,

right now we have two pull requests related to the management of the default

value in WMS dimensions:

specification of a specific value for elevation dimension over raster data.

It changes the DimensionInfo API to store a specific value for the selected default.

different strategies to handle the default value of the time dimension, either choosing

the latest value in the sequence, or the closest one to the time the WMS request was made.

There is not configuration in this case, a system variable drives the choice instead.

The two pull requests could coexist, but it seems to me things would be rather messy

if we merged them, with a few ad-hoc solutions to the problem of choosing the

default value for a dimension, and possibly others to come, including;

  • fixed value for vectors, time and custom dimensions too

  • min/closest to the zero (or other reference point) as the default value for elevation

I’m wondering about having a more general solution then, one in which the two above

patches could be seen as plugins, delivering exactly the same functionality, but

with the option to grow the set of “default value selectors” without having to also grow

the number of ad-hoc changes around.

Idea:

  • Following pull 430 approach, but making it more general, create a new DefaultValueStrategy,

which can be used to compute the default value for a given combination of dimension type and layer.

The interface would look something like the following:

interface DefaultValueStrategy implements Serializable {

/**

  • Gets the actual value given the resource, the dimension, and the selected values for the already processed dimensions

*/

Object getDefaultValue(ResourceInfo resource, DimensionInfo dimension);

/**

  • Returns the capabilities representation of the default value. For example, it could be “current”

*/

String getCapabilitiesRepresentation(ResourceInfo resource, DimensionInfo dimension);

}

These objects would become part of the DimensionInfo, and would be serialized with XStream along with

all the state they need to perform the computation:

interface DimensionInfo {

…

DefaultValueStrategy getDefaultValueStrategy();

void setDefaultValueStrategy(DefaultValueStrategy);

}

and the xml could end up looking something like (having the proper xstream aliases registrations)

for fixed value choice:

true

att

LIST

EPSG:5030

m

123

or something like this for represting current with the nearest value to the time of the request (which

does not need any inner field):

true

att

LIST

EPSG:5030

m

  • In order to locate and create the strategies depending on the current combination of resource and

layer we’d have factories registered in the app-context:

interface DefaultValueStrategyFactory {

/**

  • Returns a strategy, or

DimensionDefaultValueStrategy getStrategy(ResourceInfo resource, DimensionInfo dimension);

}

The code implemented by the two pull requests could keep on working as it does now, being layer

specific, or dimension specific, but this would leave us the option of adding more and increase the

generality in the future

  • Finally, have the GUI use the above factories to locate the strategies usable for the current resource

and dimension, presenting a drop down, and go back in the app context to find panel implementations

that can handle the configuration of a certain strategy, if a GUI is needed at all:

interface DefaultValueStrategyPanelFactory { // all right, ugly name, suggestions??

FormComponent createUIForStrategy(ResourceInfo resource, DimensionInfo di, DefaultValueStrategy strategy);

}

Opinions?

Cheers

Andrea

–

== GeoSolutions will be closed for seasonal holidays from 23/12/2013 to 06/01/2014 ==

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

3

Hello,

I'm the author of the mentioned pull request 430, and I'm liking the
generalisation of my original idea as proposed by Andrea. I dare not go deep
into implementation details, because while being an happy user on Geoserver
I have only limited experience for creating code for the project.

What kind of implementation plan and timeline would you see for do for this
kind of change in the Geoserver functionality? My client, the Finnish
Meteorological Institute, is already waiting for this fix, and I'm likely to
be able use some working time on this in yearly 2014 (Jan/Feb). They would
like to see a backport also in the 2.4.x branch, and perhaps even 2.3.x
branch if possible.

Regards,

Ilkka Rinne
Founder, Chief Technology Officer, Spatineo Inc.
Email: ilkka.rinne@anonymised.com<mailto:ilkka.rinne@anonymised.com>
Skype: ilkka.o.rinne, phone: +358 50 523 8974
Linnankoskenkatu 16 A 17, FI-00250 Helsinki, Finland
www.spatineo.com<http://www.spatineo.com>,
twitter.com/#!/spatineo<http://twitter.com/#!/spatineo&gt;
Google+ google.com/+Spatineo<https://google.com/+Spatineo&gt;
www.linkedin.com/company/spatineo-inc<http://www.linkedin.com/company/spatineo-inc&gt;

geowolf wrote

Idea:
* Following pull 430 approach, but making it more general, create a new
DefaultValueStrategy,
  which can be used to compute the default value for a given combination
of
dimension type and layer.
  The interface would look something like the following:
  interface DefaultValueStrategy implements Serializable {
      /**
       * Gets the actual value given the resource, the dimension, and the
selected values for the already processed dimensions
       */
      Object getDefaultValue(ResourceInfo resource, DimensionInfo
dimension);
      /**
       * Returns the capabilities representation of the default value. For
example, it could be "current"
       */
      String getCapabilitiesRepresentation(ResourceInfo resource,
DimensionInfo dimension);
  }

These objects would become part of the DimensionInfo, and would be
serialized with XStream along with
all the state they need to perform the computation:

  interface DimensionInfo {
     ...

    DefaultValueStrategy getDefaultValueStrategy();
    void setDefaultValueStrategy(DefaultValueStrategy);
  }

and the xml could end up looking something like (having the proper xstream
aliases registrations)
for fixed value choice:

<dimensionInfo>
         
<enabled>
true
</enabled>
         
<attribute>
att
</attribute>
         
<presentation>
LIST
</presentation>
         
<units>
EPSG:5030
</units>
         
<unitSymbol>
m
</unitSymbol>
         
<defaultValue>
               
<userProvided>
                     
<value>
123
</value>
               
</userProvided>
          
</defaultValue>
   
</dimensionInfo>
or something like this for represting current with the nearest value to
the
time of the request (which
does not need any inner field):

<dimensionInfo>
         
<enabled>
true
</enabled>
         
<attribute>
att
</attribute>
         
<presentation>
LIST
</presentation>
         
<units>
EPSG:5030
</units>
         
<unitSymbol>
m
</unitSymbol>
         
<defaultValue>
               
<currentNearestRequest/>
          
</defaultValue>
   
</dimensionInfo>
* In order to locate and create the strategies depending on the current
combination of resource and
  layer we'd have factories registered in the app-context:

  interface DefaultValueStrategyFactory {
     /**
      * Returns a strategy, or
     DimensionDefaultValueStrategy getStrategy(ResourceInfo resource,
DimensionInfo dimension);
  }

  The code implemented by the two pull requests could keep on working as
it
does now, being layer
  specific, or dimension specific, but this would leave us the option of
adding more and increase the
  generality in the future

* Finally, have the GUI use the above factories to locate the strategies
usable for the current resource
  and dimension, presenting a drop down, and go back in the app context to
find panel implementations
  that can handle the configuration of a certain strategy, if a GUI is
needed at all:

  interface DefaultValueStrategyPanelFactory { // all right, ugly name,
suggestions??
      FormComponent createUIForStrategy(ResourceInfo resource,
DimensionInfo di, DefaultValueStrategy strategy);
  }
Opinions?

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Managing-default-value-in-wms-dimensions-starting-to-get-a-number-of-ad-hoc-solutions-tp5095644p5095689.html
Sent from the GeoServer - Dev mailing list archive at Nabble.com.

4

On Sat, Dec 28, 2013 at 7:22 PM, ilkkarinne <ilkka.rinne@anonymised.com>wrote:

Hello,

I'm the author of the mentioned pull request 430, and I'm liking the
generalisation of my original idea as proposed by Andrea. I dare not go
deep
into implementation details, because while being an happy user on Geoserver
I have only limited experience for creating code for the project.

What kind of implementation plan and timeline would you see for do for this
kind of change in the Geoserver functionality? My client, the Finnish
Meteorological Institute, is already waiting for this fix, and I'm likely
to
be able use some working time on this in yearly 2014 (Jan/Feb). They would
like to see a backport also in the 2.4.x branch, and perhaps even 2.3.x
branch if possible.

Thanks for the interest. The timeframe is not clear, we need feedback from
the other core developers, and this might be a bit hard now that we're
in holidays.

However... this is also the best time for me to help, Jan 7 I'll be back
working
full time and at that point I'll only be able to help during weekends....
so it would
really be great if other PSC (Project Steering Commitee)
members could chime in and comment on this topic soon, as I'd be happy to
help.

A backport on the 2.4.x series is probably out of the question due to
project rules:
* a new feature has to be vetted by core devs before being added to the
development
  series
* that feature has to stay one month on the dev series before being
backported on the stable
  branch, after a positive vote from the PSC, that deems the feature useful
and not
  potentially harmful to the stability of the stable branch
* the backport has to be done at least two weeks before the release (which
happens once
  a month)

Now, the 2.4.x series will only have two more releases, Jan 18 and Feb 18,
then it will
end and the 2.5.x series will be branched off the dev branch (so, it will
become the new
stable series, whilst the dev branch will welcome the work target for
2.6.0, to be
released in Sept 2014).

However... I don't see the above as a big problem, you're free to apply the
patch to your fork of the
project and have FMI use them (same goes for the 2.3.x series, which has
been
dead for 4 months now).

Cheers
Andrea

--
*== GeoSolutions will be closed for seasonal holidays from 23/12/2013 to
06/01/2014 ==*

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

-------------------------------------------------------

5

GeoServer core developers… anyone with an opinion?
At this point it’s late and we’re not going to make the feature freeze (which is a pity)
but I don’t want to let drop this one drop.

And btw, even an opinion like “apply the patches as is, we’ll fix the mess later” is not out of the table,
I don’t like it personally, but I hate to have people try to contribute and giving them the could shoulder
more…

Cheers
Andrea

···

On Sat, Dec 28, 2013 at 9:16 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

== 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

On Sat, Dec 28, 2013 at 7:22 PM, ilkkarinne <ilkka.rinne@anonymised.com> wrote:

Hello,

I’m the author of the mentioned pull request 430, and I’m liking the
generalisation of my original idea as proposed by Andrea. I dare not go deep
into implementation details, because while being an happy user on Geoserver
I have only limited experience for creating code for the project.

What kind of implementation plan and timeline would you see for do for this
kind of change in the Geoserver functionality? My client, the Finnish
Meteorological Institute, is already waiting for this fix, and I’m likely to
be able use some working time on this in yearly 2014 (Jan/Feb). They would
like to see a backport also in the 2.4.x branch, and perhaps even 2.3.x
branch if possible.

Thanks for the interest. The timeframe is not clear, we need feedback from
the other core developers, and this might be a bit hard now that we’re
in holidays.

However… this is also the best time for me to help, Jan 7 I’ll be back working
full time and at that point I’ll only be able to help during weekends… so it would
really be great if other PSC (Project Steering Commitee)
members could chime in and comment on this topic soon, as I’d be happy to help.

A backport on the 2.4.x series is probably out of the question due to project rules:

  • a new feature has to be vetted by core devs before being added to the development
    series
  • that feature has to stay one month on the dev series before being backported on the stable
    branch, after a positive vote from the PSC, that deems the feature useful and not
    potentially harmful to the stability of the stable branch
  • the backport has to be done at least two weeks before the release (which happens once
    a month)

Now, the 2.4.x series will only have two more releases, Jan 18 and Feb 18, then it will
end and the 2.5.x series will be branched off the dev branch (so, it will become the new
stable series, whilst the dev branch will welcome the work target for 2.6.0, to be
released in Sept 2014).

However… I don’t see the above as a big problem, you’re free to apply the patch to your fork of the
project and have FMI use them (same goes for the 2.3.x series, which has been
dead for 4 months now).

Cheers

Andrea

–

== GeoSolutions will be closed for seasonal holidays from 23/12/2013 to 06/01/2014 ==

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

6

FYI: I have been working on the refactoring of my original pull request with a more generic approach following the outline of Andrea’s approach, I’ll probably get it finished by the end of this week.

See https://github.com/geoserver/geoserver/pull/430#issuecomment-32161840

Regards,

Ilkka Rinne

···

On Sun, Jan 12, 2014 at 8:21 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

GeoServer core developers… anyone with an opinion?
At this point it’s late and we’re not going to make the feature freeze (which is a pity)
but I don’t want to let drop this one drop.

And btw, even an opinion like “apply the patches as is, we’ll fix the mess later” is not out of the table,
I don’t like it personally, but I hate to have people try to contribute and giving them the could shoulder
more…

Cheers
Andrea

–

Ilkka Rinne
Founder, Chief Technology Officer, Spatineo Oy
Email: ilkka.rinne@anonymised.com…3889…
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

On Sat, Dec 28, 2013 at 9:16 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

== 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

On Sat, Dec 28, 2013 at 7:22 PM, ilkkarinne <ilkka.rinne@anonymised.com> wrote:

Hello,

I’m the author of the mentioned pull request 430, and I’m liking the
generalisation of my original idea as proposed by Andrea. I dare not go deep
into implementation details, because while being an happy user on Geoserver
I have only limited experience for creating code for the project.

What kind of implementation plan and timeline would you see for do for this
kind of change in the Geoserver functionality? My client, the Finnish
Meteorological Institute, is already waiting for this fix, and I’m likely to
be able use some working time on this in yearly 2014 (Jan/Feb). They would
like to see a backport also in the 2.4.x branch, and perhaps even 2.3.x
branch if possible.

Thanks for the interest. The timeframe is not clear, we need feedback from
the other core developers, and this might be a bit hard now that we’re
in holidays.

However… this is also the best time for me to help, Jan 7 I’ll be back working
full time and at that point I’ll only be able to help during weekends… so it would
really be great if other PSC (Project Steering Commitee)
members could chime in and comment on this topic soon, as I’d be happy to help.

A backport on the 2.4.x series is probably out of the question due to project rules:

  • a new feature has to be vetted by core devs before being added to the development
    series
  • that feature has to stay one month on the dev series before being backported on the stable
    branch, after a positive vote from the PSC, that deems the feature useful and not
    potentially harmful to the stability of the stable branch
  • the backport has to be done at least two weeks before the release (which happens once
    a month)

Now, the 2.4.x series will only have two more releases, Jan 18 and Feb 18, then it will
end and the 2.5.x series will be branched off the dev branch (so, it will become the new
stable series, whilst the dev branch will welcome the work target for 2.6.0, to be
released in Sept 2014).

However… I don’t see the above as a big problem, you’re free to apply the patch to your fork of the
project and have FMI use them (same goes for the 2.3.x series, which has been
dead for 4 months now).

Cheers

Andrea

–

== GeoSolutions will be closed for seasonal holidays from 23/12/2013 to 06/01/2014 ==

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

7

Hi Andrea, all,

Please check the latest version of the dimension default value pull request, the code is now in pretty good shape from my part. In addition to what was discussed earlier I’ve also added fields for the default value settings in the Dimension Editor UI.

See the details on what has been done at https://github.com/geoserver/geoserver/pull/430#issuecomment-34445447

Andrea: do you think the implementation is at least roughly following the idea you had in mind for solving this issue?

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.

Regards,

Ilkka Rinne

···

On Mon, Jan 13, 2014 at 3:33 PM, Ilkka Rinne <ilkka.rinne@anonymised.com> wrote:

FYI: I have been working on the refactoring of my original pull request with a more generic approach following the outline of Andrea’s approach, I’ll probably get it finished by the end of this week.

See https://github.com/geoserver/geoserver/pull/430#issuecomment-32161840

Regards,

Ilkka Rinne

–

Ilkka Rinne
Founder, Chief Technology Officer, Spatineo Oy
Email: ilkka.rinne@anonymised.com…3889…
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

On Sun, Jan 12, 2014 at 8:21 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

GeoServer core developers… anyone with an opinion?
At this point it’s late and we’re not going to make the feature freeze (which is a pity)
but I don’t want to let drop this one drop.

And btw, even an opinion like “apply the patches as is, we’ll fix the mess later” is not out of the table,
I don’t like it personally, but I hate to have people try to contribute and giving them the could shoulder
more…

Cheers
Andrea

–

Ilkka Rinne
Founder, Chief Technology Officer, Spatineo Oy
Email: ilkka.rinne@anonymised.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

On Sat, Dec 28, 2013 at 9:16 PM, Andrea Aime <andrea.aime@anonymised.com…1268…> wrote:

–

== 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

On Sat, Dec 28, 2013 at 7:22 PM, ilkkarinne <ilkka.rinne@anonymised.com> wrote:

Hello,

I’m the author of the mentioned pull request 430, and I’m liking the
generalisation of my original idea as proposed by Andrea. I dare not go deep
into implementation details, because while being an happy user on Geoserver
I have only limited experience for creating code for the project.

What kind of implementation plan and timeline would you see for do for this
kind of change in the Geoserver functionality? My client, the Finnish
Meteorological Institute, is already waiting for this fix, and I’m likely to
be able use some working time on this in yearly 2014 (Jan/Feb). They would
like to see a backport also in the 2.4.x branch, and perhaps even 2.3.x
branch if possible.

Thanks for the interest. The timeframe is not clear, we need feedback from
the other core developers, and this might be a bit hard now that we’re
in holidays.

However… this is also the best time for me to help, Jan 7 I’ll be back working
full time and at that point I’ll only be able to help during weekends… so it would
really be great if other PSC (Project Steering Commitee)
members could chime in and comment on this topic soon, as I’d be happy to help.

A backport on the 2.4.x series is probably out of the question due to project rules:

  • a new feature has to be vetted by core devs before being added to the development
    series
  • that feature has to stay one month on the dev series before being backported on the stable
    branch, after a positive vote from the PSC, that deems the feature useful and not
    potentially harmful to the stability of the stable branch
  • the backport has to be done at least two weeks before the release (which happens once
    a month)

Now, the 2.4.x series will only have two more releases, Jan 18 and Feb 18, then it will
end and the 2.5.x series will be branched off the dev branch (so, it will become the new
stable series, whilst the dev branch will welcome the work target for 2.6.0, to be
released in Sept 2014).

However… I don’t see the above as a big problem, you’re free to apply the patch to your fork of the
project and have FMI use them (same goes for the 2.3.x series, which has been
dead for 4 months now).

Cheers

Andrea

–

== GeoSolutions will be closed for seasonal holidays from 23/12/2013 to 06/01/2014 ==

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

8

On Fri, Feb 7, 2014 at 4:26 PM, Ilkka Rinne <ilkka.rinne@anonymised.com>wrote:

Hi Andrea, all,

Please check the latest version of the dimension default value pull
request, the code is now in pretty good shape from my part. In addition to
what was discussed earlier I've also added fields for the default value
settings in the Dimension Editor UI.

See the details on what has been done at
https://github.com/geoserver/geoserver/pull/430#issuecomment-34445447

Andrea: do you think the implementation is at least roughly following the
idea you had in mind for solving this issue?

Hi IIkka, yes, this is what I had in mind. Thanks for the screenshots and
the configuration examples.
Still haven't had time to look into the code diffs.
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)

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.
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...)

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

-------------------------------------------------------

9

On Mon, Feb 10, 2014 at 10:31 AM, Andrea Aime
<andrea.aime@anonymised.com>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.rinne@anonymised.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

10

On Mon, Feb 10, 2014 at 10:31 AM, Andrea Aime <
andrea.aime@anonymised.com> 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)

The GSIP 108 has now been created for this proposal, please review and
comment. It should now include all the relevant links and overview of
proposed implementation.

Regards,

--
Ilkka Rinne
Founder, Chief Technology Officer, Spatineo Oy
Email: ilkka.rinne@anonymised.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

11

Sorry,

a link would be nice, I assume: http://geoserver.org/display/GEOS/GSIP+108±+Customizable+dimension+default+values+for+WMS+layers#GSIP108-CustomizabledimensiondefaultvaluesforWMSlayers-Links

···

Ilkka Rinne

On Tue, Mar 18, 2014 at 4:10 PM, Ilkka Rinne <ilkka.rinne@anonymised.com> wrote:

The GSIP 108 has now been created for this proposal, please review and comment. It should now include all the relevant links and overview of proposed implementation.

Regards,

–

Ilkka Rinne
Founder, Chief Technology Officer, Spatineo Oy
Email: ilkka.rinne@anonymised.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

On Mon, Feb 10, 2014 at 10:31 AM, Andrea Aime <andrea.aime@anonymised.com68…> 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)

12

Renamed it GSIP 109 (108 was already taken by a completed proposal) and started a separate thread for discussion and votes

Cheers
Andrea

···

On Tue, Mar 18, 2014 at 3:11 PM, Ilkka Rinne <ilkka.rinne@anonymised.com> wrote:

Sorry,

a link would be nice, I assume: http://geoserver.org/display/GEOS/GSIP+108±+Customizable+dimension+default+values+for+WMS+layers#GSIP108-CustomizabledimensiondefaultvaluesforWMSlayers-Links

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

Ilkka Rinne

On Tue, Mar 18, 2014 at 4:10 PM, Ilkka Rinne <ilkka.rinne@anonymised.com> wrote:

The GSIP 108 has now been created for this proposal, please review and comment. It should now include all the relevant links and overview of proposed implementation.

Regards,

–

Ilkka Rinne
Founder, Chief Technology Officer, Spatineo Oy
Email: ilkka.rinne@anonymised.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

On Mon, Feb 10, 2014 at 10:31 AM, Andrea Aime <andrea.aime@anonymised.com68…> 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)