Closed GoogleCodeExporter closed 9 years ago
Could you give me an example of a complete query?
I imagine that it would not respond to a resultType=hits query like the
features do.
How about a DescribeFeatureType? I'm a little worried that your answer will be
no. I make a DescribeFeatureType request / layer in order to label the top of
the columns in the Feature Details panel.
If it follows drastically different rules, it will be tricky to merge it in w/
feature queries that may be coming in at the same time. E.g. a user makes a
bbox or a poly query for imperv. surface as well as counties. What would I
show? Use the centroid of the incoming bbox / poly?
Original comment by cpl...@gmail.com
on 21 Sep 2011 at 3:35
You can DescribeCoverage:
http://giswebservices.massgis.state.ma.us/geoserver/wcs?service=wcs&version=1.1.
1&request=DescribeCoverage&Identifiers=massgis:GISDATA.IMG_IMPERVIOUSSURFACE
Original comment by Aleda.Fr...@state.ma.us
on 21 Sep 2011 at 8:53
I think this is what we are looking for:
http://170.63.166.213:8080/geoserver/wms?REQUEST=GetFeatureInfo&EXCEPTIONS=appli
cation%2Fvnd.ogc.se_xml&BBOX=28898.694336%2C771320.473633%2C337101.305664%2C9646
79.526367&X=366&Y=226&INFO_FORMAT=text%2Fhtml&QUERY_LAYERS=massgis%3AGISDATA.IMG
_COQ2005&FEATURE_COUNT=50&Srs=EPSG%3A26986&Layers=massgis%3AGISDATA.IMG_COQ2005&
Styles=&WIDTH=526&HEIGHT=330&format=image%2Fjpeg
I pulled this sample from the OpenLayers demo when I click on the map and get
the response. Although the output doesn't have to be text/html. You have 2
options:
text/plain, text/html
Results will vary based on how many channels the image has. See attachments
identify_on_raster_coq2005.png vs. identify_on_raster_imp_surf.png
Original comment by Aleda.Fr...@state.ma.us
on 22 Sep 2011 at 4:09
Attachments:
So, the identify is only for a point, if they draw a box I guess you can take
the centroid? Or perhaps better, leave any raster layer off the results unless
they click as a point. The request is going to be different n any case - it's
not an XML GetFeature. You might have to put the results for rasters in a
different window or something, because the result can have various amounts of
data. (although it's all pretty small - it gives back the value at the point
of the cell for all the bands, and MassGIS only have 1,2,3 or 4 band images...
Original comment by Aleda.Fr...@state.ma.us
on 22 Sep 2011 at 4:14
The impervious surface for example is only 1 band. The values are either 0 or
1. 0 means no impervious surface, 1 means yes there is impervious surface.
For the 2005 orthos there are 4 bands of info for a cell - red, green, blue,
near infrared. Values from 0-255 for each one. For something we think of as a
grid like wind (see attachment) the cell has a value (could be integer or
float). The legend is symbolizing ranges of colors, but by "identifying" a
cell you can get the exact value for that cell.
Original comment by Aleda.Fr...@state.ma.us
on 22 Sep 2011 at 4:19
Attachments:
Committed revision 160.
v. 0.55
Clicking on a raster layer in the at-a-glance query popup will take the
CENTROID of whatever shape (bbox / poly / point) you queried and launch a
getfeatureinfo w/ the results (html) in a new window.
Original comment by cpl...@gmail.com
on 27 Sep 2011 at 9:37
Charlton, is this tool doing any math? The returned for the wind speed layer
is coming back with 15 decimal places. The raster when displayed in Arc is
only showing six decimal places and I don't believe that any rounding is
occurring. Marc and Emily, do you know if there is decimal place constraint
for ID in arc?
Original comment by daniel.s...@state.ma.us
on 28 Sep 2011 at 3:15
I'm simply passing along the HTML that the getfeatureinfo requests returns. I
get to remain completely oblivious to its contents.
Original comment by cpl...@gmail.com
on 28 Sep 2011 at 3:18
[deleted comment]
We're making good progress on this but there's still a lot left to get this
working correctly. Here's my list, some easy, some perhaps not so much:
1. The Identify on raster need to be single click driven, not rectangle driven
as for vectors. Identify on raster can only return a single value so selecting
by rectangle or, shudder, multipart poly wholly occludes the point that user
wishes to find info on. Here's what we'd like: Single click returns raster
AND polys. Drawing a box or poly ONLY returns polys.
2. When a raster is identified on, the "Feature(s) found?" = n/a. You only know
if the Identify was successful by clicking the highlighted layer name. We feel
that returning "1" in place of "n/a" is appropriate as the raster identify can
only return one and only one feature. Likewise if the user identifies on an
area that the raster data does not cover (out of bounds), the return should be
"0".
3. For those areas with "0" as above, i.e. no data, the tool currently returns
one of the following: number that comes from an unknown cell (not the
centroid), NaN (we don’t know what this means), or no features found. "0"
would again be the appropriate return.
4. Instead of displaying the cell value in the Feature Details portion of the
Query results, the data are displayed in a popup. Can we have the raster data
returned in the same manner as the vector. If we can't see 4.5 below.
4.5 The popup window that displays the identify tool is unnecessarily large. I
suggest making the width appropriate to the layer name (or perhaps wrapping the
layer name if it exceeds 50 characters) and height all that's necessary to
display the layer name and four bands (four being the most values that will
returned.)
5. Change the word "Band" to "Value." While band is correct for orthophotos
(R,G,B) it's incorrect for data like bathymetry where the return is going to be
a single depth value, e.g. 6.2 meters. The term "value" is more generic and
can suffice for both types of raster data.
6. Raster Identify doesn't work on any non-custom basemap. Value are also
flaky, try the Impervious Surface data layer that has cell values of 0 and 1
(presence and absence). Some returns are clearly giving the wrong value.
Original comment by daniel.s...@state.ma.us
on 30 Sep 2011 at 7:10
>1. The Identify on raster need to be single click driven, not rectangle driven
as
>for vectors. Identify on raster can only return a single value so selecting by
>rectangle or, shudder, multipart poly wholly occludes the point that user
>wishes to find info on. Here's what we'd like: Single click returns raster
AND
>polys. Drawing a box or poly ONLY returns polys.
This issue is only charged w/ making point requests to rasters. Even though
both our bbox and poly identify tools can fire off a point request (by only
passing along the centroid), perhaps we should have yet another button :( that
is specifically for point queries.
>2. When a raster is identified on, the "Feature(s) found?" = n/a. You only
>know if the Identify was successful by clicking the highlighted layer name. We
>feel that returning "1" in place of "n/a" is appropriate as the raster
identify can
>only return one and only one feature. Likewise if the user identifies on an
>area that the raster data does not cover (out of bounds), the return should be
>"0".
Sounds reasonable. But I'll wait for a consensus.
>3. For those areas with "0" as above, i.e. no data, the tool currently returns
>one of the following: number that comes from an unknown cell (not the
>centroid), NaN (we don’t know what this means), or no features found. "0"
>would again be the appropriate return.
>
>4. Instead of displaying the cell value in the Feature Details portion of the
>Query results, the data are displayed in a popup. Can we have the raster data
>returned in the same manner as the vector. If we can't see 4.5 below.
I have zero control of the contents in the popup window. That is entirely up
to geoserver.
>4.5 The popup window that displays the identify tool is unnecessarily large. I
>suggest making the width appropriate to the layer name (or perhaps wrapping
>the layer name if it exceeds 50 characters) and height all that's necessary to
>display the layer name and four bands (four being the most values that will
>returned.)
I can control the size of the popup and can base it on the layer name, but I
don't want to have to base it on the contents. That would imply that my end
would need to read through the contents before displaying them.
>5. Change the word "Band" to "Value." While band is correct for orthophotos
>(R,G,B) it's incorrect for data like bathymetry where the return is going to
be a
>single depth value, e.g. 6.2 meters. The term "value" is more generic and can
>suffice for both types of raster data.
Again, I have no control over that.
>6. Raster Identify doesn't work on any non-custom basemap. Value are also
>flaky, try the Impervious Surface data layer that has cell values of 0 and
>1 (presence and absence). Some returns are clearly giving the wrong value.
I haven't tested this on non-custom. Aleda, are there quirks about projections
and getfeatureinfo's for rasters that bing them to custom?
Original comment by cpl...@gmail.com
on 1 Oct 2011 at 10:15
GetFeatureInfo needs to have the X and Y in screen coordinates and not real
world map coordinates.
For example, this app uses GetFeatureInfo when a click on the map is done.
This map is 600px × 358px.
http://maps.massgis.state.ma.us/dcr/forestry/forestry23.html
The system is, 0,0 is upper left hand corner.
Y goes down, X goes right.
If you click on the upper left hand corner the X and Y will be very small.
If you click on the lower right hand corner the X and Y will be close to 600
and 358.
What we're seeing in MORIS is the X and Y is varying depending on the basemap.
It looks like the X and Y are being expressed in real world map coordinates,
not pixels.
For example:
in Google Satellite: &X=-80083&Y=-53190
In OpenStreetMap: &X=1807&Y=847
There is a little more info at our wiki:
https://wiki.state.ma.us/confluence/display/massgis/getfeatureinfo+home
We can't point to one particular click that is always going to be wrong because
it depends on various factors but this Impervious Surface layer
is a good one to test with because purple should have a value of 1 and white
should have a value of 0.
What we're seeing now is sometimes values are correct and sometimes they aren't
(regardless of basemap, even in Custom we're not getting consistently correct
responses).
http://170.63.166.213/map_ol_mop/moris.php?lyrs=Impervious%20Surface~massgis:GIS
DATA.IMG_IMPERVIOUSSURFACE&bbox=-71.06645180478837,42.43016241260629,-71.0659006
3307482,42.43040420205877&coordUnit=m&measureUnit=m&base=custom¢er=235698.34100
953,908953.26305411&zoom=15
(use your own server)
Original comment by Aleda.Fr...@state.ma.us
on 20 Oct 2011 at 2:19
That was a doosy. I was passing in x,y coords but they were obviously
incorrect. See if this fixes it, please.
v. 0.65
Committed revision 175.
Original comment by cpl...@gmail.com
on 20 Oct 2011 at 3:52
Raster ID is still not returning correct values. Choose an isolated grid cell
and note Query result does not fall within the range of values in the legend.
http://170.63.166.213/map_ol_mop/moris.php?lyrs=Massachusetts%20Municipal%20Boun
daries%20Lines~massgis:GISDATA.TOWNSSURVEY_ARC|Digital%20Offshore%20Cadastre%20-
%20Atlantic83%20-%20Submerged%20Lands%20Act%20(SLA)%20Boundary%20Line~massgis:MO
RIS.SLA_ARC|Massachusetts%20Lateral%20Boundaries~massgis:MORIS.MASS_LATERAL_BOUN
DARIES_ARC|New%20England%20Mask~massgis:GISDATA.NEMASK_POLY|Modeled%20Wind%20Spe
ed%20at%2050%20meters~massgis:GISDATA.IMG_WIND_SPD50M&bbox=-70.89256732551057,42
.15935934866247,-70.72519748300384,42.26692066838212&coordUnit=dms&measureUnit=m
&base=googleSatellite¢er=-7882408.7328827,5192963.8890476&zoom=6
Original comment by daniel.s...@state.ma.us
on 20 Oct 2011 at 5:41
Yay. I think I've got it this time.
v. 0.68
Committed revision 178.
Original comment by cpl...@gmail.com
on 20 Oct 2011 at 6:46
Emily and Aleda did some investigations and this is our theory and proposed
fix:
The width and height in the URL is not producing a close enough match in the
aspect ratio of the bounding box (reminder: width/height of the real world
coordinates meters represented by the bounding box needs to be close in value
to the width/height meters of the width and height url parameters.
We found that if we look at the width and height in Firebug - found it to be
1615 x 634 but the GetFeatureInfo URL was coming out with 1920 x 688. If we
put the 1615 x 634 in then the GetFeatureInfo result was correct.
The width and the height need to accurately reflect the image size in the
visible window.
If we changed the GetFeatureInfo URL into a GetMap we noticed that the map
image was stretched - it did not match what was in the browser window.
For example, you can change a GetFeatureInfo into a GetMap
http://170.63.166.213:8080/geoserver/wms?LAYERS=massgis%3AGISDATA.IMG_IMPERVIOUS
SURFACE&TRANSPARENT=TRUE&STYLES=GISDATA.IMG_IMPERVIOUSSURFACE%3A%3ADefault&SERVI
CE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo&FORMAT=image%2Fpng&SRS=EPSG%3A26986&
BBOX=235866.92064%2C908922.96233%2C235912.140616%2C908940.71432&X=11&Y=17&QUERY_
LAYERS=massgis%3AGISDATA.IMG_IMPERVIOUSSURFACE&WIDTH=1920&HEIGHT=688
http://170.63.166.213:8080/geoserver/wms?LAYERS=massgis%3AGISDATA.IMG_IMPERVIOUS
SURFACE&TRANSPARENT=TRUE&STYLES=GISDATA.IMG_IMPERVIOUSSURFACE%3A%3ADefault&SERVI
CE=WMS&VERSION=1.1.1&REQUEST=GetMap&FORMAT=image%2Fpng&SRS=EPSG%3A26986&BBOX=235
866.92064%2C908922.96233%2C235912.140616%2C908940.71432 &WIDTH=1920&HEIGHT=688
You don't want to use the width and height of the larger map image that
OpenLayers is probably using behind the scenes (to prevent small pans from
needing new requests), you want to use the real width and height shown in the
browser window. The Firebug Inspect Element will give you the value you need
which will be a small width/height box than what you get from the GetMap.
Original comment by Aleda.Fr...@state.ma.us
on 20 Oct 2011 at 7:01
Those were the exact comparisons I made that led me to my latest fix. Did you
try queries in 0.68?
Original comment by cpl...@gmail.com
on 20 Oct 2011 at 7:03
Yes, we're using version 68. The width and height seem to be correct now.
However, the X and Y seem to have changed - before they were correct in
starting 0,0 in the upper left hand corner and increasing as the user clicked
over to the right and down.
Now, it seems that the upper left is negative values, 0,0 is in the center and
the bottom right is positive values.
If we click in the very upper left of the screen the x and y should be
practically 0 and 0. If we click in the very lower right of the screen the x
and y should be practically the width and height.
Original comment by Aleda.Fr...@state.ma.us
on 20 Oct 2011 at 7:23
Won't this issue just go away!
One more try . . .
v. 0.69
Committed revision 179.
Original comment by cpl...@gmail.com
on 20 Oct 2011 at 7:30
Identify on rasters is working correctly! We've tested integer and floating
point rasters in custom, Bing satellite, Google road map, and OSM and always
got the correct value.
Original comment by emily.hu...@state.ma.us
on 20 Oct 2011 at 8:27
We'd like to make the raster identify results more user friendly by doing the
following:
1. When a raster is identified on, the "Feature(s) found?" = n/a. You only know
if the Identify was successful by clicking the highlighted layer name. We feel
that returning "1" in place of "n/a" is appropriate as the raster identify can
only return one and only one feature. Likewise if the user identifies on an
area that the raster data does not cover (out of bounds), the return should be
"0".
2. The popup window that displays the identify results for rasters is
unnecessarily large. Please resize to a more appropriate width and height. The
width could be equal to the dashed line.
Original comment by emily.hu...@state.ma.us
on 25 Oct 2011 at 1:46
Charlton, here's the info that you asked for in the meeting today:
Rasters are not necessarily rectangular. Though they have a rectangular bbox
as part of their metadata, relying on that to figure out if the user clicked on
or off (say, way out in the ocean) the raster is not completely accurate.
Also, some "edges" of a raster do not have real values. They are "NaN" which
means Not-a-Number (I believe they are null?). A possible alternative to the
way its is now (always shows n/a for features) would be to do the
GetFeatureInfo request in the first query results request that figures out the
number of features (for vectors it's a WFS request). The GetFeatureInfo could
be done here, if NaN is encountered or "No features were found.”, print "0".
If real values are encountered for the bands, print "1". Because a raster
identify is always clicking on one cell there is always only 1 possible
"feature" returned.
If this is not possible keep things as they are?
Original comment by Aleda.Fr...@state.ma.us
on 27 Oct 2011 at 2:28
Give it a shot. I'd rather put 'no value' and '1 value' instead of '0' or '1'.
Is that OK?
And for the record, I'm looking for the presence of 'Results' as part of the
getfeatureinfo return text to determine whether it is 'no value' or '1 value'.
I tested it w/ Impervious Surface, and it seems to work well.
If you want me to keep a query from being fired when a user clicks on 'no
value', let me know. I have left it alone so that you could test.
At one point I think Dan asked if I could do something about the popup screen
size. I made it smaller, and I am also requesting the info as text/html.
Maybe that will wrap now. The default text/plain would probably never wrap.
v. 0.81
Committed revision 212.
Original comment by cpl...@gmail.com
on 21 Nov 2011 at 3:20
Here are our comments:
1. Returning "no value" or "1 value" in the at a glance table is fine by us.
2. We would like to keep a query from being fired when a user clicks on "no
value" (otherwise the user gets a blank popup). If a user clicks a raster
dataset with no value, the pop-up message could read "This row has no values.
No details will be fetched."
3. When a user draws a bbox or poly to identify on a raster, would it be
possible to query the first cell where the user clicks rather than the
centroid? This behavior would be consistent with ArcGIS.
4. It's important to somehow highlight or flash the raster cell that is being
queried. If not, users could be confused about which cell is actually being
identified. Vector data are highlighted, so would it be possible to add a
similar behavior to the raster cell that has been identified?
5. When you identify on a raster and click "1 value," a pop-up message appears.
You can then do another query on the map and the pop-up window will stay open
with the previous raster identify results. Is there any way to close this when
a new query takes place or when a user closes the query results window? For
vector data, the feature details table is cleared each time the identify tool
is clicked on the map to ensure that users are always looking at the most
current feature details. We'd like raster queries to be treated similarly if
possible.
6. After I identify on a raster, I can keep clicking "1 value" in the at a
glance table and open multiple pop-up windows for the same raster query
results. Seems like users should only have one pop-up window per raster at a
time. Would it be possible to limit it so that users can have only one pop-up
window with the raster results?
Original comment by emily.hu...@state.ma.us
on 22 Nov 2011 at 4:31
#1 & #2 done.
#3. I really need to keep it consistent w/ how the point queries work. They,
too, are bound to the middle of the polygon and not the 1st point.
#4. Done. A big red X marks the spot. If you want to change the icon, ship
it to me.
#5 & #6. The popup is closed when the query results window is closed. The
contents of the popup is replaced w/ subsequent queries. Only 1 popup / raster
is displayed at a time.
v. 0.88
Committed revision 234.
Original comment by cpl...@gmail.com
on 23 Nov 2011 at 2:29
When I click on a row with "no value," the pop-up message refers to features.
The message should read "This raster data layer has no value in the cell you
identified."
The red x is very helpful, but it only appears if a value is returned. It would
make sense to have an x drawn on the map when a user clicks a raster layer's
row regardless of whether or not a value was returned.
Original comment by emily.hu...@state.ma.us
on 20 Dec 2011 at 10:15
The text has been changed, and the X will appear after clicking on a 'no value'
row as long as the popup is up (similar to the way the window w/ a real raster
getfeatureinfo result works).
If you are making a wish list, I think it would make mostest sense to have a
point query button to go along w/ the bbox & poly buttons. Then we could
always show the X on the map at the start of a point query. I thought about
going ahead and putting an X on the map when it seemed that the user was making
a point query. In bbox mode it worked fine, but since we allow a poly query to
turn into a single point raster query (by taking the centroid of the poly), the
X would get messy to implement. All that confusion led me to my conclusion
that a point query button would eliminate, or at least reduce, confusion.
v. 2.04
Committed revision 280.
Original comment by cpl...@gmail.com
on 21 Dec 2011 at 4:21
Verified. The text was changed and the red X appears after clicking on a "no
value" row.
Original comment by emily.hu...@state.ma.us
on 22 Dec 2011 at 8:42
Original issue reported on code.google.com by
emily.hu...@state.ma.us
on 29 Jul 2011 at 7:17Attachments: