[geotk] code for parsing WMS Capabilities docs

Jon Blower j.d.blower at reading.ac.uk
Wed May 19 10:23:11 EDT 2010


Hi Johann (and Cedric),

Thanks for your responses.  I think it is necessary to be able to pass
UPDATESEQUENCE - clients should not cache Capabilities docs forever, as
the underlying data may change.  In our case, the WMSs represent ocean
forecast models, and the data changes many times a day.

I think UPDATESEQUENCE will have to be a string, since the spec says
that it can be a timestamp or an integer counter.

For exceptions I think we need:
1. IOException for server connection problems.  (InterruptedException is
not suitable as this is related to threads.)
2. Some exception that shows that the XML response can't be parsed.
java.text.ParseException may be OK, but requires an integer offset
showing which character caused the problem, which may be hard to find.
Following Bloch's guidelines of "throw Exceptions appropriate to the
abstraction" I suggest creating your own checked exception type
"CapabilitiesParseException" or similar that wraps whatever the
underlying exception is.
3. An exception that is thrown when the server returns a WMS Exception
(e.g. CurrentUpdateSequence). In this case the server will return an XML
document containing the exception, which Java code should translate into
a checked exception.

Thanks for all the rest of the information!  If I grab the next SNAPSHOT
release, will I get the code for reading a layer's title and abstract?
Or do I have to wait longer?

Thanks, Jon

-----Original Message-----
From: sorel [mailto:johann.sorel at geomatys.fr] 
Sent: 19 May 2010 13:46
To: Jonathan Blower
Cc: geotoolkit at lists.osgeo.org
Subject: Re: [geotk] code for parsing WMS Capabilities docs

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