You need to log in before you can comment on or make changes to this bug.
Hi Paul, I have run into two issues. I'm afraid these are to do with CWC2 ver 1.0.6. Its the GoMOOS framework project, not the IOOS one. Their demo app is in 1.0.6 and is not likely to be updated to 1.99 anytime soon. So, here are my problems. Issue #1. In the Manage Servers dialog, if I add the MassGIS server (ArcIMS) it produces an error parsing the capabilities. Here's the URL if you want to test it: http://maps.massgis.state.ma.us:8080/mapaccess/main.jsp? The URL for the app so you can do this is: http://www2.dmsolutions.ca/msapps/chameleon-1.0.6/cwc2_gom.php?template=http://www2.dmsolutions.ca/msapps/gom_viewer/gom_viewer.html&context=http://www2.dmsolutions.ca/msapps/gom_viewer/context/gom_context.xml This might have to do with the version... I dunno. The MassGIS server seems to be using WMS 1.1.1. Issue #2 There is an ArcIMS server at USGS Woods Hole Field Center serving a bunch of data. If I add that server in the Manage Servers dialog it seems to find it and parse the capabilities properly. When you go to the Browse Data tab you can see all the layers, but if you add one, go back to the map and make it visible it results in a broken image. Why? Why? Why? If I add a layer from the same server to the context file it draws fine. The online resource for that one is: http://coastalmap.marine.usgs.gov:80/servlet/com.esri.wms.Esrimap?SERVICENAME=Gulf_of_Maine Let me know if you need any more info. I gotta demo this stuff in Halifax next week. Thanks. Dean
fixed a bug in server_data_manager.php (phpwms) ... the request for capabilities was all mixed up in version numbers (wmtver instead of version, request=capabilities instead of getcapabilities). This has fixed the issue with #1 listed below (with adding the server). This has raised another issue, which is that the layers added from this server don't seem to be drawn by mapserver. This is very interesting, watching the debug output of mapserver indicates that the layers added from this server are never even requested ... perhaps there is something else going on ... I will need some help with this ... For issue #2, the problem is with the remote server. In its capabilities document, it lists the following formats: <GetMap> <Format>image/jpeg</Format> <Format>image/gif</Format> <Format>image/png</Format> - <DCPType> - <HTTP> - <Get> <OnlineResource xlink:type="simple" xlink:href="http://coastalmap.marine.usgs.gov:80/servlet/com. esri.wms.Esrimap?"/> </Get> </HTTP> </DCPType> </GetMap> MapServer chooses a format from this list by scanning its own input drivers in order. GIF comes before the other drivers so it will request a GIF image in this case. This results in the following URL being sent to the remote server: http://coastalmap.marine.usgs.gov/servlet/com.esri.wms.Esrimap?SERVICE=WMS&VERSION=1.1.0&LAYERS=Canada&FORMAT=image%2Fgif&TRANSPARENT=TRUE&STYLES=&REQUEST=GetMap&WIDTH=400&HEIGHT=300&SRS=EPSG:4326&BBOX=-72.050000,39.860000,-62.920000,46.720000&EXCEPTIONS=application/vnd.ogc.se_inimage unfortunately, this returns the following error: <ServiceExceptionReport version="1.1.0"> <ServiceException> Exception in sending image. </ServiceException> </ServiceExceptionReport> Replacing the image type with png or jpeg results in the correct image being returned. I have modified chameleon to prefer png over gif but the real problem is with their server.
ok ... more on this ... the reason why the layer is never requested is because the latlonboundingbox in the layer metadata is listed as "0 0 0 0". This is obviously wrong. The capabilities document lists a boundingbox in the epsg:26986 projection ... so I think the error is in chameleon here, investigating further ...
if the server doesn't advertise a latlonboundingbox, then chameleon was adding one with 0 0 0 0 for coordinates, which is probably invalid and causes the layer to never be requested. I have fixed this so that no metadata for the latlonboundingbox will be added if they end up being 0 0 0 0. Difficult to test this right now because the server seems to be hosed ;)
ok ... I was eventually able to add the massgis server and it now attempts to draw the layer but times out ... this is now an issue with that server I think ... reassigning to Dean to follow up with that server. This bug should be closed if the server eventually starts behaving and returning layers.
Works with both servers now. MassGIS server is back up and it I was able to verify. The bug shouldn't be closed (IMHO) until the fixes are made on mapsherpa though. Can someone (Paul?) copy over the affected files, please?
I created an internal bug for the server upgrade.
Marking fixed. The technical issue is fixed.
