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

[Cedric Shock]

Hi,

> > > what about r|v.in.wfs ? Would it be nice in GRASS too?
> >
> > I didn't know those modules existed or even that WFS existed...
>
> Stephan or Markus wrote it -- I just know, there is some version arround

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.

>
> > > What version of r.in.wms|onearth should go in GRASS cvs must deside
> > > someone else :-) I tryed to write it as simple, as possible - the user
> > > should deside/script, if he wants to use tiles. The user *knows* in
> > > which projection is he working etc.
> > >
> > > Current version should be SUBMITTING_SCRIPTS-ready. Avaliable at
> > > http://les-ejk.cz/programs/grass/r.in.wms.tgz
> >
> > Well I have only used r.in.onearth, and found it to be a great tool, but
> > I know you were all working on different versions and was hoping you
> > could tell me which was the one best suited for general use.
> >
> > Hamish
>
> I will not tell you, which one is the best, but I try to describe
> general properties of these tools and to compare them side by side:
>
> 1. r.in.onearth - it was the first version of this tools. it is able to
>                   download the maps *only* from one server. There should
>                   be some support of Cedric's tiles-workaround.
>
> 2. "jachym's" version of r.in.wms - is based on the version of
>         r.in.onearth. It can download layers from *any* server. I added
>         the flag -l for list of layers. If there is proper instalation
>         of python in your box, the output can be nicer.
>         In my script, I do not care about tiling and reprojecting - user
>         knows, what is is doing (but if you use Lat/Long projectino for
>         downloaded data, they will fitt your region corectly)
>
>
> 3. "Cedric's" version of r.in.wms - (I saw it only ones) there is
>         support of tiling. r.in.wms combines more scripts together,
>         which makes the whole proces IMHO too complicated. I do
>         remeber, there was some strange way, how the rasters were
>         imported and reprojected to GRASS (creating new teporary
>         locations?) - but it is possible, that things are made some other
>         way now.

"Cedric's" version is a compilation of "jachym's" and r.in.onearth. 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:

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. 

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.

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. It would be pretty easy to 
merge this functionality from jachym's latest scripts.

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

--Cedric