[Geoserver-devel] Testing WMS cascading fixes

Jukka_Rahkonen · September 18, 2014, 9:32am

Hi,

I made some tests with two servers (http://demo.mapserver.org/cgi-bin/wms) and our own Mapserver v. 6.4.

I feel that Andrea managed to resolve at least most problems. There may be something left with schema validation though https + basic auth but I am not sure about that. There is also a trouble with cascading GetFeatureInfo: Geoserver is sendind the request by using INFO_FORMAT=application/vnd.ogc.gml and there is probably no way to change that. Mapservers usually (ever?) do not support that info_format and GetFeatureInfos fail. Most common info_formats are text/plain and text/html. I believe this is a missing feature and not a new bug in Geoserver.

Tests results:

An old Mapserver version 5.6.5 in (http://demo.mapserver.org/cgi-bin/wms). It seems to be easier to set up test servers than to update them to recent versions, demo.opengeo.org is running Geoserver 2.4 SNAPSHOT.
First SRS is EPSG:4326, supports also EPSG:3857 and a few other.
The server contains http://demo.mapserver.org/cgi-bin/wms?service=WMS&version=1.3.0&request=GetSchemaExtension

in WMS 1.3.0 GetCapabities.

Connection as WMS 1.3.0 PASSED
Connection as WMS 1.1.1 PASSED
Cascading WMS 1.3.0 as EPSG:4326 PASSED
Cascading WMS 1.3.0 as EPSG:3857 PASSED
Cascading WMS 1.1.1 as EPSG:4326 PASSED
Cascading WMS 1.1.1 as EPSG:3857 PASSED
Cascading WMS 1.1.1 as EPSG:3067 (not natively supported) PASSED, Geoserver sends requests as EPSG:4326 and re-projects into target SRS

Our own Mapserver 6.4.

Must be connected with https and basic auth
Supported projections for the test layer

EPSG:2393

EPSG:3067

EPSG:4326

EPSG:3857

Server contains https://xxx.fi/cgi-bin/xxx?service=WMS&version=1.3.0&request=GetSchemaExtension” in WMS 1.3.0 GetCapabilities

Connection as WMS 1.3.0 NOT PASSED

Error is “Connection test failed: Failed to resolve https://xxx.fi/cgi-bin/xxx?service=WMS&version=1.3.0&request=GetSchemaExtension”

This works with demo.mapserver.org and announced URL returns a document to browser. Could it be that schema resolving is not successful because of https + basic auth because that seems to be the only difference?

Connection as WMS 1.1.1 PASSED
Cascading WMS 1.1.1 as EPSG:4326 PASSED
Cascading WMS 1.1.1 as EPSG:3857 PASSED
Cascading WMS 1.1.1 as EPSG:2393 PASSED (SRS natively supported by remote WMS)
Cascading WMS 1.1.1 as EPSG:3067 PASSED (SRS natively supported by remote WMS)

Test with another layer which does not support natively EPSG:3857

Cascading WMS 1.1.1 as EPSG:3857 PASSED (not natively supported), Geoserver sends requests as EPSG:2393 which is the first on the list and re-projects into target SRS.

-Jukka Rahkonen-

···

Lähettäjä: Andrea Aime [mailto:andrea.aime@…1268…]
Lähetetty: 17. syyskuuta 2014 20:52
Vastaanottaja: Geoserver-devel
Aihe: [Geoserver-devel] Testing WMS cascading fixes

Hi,

I’m managed to squeeze in some time to look at the cascading issue (mostly by reducing

sleep hours, and a bit by keeping eclipse open in between customer meetings and

madly trying to get something done there), and believe I’ve committed a working solution

for this in geotools.

The next nightly build should have the fixes, can anybody try them out? I probably

won’t have any further time to look at this for the next… hum… 5-7 days.

Also, if anybody could kick the nightly build manually so that we have something

user testable today, that would be great.

Sorry it’s not much, but for this week it’s all I’ve managed to offer

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit

http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf

Technical Lead

GeoSolutions S.A.S.

Via Poggio alle Viti 1187

55054 Massarosa (LU)

Italy

phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 339 8844549

http://www.geo-solutions.it

http://twitter.com/geosolutions_it

Andrea_Aime4 · September 20, 2014, 10:14pm

On Thu, Sep 18, 2014 at 11:32 AM, Rahkonen Jukka (Tike) <
jukka.rahkonen@anonymised.com> wrote:

Hi,

I made some tests with two servers (http://demo.mapserver.org/cgi-bin/wms)
and our own Mapserver v. 6.4.

I feel that Andrea managed to resolve at least most problems. There may be
something left with schema validation though https + basic auth but I am
not sure about that. There is also a trouble with cascading GetFeatureInfo:
Geoserver is sendind the request by using
INFO_FORMAT=application/vnd.ogc.gml and there is probably no way to change
that. Mapservers usually (ever?) do not support that info_format and
GetFeatureInfos fail. Most common info_formats are text/plain and
text/html. I believe this is a missing feature and not a new bug in
Geoserver.

Correct, we need to get back a parseable data structure, since our feature
info "sources" generate a geotools featurecollection: there is no way
currently to just
cascade the other server featureinfo... and it's generally speaking not
fully trivial too.
What if I'm requested multiple layers, a bit local, a bit remote, in html
format, how am I going to build the result? The remote html could contain a
full
head section with css (like geoserver does) that we'd somehow have to merge
with ours.

Tests results:

- An old Mapserver version 5.6.5 in (http://demo.mapserver.org/cgi-bin/wms).
It seems to be easier to set up test servers than to update them to recent
versions, demo.opengeo.org is running Geoserver 2.4 SNAPSHOT.

- First SRS is EPSG:4326, supports also EPSG:3857 and a few other.

- The server contains
http://demo.mapserver.org/cgi-bin/wms?service=WMS&version=1.3.0&request=GetSchemaExtension

in WMS 1.3.0 GetCapabities.

- Connection as WMS 1.3.0 PASSED

- Connection as WMS 1.1.1 PASSED

- Cascading WMS 1.3.0 as EPSG:4326 PASSED

- Cascading WMS 1.3.0 as EPSG:3857 PASSED

- Cascading WMS 1.1.1 as EPSG:4326 PASSED

- Cascading WMS 1.1.1 as EPSG:3857 PASSED

- Cascading WMS 1.1.1 as EPSG:3067 (not natively supported) PASSED,
Geoserver sends requests as EPSG:4326 and re-projects into target SRS

Our own Mapserver 6.4.

- Must be connected with https and basic auth

- Supported projections for the test layer

EPSG:2393

EPSG:3067

EPSG:4326

EPSG:3857

Server contains
https://xxx.fi/cgi-bin/xxx?service=WMS&version=1.3.0&request=GetSchemaExtension”
in WMS 1.3.0 GetCapabilities

- Connection as WMS 1.3.0 NOT PASSED

Error is “Connection test failed: Failed to resolve
https://xxx.fi/cgi-bin/xxx?service=WMS&version=1.3.0&request=GetSchemaExtension
”

This works with demo.mapserver.org and announced URL returns a document
to browser. Could it be that schema resolving is not successful because of
https + basic auth because that seems to be the only difference?go out with
the

Could be... do you have a URL that I can hit, that allows reproducing the
issue?

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

Andrea_Aime4 · September 21, 2014, 6:41pm

On Sun, Sep 21, 2014 at 12:14 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

- Connection as WMS 1.3.0 NOT PASSED

Error is “Connection test failed: Failed to resolve
https://xxx.fi/cgi-bin/xxx?service=WMS&version=1.3.0&request=GetSchemaExtension
”

This works with demo.mapserver.org and announced URL returns a document
to browser. Could it be that schema resolving is not successful because of
https + basic auth because that seems to be the only difference?go out with
the

Could be... do you have a URL that I can hit, that allows reproducing the
issue?

Ok, found one that has this issue... the mapserver devs have been searching
for trouble there...
Here is a GetCapabilities:

http://openwms.statkart.no/skwms1/wms.topo2?service=WMS&version=1.3.0&request=GetCapabilities

It is customized in serveral ways, as you can see there is a stylesheet
(curious, not wrong, but made it
difficult to get the actual xml document, had to resort to command line)
and then there is a link to that GetSchemaExtension because they added a
new namespace (the ms one)
and a element attached to it:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="/xslt/WMSGetCapabilities.xsl"
?><WMS_Capabilities xmlns="http://www.opengis.net/wms" xmlns:sld="
http://www.opengis.net/sld" xmlns:xsi="http://www.w3.org/2001/XMLSchem
a-instance" xmlns:ms="http://mapserver.gis.umn.edu/mapserver"
version="1.3.0" xsi:schemaLocation="http://www.opengis.net/wms
http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd
http://www.opengis.
net/sld http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd
*http://mapserver.gis.umn.edu/mapserver
<http://mapserver.gis.umn.edu/mapserver>
http://dcriap006/cgi-bin/topo2?service=WMS&version=1.3.0&request=GetSchemaExtension
<http://dcriap006/cgi-bin/topo2?service=WMS&version=1.3.0&request=GetSchemaExtension>\*
">

...

*<ms:GetStyles>*
      <Format>text/xml</Format>
      <DCPType>
        <HTTP>
          <Get><OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://openwms.statkart.no/skwms1/wms.topo2?" /></Get>
          <Post><OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://openwms.statkart.no/skwms1/wms.topo2?" /></Post>
        </HTTP>
      </DCPType>
    </ms:GetStyles>

This little stunt makes the document impossible to parse for a parser that
is schema driven, because the url points to a local machine
instead of pointing back to original url where the caps was retrieved from,
and when we try to get the schema for the mapserver
extension, boom... I'm afraid there is not much we can do about it, besides
maybe a mapserver specific workaround (but I would like
to avoid starting littering the code base with server specific workarounds,
especially if the issue is on the other side).

If possible, this should be fixed in the mapfile, if not, I believe a bug
report to mapserver is in order