Closed GoogleCodeExporter closed 8 years ago
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
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
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
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:
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
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
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
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
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
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
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
OK, attached is a screenshot of the code.
Original comment by Aleda.Fr...@state.ma.us
on 8 Dec 2011 at 7:37
Attachments:
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
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
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
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
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
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:
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
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
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
v. 1.04
Committed revision 267.
Original comment by cpl...@gmail.com
on 13 Dec 2011 at 7:00
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
v. 2.20
Committed revision 300.
Original comment by cpl...@gmail.com
on 23 Dec 2011 at 3:20
Original issue reported on code.google.com by
emily.hu...@state.ma.us
on 29 Jul 2011 at 2:57