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