r.in.wms doesn't work in WinGRASS installer distribution

[ddalimonte]

The MSys environment included with WinGRASS (WinGRASS-6.4.0svn-r39740-2-Setup.exe) does not include the bc command used by the r.in.wms script. This causes the module to fail when trying to import maps from a WMS service.

GRASS 6.4.0svn (AoCWMS):C:/GRASS/msys/home/Dan > r.in.wms output=roads_15m \
mapserver=http://atlas.gc.ca/cgi-bin/atlaswms_en? \
layers=roads_15m format=png maxcols=1024 maxrows=1024 method=bilinear
which: wget: unknown command
which: bc: unknown command
ERROR: 'bc' is required, please install it first 

[hellik]

Replying to ddalimonte:

The MSys environment included with WinGRASS (WinGRASS-6.4.0svn-r39740-2-Setup.exe) does not include the bc command used by the r.in.wms script. This causes the module to fail when trying to import maps from a WMS service.

GRASS 6.4.0svn (AoCWMS):C:/GRASS/msys/home/Dan > r.in.wms output=roads_15m \
mapserver=http://atlas.gc.ca/cgi-bin/atlaswms_en? \
layers=roads_15m format=png maxcols=1024 maxrows=1024 method=bilinear
which: wget: unknown command
which: bc: unknown command
ERROR: 'bc' is required, please install it first 

bc can be included in the WinGrass-Installer. i've adapted ​http://trac.osgeo.org/grass/wiki/CompileOnWindows#Pre-builtBinaries with bc.

[hellik]

Replying to hellik:

bc can be included in the WinGrass-Installer. i've adapted ​http://trac.osgeo.org/grass/wiki/CompileOnWindows#Pre-builtBinaries with bc.

a quick test in my osgeo4w-tree added by bc:

r.in.wms output=roads_15m mapserver=http://atlas.gc.ca/cgi-bin/atlaswms_en? layers=roads_15m format=png maxcols=1024 maxrows=1024 method=bilinear
which: wget: unknown command
which: wget: unknown command
Calculating tiles
c:/osgeo4w/apps/grass/grass-6.4.0svn/etc/r.in.wms/wms.reques
t: /osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset: No
such file or directory
ERROR: r.tileset failure
ERROR: wms.request failure

bc is found. but now r.tileset is not found because of a wrong path to the script

[hellik]

Replying to hellik:

Replying to hellik:

bc can be included in the WinGrass-Installer. i've adapted ​http://trac.osgeo.org/grass/wiki/CompileOnWindows#Pre-builtBinaries with bc.

a quick test in my osgeo4w-tree added by bc:

r.in.wms output=roads_15m mapserver=http://atlas.gc.ca/cgi-bin/atlaswms_en? layers=roads_15m format=png maxcols=1024 maxrows=1024 method=bilinear
which: wget: unknown command
which: wget: unknown command
Calculating tiles
c:/osgeo4w/apps/grass/grass-6.4.0svn/etc/r.in.wms/wms.reques
t: /osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset: No
such file or directory
ERROR: r.tileset failure
ERROR: wms.request failure

bc is found. but now r.tileset is not found because of a wrong path to the script

r.tileset is there:

C:\OSGeo4W\apps\grass\grass-6.4.0svn\scripts\r.tileset

[hellik]

Replying to hellik: [...]

r.tileset is there:

C:\OSGeo4W\apps\grass\grass-6.4.0svn\scripts\r.tileset

at ​http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/scripts/r.tileset/r.tileset#L1 :

#!/bin/bash

this should be

#!/bin/sh

[hellik]

Replying to hellik: [...]

bc can be included in the WinGrass-Installer. i've adapted ​http://trac.osgeo.org/grass/wiki/CompileOnWindows#Pre-builtBinaries with bc.

bc needs readline, this can also be added

[hellik]

Replying to hellik:

Replying to hellik: [...]

bc can be included in the WinGrass-Installer. i've adapted ​http://trac.osgeo.org/grass/wiki/CompileOnWindows#Pre-builtBinaries with bc.

bc needs readline, this can also be added

a quick test after adding bc and readline to the osgeo4w-track with the example from the r.in.wms-manual

g.region -p
projection: 1 (UTM)
zone:       10
datum:      nad83
ellipsoid:  grs80
north:      1.2
south:      0
west:       0
east:       1.2
nsres:      1.2
ewres:      1.2
rows:       1
cols:       1
cells:      1

after starting r.in.wms g.proj.exe is crashing and the following messages:

r.in.wms output=terraserver-drg mapserver=http://terraserver.microsoft.com/ogcmap6.ashx layers=DRG region=drg-resolution format=jpeg srs=EPSG:26910
which: wget: unknown command
which: wget: unknown command
Calculating tiles
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[0]=SOURCE_PROJ: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[1]=1: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[2]=DEST_PROJ: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[3]=SOURCE_TO_DEST: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[0]=DEST_PROJ: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[1]=SOURCE_PROJ: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[2]=1: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[3]=DEST_TO_SOURCE: command not found
(standard_in) 2: parse error
(standard_in) 2: parse error
Rel. 4.7.1, 23 September 2009
<cs2cs.exe>:
projection initialization failure
cause: Unknown error
program abnormally terminated
ERROR: Problem running cs2cs. <Using from definition: >
ERROR: r.tileset failure
ERROR: wms.request failure

[hamish]

• If it matters I can probably replace bc with the more common awk to do the math.
• No, it really does need to be #!/bin/bash. Variable arrays[n] are not present in plain old sh, and if you try without bash you get errors like you see in the previous post.
• wget can be replaced by curl if it is installed; there's a flag. But really we/msys should ship a copy of wget in our windows package. (fwiw Mac ships curl not wget)
• r.in.wms for 6.4 is a problematic dead end. The new Python rewrite for grass 7 is where the future is. (using new GDAL/OGR drivers if possible)
• I half expect more problems to show up as the shell script version of this module has a number of issues, even on Linux.

Hamish

[hellik]

Replying to hellik: with debug

r.in.wms layers=global_mosaic mapserver=http://wms.jpl.nasa.gov/wms.cgi output=wms_global_mosaic
which: wget: unknown command
c:/OSGeo4W/apps/grass/grass-6.4.0svn/scripts/r.in.wms: eval:
line 1: unexpected EOF while looking for matching `''
c:/OSGeo4W/apps/grass/grass-6.4.0svn/scripts/r.in.wms: eval:
line 2: syntax error: unexpected end of file
which: wget: unknown command
Calculating tiles
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[0]=SOURCE_PROJ: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[1]=1: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[2]=DEST_PROJ: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[3]=SOURCE_TO_DEST: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[0]=DEST_PROJ: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[1]=SOURCE_PROJ: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[2]=1: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[3]=DEST_TO_SOURCE: command not found
(standard_in) 2: parse error
(standard_in) 2: parse error
Rel. 4.7.1, 23 September 2009
<cs2cs.exe>:
projection initialization failure
cause: Unknown error
program abnormally terminated
ERROR: Problem running cs2cs. <Using from definition: >
ERROR: r.tileset failure
ERROR: wms.request failure

[hellik]

Replying to hamish:

• If it matters I can probably replace bc with the more common awk to do the math.

installing and shipping bc and readline in the wingrass-installer is no problem

• No, it really does need to be #!/bin/bash. Variable arrays[n] are not present in plain old sh, and if you try without bash you get errors like you see in the previous post.

ah ok. what's about bash in msys, is beyond my knowledge at the moment

• wget can be replaced by curl if it is installed; there's a flag. But really we/msys should ship a copy of wget in our windows package. (fwiw Mac ships curl not wget)

osgeo4w ships curl

• r.in.wms for 6.4 is a problematic dead end. The new Python rewrite for grass 7 is where the future is. (using new GDAL/OGR drivers if possible)

ok

• I half expect more problems to show up as the shell script version of this module has a number of issues, even on Linux.

Hamish

Helmut

[hellik]

Replying to hellik:

• No, it really does need to be #!/bin/bash. Variable arrays[n] are not present in plain old sh, and if you try without bash you get errors like you see in the previous post.

ah ok. what's about bash in msys, is beyond my knowledge at the moment

in ​http://sourceforge.net/projects/mingw/files/ there is bash for msys. i've changed back to #!/bin/bash in r.tileset-script, bash seems to be recognized because there's no message like "r.tileset: No such file or directory".

But at all there is again:

r.in.wms layers=global_mosaic mapserver=http://wms.jpl.nasa.gov/wms.cgi output=wms_global_mosaic
which: wget: unknown command
c:/OSGeo4W/apps/grass/grass-6.4.0svn/scripts/r.in.wms: eval:
line 1: unexpected EOF while looking for matching `''
c:/OSGeo4W/apps/grass/grass-6.4.0svn/scripts/r.in.wms: eval:
line 2: syntax error: unexpected end of file
which: wget: unknown command
Calculating tiles
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[...]
(standard_in) 2: parse error
Rel. 4.7.1, 23 September 2009
<cs2cs.exe>:
projection initialization failure
cause: Unknown error
program abnormally terminated
ERROR: Problem running cs2cs. <Using from definition: >
ERROR: r.tileset failure
ERROR: wms.request failure

[hellik]

Replying to hellik:

Replying to hamish:

• wget can be replaced by curl if it is installed; there's a flag. But really we/msys should ship a copy of wget in our windows package. (fwiw Mac ships curl not wget)

osgeo4w ships curl

wget can be download as pre-built-binary from the gnuwin32-website and integrated in the windows-package

Helmut

[neteler]

Replying to hellik:

Replying to hellik:

Replying to hamish:

• wget can be replaced by curl if it is installed; there's a flag. But really we/msys should ship a copy of wget in our windows package. (fwiw Mac ships curl not wget)

Why should we then ship wget if osgeo4w already ships curl?

wget can be download as pre-built-binary from the gnuwin32-website and integrated in the windows-package

Since curl is there is looks more reasonable to get that used at this point. Apparently the test fails:

# check if we have wget or curl
if [ ! -x "`which wget`" ] ; then
    if [ ! -x "`which curl`" ] ; then
        g.message -e "Either 'wget' or 'curl' is required, please install one first"
        exit 1
    else
        g.message -v "Using CURL for downloading data."
        USE_CURL=1
    fi
else
    g.message -v "Using WGET for downloading data."
    USE_WGET=1
fi

Perhaps the which magic is non-functional with Msys?

Helmut: could you take out the test in the script and just set

USE_CURL=1

to see what happens then?

Markus

[hellik]

Replying to neteler:

Replying to hellik:

Replying to hellik:

Replying to hamish:

• wget can be replaced by curl if it is installed; there's a flag. But really we/msys should ship a copy of wget in our windows package. (fwiw Mac ships curl not wget)

Why should we then ship wget if osgeo4w already ships curl?

wget can be download as pre-built-binary from the gnuwin32-website and integrated in the windows-package

Since curl is there is looks more reasonable to get that used at this point. Apparently the test fails:

# check if we have wget or curl
if [ ! -x "`which wget`" ] ; then
    if [ ! -x "`which curl`" ] ; then
        g.message -e "Either 'wget' or 'curl' is required, please install one first"
        exit 1
    else
        g.message -v "Using CURL for downloading data."
        USE_CURL=1
    fi
else
    g.message -v "Using WGET for downloading data."
    USE_WGET=1
fi

Perhaps the which magic is non-functional with Msys?

Helmut: could you take out the test in the script and just set

USE_CURL=1

to see what happens then?

Markus

i've unset the curl/wget-check and set USE_CURL=1. bash, bc is in the osgeo4w/msys-stack:

again the same error:

r.in.wms output=elevation_meters mapserver=http://wms.jpl.nasa.gov/wms.cgi layers=us_ned styles=real -o
c:/OSGeo4W/apps/grass/grass-6.4.0svn/scripts/r.in.wms: eval:
line 1: unexpected EOF while looking for matching `''
c:/OSGeo4W/apps/grass/grass-6.4.0svn/scripts/r.in.wms: eval:
line 2: syntax error: unexpected end of file
Calculating tiles
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[0]=SOURCE_PROJ: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[1]=1: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[2]=DEST_PROJ: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[3]=SOURCE_TO_DEST: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[0]=DEST_PROJ: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[1]=SOURCE_PROJ: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[2]=1: command not found
c:/osgeo4w/apps/grass/grass-6.4.0svn/scripts/r.tileset:
[3]=DEST_TO_SOURCE: command not found
(standard_in) 2: parse error
(standard_in) 2: parse error
Rel. 4.7.1, 23 September 2009
<cs2cs.exe>:
projection initialization failure
cause: Unknown error
program abnormally terminated
ERROR: Problem running cs2cs. <Using from definition: >
ERROR: r.tileset failure
ERROR: wms.request failure

[cmbarton]

I should also note that awk/gawk doesn't seem to come with msys either. Other scripts fail in wingrass due to this lack.

Michael

[hellik]

Replying to cmbarton:

I should also note that awk/gawk doesn't seem to come with msys either. Other scripts fail in wingrass due to this lack.

Michael

I've just had a look into the packaging files for the current win-installer, based on the osgeo4w-msys-stack. awk/gawk is there.

so both should also be in the current WinGrass-Installer.

Helmut

[cmbarton]

I don't have a Windows platform computer and so cannot test directly. I've just seen scripts fail with the error that awk (or gawk) doesn't exist with recent winGRASS installations (i.e., not the osgeo4w version of GRASS).

Michael

[neteler]

Please report the current state here.

[hamish]

Replying to hamish:

• No, it really does need to be #!/bin/bash. Variable arrays[n] are not present in plain old sh, and if you try without bash you get errors like you see in the previous post.

[hamish]

Replying to cmbarton:

I don't have a Windows platform computer and so cannot test directly. I've just seen scripts fail with the error that awk (or gawk) doesn't exist with recent winGRASS installations (i.e., not the osgeo4w version of GRASS).

it seems like it is now with the r40876 nightly build, but I don't think that's the problem. I think the problem is that #!/bin/bash is being run as some other sh for some reason.

C:\Program Files\GRASS-64-SVN\msys\bin\awk and "awk" works for me at the MSys command prompt. (It is just a tiny shell script that does gawk "$@".)

fwiw bash.exe and sh.exe have the exact same filesize and $BASH_VERSION says "3.1.0(1)-release". There is no sign of dash.

fwiw2 I just ran the awk-using script r.colors.stddev from the MSys prompt and from the wxGUI menu and it worked fine.

I don't think there is any usage difference between awk and gawk, because on my Debian install it's the same symlink.

Hamish

[hellik]

Replying to hamish:

• r.in.wms for 6.4 is a problematic dead end. The new Python rewrite for grass 7 is where the future is. (using new GDAL/OGR drivers if possible)

tested with the latest WinGrass7-installer:

r.in.wms layers=global_mosaic mapserver=http://wms.jpl.nasa.gov/wms.cgi output=wms_global_mosaic
Calculating tiles...
Traceback (most recent call last):
  File "C:\Program Files\GRASS-70-SVN\scripts\m.proj.py",
line 281, in <module>
    main()
  File "C:\Program Files\GRASS-70-SVN\scripts\m.proj.py",
line 214, in main
    inf = file(infile)
IOError: [Errno 13] Permission denied:
'c:\\users\\syringia\\appdata\\local\\temp\\tmpsnqm6-'
ERROR: cs2cs failed
ERROR: r.tileset failed

[Errno 13] Permission denied: maybe related to? ​http://bugs.python.org/issue1425127

Helmut

[mmetz]

Replying to hamish:

[snip] I think the problem is that #!/bin/bash is being run as some other sh for some reason.

There is no /bin/bash available to my OSGEO4W msys. There is C:\OSGEO4W\bin\bash, but that is not available for the msys console C:\OSGEO4W\apps\msys\msys.bat because /bin seems to be equal to C:\OSGEO4W\apps\msys\bin and not C:\OSGEO4W\bin and there is no C:\OSGEO4W\apps\msys\bin\bash. So I added bash for msys plus its dependencies regex and termcap from

​http://sourceforge.net/downloads/mingw/MSYS/

and r.in.wms works.

Is this a proper solution or a crude hack?

Markus M

[hamish]

Hi,

trying again, 6.4.0svn nightly build r42845 on Windows XP using the NASA wms global_mosaic example from above.

it dies because it can't find $GISBASE/etc/r.in.wms/wms.request even though it is added to the PATH earlier on. (I note that everything else in the path is /c/Program.. but the add-on etc/ dir is c:/Program... don't know if that matters or not)

probably the Makefile needs to create .bat wrappers and copy them to $GISBASE/bin/

I expect the same thing will be needed for i.oif which also keeps helper shell scripts in $GISBASE/etc/.

Hamish

[mmetz]

Replying to hamish:

it dies because it can't find $GISBASE/etc/r.in.wms/wms.request

Works with self-compiled 64 r42894 from last week, using a newer msys than wiki recommends. Does not work with the installed version of the very same thing (package, create installer, install). I have not the faintest idea what is missing/the crucial difference, wild guess, the packager missed something?

Markus M

[hamish]

for the trac record, the shell scripts needed the programs called with their full path in the command line, and now we are struggling with getting quoting around +proj terms to be safe. Nothing is backported to 6.4 yet, and as g.proj and m.proj have changed I wonder if we should put off backporting to the stable branch for a while until those get a bit of solid testing time.

read all about it on the grass-dev ML in the "6.4.0 blocker bugs" thread.

Hamish

[mmetz]

Replying to hamish:

for the trac record, the shell scripts needed the programs called with their full path in the command line,

Not in my self-compiled 6.4 version, no changes to the local copy. My point was that calling the programs in question with their full path might be fighting symptoms and not the cause.

and now we are struggling with getting quoting around +proj terms to be safe.

A different issue.

Nothing is backported to 6.4 yet,

But it works anyway for me, at least in the OSGeo4W tree, not the installer created from it.

read all about it on the grass-dev ML in the "6.4.0 blocker bugs" thread.

Regard it as a comment to your post in this thread on July 28.

Markus M

[hamish]

Replying to hamish:

now we are struggling with getting quoting around +proj terms to be safe. Nothing is backported to 6.4 yet, and as g.proj and m.proj have changed I wonder if we should put off backporting to the stable branch for a while until those get a bit of solid testing time.

back to this one, the quoting "fix" for quoting +proj4 terms in 6.5svn doesn't work, e.g. in m.proj.

in /bin/sh:

 mkdir "/tmp/nad test"
 cp "$GISBASE"/etc/nad/nzgd2kgrid0005.gsb "/tmp/nad test/"

 IN_PROJ="'+proj=nzmg' '+lat_0=-41' '+lon_0=173' '+x_0=2510000' '+y_0=6023150' '+no_defs' '+a=6378388' '+rf=297' '+nadgrids=/tmp/nad test/etc/nad/nzgd2kgrid0005.gsb' '+to_meter=1'"

 OUT_PROJ="+proj=longlat +datum=WGS84"

feed a point to cs2cs:

 echo "2006797  5490896" | cs2cs -w5 $IN_PROJ  +to $OUT_PROJ
Using from definition: 
Rel. 4.6.0, 21 Dec 2007
<cs2cs>: 
projection initialization failure
cause: no arguments in initialization list
program abnormally terminated

same thing, but expanded:

 echo "2006797  5490896" | cs2cs -w5 '+proj=nzmg' '+lat_0=-41' '+lon_0=173' \
   '+x_0=2510000' '+y_0=6023150' '+no_defs' '+a=6378388' '+rf=297' \
   '+nadgrids=/tmp/nad test/nzgd2kgrid0005.gsb' '+to_meter=1' \
   +to +proj=longlat +datum=WGS84
166d32'36.78939"E       45d36'42.47115"S 0.000


I've tried a number of permutations of eval, `echo $IN_PROJ`, and different flavours of quoting styles, but I just can't seem to get the literal expansion to work.


any ideas?

thanks,
Hamish

[hamish]

Replying to hamish:

for the trac record, the shell scripts needed the programs called with their full path in the command line,

Replying to mmetz:

Not in my self-compiled 6.4 version, no changes to the local copy. My point was that calling the programs in question with their full path might be fighting symptoms and not the cause.

I think it happens on the second pass, when g.parser relaunches $0. (??)

perhaps it works or doesn't work because Windows includes pwd in the path while UNIX does not? So if you happen to be in the same dir as the addon script on Windows it will magically work, while on UNIX (or if you cd..), it would not?

just an idea, Hamish

[glynn]

Replying to hamish:

Replying to hamish:

for the trac record, the shell scripts needed the programs called with their full path in the command line,

Replying to mmetz:

Not in my self-compiled 6.4 version, no changes to the local copy. My point was that calling the programs in question with their full path might be fighting symptoms and not the cause.

I think it happens on the second pass, when g.parser relaunches $0. (??)

perhaps it works or doesn't work because Windows includes pwd in the path while UNIX does not? So if you happen to be in the same dir as the addon script on Windows it will magically work, while on UNIX (or if you cd..), it would not?

On Unix, g.parser re-invokes the script using execl(), which doesn't use the path. There isn't any point in using the path; g.parser must be able to open the script to read the option specifications, so it must have either the full path to the script or a path relative to the current directory.

When the shell executes a script via the path, the program specified in the #! line (e.g. bash) will receive the script's full path in argv[1]. In the case of bash, this path is available via $0.

On Windows, g.parser re-invokes a script by executing $GRASS_SH with the path to the script as the first argument. Again, this requires either a full path or a path relative to the current directory; %PATH% has no effect.

[hellik]

Replying to glynn:

Replying to hamish:

Replying to hamish:

for the trac record, the shell scripts needed the programs called with their full path in the command line,

Replying to mmetz:

Not in my self-compiled 6.4 version, no changes to the local copy. My point was that calling the programs in question with their full path might be fighting symptoms and not the cause.

I think it happens on the second pass, when g.parser relaunches $0. (??)

perhaps it works or doesn't work because Windows includes pwd in the path while UNIX does not? So if you happen to be in the same dir as the addon script on Windows it will magically work, while on UNIX (or if you cd..), it would not?

On Unix, g.parser re-invokes the script using execl(), which doesn't use the path. There isn't any point in using the path; g.parser must be able to open the script to read the option specifications, so it must have either the full path to the script or a path relative to the current directory.

When the shell executes a script via the path, the program specified in the #! line (e.g. bash) will receive the script's full path in argv[1]. In the case of bash, this path is available via $0.

On Windows, g.parser re-invokes a script by executing $GRASS_SH with the path to the script as the first argument. Again, this requires either a full path or a path relative to the current directory; %PATH% has no effect.

related to this topic there was also a thread under #1163, but switching now to this ticket.

after some testing there seems to be a missing GDAL_DATA variable in the WinGrass-installer, which is needed that for example gdalwarp is able to work properly.

I've added a fix for this in r43520 for WinGrass65. in a self built WinGrass65-installer with this fix, r.in.wms is working with all the examples in the man-pages.

this fix can also be applied to Grass64. the only issue in WinGrass64 is, that the helper scripts in C:\Program Files\GRASS-64\etc\r.in.wms (r.in.gdalwarp, wms.download, wms.request) aren't found by r.in.wms. if I copy these files in C:\Program Files\GRASS-64\scripts, then also r.in.wms is working with all the examples in the man-pages in WinGrass64.

maybe any idea/hint for the issue that the helper scripts aren't recognized?

best regards Helmut

best regards

[hamish]

again please forget about r.in.wms & co. for 6.4.0. There are other problems there besides this. Please focus on 6.5 so the backports that replace it will be well tested.

the helper scripts being found is just one of those other problems which AFAIK is already found & fixed in 6.5.

thanks, Hamish

[hellik]

Patch to get r.in.wms working in WinGrass64

[hellik]

Hi Hamish,

Replying to hamish: again please forget about r.in.wms & co. for 6.4.0. There are other problems there besides this. Please focus on 6.5 so the backports that replace it will be well tested.

I've compared r.in.wms in Grass64-source and in Grass65-source, there only some lines different in both (see attached patch).

this patch together with the fix for the missing GDAL_DATA variable, r.in.wms is also working with all the examples in the man-page for the WinGrass64-installer. I would vote for port this two fixes to Grass64.

so then only the issue with white spaces, +proj4-terms and grid shift-files seems to remain.

best regards Helmut

[hamish]

there is also r.tileset, cs2cs, and gdalwarp issues to consider.

it is getting better, but please just leave the backporting alone for now..

thanks, Hamish

[msieczka]

Replying to hamish:

there is also r.tileset, cs2cs, and gdalwarp issues to consider.

it is getting better, but please just leave the backporting alone for now..

Maybe drop r.in.wms in Win GRASS 6.4.1? Bugs are known, not going to be fixed, so no point in frustrating the user?

[hellik]

Replying to msieczka:

Replying to hamish:

there is also r.tileset, cs2cs, and gdalwarp issues to consider.

it is getting better, but please just leave the backporting alone for now..

Maybe drop r.in.wms in Win GRASS 6.4.1? Bugs are known, not going to be fixed, so no point in frustrating the user?

with the recent fixes for GDAL_DATA and PROJ_LIB variables needed in windows and some backports from Grass65 to Grass64svn, r.in.wms should now working also in WinGrass6.4.1 (tested with the examples in the manpages in WinGrass6.4.1 in the nc-location: all are working)

Helmut

[msieczka]

Replying to hellik:

Replying to msieczka:

Replying to hamish:

there is also r.tileset, cs2cs, and gdalwarp issues to consider.

it is getting better, but please just leave the backporting alone for now..

Maybe drop r.in.wms in Win GRASS 6.4.1? Bugs are known, not going to be fixed, so no point in frustrating the user?

with the recent fixes for GDAL_DATA and PROJ_LIB variables needed in windows and some backports from Grass65 to Grass64svn, r.in.wms should now working also in WinGrass6.4.1 (tested with the examples in the manpages in WinGrass6.4.1 in the nc-location: all are working)

I have Installed ​http://josef.fsv.cvut.cz/wingrass/grass64/WinGRASS-6.4.SVN-r43540-1-Setup.exe and overwritten respective files in C:\Program Files\GRASS-64-SVN\scripts with most recent stuff from ​https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4/scripts/r.in.wms/.

In spearfish60 an error crops out:

GRASS 6.4> g.region rast=elevation.dem -ag
n=4928000
s=4914020
w=590010
e=609000
nsres=30
ewres=30
rows=466
cols=633
cells=294978
GRASS 6.4> r.in.wms layers=global_mosaic mapserver=http://wms.jpl.nasa.gov/wms.
cgi output=wms_global_mosaic --o
which: wget: unknown command
which: wget: unknown command
Calculating tiles
Rel. 4.7.1, 23 September 2009
<cs2cs.exe>: 
projection initialization failure
cause: Unknown error
program abnormally terminated
ERROR: Problem running cs2cs. <Using to definition: init=epsg:4326 >
ERROR: r.tileset failure
ERROR: wms.request failure

[hellik]

Replying to msieczka:

Replying to hellik:

Replying to msieczka:

Replying to hamish:

there is also r.tileset, cs2cs, and gdalwarp issues to consider.

it is getting better, but please just leave the backporting alone for now..

Maybe drop r.in.wms in Win GRASS 6.4.1? Bugs are known, not going to be fixed, so no point in frustrating the user?

with the recent fixes for GDAL_DATA and PROJ_LIB variables needed in windows and some backports from Grass65 to Grass64svn, r.in.wms should now working also in WinGrass6.4.1 (tested with the examples in the manpages in WinGrass6.4.1 in the nc-location: all are working)

I have Installed ​http://josef.fsv.cvut.cz/wingrass/grass64/WinGRASS-6.4.SVN-r43540-1-Setup.exe and overwritten respective files in C:\Program Files\GRASS-64-SVN\scripts with most recent stuff from ​https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4/scripts/r.in.wms/.

In spearfish60 an error crops out:

GRASS 6.4> g.region rast=elevation.dem -ag
n=4928000
s=4914020
w=590010
e=609000
nsres=30
ewres=30
rows=466
cols=633
cells=294978
GRASS 6.4> r.in.wms layers=global_mosaic mapserver=http://wms.jpl.nasa.gov/wms.
cgi output=wms_global_mosaic --o
which: wget: unknown command
which: wget: unknown command
Calculating tiles
Rel. 4.7.1, 23 September 2009
<cs2cs.exe>: 
projection initialization failure
cause: Unknown error
program abnormally terminated
ERROR: Problem running cs2cs. <Using to definition: init=epsg:4326 >
ERROR: r.tileset failure
ERROR: wms.request failure

you need also:

r43520 r43542

that means add GDAL_DATA and PROJ_LIB variable in following files

C:\Program Files\GRASS-64-SVN\grass64svn.bat C:\Program Files\GRASS-64-SVN\bin\grass64svn

in grass64svn.bat

rem Set GDAL_DATA
set GDAL_DATA=%GRASSDIR%\etc\ogr_csv

rem Set PROJ_LIB
set PROJ_LIB=%GRASSDIR%\proj

and in grass64svn

# Set the GDAL_DATA variable
GDAL_DATA="C:\Program Files\GRASS-64-SVN\etc\ogr_csv"
export GDAL_DATA
# Set the PROJ_LIB variable
PROJ_LIB="C:\Program Files\GRASS-64-SVN\proj"
export PROJ_LIB 

if you want I can you give WinGRASS-6.4.SVN-r43468-1-Setup.exe (self compiled from yesterday) for testing?

Helmut

[msieczka]

Replying to hellik:

you need also:

r43520 r43542

if you want I can you give WinGRASS-6.4.SVN-r43468-1-Setup.exe (self compiled from yesterday) for testing?

Don't bother. I'll just try next nightly build and will close the ticket if all is fine. Thanks :).

[hellik]

Replying to msieczka:

Replying to hellik:

you need also:

r43520 r43542

if you want I can you give WinGRASS-6.4.SVN-r43468-1-Setup.exe (self compiled from yesterday) for testing?

Don't bother. I'll just try next nightly build and will close the ticket if all is fine. Thanks :).

the nightly builds seems to be broken at the moment. please test then within the nc-sample-dataset and the spearfish-sample dataset.

thanks Helmut

[hamish]

I would not sign this off as finished yet, but testing is still useful, thanks.

I'll probably open a new bug for the r.in.gdalwarp error when the NTv2 grid file contains a space.

Hamish

[msieczka]

Replying to hellik:

the nightly builds seems to be broken at the moment. please test then within the nc-sample-dataset and the spearfish-sample dataset.

The nightly build is back. Using today's ​http://josef.fsv.cvut.cz/wingrass/grass64/WinGRASS-6.4.SVN-r43715-1-Setup.exe, the following command in spearfish60:

g.region rast=elevation.dem res=30 -ag
r.in.wms output=elevation_meters mapserver=http://wms.jpl.nasa.gov/wms.cgi layers=us_ned styles=real -0

fails, with a following output in the beginning (full log attached):

<cs2cs.exe>: while processing file: <stdin>, line 1^M
pj_transform(): Unknown error^M
(standard_in) 1: parse error^M
(standard_in) 1: parse error^M

[msieczka]

detailed log for #comment:42

[hamish]

Hi,

any improvement in r.in.wms on WinGrass, or is it still broken?

msieczka's spearfish test case:

g.region rast=elevation.dem res=30 -ag
r.in.wms output=elevation_meters mapserver=http://wms.jpl.nasa.gov/wms.cgi layers=us_ned styles=real -c

(note I've changed trailing -0 flag to -c) see previous post for comparison error log.

for me in linux, the first time I tried I got a download error, the second time it created two maps: elevation_meters.1 and .2. The .1 file has good elevation data in it, the .2 file seems to be a 0,255 mask for nodata,data.

The two .1,.2 output maps caused r.support to fail, but that's a minor issue.

Hamish

[martinl]

Please try r.in.wms2 from GRASS Addons.

[hamish]

suggestion: for 6.4.4 let's consider packaging r.in.wms2.py in with gui/scripts/, and have it as the menu item from the wxGUI. the shell version can still be there from the command line, but I don't see it getting much more than maintenance fixes at this point.

I know the wheel is already invented a number of times, but I'd also suggest to try and make more use of OWSLib, to outsource the OGC protocol stuff to an existing library/team.

​http://geopython.github.io/OWSLib/

todo: test current state of r.in.wms(.sh) in grass6 after the script-called-from-a-script patches have been applied (#1727).

Hamish

[hamish]

latest 6.5 nightly wingrass build:

• GDAL_DATA now set in $GISBASE/etc/env.bat, points to $GISBASE/share/gdal/

• xml2.exe and wget.exe are still not installed with wingrass, but curl.exe is there so minimum requirements for r.in.wms[.sh] are fulfilled.

• script-called-from-script path problem fixed in #1727.

• r.in.wms examples still need a bit more refreshing work. #1495

from the msys command prompt:

r.in.wms -l mapserver="http://mapserver.flightgear.org/ms"

seems to work now, but the parsing is a bit messed up (linux too), if xml2.exe was installed that would be a lot better.

.. work in progress ..

Hamish

[hamish]

various quoting and spaces-in-pathnames fixes from the last 2 days backported to relbr64 in r56231; r.in.wms[.sh] in grass 6 now works on wingrass.

... at least when it is run from a ll/wgs84 loc'n (eg man-page example for NC landcover). gdalwarp may still have issues (see #1166), but I don't have many known-good cases to test (see #1495). the flightgear/telascience/osgeo.org mapserver site is super slow, so not a great example; local testing & other open-server examples with NC or Spearfish coverage would be very welcome.

---

trying to run r.in.wms[.py] from the wxGUI (File > Import raster > WMS Import) fails with:

Traceback (most recent call last):
  File "c:\Program Files\GRASS GIS
6.5.svn\etc\wxpython\modules\ogc_services.py", line 204, in
OnConnect

self.list.LoadData(layers)
  File "c:\Program Files\GRASS GIS
6.5.svn\etc\wxpython\modules\ogc_services.py", line 259, in
LoadData

title = data[layer]['title']
KeyError
:
'title'

after you paste in the server ("​http://mapserver.flightgear.org/ms") and click [Connect].

Hamish

[hamish]

Replying to hamish: ...

trying to run r.in.wms[.py] from the wxGUI (`File > Import raster > WMS Import`) fails with:

...
title = data[layer]['title']
KeyError
:
'title'

that is #1163.

[hamish]

It fails anytime when xml2 is not available, so not a wingrass bug per se, xml2.exe just happens to be missing there (see #1952).

The output of 'r.in.wms -l' changes depending on if xml2 is de-xml'ing the capabilities file or if r.in.wms.sh is trying to do it.

attempt to catch that and abort with an informative error message added to devbr6 in r56743 for testing.

Hamish

[hamish]

Replying to hamish:

It fails anytime when xml2 is not available, so not a wingrass bug per se, xml2.exe just happens to be missing there (see #1952).

...

attempt to catch that and abort with an informative error message added to devbr6 in r56743 for testing.

tested ok and backported to 6.4svn with r56783.

cs2cs + grid paths is likely still a problem, more testing needed. On the other hand basic functionality is present so changing the milestone to 6.4.4.

TBC ...

Hamish

[hamish]

re. cs2cs + grid paths, it is still a problem with the latest nightly build. if you are on wingrass and using grass 6.x and using a datum transform grid file in your projection definition, m.proj fails. (and so r.in.wms.sh too)

two issues:

• the path to the +nadgrids file should be quoted (see proj4 ticket # 218)
• msys is messing up the path string (the "g.message '/'" expansion problem).

possible aid for the second issue in init.sh and r.in.wms.sh's wms_request with "dos2unix_path()", but I don't know if that helps here or not until the quoting issue gets fixed.

Hamish