Hi list,
I've got a couple of questions regarding a GetFeatureInfo request.
1. Why should I put both LAYERS and QUERY_LAYERS in the request?
I doesn't work with only one of those params, but I put in the same
list of layers in both params all the time.
What's the difference between them?
2. Why do I have to put both BBOX and HEIGHT, WIDTH params in the request?
I guess the server draws a map with the requested bbox, height and
width, and then takes x and y, transforms to coordinates and executes
a query.
But that is just a blind guess and seems a bit strange.
So, pretend I want to get info for specified layer, it's in EPSG:4326
and lat/lon of the point is (-104.97,39.71).
How do I calculate the BBOX, HEIGHT, WIDTH, X and Y of the request?
Is it somehow different if a layer is in EPSG:900913?
Hi,
That all comes from WMS standard and it is rather well written there http://portal.opengeospatial.org/files/?artifact_id=1081&version=1&format=pdf
Logic goes somehow in opposite direction than what you planning to do. It assumes that user has made a GetMap request and sees a map on a screen. It is just an image and does not include any information about georeferencing. If use is clicking on a map the client software can only record which pixel was clicked. However, the georeferencing can be computed on the WMS server side if the WMS GetMap request with BBOX and image size is known.
LAYERS just need to be in the request because standard says so but QUERY_LAYERS is the one used for selecting layers to be queried. They do not need to be the same.
For creating GetFeatureInfo requests from a scratch you will need to do some calculation. The the centre point, decide some image size in WIDTH and HEIGHT and compute BBOX according to those.
-Jukka Rahkonen-
Gis Mage wrote:
Hi list,
I've got a couple of questions regarding a GetFeatureInfo request.
1. Why should I put both LAYERS and QUERY_LAYERS in the request?
I doesn't work with only one of those params, but I put in the same
list of layers in both params all the time.
What's the difference between them?
2. Why do I have to put both BBOX and HEIGHT, WIDTH params in
the request?
I guess the server draws a map with the requested bbox, height and
width, and then takes x and y, transforms to coordinates and executes
a query.
But that is just a blind guess and seems a bit strange.
So, pretend I want to get info for specified layer, it's in EPSG:4326
and lat/lon of the point is (-104.97,39.71).
How do I calculate the BBOX, HEIGHT, WIDTH, X and Y of the request?
Is it somehow different if a layer is in EPSG:900913?
--------------------------------------------------------------
----------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
On 11 November 2011 09:07, Rahkonen Jukka <Jukka.Rahkonen@anonymised.com> wrote:
Hi,
That all comes from WMS standard and it is rather well written there http://portal.opengeospatial.org/files/?artifact_id=1081&version=1&format=pdf
Logic goes somehow in opposite direction than what you planning to do. It assumes that user has made a GetMap request and sees a map on a screen. It is just an image and does not include any information about georeferencing. If use is clicking on a map the client software can only record which pixel was clicked. However, the georeferencing can be computed on the WMS server side if the WMS GetMap request with BBOX and image size is known.
LAYERS just need to be in the request because standard says so but QUERY_LAYERS is the one used for selecting layers to be queried. They do not need to be the same.
LAYERS is there because in theory you can just change the request from
getmap to getfeatureinfo and concatenate the click location and query
layer and send it back. This meant that back in the early days before
JavaScript became popular you could create a WMS client with some cgi
shell scripts and a submit button in ah HTML form.
For creating GetFeatureInfo requests from a scratch you will need to do some calculation. The the centre point, decide some image size in WIDTH and HEIGHT and compute BBOX according to those.
If you find that you are having to do that sort of calculation then
you should probably be using a WFS getFeature request instead of a WMS
getFeatureInfo.
Ian
Thanks, guys!
I'm just looking for a way to reduce the length of a request, because
I'm requesting a lot of layers at once.
Layer group is not an option, because the list of the layers is being
formed programatically.
WFS GetFeature is cool, but I guess it requires proxy - I have to
investigate that.
So the smaller the BBOX and HEIGHT/WIDTH, the faster a client gets a
response, right?
2011/11/11 Ian Turton <ijturton@anonymised.com>:
On 11 November 2011 09:07, Rahkonen Jukka <Jukka.Rahkonen@anonymised.com> wrote:
Hi,
That all comes from WMS standard and it is rather well written there http://portal.opengeospatial.org/files/?artifact_id=1081&version=1&format=pdf
Logic goes somehow in opposite direction than what you planning to do. It assumes that user has made a GetMap request and sees a map on a screen. It is just an image and does not include any information about georeferencing. If use is clicking on a map the client software can only record which pixel was clicked. However, the georeferencing can be computed on the WMS server side if the WMS GetMap request with BBOX and image size is known.
LAYERS just need to be in the request because standard says so but QUERY_LAYERS is the one used for selecting layers to be queried. They do not need to be the same.
LAYERS is there because in theory you can just change the request from
getmap to getfeatureinfo and concatenate the click location and query
layer and send it back. This meant that back in the early days before
JavaScript became popular you could create a WMS client with some cgi
shell scripts and a submit button in ah HTML form.
For creating GetFeatureInfo requests from a scratch you will need to do some calculation. The the centre point, decide some image size in WIDTH and HEIGHT and compute BBOX according to those.
If you find that you are having to do that sort of calculation then
you should probably be using a WFS getFeature request instead of a WMS
getFeatureInfo.
Ian
Hi,
I do not believe that the size of BBOX and HEIGHT/WIDTH has any effect at all. The mathematics for finding the coordinates of the selected pixel is always the same. Server does not ever render that image if you are thinking about that.
One thing you would probably know about Geoserver is that I just learned that it is applying a buffer to the coordinates and by default it is three image pixel wide. Otherwise it would be practically impossible to find any points or linear features. You can control that with Geoserver vendor parameter "buffer".
-Jukka Rahkonen-
Gis Mage wrote:
Thanks, guys!
I'm just looking for a way to reduce the length of a request, because
I'm requesting a lot of layers at once.
Layer group is not an option, because the list of the layers is being
formed programatically.
WFS GetFeature is cool, but I guess it requires proxy - I have to
investigate that.
So the smaller the BBOX and HEIGHT/WIDTH, the faster a client gets a
response, right?
2011/11/11 Ian Turton <ijturton@anonymised.com>:
> On 11 November 2011 09:07, Rahkonen Jukka
<Jukka.Rahkonen@anonymised.com> wrote:
>> Hi,
>>
>> That all comes from WMS standard and it is rather well
written there
http://portal.opengeospatial.org/files/?artifact_id=1081&versi
on=1&format=pdf
>>
>> Logic goes somehow in opposite direction than what you
planning to do. It assumes that user has made a GetMap
request and sees a map on a screen. It is just an image and
does not include any information about georeferencing. If use
is clicking on a map the client software can only record
which pixel was clicked. However, the georeferencing can be
computed on the WMS server side if the WMS GetMap request
with BBOX and image size is known.
>>
>> LAYERS just need to be in the request because standard
says so but QUERY_LAYERS is the one used for selecting layers
to be queried. They do not need to be the same.
>
> LAYERS is there because in theory you can just change the
request from
> getmap to getfeatureinfo and concatenate the click location
and query
> layer and send it back. This meant that back in the early
days before
> JavaScript became popular you could create a WMS client
with some cgi
> shell scripts and a submit button in ah HTML form.
>
>>
>> For creating GetFeatureInfo requests from a scratch you
will need to do some calculation. The the centre point,
decide some image size in WIDTH and HEIGHT and compute BBOX
according to those.
>
> If you find that you are having to do that sort of calculation then
> you should probably be using a WFS getFeature request
instead of a WMS
> getFeatureInfo.
>
> Ian
>
On 11 November 2011 09:30, Gis Mage <gismage@anonymised.com> wrote:
Thanks, guys!
I'm just looking for a way to reduce the length of a request, because
I'm requesting a lot of layers at once.
Layer group is not an option, because the list of the layers is being
formed programatically.
You only need to set the actual layer you are interested in in both
LAYERS and QUERY_LAYERS
WFS GetFeature is cool, but I guess it requires proxy - I have to
investigate that.
Actually a getFeatureInfo request will require a proxy too (iff you
are running the server on a different host/port combo than the map).
So the smaller the BBOX and HEIGHT/WIDTH, the faster a client gets a
response, right?
Not really but you'll lose accuracy if you make them too small.
Ian
On Fri, Nov 11, 2011 at 10:20 AM, Ian Turton <ijturton@anonymised.com> wrote:
On 11 November 2011 09:07, Rahkonen Jukka <Jukka.Rahkonen@anonymised.com> wrote:
Hi,
That all comes from WMS standard and it is rather well written there http://portal.opengeospatial.org/files/?artifact_id=1081&version=1&format=pdf
Logic goes somehow in opposite direction than what you planning to do. It assumes that user has made a GetMap request and sees a map on a screen. It is just an image and does not include any information about georeferencing. If use is clicking on a map the client software can only record which pixel was clicked. However, the georeferencing can be computed on the WMS server side if the WMS GetMap request with BBOX and image size is known.
LAYERS just need to be in the request because standard says so but QUERY_LAYERS is the one used for selecting layers to be queried. They do not need to be the same.
LAYERS is there because in theory you can just change the request from
getmap to getfeatureinfo and concatenate the click location and query
layer and send it back. This meant that back in the early days before
JavaScript became popular you could create a WMS client with some cgi
shell scripts and a submit button in ah HTML form.
I believe this is a valid reason, but there is also a better one.
GetFeatureInfo theretically should tell info about you what you clicked.
Say I have a point layer and a polygon layer, the polygons contain all the points,
and you want to query them.
If the points are above the polygons the correct answer would contain some points
data (provided you clicked close enough to one).
But if the polygons are above the points instead, in theory you should not get
any info because you are actually not seeing them.
The layer ordering can only be detemined by having LAYERS
Now, that said, most servers just query all the layers without checking what is
hidden and what is visible graphically, so they would return points in both cases.
Cheers
Andrea
–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
I know this is an old thread but I was thinking about how getFeatureInfo
might work under the covers and Andrea's description of layer ordering and
only querying what the user can see is what I would expect to happen.
Regarding "most servers just query all the layers without checking what is
hidden and what is visible graphically" does this include GeoServer (2.1.3)?
I also assumed that the server would consider symbology, so if I have a
250x250 px icon GeoServer would know that I didn't have to click on or near
the underlying geographic location to select it.
Are my expectations / assumptions correct, or is GetFeatureInfo's logic
actually less sophisticated?
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/What-s-the-difference-between-LAYERS-and-QUERY-LAYERS-parameters-in-GetFeatureInfo-request-tp3788587p4964007.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
On Wed, May 9, 2012 at 10:43 PM, cheesybiscuits
<thomaschristian@anonymised.com> wrote:
I know this is an old thread but I was thinking about how getFeatureInfo
might work under the covers and Andrea's description of layer ordering and
only querying what the user can see is what I would expect to happen.
Regarding "most servers just query all the layers without checking what is
hidden and what is visible graphically" does this include GeoServer (2.1.3)?
I also assumed that the server would consider symbology, so if I have a
250x250 px icon GeoServer would know that I didn't have to click on or near
the underlying geographic location to select it.
Are my expectations / assumptions correct, or is GetFeatureInfo's logic
actually less sophisticated?
Hum, yes and no. The code in the released version tries to take into account
all symbolizer sizes, but due to this bug
https://jira.codehaus.org/browse/GEOS-5112
the buffer distance evaluator did not take into account the size of external
graphics unless you explicitly declared it in the SLD file, but leaving instead
the icon at its natural size.
The issue should be fixed now, if you want to try out the fix try using the
latest nightly build here:
http://gridlock.opengeo.org/geoserver/2.1.x/
Cheers
Andrea
--
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf