Hi,
I somehow lost my interest in this because I noticed that it was not as simple as I thought first. However, because I did some brainwork and testing I try to write a summary before burying the idea.
-
“What is here?” is a common spatial question.
-
WMS standard lacks a “what is here” query.
-
Perhaps because when the standard was written there were no lightweight but location aware clients like smartphones.
-
However, such a thing could be useful.
-
WMS has a GetFeatureInfo query which primary meaning is “Tell me more about this thing that I see on a rendered map image”. It has also another meaning that is described in WMS standars for raster layers “What is the value of this pixel?”
-
GetFeatureInfo can be turned into “What is here” query with a little violence but because of rendering rules what is in data is not always drawn on a map as such.
-
Most WMS servers support GetFeatureInfo which makes it teasing to consider enhancing just that to support better “what is here” questions.
-
Geoserver, Mapserver, deegree, QGIS Mapserver and MapGuide are all OSGeo projects and if they all could make a common decision about extending their GetFeatureInfo support in a similar way, that would be something.
-
WFS and WPS can also answer sometimes to What is here but they are not as common as WMS. A common What is here WPS process could be a good alternative, though.
-
I had not thought that “what is here” is scale dependent. Rendering is for sure dependent on scale and style but but if you walk on the street and ask “What street this is?” then you do not expect to hear a counter question “At which scale?”. You would think perhaps “At any scale”, or “In one-to-one” because it is a real world. But that suits only for continuous coverages like raster data and polygon layers. For lines and points the question is often “What is near?”
I started to think about this because there was a question on the gdal-dev mailing list about how to make gdallocationinfo utility to answer fast. The thread was this one http://thread.gmane.org/gmane.comp.gis.gdal.devel/36544.
Gdallocationinfo was the utility that was used for testing http://gdal.org/gdallocationinfo.html and it has a simple and general syntax for checking a pixel value of any raster data format supported by GDAL. Thus it can partly give answers to what is here questions, but only when it comes to something measurable that can be expressed as a raster. Digital elevation model is perhaps the most common example.
The syntax of gdallocationinfo is simple: gdallocationinfo -source data - queried coordinates.
It can read local files but also remote files if they can be accessed with http as in this example
gdallocationinfo /vsicurl/http://latuviitta.kapsi.fi/data/dem10m/dem_10m.tif -geoloc 389559 6677412
What I did not think in the beginning is that actually gdallocationinfo supports also WMS because WMS is one of the GDAL formats. It seems to send two requests in a row for the WMS service: First GetFeatureInfo followed by GetMap. Here comes an example:
If the request is
gdallocationinfo –wgs84 demo_opengeo_org.xml -77.85 39.05
(demo_opengeo_org.xml is GDAL config file which defines the WMS service), these two WMS requests are sent:
Even Rouault, I guess, has made a nice general solution. If WMS service supports GetFeatureInfo it is utilized but in all cases WMS for sure supports GetMap and then the pixel value can be checked on the client side. The Geoserver at demo.opengeo is a fine test server because the results are very different: GetFeature info shows attribute value for “GREY_INDEX” (193.65) but Geoserver is pushing the DEM through a SLD style and RGB values of the rendered map are (1,0,132).
So this is where I stopped. I believe there are somehow common use cases for a coordinate based location/featureinfo service that would be handled on the server side and that would be very lightweight and simple on the client side. However, perhaps the needs are not common enough for making one service to suit enough many users. If something then perhaps we could have a simple WPS demo that takes coordinates and layer name and returns height value. We seem to have sf:sfdem in our demo layers.
-Jukka Rahkonen-
···
Jody Garnett wrote:
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.comts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel