search

nakijun / morisoliver

Automatically exported from code.google.com/p/morisoliver
0 stars 0 forks source link

Add ability to identify points on rasters #51

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Identify can work on rasters to give the values of the bands. We would like to 
add the ability to identify points on rasters. See the attached screenshot for 
an example in OpenLayers showing identify on two rasters (GISDATA.IMG_COQ2001 
is an ortho with 3 bands and GISDATA.IMG_IMPERVIOUSSURFACE is a "grid" with 1 
band).

Original issue reported on code.google.com by emily.hu...@state.ma.us on 29 Jul 2011 at 7:17

Attachments:

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
>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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
#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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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