[Geoserver-devel] Enhanced GetFeatureInfo and new GetProfile

GeoServer GeoServer Developer
,
1

Hi,

Inspired by the "Get Height values fast" discussion I started to dream. The WMS GetFeatureInfo is nice tool for getting an answer to question "What's here". Unfortunately it is designed to work on top of a map that has previously captured from WMS and even it is possible to construct working queries as Andrea wrote, they are ugly. That made me to dream that it would be cool if all the WMS server projects under the OSGeo umbrella (Geoserver, Mapserver, deegree, QGIS Mapserver, MapGuide) would start to support GetFeatureInfo requests by plain coordinates in a common way.

The request could look a much like the Standard GetFeatureInfo, but simpler. M means mandatory, O optional parameter.

VERSION= M
REQUEST=GetFeatureInfo M
QUERY_LAYERS= M
INFO_FORMAT= M
SRS or CRS= M
LON_E= M longitude or easting of the queried point in given SRS/CRS,
LAT_N= M latitude or northing of the queried point in given SRS/CRS
FEATURE_COUNT O
EXCEPTIONS= O
BUFFER O

Nothing special there. LON_E and LAT_N are as they are to prevent the struggle about the axis order. Order of the parameters would not matter. Common parameter for defining the buffer would be needed or otherwise it would be hard to hit points and linear features.

Another extension could be a profile query tool. Most typical use case would be to read a height profile along a line from a DEM layer. The query would take in the line in for example WKT format and the relation which means the distance between returned height profile points is units of the SRS/CRS. Example:

REQUEST=GetProfile
PROFILE=LINESTRING(3413306 6974122, 3413316 6974132)
RESOLUTION=10
LAYER=
SRS/CRS=
INFO_FORMAT=

I do not believe so much that this idea will come true but I think that both query types could have real use cases.

-Jukka Rahkonen-

2

On the Improved GetFeatures part:
+1
I think this is an excellent idea and in hindsight I’m surprised there isn’t already this feature within WMS as it should probably be very simple to implement (one level of maths less than a standard GetFeatures query).

I wonder if maybe it can be added to WMS 1.3.1 or whatever it next?

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

···

On 5 February 2014 15:43, Rahkonen Jukka (Tike) <jukka.rahkonen@anonymised.com> wrote:

Hi,

Inspired by the “Get Height values fast” discussion I started to dream. The WMS GetFeatureInfo is nice tool for getting an answer to question “What’s here”. Unfortunately it is designed to work on top of a map that has previously captured from WMS and even it is possible to construct working queries as Andrea wrote, they are ugly. That made me to dream that it would be cool if all the WMS server projects under the OSGeo umbrella (Geoserver, Mapserver, deegree, QGIS Mapserver, MapGuide) would start to support GetFeatureInfo requests by plain coordinates in a common way.

The request could look a much like the Standard GetFeatureInfo, but simpler. M means mandatory, O optional parameter.

VERSION= M
REQUEST=GetFeatureInfo M
QUERY_LAYERS= M
INFO_FORMAT= M
SRS or CRS= M
LON_E= M longitude or easting of the queried point in given SRS/CRS,
LAT_N= M latitude or northing of the queried point in given SRS/CRS
FEATURE_COUNT O
EXCEPTIONS= O
BUFFER O

Nothing special there. LON_E and LAT_N are as they are to prevent the struggle about the axis order. Order of the parameters would not matter. Common parameter for defining the buffer would be needed or otherwise it would be hard to hit points and linear features.

Another extension could be a profile query tool. Most typical use case would be to read a height profile along a line from a DEM layer. The query would take in the line in for example WKT format and the relation which means the distance between returned height profile points is units of the SRS/CRS. Example:

REQUEST=GetProfile
PROFILE=LINESTRING(3413306 6974122, 3413316 6974132)
RESOLUTION=10
LAYER=
SRS/CRS=
INFO_FORMAT=

I do not believe so much that this idea will come true but I think that both query types could have real use cases.

-Jukka Rahkonen-

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

Cheers,
Jonathan

3

On Wed, Feb 5, 2014 at 4:43 PM, Rahkonen Jukka (Tike) <
jukka.rahkonen@anonymised.com> wrote:

Hi,

Inspired by the "Get Height values fast" discussion I started to dream.
The WMS GetFeatureInfo is nice tool for getting an answer to question
"What's here". Unfortunately it is designed to work on top of a map that
has previously captured from WMS and even it is possible to construct
working queries as Andrea wrote, they are ugly. That made me to dream that
it would be cool if all the WMS server projects under the OSGeo umbrella
(Geoserver, Mapserver, deegree, QGIS Mapserver, MapGuide) would start to
support GetFeatureInfo requests by plain coordinates in a common way.

The request could look a much like the Standard GetFeatureInfo, but
simpler. M means mandatory, O optional parameter.

VERSION= M
REQUEST=GetFeatureInfo M
QUERY_LAYERS= M
INFO_FORMAT= M
SRS or CRS= M
LON_E= M longitude or easting of the queried point in given
SRS/CRS,
LAT_N= M latitude or northing of the queried point in given
SRS/CRS
FEATURE_COUNT O
EXCEPTIONS= O
BUFFER O

Nothing special there. LON_E and LAT_N are as they are to prevent the
struggle about the axis order. Order of the parameters would not matter.
Common parameter for defining the buffer would be needed or otherwise it
would be hard to hit points and linear features.

Hmm... you're missing a scale denominator there. Without it, it's
impossible to know what layers/rules are active.
However, it seems to me this is a large departure from the WMS protocol...
maybe it would be better implemented via WPS?

Another extension could be a profile query tool. Most typical use case
would be to read a height profile along a line from a DEM layer. The query
would take in the line in for example WKT format and the relation which
means the distance between returned height profile points is units of the
SRS/CRS. Example:

REQUEST=GetProfile
PROFILE=LINESTRING(3413306 6974122, 3413316 6974132)
RESOLUTION=10
LAYER=
SRS/CRS=
INFO_FORMAT=

I do not believe so much that this idea will come true but I think that
both query types could have real use cases.

This is definitely WPS

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

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

4

Just seconding Andrea’s feedback. WPS is a better fit for a “what is here” question. Even then it is hard because point and line work are hard to query with a point, so consider a small bounding box instead.

WMS really drags styling into the mix (and thus needs to know both the scale, and the pixel size).

···

Jody Garnett

On Thu, Feb 6, 2014 at 2:43 AM, Rahkonen Jukka (Tike) <jukka.rahkonen@anonymised.com> wrote:

Hi,

Inspired by the “Get Height values fast” discussion I started to dream. The WMS GetFeatureInfo is nice tool for getting an answer to question “What’s here”. Unfortunately it is designed to work on top of a map that has previously captured from WMS and even it is possible to construct working queries as Andrea wrote, they are ugly. That made me to dream that it would be cool if all the WMS server projects under the OSGeo umbrella (Geoserver, Mapserver, deegree, QGIS Mapserver, MapGuide) would start to support GetFeatureInfo requests by plain coordinates in a common way.

The request could look a much like the Standard GetFeatureInfo, but simpler. M means mandatory, O optional parameter.

VERSION= M
REQUEST=GetFeatureInfo M
QUERY_LAYERS= M
INFO_FORMAT= M
SRS or CRS= M
LON_E= M longitude or easting of the queried point in given SRS/CRS,
LAT_N= M latitude or northing of the queried point in given SRS/CRS
FEATURE_COUNT O
EXCEPTIONS= O
BUFFER O

Nothing special there. LON_E and LAT_N are as they are to prevent the struggle about the axis order. Order of the parameters would not matter. Common parameter for defining the buffer would be needed or otherwise it would be hard to hit points and linear features.

Another extension could be a profile query tool. Most typical use case would be to read a height profile along a line from a DEM layer. The query would take in the line in for example WKT format and the relation which means the distance between returned height profile points is units of the SRS/CRS. Example:

REQUEST=GetProfile
PROFILE=LINESTRING(3413306 6974122, 3413316 6974132)
RESOLUTION=10
LAYER=
SRS/CRS=
INFO_FORMAT=

I do not believe so much that this idea will come true but I think that both query types could have real use cases.

-Jukka Rahkonen-

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

5

On Wed, Feb 5, 2014 at 5:48 PM, Andrea Aime <andrea.aime@anonymised.com>wrote:

On Wed, Feb 5, 2014 at 4:43 PM, Rahkonen Jukka (Tike) <
jukka.rahkonen@anonymised.com> wrote:

Hi,

Inspired by the "Get Height values fast" discussion I started to dream.
The WMS GetFeatureInfo is nice tool for getting an answer to question
"What's here". Unfortunately it is designed to work on top of a map that
has previously captured from WMS and even it is possible to construct
working queries as Andrea wrote, they are ugly. That made me to dream that
it would be cool if all the WMS server projects under the OSGeo umbrella
(Geoserver, Mapserver, deegree, QGIS Mapserver, MapGuide) would start to
support GetFeatureInfo requests by plain coordinates in a common way.

The request could look a much like the Standard GetFeatureInfo, but
simpler. M means mandatory, O optional parameter.

VERSION= M
REQUEST=GetFeatureInfo M
QUERY_LAYERS= M
INFO_FORMAT= M
SRS or CRS= M
LON_E= M longitude or easting of the queried point in
given SRS/CRS,
LAT_N= M latitude or northing of the queried point in
given SRS/CRS
FEATURE_COUNT O
EXCEPTIONS= O
BUFFER O

Nothing special there. LON_E and LAT_N are as they are to prevent the
struggle about the axis order. Order of the parameters would not matter.
Common parameter for defining the buffer would be needed or otherwise it
would be hard to hit points and linear features.

Hmm... you're missing a scale denominator there. Without it, it's
impossible to know what layers/rules are active.
However, it seems to me this is a large departure from the WMS protocol...
maybe it would be better implemented via WPS?

Thinking about this one more, _maybe_ we would roll something similar to
this in the WMS reflector implementation.

The WMS reflector (
http://docs.geoserver.org/stable/en/user/tutorials/wmsreflector.html) is
designed to help getting a map
out of a request without having to fill all the parameters, every missing
parameter is filled in automatically and the request
gets turned into a valid GetMap internally.

At the moment it works only for GetMap, but we could have it work for
GetFeatureInfo too, and default most of the GFI bits, leaving just a list
queryLayer as the basic parameter.... the twist here is that we'd have some
extra vendor parameter that the reflector would use to fill some of the
blacks.

Some examples:
Minimal request, no vendor params, we can figure out the rest:

.../wms/reflect?query_layers=topp:states&bbox=....&width=...&height=...&x=...&y=....

Minimal request with vendor params, for computing the scale we assume the
width of the layer (from the capabilities) and a width of 1024, then create
a real bbox, width/height, x, y from it and turn it into a real
GetFeatureInfo:
   .../wms/reflect?query_layers=topp:states&lon=...&lat=...

Minimal request with two vendor params:

.../wms/reflect?query_layers=topp:states&lon=...&lat=...&scale_denominator=...

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

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