[Geoserver-devel] GSIP 60: WMS time and elevation support

Hi folks (hello PSC members!),
we would like to contribute time and elevation WMS support for GeoServer,
for both raster and vector data.

I've put togheter a proposal here:
http://geoserver.org/display/GEOSDOC/0+Project+Steering+Committee

The idea is to do the work on trunk, and once we are satisfied with the
quality of it, backport it to the 2.1.x series (I guess by 2.1.2, assuming
2.1.1 gets released soon-ish, otherwise 2.1.1)

The discussion is open, feedback is appreciated.

Ah, I could not find the current list of PSC members, the proposal
is using the list I took for GSIP 59, but it's quite likely outdated.
Will fix once I get my hands on the official list, but feel free to
add/remove yourself and fix it directly.

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

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

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

Interesting. Not much to add, the proposal seems concise and solid
enough. To be fancy we could let the "time" property be an expression
and not just a single property name.

I'm already +1 though.

For the record, the proposal is actually here:
<http://geoserver.org/display/GEOS/GSIP+60+-+WMS+Time+and+Elevation
+support+for+vector+and+raster+data>

On Mon, 2011-05-30 at 19:47 +0200, Andrea Aime wrote:

Hi folks (hello PSC members!),
we would like to contribute time and elevation WMS support for GeoServer,
for both raster and vector data.

I've put togheter a proposal here:
http://geoserver.org/display/GEOSDOC/0+Project+Steering+Committee

The idea is to do the work on trunk, and once we are satisfied with the
quality of it, backport it to the 2.1.x series (I guess by 2.1.2, assuming
2.1.1 gets released soon-ish, otherwise 2.1.1)

The discussion is open, feedback is appreciated.

Ah, I could not find the current list of PSC members, the proposal
is using the list I took for GSIP 59, but it's quite likely outdated.
Will fix once I get my hands on the official list, but feel free to
add/remove yourself and fix it directly.

Cheers
Andrea

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

Looks great. A few small questions - how does this interact with the time.ftl and height.ftl KML templates?

Are you going to use templates for the configuration? Or just select an attribute which must be a time or elevation? The .ftl’s had a nice small advantage of being able to do some formatting on the fly. And how will people select units for the elevation?

On Mon, May 30, 2011 at 10:01 PM, Gabriel Roldán <groldan@…1501…> wrote:

Interesting. Not much to add, the proposal seems concise and solid
enough. To be fancy we could let the “time” property be an expression
and not just a single property name.

I’m already +1 though.

For the record, the proposal is actually here:
<http://geoserver.org/display/GEOS/GSIP+60±+WMS+Time+and+Elevation
+support+for+vector+and+raster+data>

On Mon, 2011-05-30 at 19:47 +0200, Andrea Aime wrote:

Hi folks (hello PSC members!),
we would like to contribute time and elevation WMS support for GeoServer,
for both raster and vector data.

I’ve put togheter a proposal here:
http://geoserver.org/display/GEOSDOC/0+Project+Steering+Committee

The idea is to do the work on trunk, and once we are satisfied with the
quality of it, backport it to the 2.1.x series (I guess by 2.1.2, assuming
2.1.1 gets released soon-ish, otherwise 2.1.1)

The discussion is open, feedback is appreciated.

Ah, I could not find the current list of PSC members, the proposal
is using the list I took for GSIP 59, but it’s quite likely outdated.
Will fix once I get my hands on the official list, but feel free to
add/remove yourself and fix it directly.

Cheers
Andrea

Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers


Simplify data backup and recovery for your virtual environment with vRanger.
Installation’s a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It’s vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

+1 from me. Looks both useful an interesting.

I take it for granted that you are not going to break any existing code or clients. Note that app-schema now supports WMS too (xpaths in SLD properties) so keep us in mind.

On 31/05/11 01:47, Andrea Aime wrote:

Hi folks (hello PSC members!),
we would like to contribute time and elevation WMS support for GeoServer,
for both raster and vector data.

I've put togheter a proposal here:
http://geoserver.org/display/GEOSDOC/0+Project+Steering+Committee

The idea is to do the work on trunk, and once we are satisfied with the
quality of it, backport it to the 2.1.x series (I guess by 2.1.2, assuming
2.1.1 gets released soon-ish, otherwise 2.1.1)

The discussion is open, feedback is appreciated.

Ah, I could not find the current list of PSC members, the proposal
is using the list I took for GSIP 59, but it's quite likely outdated.
Will fix once I get my hands on the official list, but feel free to
add/remove yourself and fix it directly.

Cheers
Andrea

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

On Tue, May 31, 2011 at 4:01 AM, Gabriel Roldán <groldan@anonymised.com> wrote:

Interesting. Not much to add, the proposal seems concise and solid
enough. To be fancy we could let the "time" property be an expression
and not just a single property name.

Yeah, I would have loved to go that way but ECQL, which we're currently using,
only works as a parser, but cannot encode back a filter into ECQL.
So the current idea is to keep it as an attribute and evolve it to use ECQL
when ECQL is ready for that

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

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

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

On Tue, May 31, 2011 at 5:19 AM, Chris Holmes <cholmes@anonymised.com> wrote:

Looks great. A few small questions - how does this interact with the
time.ftl and height.ftl KML templates?
Are you going to use templates for the configuration? Or just select an
attribute which must be a time or elevation? The .ftl's had a nice small
advantage of being able to do some formatting on the fly.

The proposal ignores KML solid, we are not going to touch or interact in
any way with it. This means if the time/elevation attributes happen to be the
same as the ftl the user will have to configure it twice.

Mind though, the behavior of the two is different different, if you don't say
anything once time is configured you'll get back a point in time, the
features that have the
latest time value, not the entire series.
Same goes for elevation, you get back features with a certain default value,
not the entire set.

So it's safe to say that you probably don't actually want to enable
TIME/ELEVATION
WMS behavior on data destined to GE animations unless the queries are
also changed to use TIME and ELEVATION KVP parameters to select an
interval.

That said, if someone maintaining KML land wants to pick them up from
the configuration
and use them when the ftl is not around, it should not be too hard, I guess
a new level of indirection masking whether the current value comes from
a ftl file or an attribute name would be needed.

And how will people select units for the elevation?

Units are ignored like in any other parts of GeoServer as well (think all
distance related filters, none of them deals with unit).

Time wise the WMS specification has just one unit, ISO8601, so we are
going to stick with it statically.

Elevation wise, in theory we could make a elevation unit chooser, in practice
that's too hard now.
Elevation units are expressed referring to a EPSG code for a vertical datum.
EPSG:5030, the sample value reported in the WMS spec would not even
decode property if you tried (and you would not be able to
use the CRS class too, you'd have to get the authority factory and cast it
to AbstractAuthorityFactory to just try.).
We'd have to first improve the referencing subsystem and then make a
popup chooser like for the CRS one, while we have the abilities to do that,
it bring us beyond the funding we have available at the moment.

So for the moment the proposal will advertise units ISO8601 for
time and EPSG:5030 for elevations.
However the way we're going to develop it will make it possible to add
the selectable vertical datum as a new attribute in a second time, as
resources to do so show up.

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

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

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

On Tue, May 31, 2011 at 6:18 AM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com> wrote:

+1 from me. Looks both useful an interesting.

I take it for granted that you are not going to break any existing code
or clients. Note that app-schema now supports WMS too (xpaths in SLD
properties) so keep us in mind.

We'll try hard not to add simple feature assumptions in the WMS code, however:
- we don't have any way to test complex features, nor time to
configure any significant
  complex data set, so I hope you added GetMap and GetFeatureInfo
tests somewhere
  that will blow up if a simple feature assumption slips our attention
- the GUI to select the time attribute will have a drop down list, I can make it
  work with the top level attributes of a complex feature, or I guess
I could detect that
  the feature is complex and disable that configuration altogether.
  We have no funding to go for an expression builder nor a tree
selector, however
  since we just store the attribute name in the configuration nothing
prevents someone
  with a complex feature use case to build the proper GUI to create an xpath and
  then build a filter with the necessary namespace support.

Long story short, we'll try hard not to make the current code regress
and fix whatever
regression we cause, but we're not going to add time and elevation support for
complex features either.

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

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

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

Hello Andrea and all,

I specified a bit more the behaviour of the KVP parsers and the default values on the proposal.

Cheers,
Alessio.


Ing. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: (+39) 0584 96.23.13
fax: (+39) 0584 96.23.13
mobile:(+39) 331 62.33.686

http://www.geo-solutions.it
http://geo-solutions.blogspot.com
http://www.linkedin.com/in/alessiofabiani
http://twitter.com/geosolutions_it

On Tue, May 31, 2011 at 9:34 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, May 31, 2011 at 6:18 AM, Ben Caradoc-Davies
Ben.Caradoc-Davies@anonymised.com wrote:

+1 from me. Looks both useful an interesting.

I take it for granted that you are not going to break any existing code
or clients. Note that app-schema now supports WMS too (xpaths in SLD
properties) so keep us in mind.

We’ll try hard not to add simple feature assumptions in the WMS code, however:

  • we don’t have any way to test complex features, nor time to
    configure any significant
    complex data set, so I hope you added GetMap and GetFeatureInfo
    tests somewhere
    that will blow up if a simple feature assumption slips our attention
  • the GUI to select the time attribute will have a drop down list, I can make it
    work with the top level attributes of a complex feature, or I guess
    I could detect that
    the feature is complex and disable that configuration altogether.
    We have no funding to go for an expression builder nor a tree
    selector, however
    since we just store the attribute name in the configuration nothing
    prevents someone
    with a complex feature use case to build the proper GUI to create an xpath and
    then build a filter with the necessary namespace support.

Long story short, we’ll try hard not to make the current code regress
and fix whatever
regression we cause, but we’re not going to add time and elevation support for
complex features either.

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

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



Simplify data backup and recovery for your virtual environment with vRanger.
Installation’s a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It’s vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Proposal looks good to me. While I don’t know much about the domain the plan forward seems good. +1

On Tue, May 31, 2011 at 3:55 AM, Alessio Fabiani <alessio.fabiani@anonymised.com> wrote:

Hello Andrea and all,

I specified a bit more the behaviour of the KVP parsers and the default values on the proposal.

Cheers,
Alessio.


Ing. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.

GeoSolutions S.A.S.

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: (+39) 0584 96.23.13
fax: (+39) 0584 96.23.13
mobile:(+39) 331 62.33.686

http://www.geo-solutions.it
http://geo-solutions.blogspot.com

http://www.linkedin.com/in/alessiofabiani
http://twitter.com/geosolutions_it

On Tue, May 31, 2011 at 9:34 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, May 31, 2011 at 6:18 AM, Ben Caradoc-Davies
Ben.Caradoc-Davies@anonymised.com wrote:

+1 from me. Looks both useful an interesting.

I take it for granted that you are not going to break any existing code
or clients. Note that app-schema now supports WMS too (xpaths in SLD
properties) so keep us in mind.

We’ll try hard not to add simple feature assumptions in the WMS code, however:

  • we don’t have any way to test complex features, nor time to
    configure any significant
    complex data set, so I hope you added GetMap and GetFeatureInfo
    tests somewhere
    that will blow up if a simple feature assumption slips our attention
  • the GUI to select the time attribute will have a drop down list, I can make it
    work with the top level attributes of a complex feature, or I guess
    I could detect that
    the feature is complex and disable that configuration altogether.
    We have no funding to go for an expression builder nor a tree
    selector, however
    since we just store the attribute name in the configuration nothing
    prevents someone
    with a complex feature use case to build the proper GUI to create an xpath and
    then build a filter with the necessary namespace support.

Long story short, we’ll try hard not to make the current code regress
and fix whatever
regression we cause, but we’re not going to add time and elevation support for
complex features either.

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

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



Simplify data backup and recovery for your virtual environment with vRanger.
Installation’s a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It’s vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Simplify data backup and recovery for your virtual environment with vRanger.
Installation’s a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It’s vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

+1 on my end.

Note: The GeoTools WMS client already supports parsing this information when provided in the WMS Capabilities document; there was some madness with the WMS 1.3 specification doing things slightly differently than earlier versions as usual for the OGC.


Jody Garnett

On Wednesday, 1 June 2011 at 12:07 AM, Justin Deoliveira wrote:

Proposal looks good to me. While I don’t know much about the domain the plan forward seems good. +1

On Tue, May 31, 2011 at 3:55 AM, Alessio Fabiani <alessio.fabiani@anonymised.com> wrote:

Hello Andrea and all,

I specified a bit more the behaviour of the KVP parsers and the default values on the proposal.

Cheers,
Alessio.


Ing. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.

GeoSolutions S.A.S.

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: (+39) 0584 96.23.13
fax: (+39) 0584 96.23.13
mobile:(+39) 331 62.33.686

http://www.geo-solutions.it
http://geo-solutions.blogspot.com

http://www.linkedin.com/in/alessiofabiani
http://twitter.com/geosolutions_it

On Tue, May 31, 2011 at 9:34 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, May 31, 2011 at 6:18 AM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com54…> wrote:

+1 from me. Looks both useful an interesting.

I take it for granted that you are not going to break any existing code
or clients. Note that app-schema now supports WMS too (xpaths in SLD
properties) so keep us in mind.

We’ll try hard not to add simple feature assumptions in the WMS code, however:

  • we don’t have any way to test complex features, nor time to
    configure any significant
    complex data set, so I hope you added GetMap and GetFeatureInfo
    tests somewhere
    that will blow up if a simple feature assumption slips our attention
  • the GUI to select the time attribute will have a drop down list, I can make it
    work with the top level attributes of a complex feature, or I guess
    I could detect that
    the feature is complex and disable that configuration altogether.
    We have no funding to go for an expression builder nor a tree
    selector, however
    since we just store the attribute name in the configuration nothing
    prevents someone
    with a complex feature use case to build the proper GUI to create an xpath and
    then build a filter with the necessary namespace support.

Long story short, we’ll try hard not to make the current code regress
and fix whatever
regression we cause, but we’re not going to add time and elevation support for
complex features either.

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

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



Simplify data backup and recovery for your virtual environment with vRanger.
Installation’s a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It’s vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Simplify data backup and recovery for your virtual environment with vRanger.
Installation’s a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It’s vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Simplify data backup and recovery for your virtual environment with vRanger.
Installation’s a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It’s vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel