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) <
[email protected]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
