Add WMSCapabilities format

wms capabilities parsing

I'd prefer to have the versioned copies in a subdirectory: Format/WMSCapabiities/1.1.1.js . Other than that, this looks fine.

I'm not too sure with the inheritance logic of this patch. I don't see why WMSCapabilities_1_1_1 needs to inherit from WMSCapabilities. I'd rather see WMSCapabilities_1_1_1 inherit from XMS and WMSCapabilities.just composes WMSCapabilities_1_1_1. I might be wrong...

Yeah, I should pull this patch. The idea was that eventually we could support all versions. I thought it would make sense to have common code on the WMSCapabilities class. Then versions could first inherit from WMSCapabilities, then from a major version, then from a minor version, etc. It's not complete as is.

I'll be submitting a WMC patch soon that does a better job at this.

Mass ticket move out of 2.7 in preparation for a release plan.

If you are actively working on this task, and think that you can help this ticket to get finished and closed by September 1, please move it back to 2.7.

wms capabilities parsing

This patch extends the work of tschaub.

UPDATE:

• the class is built like the OpenLayers.Format.WMC class
• inheritance improvement
• some new nodes are supported

TODO:

• do not follow node order (inheritance problem)
• WMS 1.3.0 support
• How to support the WMF GetCapabilities whithout code duplication ? WFSCapabilities is close to WFSCapabilities

EXAMPLE:

this.request = OpenLayers.Request.GET({
    url: "http://world.freemap.in/cgi-bin/mapserv?map=/www/freemap.in/world/map/factbook.map&request=GetCapabilities&version=1.1.1&service=WMS",
    success: function(response) {
        var XMLformat = new OpenLayers.Format.XML();
        xml = XMLformat.read(response.responseText);
        
        var CAPformat = new OpenLayers.Format.WMSCapabilities();
        capabilities = CAPformat.read(xml);
        
        window.console.log(capabilities);
    }
});

I add a patch with support of:

• WMS Capabilities v1.1.1
• WMS Capabilities v1.3.0
• WFS Capabilities v1.0.0
• WFS Capabilities v1.1.0

To try, you can use:

• http://schemas.opengis.net/wfs/1.1.0/examples/WFS_Capabilities_Sample.xml
• http://schemas.opengis.net/wms/1.1.1/capabilities_1_1_1.xml
• http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xml

Output data schemes are described in documentation of OpenLayers.Format.WMSCapabilities and OpenLayers.Format.WFSCapabilities classes.

Not touched since 2.7, bumping.

(In [9125]) parsing queryable attribute from capabilities (diff from r8992). (see #1176)

wms capabilities

wms capabilities parsing

Here's what I think about this: this format could be enhanced. I'd like to rewrite it to the new style. It could use more options. It could maintain a representation of the layer hierarchy in the capabilities doc by having a "parents" property (array) or other. It could parse srs (and have an option not to).

All of those things can come later. Until then, I think this makes a good addition.

Tests pass in FF3. Will report on IE later. Thanks for any review.

Tests pass in IE6 as well (though the browser nearly kicks the bucket while parsing that doc). Will happily commit with review. (Only assigning to ahocevar in hopes of a review. If anybody else can review, please do.)

Hi Tim,

The naming convention you use seems a bit odd to me (compared to other OL Classes): read_cap_Capability, read_cap_Request, etc. Wouldn't it be more intuitive to have something like below?

readers: {
  Capability: function () ..,
  Request: function ()...
}

And then you'd use something like this:

processor = this.readers[childNode.nodeName]; 

'readers' is probably not the correct term (I stole it from GML), but you get my point.

Replying to rdewit:

Hi Tim, The naming convention you use seems a bit odd to me (compared to other OL Classes): read_cap_Capability, read_cap_Request, etc. Wouldn't it be more intuitive to have something like below? {{{ readers: { Capability: function () .., Request: function ()... } }}} And then you'd use something like this: {{{ processor = this.readers[childNode.nodeName]; }}} 'readers' is probably not the correct term (I stole it from GML), but you get my point.

Yeah, this is what I meant by wanting to rewrite this in the "new style." I originally wrote things this way for the WMC format. And continued this style for a couple other formats. Then decided that having readers and writers objects with properties for each namespace made for more reusable code. So, yes, the new GML formats, the Filter formats, and the SLD format all have the style that I'd like to continue using for XML based formats. This is particularly useful for formats that might be extended/mixed. Less important for something like the WMS capabilities format - but the format could share some of the base XML methods if it were rewritten.

Anyway, that's the part that can come later. These aren't API methods.

Looks good! Please commit.

(In [9212]) Adding a format for parsing WMS capabilities docs. r=ahocevar (closes #1176)

All,

Just a minor bug I found while working with the min/max scales for the WMSCapabilities. It looks like they are being reversed within the function read_cap_ScaleHint.

Should be able to just swap line 182 and 185.

layer.maxScale = parseFloat(
     ((rad2 * min) * ipm * OpenLayers.DOTS_PER_INCH).toPrecision(13)
);
layer.minScale = parseFloat(
     ((rad2 * max) * ipm * OpenLayers.DOTS_PER_INCH).toPrecision(13)
);

The min is just being applied to the max. Simple fix below:

layer.maxScale = parseFloat(
     ((rad2 * min) * ipm * OpenLayers.DOTS_PER_INCH).toPrecision(13)
);
layer.minScale = parseFloat(
     ((rad2 * max) * ipm * OpenLayers.DOTS_PER_INCH).toPrecision(13)
);

Thanks,

Dave O

And by simple fix, I mean:

layer.maxScale = parseFloat(
     ((rad2 * max) * ipm * OpenLayers.DOTS_PER_INCH).toPrecision(13)
);
layer.minScale = parseFloat(
     ((rad2 * min) * ipm * OpenLayers.DOTS_PER_INCH).toPrecision(13)
);

Replying to overstdr:

All, Just a minor bug I found while working with the min/max scales for the WMSCapabilities. It looks like they are being reversed within the function read_cap_ScaleHint. Should be able to just swap line 182 and 185. {{{ layer.maxScale = parseFloat( ((rad2 * min) * ipm * OpenLayers.DOTS_PER_INCH).toPrecision(13) ); layer.minScale = parseFloat( ((rad2 * max) * ipm * OpenLayers.DOTS_PER_INCH).toPrecision(13) ); }}} The min is just being applied to the max. Simple fix below: {{{ layer.maxScale = parseFloat( ((rad2 * min) * ipm * OpenLayers.DOTS_PER_INCH).toPrecision(13) ); layer.minScale = parseFloat( ((rad2 * max) * ipm * OpenLayers.DOTS_PER_INCH).toPrecision(13) ); }}} Thanks, Dave O

Nope, that is the way it should be. OGC minScaleDenominator should map to OL maxScale. In OGC maxScaleDenominator is > minScaleDenominator, but in OL minScale is > maxScale (see e.g. http://trac.openlayers.org/wiki/SettingZoomLevels)

Ahh...good call! Ignore my previous comments. I thought they were supposed to match the OGC denominators. Thank you for pointing this out bartvde.