wingrass: cs2cs fails from the msys command line

[hamish]

Hi,

while testing r.in.wms in 6.5svn in WinGrass I'm finding that a simple cs2cs call fails on the Msys command line. (actually happens in r.tileset)

perhaps it's not finding the "/usr/share/proj/" support files (however that's registered in the Windows build), although cs2cs -ld et al. seem to work ok.

GRASS 6.5> cs2cs +proj=longlat +to +proj=longlat
Using from definition: proj=longlat
Rel. 4.7.1, 23 September 2009
<cs2cs.exe>: 
projection initialization failure
cause: Unknown error
program abnormally terminated

GRASS 6.5> echo $?
3

the above should result in a blank line awaiting coord input.

?

thanks, Hamish

[hellik]

Replying to hamish:

the above should result in a blank line awaiting coord input.

I've tested this in the WinGrass64-release-installer, there is a blank line awaiting coord input.

Helmut

[hamish]

Even after applying Helmut's GDAL_DATA path fix (r43520) to the destination files by hand, this still fails for me in 6.5svn on XP in the same way, both Msys (etc/Init.sh) and DOS-box (grass65svn.bat).

I don't think it will help here, but should that "set GDAL_DATA=" also be added to mswindows/osgeo4w/ini.bat.tmpl as well?

thanks, Hamish

[hellik]

Replying to hamish:

Even after applying Helmut's GDAL_DATA path fix (r43520) to the destination files by hand, this still fails for me in 6.5svn on XP in the same way, both Msys (etc/Init.sh) and DOS-box (grass65svn.bat).

I don't think it will help here, but should that "set GDAL_DATA=" also be added to mswindows/osgeo4w/ini.bat.tmpl as well?

thanks, Hamish

Hi Hamish,

I think the GDAL_DATA variable is needed for the gdal stuff.

I've studied a little bit the proj4- and cs2cs-manpages and faq:

​http://trac.osgeo.org/proj/wiki/man_cs2cs ​http://trac.osgeo.org/proj/wiki/man_proj

from there I've found:

[...]
The   environment   parameter
       PROJ_LIB establishes the default directory for a
       file reference without an absolute  path.   This
       is  also  used  for  supporting files like datum
       shift files.
[...]

​http://trac.osgeo.org/proj/wiki/FAQ#HowdoIbuildconfigurePROJ.4tosupportdatumshifting

[...]
A default build and install on Unix will normally build knowledge of the directory where the grid shift files are installed into the PROJ.4 library (usually /usr/local/share/proj). On Windows the library is normally built thinking that C:\PROJ\NAD is the installed directory for the grid shift files. If the built in concept of the PROJ.4 data directory is incorrect, the PROJ_LIB environment can be defined with the correct directory.
[...] 

so if I'm correct there are following variables that have to be set in windows:

GRASS_PROJSHARE => needed by grass GDAL_DATA => needed by the gdal-stuff PROJ_LIB => needed by the proj4/cs2cs-stuff

best regards Helmut

[hellik]

Replying to hamish:

Even after applying Helmut's GDAL_DATA path fix (r43520) to the destination files by hand, this still fails for me in 6.5svn on XP in the same way, both Msys (etc/Init.sh) and DOS-box (grass65svn.bat).

I don't think it will help here, but should that "set GDAL_DATA=" also be added to mswindows/osgeo4w/ini.bat.tmpl as well?

thanks, Hamish

try r43542 in the next nightly WinGrass65-build.

best regards Helmut

[hellik]

Replying to hellik:

Replying to hamish:

Even after applying Helmut's GDAL_DATA path fix (r43520) to the destination files by hand, this still fails for me in 6.5svn on XP in the same way, both Msys (etc/Init.sh) and DOS-box (grass65svn.bat).

I don't think it will help here, but should that "set GDAL_DATA=" also be added to mswindows/osgeo4w/ini.bat.tmpl as well?

thanks, Hamish

try r43542 in the next nightly WinGrass65-build.

best regards Helmut

AFAICT this fix above should help.

but there seems a very interesting issue with osgeo-msys-commandline.

I've tried following in the osgeo4w-stack and examples from ​http://trac.osgeo.org/proj/wiki/GenParms, but not in the modified WinGrass65-install.

(1) open OSGeo4W Shell (which is a windows-command-line with all osgeo4w-utilities):

C:\>echo %PROJ_LIB%
C:\OSGeo4W\share\proj

C:\>cs2cs +proj=latlong +datum=WGS84 +to +proj=latlong +datum=WGS84 +pm=madrid
0 0
3d41'16.58"E    0dN 0.000
{{{

all works fine, but

(2) open osgeo4w-msys-shell

}}}
syringia@NADA ~
$ echo $PROJ_LIB
C:\OSGeo4W\share\proj

syringia@NADA ~
$ cs2cs +proj=latlong +datum=WGS84 +to +proj=latlong +datum=WGS84 +pm=madrid
0 0

nothing happens, no computations of the new coordinates, a blank line is waiting (I've waited about 10 minutes, but nothing happend)

so maybe there are underlying problems of proj4/cs2cs in an (osgeo4w-inherited) msys-environment?

best regards Helmut

[hellik]

this should be edited as: (1) open OSGeo4W Shell (which is a windows-command-line with all osgeo4w-utilities):

C:\>echo %PROJ_LIB%
C:\OSGeo4W\share\proj

C:\>cs2cs +proj=latlong +datum=WGS84 +to +proj=latlong +datum=WGS84 +pm=madrid
> 0 0
3d41'16.58"E    0dN 0.000

all works fine, but (2) open osgeo4w-msys-shell

syringia@NADA ~
>$ echo $PROJ_LIB
C:\OSGeo4W\share\proj

syringia@NADA ~
> $ cs2cs +proj=latlong +datum=WGS84 +to +proj=latlong +datum=WGS84 +pm=madrid
0 0

nothing happens, no computations of the new coordinates, a blank line is waiting (I've waited about 10 minutes, but nothing happend)

so maybe there are underlying problems of proj4/cs2cs in an (osgeo4w-inherited) msys-environment?

Helmut

[hellik]

Replying to hellik:

this should be edited as: (1) open OSGeo4W Shell (which is a windows-command-line with all osgeo4w-utilities):

C:\>echo %PROJ_LIB%
C:\OSGeo4W\share\proj

C:\>cs2cs +proj=latlong +datum=WGS84 +to +proj=latlong +datum=WGS84 +pm=madrid
> 0 0
3d41'16.58"E    0dN 0.000

all works fine, but (2) open osgeo4w-msys-shell

syringia@NADA ~
>$ echo $PROJ_LIB
C:\OSGeo4W\share\proj

syringia@NADA ~
> $ cs2cs +proj=latlong +datum=WGS84 +to +proj=latlong +datum=WGS84 +pm=madrid
0 0

nothing happens, no computations of the new coordinates, a blank line is waiting (I've waited about 10 minutes, but nothing happend)

so maybe there are underlying problems of proj4/cs2cs in an (osgeo4w-inherited) msys-environment?

Helmut

AFAICT this issue above is inherited by WinGrass-installer

(1) trying above example in a patched WinGrass65-installer in GRASS 6.5.SVN with MSYS, that means in the delivered msys-command-line, nothing happens with cs2cs

(2) the patched WinGrass65 started in text-mode (in a windows-command-line), the cs2cs-example works like a charm.

so maybe a strong argument to leave msys behind in WinGrass64/65 and deliver a shell-environment in a windows-commandline, as actuall WinGrass70 does?

best regards Helmut

[hamish]

Hi,

yes, setting PROJ_LIB in the startup scripts helps get cs2cs running. I get stuck in stdin-land when running from the MSys-rxvt window just like you, but 'echo "10 10" | cs2cs' style works ok, so scripts should be ok as well and that only an annoyance. (I would say these things confirm our move away from msys's rxvt, but are not so strong to force us to take drastic action to abandon it for 6.x just yet)

From the DOS box do you have to do F6, ^{Z or so to break out of cs2cs? (I didn't test that yet)}

I assume your GDAL_DATA fix is good as well for end-user systems without C:\OSGeo4W existing, but I haven't tested.

FWIW, there is also $GISBASE/etc/nad/, but I think we need the full set of PROJ_LIB files that were present with it when proj4 was built. The duplication shouldn't be more than a few megabytes.

thanks for the detective work, Hamish

[hellik]

Replying to hamish:

From the DOS box do you have to do F6, ^{Z or so to break out of cs2cs? (I didn't test that yet)}

yes.

Helmut

[hamish]

merged r43520 and r43542 from devbr6 into relbr64 and trunk with r43602 and r43603.

thanks, Hamish

[hamish]

I don't consider cs2cs in msys not releasing stdin to be a major bug, or at least one we can do much about, so closing the report as the main problem is now solved and committed.

thanks

[glynn]

Replying to hellik:

this should be edited as: (1) open OSGeo4W Shell (which is a windows-command-line with all osgeo4w-utilities):

C:\>cs2cs +proj=latlong +datum=WGS84 +to +proj=latlong +datum=WGS84 +pm=madrid
> 0 0
3d41'16.58"E    0dN 0.000

all works fine, but (2) open osgeo4w-msys-shell

syringia@NADA ~
> $ cs2cs +proj=latlong +datum=WGS84 +to +proj=latlong +datum=WGS84 +pm=madrid
0 0

nothing happens, no computations of the new coordinates, a blank line is waiting (I've waited about 10 minutes, but nothing happend)

so maybe there are underlying problems of proj4/cs2cs in an (osgeo4w-inherited) msys-environment?

This is really a problem with the Windows rxvt port (the "MSys terminal"). According to MSVCRT's isatty() function, a Windows console is a tty, while rxvt isn't. stdin and stdout are line-buffered if it is associated with a tty and fully-buffered otherwise. As rxvt isn't a tty, stdout is fully-buffered, so you won't see any output from cs2cs until it either writes a buffer's-worth of data or it terminates (i.e. when you press Ctrl-D).

The solution is not to use rxvt. The MSys project has basically disowned it because of issues like this. Just run sh.exe in a Windows console. FWIW, my "MSys" icon runs a batch file which sets PATH then executes:

start C:\msys\1.0\bin\sh.exe --login -i

Apart from the issue with rxvt not being a tty, it doesn't with the pdcurses implementation which WinGRASS should be using. Unix curses libraries are designed for traditional ttys, where cursor positioning, colours, etc are selected using escape sequences, which don't work with the Windows console. pdcurses uses the Windows console API (​WriteConsoleOutput etc), and won't work with rxvt.

Oh; and rxvt is rather prone to crashing if you try to paste into it.