[GRASS5] Re: [GRASS] WMS -> CVS

[Cedric Shock]

Hi,

I committed the big collection of r.in.wms scripts to CVS. Three of them are 
visible publically: r.tileset, r.in.wms, and r.in.onearth.

Sören, can you look over description.html for r.in.onearth?

> > It would be nice if the wording on both r.in.wms and v.in.wfs for
> > servers, SRS  projections, etc. are in sync before releasing anything.
>
> Very well, but this is up to the authors of the scripts to understand
> and decide... if this doesn't happen very soon (ie now) the scripts will
> not be in by the feature freeze for 6.2.

I used the following options:
mapserver for the base uri of the server
srs for the projection
layer for the layer and
style for the style.
These are all the option types that I imagine might be in common between WMS 
and WFS (I've never looked at WFS).

>
> multiple related scripts should live in the same CVS source directory,
> the Makefile can copy the parts to somewhere that $GISBASE/etc/ can find.
> e.g. have a look at how the i.oif script creates and uses
> $GISBASE/etc/i.oif/ for sub-modules but goes in $GISBASE/scripts/ itself.
>
...
>
> > Separating the scripts clarifies and enforces separations in code. It
> > also allows more possible scripting by users in terms of downloads,
> > retrying downloads, etc. It would, however, be nice if wms.request,
> > wms.download, and r.in.gdalwarp could be slightly less exposed
> > (though no less documented).
>
> A worthy consideration, see r.univar.sh and i.oif examples for two
> levels of script integration below full-fledged "GRASS modules".

I did it the i.oif way (sort-of). It'll be easy to rip out any of these 
pseudo-modules into full fledged modules if they are ever desired since they 
already use g.parser.

>
> A test could be done for an XML parser iff the "-l" flag (or whatever)
> was used:
>
> r.in.wms -l ...
> if [ -x `which xml2` ] ; then
> ERROR: Listing of available maps requires the "xml2" XML parser.
>   http://http://dan.egnor.name/xml2
>
> As long as it is just optional functionalilty that will be lost it's not
> a huge deal. (& the debian package can just be set to depend on the xml2
> package :)
>
> > It would be pretty easy to merge this functionality from jachym's
> > latest scripts.
>
> Go for it!

Done and done.

--Cedric