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:
http://demo.opengeo.org/geoserver/wms?service=WMS&request=GetFeatureInfo&version=1.1.1&layers=usgs:ned&styles=&srs=EPSG:4326&format=image/jpeg&width=1024&height=1024&bbox=-78.40192771,38.96234375,-77.84674699,39.12334582&query_layers=usgs:ned&x=1017&y=466&info_format=application/vnd.ogc.gml
http://demo.opengeo.org/geoserver/wms?service=WMS&request=GetMap&version=1.1.1&layers=usgs:ned&styles=&srs=EPSG:4326&format=image/jpeg&width=1024&height=1024&bbox=-78.40192771,38.96234375,-77.84674699,39.12334582
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)
<[email protected]<mailto:[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]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
