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

[Jachym Cepicky]

Hallo, two things:

First:
Started compilation: Út kvě  2 08:20:07 CEST 2006
--
Errors in:
/usr/src/grass6/raster/r.average
/usr/src/grass6/scripts/r.in.onearth
/usr/src/grass6/scripts/r.in.wms
/usr/src/grass6/scripts/r.tileset
--
Finished compilation: Út kvě  2 08:25:28 CEST 2006


bobes:/usr/src/grass6# ls /usr/src/grass6/scripts/r.in.wms
ls: /usr/src/grass6/scripts/r.in.wms: No such file or directory
bobes:/usr/src/grass6# 

bobes:/usr/src/grass6# find . -name r.in.wms -print
bobes:/usr/src/grass6#

Something is missing?

Second:
With respect to Soeren, I do not thing, r.in.onearth should be in CVS.
It is too special tool - it is like adding "r.multiply" next to
r.mapcalc

just my two cents

Jachym

On Mon, May 01, 2006 at 08:52:22PM -0700, Cedric Shock wrote:
> 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

-- 
Jachym Cepicky
e-mail: jachym.cepicky at centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------   
OFFICE:                                     
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky at gdf-hannover.de
URL:    http://gdf-hannover.de
Tel.:   +49 511-39088507
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20060502/33bc9c86/attachment.bin