Allow user to change a layer's symbology

[GoogleCodeExporter]

Allow user to change a layer's symbology by selecting from a set of colors. 
Color change would alter the legend as well. 

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

[GoogleCodeExporter]

I assume that a user-selected color would alter the STYLE that I am requesting 
for a given layer.  Since the app. is showing the layers based on styles 
identified in foldersets, I'm a bit worried about monkeying w/ this param.  
Aleda, you don't see this as an issue?  Could you give me an example of a 
default WMS request vs. one where a user has selected a color?

Original comment by cpl...@gmail.com on 24 Aug 2011 at 8:05

[GoogleCodeExporter]

This is a really tough one.  There are a few ways it could be done possibly.
I could provide a set of alternative styles.  Say, for point, line and polygon 
8 different colors.  That would be 24 styles.  Styles can be generic so that 
the datalayer does not have to be mentioned.  Then we could provide the user 
with a color picker for the 8 colors.  All features of the layer would turn 
that color.  MORIS would need to start using the NEW style.  Say, "Red_Poly", 
"Red_Line" "Red_Pt". 

For example, I have "Black_Outlines" and "Red_Outlines" styles already which 
can be applied to any polygon layer.  Here are WMS and GetLegendGraphic 
requests for these examples:

http://giswebservices.massgis.state.ma.us/geoserver/wms?service=WMS&version=1.1.
0&request=GetMap&layers=massgis:GISDATA.TOWNS_POLY&styles=Black_Outlines&bbox=33
861.264,777514.311,330846.094,959747.441&width=537&height=330&srs=EPSG:26986&for
mat=image/png

http://giswebservices.massgis.state.ma.us/geoserver/wms?service=WMS&version=1.1.
0&request=GetMap&layers=massgis:GISDATA.TOWNS_POLY&styles=Red_Outlines&bbox=3386
1.264,777514.311,330846.094,959747.441&width=537&height=330&srs=EPSG:26986&forma
t=image/png 

http://giswebservices.massgis.state.ma.us/geoserver/wms?VERSION=1.1.0&REQUEST=Ge
tLegendGraphic&LAYER=massgis:GISDATA.TOWNS_POLY&STYLE=Black_Outlines 
&WIDTH=16&HEIGHT=16&FORMAT=image/png

http://giswebservices.massgis.state.ma.us/geoserver/wms?VERSION=1.1.0&REQUEST=Ge
tLegendGraphic&LAYER=massgis:GISDATA.TOWNS_POLY&STYLE=Red_Outlines&WIDTH=16&HEIG
HT=16&FORMAT=image/png 

However, in our system we have OL_MORIS_Cache output for every layer/style 
combination.  Generating 24 more options for each layer would be awkward. Is it 
necessary to do that?

The other way of doing this is to send a more complicated WMS request. 
For example, I could put on maps.massgis.state.ma.us XML for the 24 styles.
Then you could generate a WMS and GetLegendGraphic request that referenced the 
XML:
(note, that black_points.sld.xml isn't there just now).

http://giswebservices.massgis.state.ma.us/geoserver/wms?VERSION=1.1.0&REQUEST=Ge
tLegendGraphic&LAYER=massgis:GISDATA.AIRPORTS_PT&SLD=http://maps.massgis.state.m
a.us/misc/black_points.sld.xml&WIDTH=16&HEIGHT=16&FORMAT=image/png

Another way is to embed the symbolization into the request:
https://wiki.state.ma.us/confluence/display/massgis/point+example 
But you need to do XML request at that point.  And you can't get your legend 
that way: https://wiki.state.ma.us/confluence/display/massgis/legend

Original comment by Aleda.Fr...@state.ma.us on 25 Aug 2011 at 4:18

[GoogleCodeExporter]

This post makes a good point that there really doesn't have to be a difference 
b/w a legend and a table of contents in a web mapping app.  That said, Elvis 
has left the building.  <-- bad joke

http://gis.stackexchange.com/questions/7917/whats-the-difference-between-toc-and
-legend-really

Original comment by daniel.s...@state.ma.us on 26 Aug 2011 at 7:13

[GoogleCodeExporter]

They are 2 when you have a complicated symbology like landuse.

Original comment by Aleda.Fr...@state.ma.us on 26 Aug 2011 at 7:36

Attachments:

• landuse_legend.JPG

[GoogleCodeExporter]

"However, in our system we have OL_MORIS_Cache output for every layer/style 
combination.  Generating 24 more options for each layer would be awkward. Is it 
necessary to do that"

Thinking out loud . . .

* I follow the layer-style pairing in order to know what STYLE param to pass as 
part of both the getimage and getlegendgrphic requests, and I also need to know 
this pairing to discover any scale issues that you choose to relate to a STYLE.

* If you were to supplement this style w/ something like 'yellow' or 'red', I 
wouldn't want to lose the hook to its scale info.

* Would these 'yellow' or 'red' styles only apply to relatively simple layers 
that aren't tied up w/ scale info?  I can't recall a good example where munging 
w/ the style would complicate things, but I know they are there!

* It is very easy for me to swap out the style param in the requests here.  I 
just don't want to break anything elsewhere (scale checks, etc.).

Original comment by cpl...@gmail.com on 19 Sep 2011 at 8:36

[GoogleCodeExporter]

Charlton, I made the 33 styles.
They are:

White_Points  /  White_Lines  / White_Polys
Tan...
Grey
Pink
Red
Orange
Yellow
Green
Blue
Dark_Blue
Purple

ex:

http://giswebservices.massgis.state.ma.us/geoserver/wms?service=WMS&version=1.1.
0&request=GetMap&layers=massgis:GISDATA.TOWNS_POLY&styles=Green_Polys&bbox=42861
.473,779140.0,325961.437,949687.312&width=547&height=330&srs=EPSG:26986&format=i
mage/png

http://giswebservices.massgis.state.ma.us/geoserver/wms?service=WMS&version=1.1.
0&request=GetMap&layers=massgis:GISDATA.AIRPORTS_PT&styles=Dark_Blue_Points&bbox
=42861.473,779140.0,325961.437,949687.312&width=547&height=330&srs=EPSG:26986&fo
rmat=image/png

http://giswebservices.massgis.state.ma.us/geoserver/wms?service=WMS&version=1.1.
0&request=GetMap&layers=massgis:GISDATA.TOWNS_ARC&styles=Purple_Lines&bbox=42861
.473,779140.0,325961.437,949687.312&width=547&height=330&srs=EPSG:26986&format=i
mage/png

These aren't going to have an OL_MORIS_cache for each one for each possible 
layer.  Hopefully you can hard code the names of these 33 styles.

The color picker would use these 11 plus one "revert" button.

The colors in Hex to show are:

FFFFFF - white
D7C29E - tan
686868 - grey
FFBEBE - pink
FF0000 - red
FFD37F - orange
FFFF00 - yellow
55FF00 - green
00C5FF - blue
005CE6 - dark blue
C500FF - purple

The GetLegendGraphic request will automatically draw the correct legend using 
these styles. 

Please let me know if you have any questions.

http://giswebservices.massgis.state.ma.us/geoserver/wms?VERSION=1.1.0&REQUEST=Ge
tLegendGraphic&LAYER=massgis:GISDATA.AIRPORTS_PT&STYLE=Green_Points&WIDTH=16&HEI
GHT=16&FORMAT=image/png

Original comment by Aleda.Fr...@state.ma.us on 31 Oct 2011 at 8:54

[GoogleCodeExporter]

Give it a shot!

A couple of things:

* It's fine as is, but we probably should have stuck w/ the original naming 
convention of pt, poly, and line.

* Any color customizations should carry over into permalink and printing.

* I hope color customizations don't break any of the downstream uses of the 
styles param, e.g. data export scale checks.

* The colorpicker box has been limited to the colors you listed above.  I 
realize there is white space around the boxes.  Not sure if I can fix that.

* I cannot put a revert button below the picker.  So I put it in the top menu 
level.

v. 0.77
Committed revision 192.

Original comment by cpl...@gmail.com on 17 Nov 2011 at 4:22

• Changed state: Fixed

[GoogleCodeExporter]

"we probably should have stuck w/ the original naming convention of pt, poly, 
and line."
sorry about that.  Pain to change it now... 

Original comment by Aleda.Fr...@state.ma.us on 17 Nov 2011 at 4:31

[GoogleCodeExporter]

Very neat! Below are our comments:

1. The custom symbology is lost when changing to or from the Custom basemap.

2. The order of the first three colors is different in different browsers. This 
should be consistent across all browsers.
> Chrome and IE: gray, white, and tan
> Firefox and Safari: white, tan, and gray

3. After a user selects a color, the color picker menu should close.

4. If a user doesn't select a color and moves the mouseover away from the menu, 
the menu should close.

5. Would it be possible to resize the color picker menu to remove the white 
space? If so, we'd like to add a 12th color option so that the colors could be 
arranged in a 4x3 or 6x2 table. If we can't resize the menu, what about making 
the color icons bigger to fill more space?

6. "Revert to original color" should be "Revert to original symbology"

Original comment by emily.hu...@state.ma.us on 17 Nov 2011 at 9:25

[GoogleCodeExporter]

One more comment:

7. Layers that are drawn with a special style (rather than the default style) 
are no longer drawing with the correct style. For example, the Boston Harbor 
Islands layer is the National Park Service dataset with a special style. When I 
first add the Boston Harbor Islands layer, it is drawn with the default NPS 
style (black outlines). If I then choose "Revert to original color," it changes 
to the correct style (brown filled polygon). It looks like layers that aren't 
drawn with the default style are originally added to the map with the default 
style and I have to revert to the original symbology to get the correct style.

Original comment by emily.hu...@state.ma.us on 17 Nov 2011 at 9:45

[GoogleCodeExporter]

I'm glad I slept on your comment #7.  That made no sense to me when I read it 
at COB yesterday.  COB today?  Yes it did!

Everything except #4 should be taken care of.  You're welcome to push back, but 
I don't think the menu should disappear when a user moves the mouse away from 
the color picker.  In my mind, that's not natural behavior.  Clicking anywhere 
outside of the picker closes it (default behavior) -- and now making a 
selection closes it, too.

v. 0.78
Committed revision 209.

Original comment by cpl...@gmail.com on 18 Nov 2011 at 9:52

[GoogleCodeExporter]

Aleda, make sure you pull the revised .css.  And, CZM, if you don't see a 
change in the size of the color picker, refresh your browser so that it picks 
up the changes.

Oh, I guess I should tell you . . . I added a 12th color! 000000 = 'black'.  So 
creative.  If you want another one instead, let me know.  But we needed more 
balance in our lives and in our application.

Original comment by cpl...@gmail.com on 18 Nov 2011 at 9:54

[GoogleCodeExporter]

Aleda, in order to make the legends and the layers match w/ custom styles, I am 
passing a STYLE param to both.  Oddly, getlegendgraphic wants STYLE while 
getmap wants STYLE.  Since I'm passing them to both, the param gatekeeper is 
not happy w/ things like raster point queries since I'm passing it a STYLE 
param.  Can you allow that one through?

Original comment by cpl...@gmail.com on 18 Nov 2011 at 10:26

[GoogleCodeExporter]

Meant to say that getmap wants STYLES.

Original comment by cpl...@gmail.com on 18 Nov 2011 at 10:27

[GoogleCodeExporter]

I just added styles to getlegendgraphic (that's what you needed right?  getmap 
had both style and styles already), but the gateway's cache needs to be cleared.
It does happen maybe once an hour I'm told.  No one will be there now to do it 
manually I think. 

Original comment by Aleda.Fr...@state.ma.us on 18 Nov 2011 at 10:31

[GoogleCodeExporter]

Sorry . . . hold off on my gatekeeper request for STYLE.  I may have a 
workaround here.

Original comment by cpl...@gmail.com on 18 Nov 2011 at 10:31

[GoogleCodeExporter]

getmap already accepts "STYLES"

http://giswebservices.massgis.state.ma.us/geoserver/wms?VERSION=1.1.1&REQUEST=Ge
tMap&SERVICE=WMS&LAYERS=massgis:GISDATA.TOWNS_POLYM,massgis:GISDATA.NAVTEQRDS_AR
C,massgis:GISDATA.NAVTEQRDS_ARC_INT&SRS=EPSG:26986&BBOX=232325.38526025353,89870
5.3447384972,238934.49648710093,903749.1401484597&WIDTH=570&HEIGHT=435&FORMAT=im
age/png&STYLES=Black_Lines,GISDATA.NAVTEQRDS_ARC::ForOrthos,GISDATA.NAVTEQRDS_AR
C_INT::Default&TRANSPARENT=TRUE

Original comment by Aleda.Fr...@state.ma.us on 18 Nov 2011 at 10:34

[GoogleCodeExporter]

GetMap may support STYLES but it probably doesn't support STYLE.  But don't 
worry about it.  I may have a fix here.

Original comment by cpl...@gmail.com on 18 Nov 2011 at 10:37

[GoogleCodeExporter]

But just so you know . . . I think that raster point query is broken for now.

Original comment by cpl...@gmail.com on 18 Nov 2011 at 10:38

[GoogleCodeExporter]

yes, the gateway will let both styles and style through, but only styles will 
do anything with geoserver.

Original comment by Aleda.Fr...@state.ma.us on 18 Nov 2011 at 10:46

[GoogleCodeExporter]

re: comment 20 - for getmap I mean

Original comment by Aleda.Fr...@state.ma.us on 18 Nov 2011 at 10:46

[GoogleCodeExporter]

Raster query working again.  (I needed to strip STYLE= out of the request.)

v. 0.80
Committed revision 211.

Original comment by cpl...@gmail.com on 19 Nov 2011 at 2:42

[GoogleCodeExporter]

Looks good! Here are our notes:

1. The custom symbology is lost when changing to or from the Custom basemap.
>>> Fixed

2. The order of the first three colors is different in different browsers. This 
should be consistent across all browsers.
>>> Fixed

3. After a user selects a color, the color picker menu should close.
>>> Fixed

4. If a user doesn't select a color and moves the mouseover away from the menu, 
the menu should close.
>>> Your point about not changing #4 makes sense. Currently, menus close when a 
user clicks anywhere on the three windows to the right and the toolbars, but 
not when a user clicks on the map. Would it be possible to add this to the 
default behavior? It would be nice if menus close any time a user clicks, 
whether in the map view or elsewhere.

5. Would it be possible to resize the color picker menu to remove the white 
space? If so, we'd like to add a 12th color option so that the colors could be 
arranged in a 4x3 or 6x2 table.
>>> Fixed

6. "Revert to original color" should be "Revert to original symbology"
>>> Fixed

7. Layers that are drawn with a special style (rather than the default style) 
are no longer drawing with the correct style.
>>> Fixed

New bug:
Once I change the color of one layer, I can't change the color of a second 
layer to the same color as the first layer. For example, I changed the MIMIC 
2010 monitoring sites to red. I then tried to change the ferry routes to red, 
but I couldn't. Red is already selected in the ferry routes color picker menu 
even though I haven't changed the symbology of that layer. To change the ferry 
routes to red, I have to first change it to another color and then I can select 
red.

Original comment by emily.hu...@state.ma.us on 21 Nov 2011 at 8:21

[GoogleCodeExporter]

Just want to clarify the above comment #4. We'd like all the drop-down and 
right-click menus to behave the same way, not just the color picker. So, when a 
user clicks on the map, this would close any drop-down or right-click menu that 
is open (e.g., the Help drop-down menu should also close when a user clicks 
anywhere on the screen).

Original comment by emily.hu...@state.ma.us on 22 Nov 2011 at 2:25

[GoogleCodeExporter]

See if the bug is now fixed.

v. 0.85
Committed revision 227.

Original comment by cpl...@gmail.com on 22 Nov 2011 at 2:54

[GoogleCodeExporter]

Re comment 24.  That's a valid request, but I think it should be moved to a new 
issue to see if it makes the cut.  Checking for any popups across the board 
would be pretty hairy.

Original comment by cpl...@gmail.com on 22 Nov 2011 at 3:10

[GoogleCodeExporter]

Regarding comment 24, I created Issue 95: Close menus when a user clicks on map 
view.

Original comment by emily.hu...@state.ma.us on 22 Nov 2011 at 5:13

[GoogleCodeExporter]

The bug is fixed. I can change more than one layer to the same color now.

Original comment by emily.hu...@state.ma.us on 22 Nov 2011 at 8:42

• Changed state: Verified

[GoogleCodeExporter]

After a user changes the symbology of a layer with a scale dependency that is 
not visible at the current map scale, they can then view the layer. The icon, 
however, keeps the yellow exclamation point. The yellow exclamation point icon 
should be removed since the layer is now visible.

Original comment by emily.hu...@state.ma.us on 16 Dec 2011 at 4:08

• Changed state: Fixed

Attachments:

• screenshot.png

[GoogleCodeExporter]

I think this is actually a bigger issue.  The min/max resolution info I get 
from slice getcaps is telling me that the layer should NOT be visible at 
whatever resolution you are looking at, yet by changing the style, it is 
obviously vizzing fine.  So the custom style seems to bypass the min/max 
resolution info for the default style at the SERVER.

E.g. I ask for a WMS layer to be drawn at 1:1000 w/ the default style.  My end 
knows that this is a bad request, so it shows the icon (and makes the request 
anyway which is a blank image).  Next I change the style to a new color.  It 
still thinks this is a bad request due to the slice_getcaps rule, yet when it 
tries to draw the layer anyway, it actually gets an image.

Is that the way it should be working on the backend?  If that's NOT how the 
backend should be working, then I need to turn off the scale checks for custom 
styles.

Original comment by cpl...@gmail.com on 16 Dec 2011 at 6:55

[GoogleCodeExporter]

Once a user changes to a custom style, the layer loses whatever scale 
dependency may have been present in the default symbology. We're okay with 
that, so we'd like the yellow exclamation point icon to go away when a user 
changes to a custom style since the custom styles are visible at all scales. 
When a user reverts back to the original symbology, the yellow exclamation 
point icon should come back on if the map is zoomed outside of the layer's 
available scale range.

Original comment by emily.hu...@state.ma.us on 16 Dec 2011 at 9:53

[GoogleCodeExporter]

All set.  Once a user picks a custom style, all bets are off, and all scale 
tests return OK.  When a style is reverted, the standard scaling tests apply.

One side effect (positive? / negative?) is that the custom-style-scale-is-OK 
means that queries will now work on scales that would otherwise not be allowed.

v. 2.01
Committed revision 276.

Original comment by cpl...@gmail.com on 17 Dec 2011 at 3:01

[GoogleCodeExporter]

Verified. When I change an out-of-scale layer to a custom style, the yellow 
exclamation point goes away and I'm able to identify on it. When I revert back 
to the original symbology, the yellow exclamation point appears and I can no 
longer query it.

Original comment by emily.hu...@state.ma.us on 20 Dec 2011 at 8:14

• Changed state: Verified

[GoogleCodeExporter]

We may have found a bug with this. We now get a red exclamation point when we 
try to change the color of a line data layer (e.g., shoreline change transects) 
to red. All the other colors work for points, lines, and polys. Any idea what 
may be causing this?

Original comment by emily.hu...@state.ma.us on 20 Dec 2011 at 10:28

• Changed state: Fixed

[GoogleCodeExporter]

When I read your message, I had a suspicion of why this might be happening, but 
I can't reproduce the behavior you describe.  Could you give me a few 
repeatable steps?

Original comment by cpl...@gmail.com on 21 Dec 2011 at 3:46

[GoogleCodeExporter]

Add in any line datalayer, such as Massachusetts Municipal Boundary Lines.  Try 
to change the color of this layer to any color.  All colors except red will 
make the map redraw properly.  However, the red color will not draw on the map 
and it also pops up the red exclamation mark! 

Original comment by Aleda.Fr...@state.ma.us on 21 Dec 2011 at 3:19

[GoogleCodeExporter]

I realize you're fighting internet daemons [sic], but attached is a pretty 
looking, non-yellow warning red-lined layer.  You're saying you can't do the 
same on your end?

Original comment by cpl...@gmail.com on 21 Dec 2011 at 8:30

Attachments:

• seeingred.png

[GoogleCodeExporter]

No, attached is what we see. We get the red exclamation point and no legend, 
and the layer is still drawn with the previous style.

Original comment by emily.hu...@state.ma.us on 21 Dec 2011 at 8:41

Attachments:

• notseeingred.png

[GoogleCodeExporter]

What we see is on staging maps.  I could move the code over to prod. maps and 
then we could try it there as well. 

Original comment by Aleda.Fr...@state.ma.us on 21 Dec 2011 at 8:41

[GoogleCodeExporter]

Weird.  My end is running the latest here, and we've seen some strange things 
between staging vs. prod, so if you could try it there, too, it might be 
helpful.

Original comment by cpl...@gmail.com on 21 Dec 2011 at 8:53

[GoogleCodeExporter]

We can change lines to red on production maps, so this must be something weird 
on staging. I'm changing this back to verified since this only happens on 
staging maps.

Original comment by emily.hu...@state.ma.us on 22 Dec 2011 at 1:34

• Changed state: Verified