[geotk] code for parsing WMS Capabilities docs

sorel johann.sorel at geomatys.fr
Wed May 19 08:46:24 EDT 2010


Hi,
see below :

Jonathan Blower wrote:
> Hi Johann,
>
> Thanks very much for this information.  I've just started to play with
> your WMS Capabilities parsing code and it looks great so far - it's
> going to save me a lot of time, so thanks!  I have a few comments and
> questions from my experiments:
>
> 1) WmsServer.getCapabilities() throws no checked exceptions.  This means
> that there is no specified way to catch an error, such as a WMS server
> not responding.  I would have to catch an (unspecified) runtime
> exception to deal with this condition.  Can I suggest creating and
> throwing some appropriate checked exceptions such as
> ServerNotResponding, InvalidCapabilitiesDocument, WmsException (for the
> case where the server returns an XML exceptions document), or some
> better names that you can probably think of?
>   
Jira task created (like said cedric).

> 2) There seems to be no way to pass an UPDATESEQUENCE string to
> .getCapabilities().  This would be useful for me (but not urgent) to
> help with cache consistency.
>   
Could you explain ? how will this update sequence work ?
an int value would do the trick I think. something like
"if the capabilities is older than the time given then reload it otherwise
return the current one".

The WMS spec (and most server specs) specify that the
capabilities response is something stable and should be accessed
once and cached afterward by the client. I never seen some dynamic
capabilities which should be reloaded every minuts.

Remember you can also create the getCapabilities request and parse
the response stream as you need.

> 3) More importantly (for me) there is no AbstractLayer.getTitle() method
> (or .getAbstract()), so I can't get the displayable title of a layer.
> Is there a way I can get this information by delving into lower-level
> code?
>   
Cedric just fixed it a few minuts ago.

> 4) Lastly, I'm using Maven to manage dependencies and there seem to be
> an awful lot of dependencies for geotk-client-wms.  I guess this is
> because of the whole geotk dependency tree and is probably not easy to
> change, but I wonder if most of these dependencies (e.g.
> geotk-coverageio) are really needed for the "simple" job of parsing WMS
> Capabilities docs?
>   
That's true coverageio is not needed for the capabilities part.
I think most dependencies are coming because of the WMSMapLayer class
which need to know the engine, the coverage system and so on.
If you don't intend to use it, then you can safely exclude the unwanted
dependencies in your pom.xml.


> Anyway, thanks again for your code!
>
> Jon
>   

Johann Sorel



More information about the Geotoolkit mailing list