[Geoserver-devel] Adding property selection to GetFeatureInfo

Andrea_Aime4 · February 27, 2012, 9:19am

Hi,
the current GetFeatureInfo implementation already mimicks WFS
GetFeature in a number of ways,
including the ability to set a filter and output in GML2/GML3.

One bit that is missing is support for the PROPERTYNAME parameter,
that is, the ability to select
what attributes should be returned to the client as a request property.
The interest is mostly related to network performance, especially when
using an output
like GML, where the geometry is included in the result too (and it can
be large), but it's also easy
to think about situations where the client just wants a single
attribute out of of a potentially long list.

So I would like to add support for &PROPERTYNAME=att1,att2,... , just
like it is working today in
WFS GetFeature, to GetFeatureInfo, both in trunk and in the stable series.

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

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

Justin_Deoliveira · February 27, 2012, 4:35pm

Sounds like a great improvement to me. +1

On Mon, Feb 27, 2012 at 2:19 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
the current GetFeatureInfo implementation already mimicks WFS
GetFeature in a number of ways,
including the ability to set a filter and output in GML2/GML3.

One bit that is missing is support for the PROPERTYNAME parameter,
that is, the ability to select
what attributes should be returned to the client as a request property.
The interest is mostly related to network performance, especially when
using an output
like GML, where the geometry is included in the result too (and it can
be large), but it’s also easy
to think about situations where the client just wants a single
attribute out of of a potentially long list.

So I would like to add support for &PROPERTYNAME=att1,att2,… , just
like it is working today in
WFS GetFeature, to GetFeatureInfo, both in trunk and in the stable series.

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

Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

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.

Gabriel_Roldan2 · February 29, 2012, 2:54pm

+1. Just for comment completeness, unifying the request/response handling for WMS GetFeatureInfo/GML and WFS GetFeature is a long standing wish. Although by no means I’m asking you to do so, just recalling at some point we might one to somehow let them share more code.

Cheers,
Gabriel

On Mon, Feb 27, 2012 at 1:35 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Sounds like a great improvement to me. +1

On Mon, Feb 27, 2012 at 2:19 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
the current GetFeatureInfo implementation already mimicks WFS
GetFeature in a number of ways,
including the ability to set a filter and output in GML2/GML3.

One bit that is missing is support for the PROPERTYNAME parameter,
that is, the ability to select
what attributes should be returned to the client as a request property.
The interest is mostly related to network performance, especially when
using an output
like GML, where the geometry is included in the result too (and it can
be large), but it’s also easy
to think about situations where the client just wants a single
attribute out of of a potentially long list.

So I would like to add support for &PROPERTYNAME=att1,att2,… , just
like it is working today in
WFS GetFeature, to GetFeatureInfo, both in trunk and in the stable series.

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

Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

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

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

Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

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

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea_Aime4 · February 29, 2012, 4:19pm

On Wed, Feb 29, 2012 at 3:54 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

+1. Just for comment completeness, unifying the request/response handling
for WMS GetFeatureInfo/GML and WFS GetFeature is a long standing wish.
Although by no means I'm asking you to do so, just recalling at some point
we might one to somehow let them share more code.

Yep, agreed... to some extent.

The fact is, GetFeatureInfo is different from GetFeature in a number of ways:
- can work on cascaded wms layers and coverages
- it tries hard to match the SLD, so it's not just a random distance from the
point you chose, which is based on a static analysis of the SLD that
tries to determine the optimal search area for that particular layer

Long story short, the part that is actually easily shareable is the
output formats,
they both eat feature collections so they should be the same imho (with some
limits, like not sure if template HTML is any good for WFS...)