Add ability to add an external WMS

[GoogleCodeExporter]

Add ability to manually add an external WMS from a list of WMS servers provided 
by MassGIS and also ability to manually enter a WMS server URL.

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

[GoogleCodeExporter]

I'd like to revisit comment 8, regarding the ability to display WMS layers in 
900913 aliases. EPSG codes such as 3857 (official code), 102113, and 102100 
represent projections (web/spherical Mercator)that are equivalent to 900913. 
It's important that we not limit ourselves to 900913, as many, if not most, 
desirable services use an alias

Can we specify in the GetMap request for a particular layer that we want a 
pre-determined SRS returned? For instance, if we know that a NOAA chart service 
provides layers in 3857, can we force the request to 3857 without reading 
GetCaps? If we need to read GetCaps for all GetMap request parameters, can we 
look for one or more of the aliases? We're working with pre-determined 
services, so we'll know the desired SRS of each service.

Original comment by marc.car...@state.ma.us on 5 Dec 2011 at 9:46

[GoogleCodeExporter]

Re. comment 50.  A red exclamation indicates a drawing error, not a projection 
error.  Could you give me some repeatable instructions to reproduce it?

I'm not sure about comment 51.  You can't get around doing a getcaps.  The WMS 
requests always contains the same SRS projection parameter that matches the 
base layer.  So if you are in google, all WMS requests will be 900913 instead 
of 3857 -- unless I launched google w/ the 3857 projection code.  So, again, I 
need to think about this.

For several of the things we're doing I recall echoes of the next geoserver 
release supporting x, y, and z.  Is your geoserver going to consider proxying 
these external services?  If so, it seems that we may be jumping through many 
hoops unnecessarily.

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

[GoogleCodeExporter]

Well... I remembered that our production servers cannot access the Internet.  
So cascading WMS would require setting up a rule on the Gateway (which is in 
front of our GeoServers) to proxy outgoing requests to certain servers.  This 
is probably technically possible, but considering certain circumstances here of 
resources would take some months to see reality and I can't guarantee will ever 
happen. 

Original comment by Aleda.Fr...@state.ma.us on 6 Dec 2011 at 6:22

[GoogleCodeExporter]

We've discussed the location of the WMS tool and would like to revert it back 
to a button, preferably on the top toolbar (to the left of permalink, separated 
by a divider).  This is especially important since the dedicated WMS toolbar on 
the right will not be configurable.  With that, please make the new button 
configurable to show/hide.  A 24x24 icon is attached. Please don't label this 
button; the tool tip was included in the text edits document sent yesterday.

Original comment by marc.car...@state.ma.us on 6 Dec 2011 at 9:19

Attachments:

• external_data_sources.png

[GoogleCodeExporter]

It is now a button again.  But I'll leave it to someone else to do the magic to 
make it show/hide configurable.  I don't know how that works.

v. 1.01
Committed revision 261.

Original comment by cpl...@gmail.com on 7 Dec 2011 at 4:44

[GoogleCodeExporter]

This is a big deal, because I think I've given you the ability to define the 
crosswalks as your requested.  Aleda, the externalGetCaps has been 
restructured.  Here is an example:

// Do not include a trailing ? on any url below.
// The index is the value you see in the OnlineResource's href.
// 'proj' is optional and defined any custom projection crosswalks.
var externalGetCaps = {
  'http://services.coastmap.com/ecop/wms.aspx' : {
     name    : 'ASA ECOP'
    ,getcaps : 'http://services.asascience.com/ecop/wms.aspx'
    ,proj    : {'EPSG:900913' : 'EPSG:3857'}
  }
};

That ASA service is a good example.  It happens to advertise support of 900913, 
but it doesn't work.  So that declaration says that for any basemap of 900913, 
request it as a 3857.  If MORIS happened to also support 4326, for example, it 
would pass through like normal.  So the 'proj' should only be used to enumerate 
crosswalking.  If you wanted MORIS to function normally (and pass 900913 and 
26986 like you're used to), you'd leave it blank.  So if the ASA server 
happened to support 26986 and we didn't need to do any crosswalk, I would NOT 
have to list it.  900913 did need it -- that's why it's there.

Aleda, you'll notice that there are 2 URL's as part of a single getcaps entry.  
In the ASA example, they happen to be identical, but that might not always be 
the case.  When you are adding entries, please run a getcaps on your own to 
check out the onlineresource's href value.  That is what belongs on the 
top-level.  The example you gave me for "Yard Sale Permits" URL's differ -- in 
that case the online href actually had a :80 in it.

I think I also fixed errors where the red ! was showing up.

v. 1.02
Committed revision 263.

Original comment by cpl...@gmail.com on 7 Dec 2011 at 7:10

[GoogleCodeExporter]

Charlton, I'm trying this:

      var externalGetCaps = {
        'http://services.coastmap.com/ecop/wms.aspx' : {
         name    : 'ASA ECOP'
         ,getcaps : 'http://services.asascience.com/ecop/wms.aspx'
         ,proj    : {'EPSG:900913' : 'EPSG:3857'}
       },
        'http://egisws02.nos.noaa.gov/ArcGIS/services/MPA/MPA_Inventory/MapServer/WMSServer?request=GetCapabilities&service=WMS' : {
         name    : 'NOAA : Marine Protected Areas'
         ,getcaps : 'http://egisws02.nos.noaa.gov/ArcGIS/services/MPA/MPA_Inventory/MapServer/WMSServer?request=GetCapabilities&service=WMS'
         ,proj    : {'EPSG:900913' : 'EPSG:3857'}
       }
      };

But I don't get a parse of the GetCaps URL MORIS (the URL works).  We are 
trying to request this WMS in 3857.

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

[GoogleCodeExporter]

I think these are the correct href and GetCaps URLs, based on comment 56 and 
the MPA GetCaps return.

var externalGetCaps = {
        'http://services.coastmap.com/ecop/wms.aspx' : {
         name    : 'ASA ECOP'
         ,getcaps : 'http://services.asascience.com/ecop/wms.aspx'
         ,proj    : {'EPSG:900913' : 'EPSG:3857'}
       },
        'http://egisws02.nos.noaa.gov/ArcGIS/services/MPA/MPA_Inventory/MapServer/WMSServer' : {
         name    : 'NOAA : Marine Protected Areas'
         ,getcaps : 'http://egisws02.nos.noaa.gov/ArcGIS/services/MPA/MPA_Inventory/MapServer/WMSServer'
         ,proj    : {'EPSG:900913' : 'EPSG:3857'}
       }
      };

Original comment by marc.car...@state.ma.us on 8 Dec 2011 at 7:25

[GoogleCodeExporter]

What I get in MORIS is "Loading" and then nothing.  No error messages.  I did 
add it to the proxy (otherwise I'd see that error message).  Does this 
externally available service work for you in MORIS? 

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

[GoogleCodeExporter]

No, it doesn't work.  It can't parse the XML.  Could it be that there are 
redundant strings in the GetCaps URL (see below).  What would happen if you 
lopped off "?request=GetCapabilities&service=WMS" from the two URLs in your 
example (see comment 58)?

http://egisws02.nos.noaa.gov/ArcGIS/services/MPA/MPA_Inventory/MapServer/WMSServ
er?request=GetCapabilities&service=WMS?request=GetCapabilities&service=WMS&versi
on=1.1.1

Original comment by marc.car...@state.ma.us on 8 Dec 2011 at 7:32

[GoogleCodeExporter]

It's linking my stuff.  I'll try putting quotes around it.  I don't see 
anything extra... 

"      var externalGetCaps = {
        'http://services.coastmap.com/ecop/wms.aspx' : {
         name    : 'ASA ECOP'
         ,getcaps : 'http://services.asascience.com/ecop/wms.aspx'
         ,proj    : {'EPSG:900913' : 'EPSG:3857'}
       },
        'http://egisws02.nos.noaa.gov/ArcGIS/services/MPA/MPA_Inventory/MapServer/WMSServer?request=GetCapabilities&service=WMS' : {
         name    : 'NOAA : Marine Protected Areas'
         ,getcaps : 'http://egisws02.nos.noaa.gov/ArcGIS/services/MPA/MPA_Inventory/MapServer/WMSServer?request=GetCapabilities&service=WMS'
         ,proj    : {'EPSG:900913' : 'EPSG:3857'}
       }
      };
"

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

[GoogleCodeExporter]

OK, attached is a screenshot of the code.

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

Attachments:

• externalwms.PNG

[GoogleCodeExporter]

Don't include any params at all in any of the links.  So no 
'?request=GetCapabilities&service=WMS'.

I haven't tried it, but this should get you going:

        'http://egisws02.nos.noaa.gov/ArcGIS/services/MPA/MPA_Inventory/MapServer/WMSServer' : {
         name    : 'NOAA : Marine Protected Areas'
         ,getcaps : 'http://egisws02.nos.noaa.gov/ArcGIS/services/MPA/MPA_Inventory/MapServer/WMSServer'
         ,proj    : {'EPSG:900913' : 'EPSG:3857'}
       }

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

[GoogleCodeExporter]

Thanks, Charlton.  I was hoping that was the sole difference.

Original comment by marc.car...@state.ma.us on 8 Dec 2011 at 8:06

[GoogleCodeExporter]

Usually I play it cool and keep from showing my cards, but in this case . . . 
I'm dying to know if the external wms is working out or not.  You report, I 
decide?

Original comment by cpl...@gmail.com on 9 Dec 2011 at 6:38

[GoogleCodeExporter]

Usually I play it cool and keep from showing my cards, but in this case . . . 
I'm dying to know if the external wms is working out or not.  You report, I 
decide?

Original comment by cpl...@gmail.com on 9 Dec 2011 at 6:38

[GoogleCodeExporter]

I made the change and now I can add a datalayer.  I see the legend, but it has 
a red exclamation point.  I don't understand why you haven't tried it.  It's 
available to you.  Are we assuming it does work for you but doesn't for us?  Or 
that we've never yet seen it working anywhere?

Original comment by Aleda.Fr...@state.ma.us on 12 Dec 2011 at 2:31

[GoogleCodeExporter]

It works fine here.  I assume that it's only supposed to overlay on google but 
force a 3857 request?  That is what firebug is showing me.

Original comment by cpl...@gmail.com on 12 Dec 2011 at 2:54

Attachments:

• Untitled.png

[GoogleCodeExporter]

Works for me too.  Strangely, it work in Custom and 900913 basemaps, therefore 
I don't get a red exclamation.  I get legend symbology, but no legend title, 
with 900913 basemaps.  On the other hand, I get legend title, but no legend 
symbology, with a Custom basemp.

Aleda, thanks for making the changes this morning.  Would you mind adding the 
NOAA Charts (RNC) service in 3857 for additional testing when you get a chance? 
 The GetCaps URL is 
http://egisws02.nos.noaa.gov/ArcGIS/services/RNC/NOAA_RNC/MapServer/WMSServer?re
quest=GetCapabilities&service=WMS.  Thanks!

Original comment by marc.car...@gmail.com on 12 Dec 2011 at 3:39

[GoogleCodeExporter]

Thanks for adding NOAA Charts, Aleda.  Big thanks to Charlton for working up 
this crosswalk!  The charts layer works great in both 26986 and 900913 
basemaps, which is a nice, but unexpected, surprise.  Is GeoServer reprojecting 
WMS layers between 26986 and 900913?  Charts aren't being served in 26986.  
Note that this isn't the way WMS layers were working in our previous tests.  
I'm certainly not complaining!

Unfortunately, it seems that NoData = 255 in the charts layers, as the white 
areas are transparent.  I didn't realize that when testing this service, as I 
tested in on a white background.  Nevertheless, it's a great layer.  As for 
legend symbology, it seems that lots of service providers are incorrectly 
configuring their WMS legends.  They're serving them with a 32 pixel width, but 
clearly that's not enough for anything other than a non-labeled, simple shape.  
Oh well.  Nice work all around.

Aleda, we'll get you an updated list of services that we'd love to have made 
available in the near future.

Original comment by marc.car...@gmail.com on 12 Dec 2011 at 4:10

[GoogleCodeExporter]

Everyone,

I regret to inform you that at present the external WMS is not going to work on 
the maps server.
We had unfortunately not gotten around to testing it there.  This is my fault.  
Staging maps and maps are very different animals, until we see it working on 
maps it's not *real*.
The maps server is simply not allowed to reach out to the internet.
The same origin policy of browsers requires us to use the proxy script to ask 
the maps server to pull the GetCapabilities document.
This is not possible.
Saul says that there is a *possibility* of having a type of "crossdomain" file 
on the server to relax the same origin policy for newer browsers.
I propose to include this R&D in a task order with some other MORISOLIVER 
enhancements for PeopleGIS this spring.  
I will create another Issue for this. 
Charlton, for now can you make the external WMS tool disappear?  I guess I 
should take out my external references in the .php as well. 

Original comment by Aleda.Fr...@state.ma.us on 13 Dec 2011 at 5:40

[GoogleCodeExporter]

v. 1.04
Committed revision 267.

Original comment by cpl...@gmail.com on 13 Dec 2011 at 7:00

[GoogleCodeExporter]

How about this for the interim?

Instead of sending the user directly to the getcaps, you wget them and store 
them locally.  This makes sense to me since you are cherry picking these links, 
anyway.

Before:
'http://egisws02.nos.noaa.gov/ArcGIS/services/MPA/MPA_Inventory/MapServer/WMSSer
ver' : {
   name    : 'NOAA : Marine Protected Areas'
  ,getcaps : 'http://egisws02.nos.noaa.gov/ArcGIS/services/MPA/MPA_Inventory/MapServer/WMSServer'
  ,proj    : {'EPSG:900913' : 'EPSG:3857'}
}

After:
'http://egisws02.nos.noaa.gov/ArcGIS/services/MPA/MPA_Inventory/MapServer/WMSSer
ver' : {
   name    : 'NOAA : Marine Protected Areas'
  ,getcaps : 'noaa.mpa.getcaps.xml'
  ,proj    : {'EPSG:900913' : 'EPSG:3857'}
}

And on the system you had done a:
wget 
'http://egisws02.nos.noaa.gov/ArcGIS/services/MPA/MPA_Inventory/MapServer/WMSSer
ver%&request=getcapabilities&service=wms&version=1.1.1' -O noaa.mpa.getcaps.xml

Stick that noaa.mpa.getcaps.xml in the same dir as your .php's for ease.

Then simply uncomment my last change to map.js, and you should be good to go.

The only downside to this is that you will miss out on any changes that may 
happen at the provider's end if you only refresh your getcaps once in a blue 
moon.

Original comment by cpl...@gmail.com on 13 Dec 2011 at 7:44

[GoogleCodeExporter]

My end will add the ?service=wms&request=getcapabilities&version=1.1.1 to the 
local getcaps request -- hopefully that won't offend your param filter nazi.

Original comment by cpl...@gmail.com on 13 Dec 2011 at 7:46

[GoogleCodeExporter]

My end will still try using the proxy even if it is to access your local .xml 
(since it is setup assuming remove services).  If that fails, let me know, and 
I'll remove the proxy from the equation.

Original comment by cpl...@gmail.com on 13 Dec 2011 at 7:48

[GoogleCodeExporter]

This is indeed unfortunate. Charlton, thanks for brainstorming workarounds. 
Aleda, external URLs are accessed from MORIS running on maps (e.g., Bing 
basemap links to Wikipedia entries). Is the difference here that external WMS 
services would require two-way communication?  Charlton, does your workaround 
avoid a GetMap request to be returned by the WMS provider?  I like where you're 
going, but I'm not sure I understand how we can avoid this by storing GetCaps 
xmls on our external map server.   

Original comment by marc.car...@gmail.com on 13 Dec 2011 at 8:43

[GoogleCodeExporter]

Storing the getcaps locally on maps sounds like a great idea.  I'll give it a 
try.

Marc, the browser client can make requests anywhere, the server can't (except 
to itself is OK).  It's hard to describe this without a diagram 
unfortunately... What Charlton suggested should work.

Original comment by Aleda.Fr...@state.ma.us on 13 Dec 2011 at 9:33

[GoogleCodeExporter]

You may need to put the full URL to each local getcaps. If that still doesn't 
work, I'll take the proxy out. 

Original comment by cpl...@gmail.com on 13 Dec 2011 at 9:42

[GoogleCodeExporter]

Actually, give me half a sec to come up w/ something a little more classy.

Original comment by cpl...@gmail.com on 13 Dec 2011 at 10:02

[GoogleCodeExporter]

Aleda, you need to revisit the way externalGetCaps is defined.  If you need a 
proxy, you simply make it part of the getcaps AND you put all the normal 
request/service/version params.  Here is a working example (after I corrected 
the wget above!):

// The index is the value you see in the OnlineResource's href.
// 'proj' is optional and defined any custom projection crosswalks.
var externalGetCaps = {
  'http://services.coastmap.com/ecop/wms.aspx' : {
     name    : 'ASA ECOP'
    ,getcaps : proxyLocBing + escape('http://services.asascience.com/ecop/wms.aspx?request=GetCapabilities&service=WMS&version=1.1.1')
    ,proj    : {'EPSG:900913' : 'EPSG:3857'}
  }
  ,'http://egisws02.nos.noaa.gov/ArcGIS/services/MPA/MPA_Inventory/MapServer/WMSServer' : {
    name    : 'NOAA : Marine Protected Areas'
   ,getcaps : 'noaa.mpa.getcaps.xml'
   ,proj    : {'EPSG:900913' : 'EPSG:3857'}
  }
};

*** That *MUST* go after proxyLocBig is defined!!! ***

v. 1.05
Committed revision 268.

Original comment by cpl...@gmail.com on 13 Dec 2011 at 10:12

[GoogleCodeExporter]

Charlton, I don't understand this at all.  I thought I was going to put the 
GetCaps results on maps.  That's the only way this is going to work.  Help.

Original comment by Aleda.Fr...@state.ma.us on 14 Dec 2011 at 4:01

[GoogleCodeExporter]

Local GetCapabilities XML document works great!  Whew!  Loading the 
GetCapabilities XML document is faster, and as Charlton noted we have control 
over which layers we offer (we can edit the xml file to drop some if we wish).  
However, if new layers are added from their service we'll have to get another 
copy of the GetCapabilities XML document. 

Original comment by Aleda.Fr...@state.ma.us on 14 Dec 2011 at 5:06

[GoogleCodeExporter]

That's great!  It might be worth scheduling periodic updates of GetCaps XMLs on 
maps.

Original comment by marc.car...@state.ma.us on 14 Dec 2011 at 5:14

[GoogleCodeExporter]

Hmm.  I haven't gotten any NYT text alerts announcing the release.

Original comment by cpl...@gmail.com on 14 Dec 2011 at 6:00

[GoogleCodeExporter]

We unfortunately just found a WMS legend bug. The legend doesn't reorder 
correctly when I move WMS layers around. For example, I added the MPA inventory 
layer. I moved it down one in the list of the active data layers, but the 
legend shows it at the bottom of the list (see legend1 screenshot). Once this 
happens and I start moving non-WMS layers around, the order of all the layers 
in the legend is wrong (see legend2 screenshot). This is similar to Issue 89, 
but in this case, the layers are drawn in the correct order.

Also, I don't know if this is a bug with MORIS or with the MPA WMS service, but 
once I zoom in, I lose the layer title for the MPA inventory layer in the 
legend (see attached screenshots of the MPA legend before and after I zoom).

Original comment by emily.hu...@state.ma.us on 15 Dec 2011 at 7:47

Attachments:

• legend1.png
• legend2.png
• mpa_legend_before_zoom.png
• mpa_legend_after_zoom.png

[GoogleCodeExporter]

I'm pretty sure this has to do w/ the modification I made to the GeoExt code to 
get around the bug it was having w/ layers named '0'.  The section I commented 
out had to do w/ refreshing the title, and that seems to be exactly what you're 
running into.  Unfortunately, my code doesn't control the order of the layers 
that appear in the legend.  That's GeoExt.

Even though the legend gets confused, is the map still rendering the order 
properly?

I can tell you my real feelings about GeoExt offline.  Suffice it to say, I've 
moved away from it for newer applications.

Original comment by cpl...@gmail.com on 15 Dec 2011 at 7:56

[GoogleCodeExporter]

Actually, if you leave external WMS-es out of the equation and try reordering 
the default moris.php layers, the legend gets confused.  Let me try undoing my 
geoext modification locally and see what happens.  If it fixes the normal order 
of the legend, then I think we need to reconsider using arc services who might 
have layers named '0'.

Original comment by cpl...@gmail.com on 15 Dec 2011 at 8:16

[GoogleCodeExporter]

Unfortunately I think all ArcGIS Servers name the first layer of each 
mapservice that way and I'm not sure that's configurable by the admin.  

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

[GoogleCodeExporter]

Bad news, bears, it looks like the legend order has been broken for a long 
time.  I'm not sure when it broke, exactly, but I rolled back to earlier 
releases (long before the GeoExt mod), and it doesn't order properly.

I think we have 2 beasts:  the ordering of the layers and the external WMS 
title going AWOL.

The external title is definitely the GeoExt modification I made to get around a 
bug.  We'll either need to live w/ it as-is or simply not have you access 
ArcGIS services.

The layer ordering . . . I have no idea what the problem is or where it crept 
up.  Sounds like a new issue to me.

Original comment by cpl...@gmail.com on 15 Dec 2011 at 8:39

[GoogleCodeExporter]

I think I've taken care of the legend panel layer order.  The problem was that 
GeoExt wanted control of the layer order when you drag layers around, but our 
end needs control to make sure that things like the query box/poly and raster 
query point were always drawn on top.

Anyhoo, I think we're OK now.

Re. the externalWMS legend handling . . . this probably won't fix that.  Would 
you mind re-testing that out on your public site and letting me know how that 
cookie crumbles?

v. 1.06
Committed revision 274.

Original comment by cpl...@gmail.com on 16 Dec 2011 at 12:35

[GoogleCodeExporter]

Printing a WMS layer doesn't work externally. When I try to print a map with a 
WMS layer, the assembling map spins and spins and then finally dies without 
giving me the map and legend images. As Aleda has mentioned, the external maps 
server can't access the internet, and it looks like print.php is making the 
request. Could the print be fixed to include WMS layers? If not, would there be 
a way to drop WMS layers from print so that a user can still get the map and 
legend images? If we do this, then we could add a note to the print window that 
lets users know that external data layers will not be shown on the printed map 
image.

The legend is working a lot better, but we unfortunately found a way to break 
it. Try this:

1) Add MPA Inventory (OK)
2) Move it down one level (OK in drawing order and legend)
3) Add MWRA Towns with Water and Sewer (OK in drawing order and legend)
4) Try moving MPA Inventory to the top (OK in drawing order, but the legend 
image goes to the bottom)

Marc discovered that if you try moving MPA inventory down in the list in step 
4, it works. It's only when I move it up in the list that it doesn't work. 
Please note that this has nothing to do with external WMS. It also occurs when 
testing with MassGIS layers.

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

[GoogleCodeExporter]

Awwwwwwwwwwwwwwwwwwww bugger!  I'm running out of creative ways to get around 
this booger, but I hope this does the trick.

v. 2.00
Committed revision 275.

Original comment by cpl...@gmail.com on 17 Dec 2011 at 2:34

[GoogleCodeExporter]

Comment 92 was related to the legend.

You're right about printing.  The layer has to be fetched and assembled from 
the print.php host.  So shoot me the text you'd like in the print popup, 
please.  Otherwise, I know I'll get it wrong.

Original comment by cpl...@gmail.com on 17 Dec 2011 at 2:34

[GoogleCodeExporter]

Good news! The legend looks fixed.

We'll send you the text for the print popup later today or tomorrow.

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

[GoogleCodeExporter]

Here's the language for the print/save popup message (please bold "Please 
note:"):

Enter a title and click OK to print or save images of your map and legend.

Please note: Basemaps and external data layers will not be shown on the map 
image. If you would like to print or save a map with the basemap or external 
data layers, use the print option in your browser or capture a screenshot of 
the map.

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

[GoogleCodeExporter]

Here's a mockup of the WMS popup we'd like to see in place of the drop-down 
menu approach. The intro text should read as follows:

"Select an external data source to view its available data layers. These can be 
added to your map for display only. You will not be able to use the identify, 
export, or print tools with data layers from external sources, nor will you be 
able to view their metadata."

Please allow the following:
1. Selection of multiple layers with Ctrl and Shift keys (as with Identify 
results > feature details).
2. Double-clicking of single layers to add to the map; multiple layers by the 
"Add selected" or "Add all" button.

Thanks!

Original comment by marc.car...@gmail.com on 22 Dec 2011 at 4:07

Attachments:

• wms_popup.png

[GoogleCodeExporter]

I just wanted to add another item to the "Please allow the following" list in 
#96.

3. Right-click menu option to "Add layer(s)". Please enable addition of 
multiple layers with this menu option when more than one layer is selected.

Original comment by marc.car...@gmail.com on 22 Dec 2011 at 7:11

[GoogleCodeExporter]

I'm rushing out the door, but I wanted to get this change out to you for 
testing.

v. 2.14
Committed revision 292.

Original comment by cpl...@gmail.com on 22 Dec 2011 at 9:09

[GoogleCodeExporter]

This is just a friendly reminder that we would like WMS layers excluded from 
print. Here's the language for the print/save popup message (please bold 
"Please note:"):

Enter a title and click OK to print or save images of your map and legend.

Please note: Basemaps and external data layers will not be shown on the map 
image. If you would like to print or save a map with the basemap or external 
data layers, use the print option in your browser or capture a screenshot of 
the map.

Original comment by emily.hu...@state.ma.us on 23 Dec 2011 at 2:56

[GoogleCodeExporter]

v. 2.20
Committed revision 300.

Original comment by cpl...@gmail.com on 23 Dec 2011 at 3:20