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?

Cheers,
Jonathan


On 5 February 2014 15:43, 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
>

-- 
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.
------------------------------------------------------------------------------
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

Reply via email to