Opened 15 years ago
Last modified 8 years ago
#820 new defect
r.in.wms doesn't work in WinGRASS installer distribution
Reported by: | ddalimonte | Owned by: | hamish |
---|---|---|---|
Priority: | major | Milestone: | 6.4.6 |
Component: | Projections/Datums | Version: | svn-releasebranch64 |
Keywords: | r.in.wms, wingrass, cs2cs | Cc: | grass-dev@… |
CPU: | All | Platform: | MSWindows XP |
Description
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
Attachments (2)
Change History (54)
comment:1 by , 15 years ago
Keywords: | r.in.wms added |
---|
follow-ups: 3 6 comment:2 by , 15 years ago
follow-up: 4 comment:3 by , 15 years ago
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
follow-up: 5 comment:4 by , 15 years ago
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 failurebc 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
comment:5 by , 15 years ago
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
follow-up: 7 comment:6 by , 15 years ago
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
follow-up: 9 comment:7 by , 15 years ago
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
follow-ups: 10 19 22 comment:8 by , 15 years ago
- 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
comment:9 by , 15 years ago
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
follow-ups: 11 12 comment:10 by , 15 years ago
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
comment:11 by , 15 years ago
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
follow-up: 13 comment:12 by , 15 years ago
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
follow-up: 14 comment:13 by , 15 years ago
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
comment:14 by , 15 years ago
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 fiPerhaps the which magic is non-functional with Msys?
Helmut: could you take out the test in the script and just set
USE_CURL=1to 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
follow-up: 16 comment:15 by , 15 years ago
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
comment:16 by , 15 years ago
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
follow-up: 21 comment:17 by , 15 years ago
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
comment:19 by , 15 years ago
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.
comment:20 by , 15 years ago
Keywords: | wingrass added |
---|
follow-up: 23 comment:21 by , 15 years ago
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
comment:22 by , 14 years ago
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
comment:23 by , 14 years ago
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
follow-up: 25 comment:24 by , 14 years ago
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
comment:25 by , 14 years ago
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
follow-ups: 27 28 comment:26 by , 14 years ago
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
follow-up: 29 comment:27 by , 14 years ago
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
comment:28 by , 14 years ago
Component: | Packaging → Projections/Datums |
---|---|
Keywords: | cs2cs added |
Priority: | normal → major |
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
follow-up: 30 comment:29 by , 14 years ago
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
follow-up: 31 comment:30 by , 14 years ago
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.
comment:31 by , 14 years ago
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
follow-up: 33 comment:32 by , 14 years ago
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
by , 14 years ago
Attachment: | WinGrass64_rinwms.patch added |
---|
Patch to get r.in.wms working in WinGrass64
comment:33 by , 14 years ago
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
follow-up: 35 comment:34 by , 14 years ago
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
follow-up: 36 comment:35 by , 14 years ago
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?
follow-up: 37 comment:36 by , 14 years ago
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
follow-up: 38 comment:37 by , 14 years ago
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
follow-up: 39 comment:38 by , 14 years ago
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:
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
follow-up: 40 comment:39 by , 14 years ago
follow-up: 42 comment:40 by , 14 years ago
Replying to msieczka:
Replying to hellik:
you need also:
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
comment:41 by , 14 years ago
Cc: | added |
---|---|
Milestone: | 6.4.0 → 6.4.1 |
Owner: | changed from | to
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
comment:42 by , 14 years ago
CPU: | Unspecified → All |
---|
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
comment:43 by , 13 years ago
Milestone: | 6.4.1 → 6.4.2 |
---|
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
comment:45 by , 11 years ago
Milestone: | 6.4.2 → 6.4.3 |
---|
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.
todo: test current state of r.in.wms(.sh) in grass6 after the script-called-from-a-script patches have been applied (#1727).
Hamish
comment:46 by , 11 years ago
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
follow-up: 48 comment:47 by , 11 years ago
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
comment:48 by , 11 years ago
follow-up: 50 comment:49 by , 11 years ago
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
comment:50 by , 11 years ago
Milestone: | 6.4.3 → 6.4.4 |
---|
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
comment:51 by , 11 years ago
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
comment:52 by , 8 years ago
Milestone: | 6.4.4 → 6.4.6 |
---|
Replying to ddalimonte:
bc can be included in the WinGrass-Installer. i've adapted http://trac.osgeo.org/grass/wiki/CompileOnWindows#Pre-builtBinaries with bc.