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

[Hamish]

> 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.


> "Cedric's" version is a compilation of "jachym's" and r.in.onearth.

ok, then "Cedric's" is the most featureful one & what we should use.
?

> There are,  if I recall correctly, five scripts involved in the main
> event, and one for r.in.onearth. I did this to separate the code out
> into pieces. The scripts are something like:

could non-reusable parts be combined into the main script file as script
function calls? (e.g. cleanup() in r.univar.sh) Less file clutter that
way.


> r.tileset which generates tilings in a general way.
> 
> wms.request which generates requests to wms servers. This is heavily
> lifted  from r.in.onearth and "jachym's" version.
> 
> wms.download which downloads requests (a very simple wrapper around
> wget).
> 
> r.in.gdalwarp which imports and patches many files using gdalwarp to
> reproject data if necessary (pretty much lifted from r.in.onearth).
> 
> and r.in.wms which is a simple wrapper around the first four and what
> people would usually use.
> 
> Finally it has another r.in.onearth that Sören wrote that wraps up
> this r.in.wms. 

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.


> Most everything here (except for tiling) was lifted straight from
> jachym's and Sören's work, which made most of the programming quite
> easy.

A fine example of the collaborative nature of Open Source...

> One thing this set is missing (besides html documentation and
> makefiles) is some of the interaction with the server that "jachym's"
> does (listing layers). I was kind of hoping to parse and comprehend
> the entire capabilities request like I did with "raster plaster" but
> the difficulty and dependencies of parsing XML in shell scripts was
> too high.

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!

> 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".



thanks,
Hamish


ps - some XML->ASCII parsers I found when looking into v.in.gpsbabel:
  v.in.gpsbabel does the parsing by hand, fragile..


* "expat":
  http://expat.sourceforge.net/

* "xml2" might be better choice?:
Description: Convert between XML, HTML, CSV and a line-oriented format
 xml2 tools are used to convert XML, HTML and CSV to and from a
 line-oriented format more amenable to processing by classic Unix
 pipeline processing tools, like grep, sed, awk, cut, shell scripts,
 and so forth.
(download to gpx format with gpsbabel and then feed through xml2 to get csv?)
  http://dan.egnor.name/xml2/
  http://dan.egnor.name/xml2/ref

* Also "xmlto" software will do this... but xml2 is more popular.
  http://cyberelk.net/tim/xmlto/