r.tileset: projection string munching on wingrass

[hamish]

Hi,

while running r.in.wms at the MSys prompt on WinGrass with the NASA OnEarth Landsat man page example, the r.tileset part does some weird things to the +proj4 strings.

to see them, you need to add some debug messages to the r.tileset script, line ~233:

        g.message -i message="[$p_source_proj]"
	g.message -i message="[$p_dest_proj]"        

also I changed "message 3 ... $CS2CS" just above that to "g.message -i message=..." so the cs2cs command line would show up.

the weirdness displayed by that g.message is:

echo "589980.0 4913700.0" | cs2cs -f "\.8\f" '+proj=utm' '+zone=13'
'+a=6378206.4' '+rf=294.9786982' '+no_defs'
'+nadgrids=c;C:\PROGRA~1\GRASS-~1\msys\Program
Files\GRASS-65-SVN\etc\nad\conus' '+to_meter=1.0' +to +init=epsg;4326

namely "+nadgrids=c;C:\PROGRA~1\..." starting with "c;" and "+init=epsg:4326" becoming "+init=epsg;4326" (with an ';' instead of a ':').

g.proj -j by itself looks fine.

?

thanks, Hamish

[hamish]

quite strange, maybe related to the g.message "%.8f" bug? (#1162)

GRASS 6.5> g.proj -j  
+proj=utm
+zone=13
+a=6378206.4
+rf=294.9786982
+no_defs
+nadgrids=c:/Program Files/GRASS-65-SVN/etc/nad/conus
+to_meter=1.0

GRASS 6.5> g.message message="`g.proj -j`"
+proj=utm
+zone=13
+a=6378206.4
+rf=294.9786982
+no_defs
+nadgrids=c;C:\PROGRA~1\GRASS-~1\msys\Program
Files\GRASS-65-SVN\etc\nad\conus
+to_meter=1.0

Hamish

[hamish]

simplified even further:

GRASS 6.5> g.message "+c:"
+c:

GRASS 6.5> g.message "+c:/"
+c;C:\PROGRA~1\GRASS-~1\msys

Hamish

[hamish]

GRASS 6.5> g.message ":/"
;C:\PROGRA~1\GRASS-~1\msys

GRASS 6.5> g.message "/"
C:/PROGRA~1/GRASS-~1/msys

[hellik]

Replying to hamish:

Hi,

while running r.in.wms at the MSys prompt on WinGrass with the NASA OnEarth Landsat man page example, the r.tileset part does some weird things to the +proj4 strings.

to see them, you need to add some debug messages to the r.tileset script, line ~233:

        g.message -i message="[$p_source_proj]"
	g.message -i message="[$p_dest_proj]"        

also I changed "message 3 ... $CS2CS" just above that to "g.message -i message=..." so the cs2cs command line would show up.

the weirdness displayed by that g.message is:

echo "589980.0 4913700.0" | cs2cs -f "\.8\f" '+proj=utm' '+zone=13'
'+a=6378206.4' '+rf=294.9786982' '+no_defs'
'+nadgrids=c;C:\PROGRA~1\GRASS-~1\msys\Program
Files\GRASS-65-SVN\etc\nad\conus' '+to_meter=1.0' +to +init=epsg;4326

namely "+nadgrids=c;C:\PROGRA~1\..." starting with "c;" and "+init=epsg:4326" becoming "+init=epsg;4326" (with an ';' instead of a ':').

g.proj -j by itself looks fine.

?

thanks, Hamish

I don't know if it's related to this (maybe worth for an extra ticket?).

in the osgeo4w-stack there are in C:\OSGeo4W\share following folder with a lot projection informations:

C:\OSGeo4W\share\epsg_csv C:\OSGeo4W\share\gdal C:\OSGeo4W\share\proj

but only the proj-folder-content is included in WinGrass-installer. I've tested r.in.wms in WinGrass64 and r.in.gdalwarp/gdalwarp couldn't find the needed gcs.csv etc. files.

Should the other folders also be included in the WinGrass-Installer?

Helmut

[hamish]

Replying to hellik:

I've tested r.in.wms in WinGrass64 and r.in.gdalwarp/gdalwarp couldn't find the needed gcs.csv etc. files.

fwiw, r.in.wms is known to be partly not working in 6.4.0 wingrass, pls use latest 6.5svn for testing that.

also gdalwarp will fail if the target SRS contains a NTv2 +nadgrids file path with a space in it. No known solution (see thread on PROJ4 mailing list).

The Location wizard seems to be able to find the share/epsg file, so some of the support files must be getting copied...

thanks, Hamish

[hellik]

Replying to hamish:

Replying to hellik:

I've tested r.in.wms in WinGrass64 and r.in.gdalwarp/gdalwarp couldn't find the needed gcs.csv etc. files.

fwiw, r.in.wms is known to be partly not working in 6.4.0 wingrass, pls use latest 6.5svn for testing that.

see also ​http://trac.osgeo.org/grass/ticket/1163#comment:7

Helmut

[glynn]

Replying to hamish:

GRASS 6.5> g.message "/"
C:/PROGRA~1/GRASS-~1/msys

MSys converts any argument which "looks like" a filename to Windows syntax when executing any command outside of the MSys "filesystem". The "mkpath" command in Rules.make (in 7.0) relies upon this (via tools/g.echo) to construct a valid PYTHONPATH.

This "feature" is one reason why shell scripts will never be robust on Windows. Any shell aiming for Unix-compatibility can't use native Windows filenames due to the use of ":" in *PATH variables, but Windows programs won't understand whatever Unix-style filenames it uses, so it has to perform translation. Which falls down when something which looks like a filename isn't one (and also when it needs to translate but doesn't; e.g. when Init.sh writes $GISDBASE into $GISRC, it doesn't get translated).

[hamish]

fortunately

r.mapcalc "sum / count"

doesn't get expanded, only when : or nothing precedes the /. perhaps there are other string combinations that trigger it off.

hmm, I wonder about "( a ? b : c ) / d" style r.mapcalc expressions..?

... surely the MSys people would have added some enivro variable which would let you temporarily turn this behaviour off ... (one would hope)

Hamish

[glynn]

Replying to hamish:

fortunately

r.mapcalc "sum / count"

doesn't get expanded

That's because "sum / count" (which is a single "word" because of the quotes) doesn't "look like" a filename. If you omit the quotes (which should work in 6.x, not in 7.0):

~ $ args r.mapcalc sum / count
argv[ 0] = 'C:\msys\1.0\local\bin\args.exe'
argv[ 1] = 'r.mapcalc'
argv[ 2] = 'sum'
argv[ 3] = 'C:/msys/1.0'
argv[ 4] = 'count'
~ $

[hamish]

Hi,

m.proj is another one that fails.. wingrass 6.5svn daily build from the last day or two, Windows XP Pro from MSys's rxvt, in the spearfish dataset:

GRASS 6.5> export PROJ_DEBUG=5

GRASS 6.5> echo "-103.75|44.5" | m.proj -i
input parameters=[+proj=longlat +datum=WGS84]
output parameters=[ '+proj=utm' '+zone=13' '+a=6378206.4' '+rf=294.9786982'
'+no_defs' '+nadgrids=c;C:\PROGRA~1\GRASS-~1\msys\Program
Files\GRASS-65-SVN\etc\nad\conus' '+to_meter=1.0']
*       * 0.00
pj_open_lib(proj_def.dat): call fopen(C:\Program Files\GRASS-65-SVN\proj\proj_def.dat) - succeeded

pj_open_lib(c;C:\PROGRA~1\GRASS-~1\msys\Program Files\GRASS-65-SVN\etc\nad\conus):
  call fopen(C:\Program Files\GRASS-65-SVN\proj\c;C:\PROGRA~1\GRASS-~1\msys\Program Files\GRASS-65-SVN\etc\nad\conus) - failed

Rel. 4.7.1, 23 September 2009
<cs2cs.exe>: while processing file: <stdin>, line 1
pj_transform(): Unknown error

this time it's the path name that's getting munched, or otherwise mangled.

Hamish

[hamish]

GRASS 6.5> g.message "/"
C:/PROGRA~1/GRASS-~1/msys

still an issue from the msys bash prompt in latest nightly builds.