[GRASS-dev] 6.4.0 blocker bugs

Hamish hamish_b at yahoo.com
Wed Jul 28 01:05:01 EDT 2010


> > Markus Neteler wrote:
> > > -> r.in.wms should not hold a release.

Hamish:
> > fwiw, r.in.wms and (presumably) i.oif on WinGrass do not work right now
> > because they use helper shell scripts installed to
> > $GISBASE/etc/$module/ and those shell scripts do not currently have
> > associated .bat files

Glynn:
> I'm not sure that they should need .bat files, given that they are
> only run from within a shell scripts. I thought that MSys could handle
> this itself.
> Does it work if the main scripts are changed to run helper scripts via
> an absolute path?

You are correct, by adding the full path to the helper script it can
now find them. fix applied in 6.5svn.
i.oif already had that.


next problem: r.in.wms calls wms.request which calls r.tileset.
r.tileset calls cs2cs*, with +proj4 terms taken from SRS=`g.proj -j`.

for spearfish those terms include the conus grid file, which is in
$GISBASE/etc/nad/ ... and $GISBASE of course contains a space, and
then cs2cs dies a horrible death.

so how to quote the right side of the individual +nadgrids= line? and
will cs2cs accept that?

I expect it may be a bad idea to ask g.proj to output that, but maybe
that's not so evil after all.  ?? perhaps just do that for MINGW32?
I guess that would mean putting ugliness into g.proj's print_proj4().


[*] so m.proj and r.in.gdalwarp probably also has this problem



I'm also a bit concerned about what happens when it hits r.tileset's
bashisms alittle later in, but we'll jump off that bridge when we get to
it.


Hamish



      


More information about the grass-dev mailing list