Opened 9 years ago

Last modified 4 years ago

#1166 new defect

r.tileset: projection string munching on wingrass

Reported by: hamish Owned by: grass-dev@…
Priority: major Milestone: 6.4.6
Component: Packaging Version: svn-develbranch6
Keywords: r.tileset, wingrass, msys Cc:
CPU: x86-64 Platform: MSWindows XP

Description

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

Change History (13)

comment:1 Changed 9 years ago by 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

comment:2 Changed 9 years ago by 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

comment:3 Changed 9 years ago by hamish

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

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

comment:4 in reply to:  description ; Changed 9 years ago by 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

comment:5 in reply to:  4 ; Changed 9 years ago by 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

comment:6 in reply to:  5 Changed 9 years ago by 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

comment:7 in reply to:  3 Changed 9 years ago by 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).

comment:8 Changed 9 years ago by 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

comment:9 in reply to:  8 Changed 9 years ago by 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'
~ $

comment:10 Changed 9 years ago by 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

comment:11 Changed 8 years ago by hamish

Keywords: msys added
Milestone: 6.4.16.4.3
Priority: normalmajor

comment:12 Changed 7 years ago by hamish

Component: DefaultPackaging
Milestone: 6.4.36.4.4
GRASS 6.5> g.message "/"
C:/PROGRA~1/GRASS-~1/msys

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

comment:13 Changed 4 years ago by neteler

Milestone: 6.4.46.4.6
Note: See TracTickets for help on using tickets.