[Geoserver-devel] Time and elevation support for WFS

GeoServer GeoServer Developer
1

Hi,
so far in GeoServer history we ported a number of common and useful WFS
parameters towards the WMS protocol as vendor extensions: filtering
and paging are two examples.

I would like to propose that, for once, we do the operation in the opposite direction,
have WFS GET requests respond to the TIME/ELEVATION parameters as well.

The idea is to facilitate the development of client applications using data with
time and elevation, applications that are using primarily WMS but that do
occasionally require wfs to pull in raw vector data, without the need to get extra knowledge
about how thing are configured time/elevation wise, but just keep on using the
same parameters as WMS in the requests.

I don’t have a plan to expose the time/elevation metadata in the WFS capabilities
though (just like we don’t expose the attribute list for CQL filtering in WMS caps,
to draw a parallel). The WFS capabilities document does not allow for vendor
extensions on the feature types description regardless.

The behavior would mimic one to one the WMS one, so that you get exactly
the same data back when doing requests.
In particular, as already discussed in the past, we want to expose 4D data
having a time offset being the 4th dimension, and allow for slicing on a time
interval when a configuration flag is raised: the WFS would have to behave
the same way to ensure consistency between the two enviroments, with the
geometry cut and the Z interpolated to represent the elevation of the linestring
subset in the specified time interval

Opinions?

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

2

Sounds like a great addition to me to me. Is the plan to only support the time/elevation parameters in GET requests like WMS or also handled via POST? I ask because POST request parsing often gets overlooked (like with viewParams).

On Tue, Jul 3, 2012 at 4:17 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
so far in GeoServer history we ported a number of common and useful WFS
parameters towards the WMS protocol as vendor extensions: filtering
and paging are two examples.

I would like to propose that, for once, we do the operation in the opposite direction,
have WFS GET requests respond to the TIME/ELEVATION parameters as well.

The idea is to facilitate the development of client applications using data with
time and elevation, applications that are using primarily WMS but that do
occasionally require wfs to pull in raw vector data, without the need to get extra knowledge
about how thing are configured time/elevation wise, but just keep on using the
same parameters as WMS in the requests.

I don’t have a plan to expose the time/elevation metadata in the WFS capabilities
though (just like we don’t expose the attribute list for CQL filtering in WMS caps,
to draw a parallel). The WFS capabilities document does not allow for vendor
extensions on the feature types description regardless.

The behavior would mimic one to one the WMS one, so that you get exactly
the same data back when doing requests.
In particular, as already discussed in the past, we want to expose 4D data
having a time offset being the 4th dimension, and allow for slicing on a time
interval when a configuration flag is raised: the WFS would have to behave
the same way to ensure consistency between the two enviroments, with the
geometry cut and the Z interpolated to represent the elevation of the linestring
subset in the specified time interval

Opinions?

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

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@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

3

On Tue, Jul 3, 2012 at 2:55 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Sounds like a great addition to me to me. Is the plan to only support the time/elevation parameters in GET requests like WMS or also handled via POST? I ask because POST request parsing often gets overlooked (like with viewParams).

Indeed, only with GET, modifying the EMF bindings to add vendor params is
something I want to avoid at all costs, doing the mixed approach has
been discussed on jira but it’s not trivial either (it seems it would go though
a EMF modification too, ugh):
http://jira.codehaus.org/browse/GEOS-5160

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

4

On Tue, Jul 3, 2012 at 7:20 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Jul 3, 2012 at 2:55 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Sounds like a great addition to me to me. Is the plan to only support the time/elevation parameters in GET requests like WMS or also handled via POST? I ask because POST request parsing often gets overlooked (like with viewParams).

Indeed, only with GET, modifying the EMF bindings to add vendor params is
something I want to avoid at all costs, doing the mixed approach has
been discussed on jira but it’s not trivial either (it seems it would go though
a EMF modification too, ugh):
http://jira.codehaus.org/browse/GEOS-5160

I think this is pretty limiting with WFS where POST requests are much more common than with WMS.

If updating the object model is so hindering then we need to figure out what an acceptable alternative is since because imo just adding the GET bindings for WFS is not really an option. I have ran into a few cases of people being confused about “vendor” functionality only being available in GET requests. I don’t even believe this is documented anywhere.

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.

5

On Tue, Jul 3, 2012 at 4:04 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

On Tue, Jul 3, 2012 at 7:20 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Jul 3, 2012 at 2:55 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Sounds like a great addition to me to me. Is the plan to only support the time/elevation parameters in GET requests like WMS or also handled via POST? I ask because POST request parsing often gets overlooked (like with viewParams).

Indeed, only with GET, modifying the EMF bindings to add vendor params is
something I want to avoid at all costs, doing the mixed approach has
been discussed on jira but it’s not trivial either (it seems it would go though
a EMF modification too, ugh):
http://jira.codehaus.org/browse/GEOS-5160

I think this is pretty limiting with WFS where POST requests are much more common than with WMS.

If updating the object model is so hindering then we need to figure out what an acceptable alternative is since because imo just adding the GET bindings for WFS is not really an option. I have ran into a few cases of people being confused about “vendor” functionality only being available in GET requests. I don’t even believe this is documented anywhere.

The documentation only shows GET requests, never POSTS, but indeed it does not tell these vendor options
are not available in POST requests. That would be easy to fix though.

As for a better way, I don’t know, the obvious one to me would be not using EMF and use plain java beans
that everybody knows how to modify, but we’re too far in to escape it without a seriously major investment
(thought we should probably consider not developing EMF models for new specs we implement, but
try something different, maybe plain java beans with annotations to compensate for the info we cannot
retrieve via reflection?)

To give you a comparison, see how “easy” it has been to upgrade the filters along their evolution,
while for WFS we need to have different EMF models and proxy classes that hide the differences,
which is imho ugly (but necessary).

Modifying a model in EMF is a russian roulette, can take a few hours or days, it depends on having
the right version of Eclipse with the right version of EMF in it (that is, the one that was used to
generate the model in the first place, which is often not known), there are a few ways to do it
but none is documented afaik.
The only person I know that can do it right relatively quickly and in a consistent way is you,
I honestly don’t remember where to start the one time a year I have to put my hands on it.

Given that we cannot escape EMF for WFS without a major investment, maybe you could
upload somewhere a version of Eclipse that is known to work with our current bindings,
and document a single way to do model modifications?

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

6

On Tue, Jul 3, 2012 at 8:22 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Jul 3, 2012 at 4:04 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

On Tue, Jul 3, 2012 at 7:20 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Jul 3, 2012 at 2:55 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Sounds like a great addition to me to me. Is the plan to only support the time/elevation parameters in GET requests like WMS or also handled via POST? I ask because POST request parsing often gets overlooked (like with viewParams).

Indeed, only with GET, modifying the EMF bindings to add vendor params is
something I want to avoid at all costs, doing the mixed approach has
been discussed on jira but it’s not trivial either (it seems it would go though
a EMF modification too, ugh):
http://jira.codehaus.org/browse/GEOS-5160

I think this is pretty limiting with WFS where POST requests are much more common than with WMS.

If updating the object model is so hindering then we need to figure out what an acceptable alternative is since because imo just adding the GET bindings for WFS is not really an option. I have ran into a few cases of people being confused about “vendor” functionality only being available in GET requests. I don’t even believe this is documented anywhere.

The documentation only shows GET requests, never POSTS, but indeed it does not tell these vendor options
are not available in POST requests. That would be easy to fix though.

As for a better way, I don’t know, the obvious one to me would be not using EMF and use plain java beans
that everybody knows how to modify, but we’re too far in to escape it without a seriously major investment
(thought we should probably consider not developing EMF models for new specs we implement, but
try something different, maybe plain java beans with annotations to compensate for the info we cannot
retrieve via reflection?)

I will fully admit if I was looking at implementing the ows service / xml parsing architecture from scratch today in a green field i would probably avoid the use of EMF. But my opinion is that we are so far into it that we can’t avoid it for some services (like WFS) that have already chosen to go that way.

To give you a comparison, see how “easy” it has been to upgrade the filters along their evolution,
while for WFS we need to have different EMF models and proxy classes that hide the differences,
which is imho ugly (but necessary).

I’ll agree it is pretty easy when things don’t change among specification versions. Going from filter 1.0 to filter 1.1 was trivial yes. But not so trivial to implement the new functionality for filter 2.0 that involved adding the temporal filter classes and everything for joining. I don’t have exact times available but that in itself was weeks of work. It was certainly much more work than generating out the entire wfs 2.0 schema model and using the emf xml parse bindings to basically (with a few exceptions) request/response parsing for free.

Modifying a model in EMF is a russian roulette, can take a few hours or days, it depends on having
the right version of Eclipse with the right version of EMF in it (that is, the one that was used to
generate the model in the first place, which is often not known), there are a few ways to do it
but none is documented afaik.
The only person I know that can do it right relatively quickly and in a consistent way is you,
I honestly don’t remember where to start the one time a year I have to put my hands on it.

A few years back I documented in what I thought was pretty good detail how to instrument an emf object model for geotools. This used to live in the confluence developer guide but for the life of me i can’t find it now, in confluence or the new sphinx docs for geotools.

Given that we cannot escape EMF for WFS without a major investment, maybe you could
upload somewhere a version of Eclipse that is known to work with our current bindings,
and document a single way to do model modifications?

Happy to do so. I will start by asking Jody how to resurrect that doc i wrote a while back.

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.