[geotk] code for parsing WMS Capabilities docs

[Cédric Briançon]

Hi Jonathan,

some answers about the point your highlightening.

2) Indeed you can't give an updatesequence for the moment to the current 
implementation of the WMS client. This is something known and to do, I 
will create a task for that particular case on the jira at 
http://jira.geotoolkit.org.

3) You're right there is no getTitle() or getAbstract() method in the 
WMS xml binding on AbstractLayer. But you have a getName() method that 
could probably returned something interesting about the layer. Another 
option for the current implementation is to cast your AbstractLayer in 
org.geotoolkit.wms.xml.v111.Layer or org.geotoolkit.wms.xml.v130.Layer 
if you know the version at this point. On those subclasses you have the 
methods getTitle() and getAbstract().
Anyway, the two methods you ask for should be present in the 
AbstractLayer class since all subclasses already implements these 
methods, and it really has a meaning on AbstractLayer to have those 
methods. I will add them in a couple of hours.

4) I will have a look to that point too.

Regards,
Cédric Briançon.


Le 19/05/2010 12:46, Jonathan Blower a écrit :
> 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?
>
> 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.
>
> 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?
>
> 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?
>
> Anyway, thanks again for your code!
>
> Jon
>
> -----Original Message-----
> From: johann sorel [mailto:johann.sorel at geomatys.fr]
> Sent: 18 May 2010 23:37
> To: Jonathan Blower
> Cc: geotoolkit at lists.osgeo.org
> Subject: Re: [geotk] code for parsing WMS Capabilities docs
>
> Hi,
>
> I guess we have something that looks like metadata database : MDWeb for
> exemple which purpose is to store metadatas or also the Coverage-SQL
> database. But even if they can store thoses informations I'm not sure
> that's what you are looking for.
>
> About time and elevation, the current rendering engine of geotoolkit
> pending can handle thoses, Multi-dimentional navigation is not a sweet
> dream, works for coverages, features and WMS (by sending the appropriate
>
> time and elevation parameters in the query).
> Here is a small demonstration on features :
> http://jsorel.developpez.com/temp/tempele.ogv
>
> Johann Sorel
>
> _______________________________________________
> Geotoolkit mailing list
> Geotoolkit at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geotoolkit
>
>
>