[GRASS-dev] Re: winGRASS

Michael Barton michael.barton at asu.edu
Mon Dec 18 10:28:03 EST 2006


Moritz


On 12/18/06 4:23 AM, "Moritz Lennert" <mlennert at club.worldonline.be> wrote:

> And some more issues:
> 
> - trying to create a new location from a georeferenced file or from an
> EPSG code, I get:
> 
> couldn't execute "c:\grass\grass-6.3.cvs\etc\grass-xterm-wrapper": no such
> file or directory
> couldn't execute "c:\grass\grass-6.3.cvs\etc\grass-xterm-wrapper": no such
> file or directory
>     while executing
> "exec -- $env(GISBASE)/etc/grass-xterm-wrapper -T g.proj -n g.proj -e
> $env(GISBASE)/etc/grass-run.sh g.proj -c georef=$filepath
> location=$fileLocation"
>     invoked from within
> ".fileloc.def invoke"
>     ("uplevel" body line 1)
>     invoked from within
> "uplevel #0 [list $w invoke]"
>     (procedure "tk::ButtonUp" line 24)
>     invoked from within
> "tk::ButtonUp .fileloc.def"
>     (command bound to event)
> 
> I imagine that wingrass should'nt even call grass-xterm-wrapper since we
> don't have an xterm, or ?

What is going on here is a call to execute a bash script that is currently a
workaround to a g.proj requirement to have a preexisting and valid
GISDBASE/location/mapset/WIND suite before it will create a new location.

I think a change to g.proj is in process that would eliminate the need for
this script.

I've got a much better version of the EPSG module ready to go once this is
done. It will now let you search on any term and automatically returns the
EPSG code.

> 
> - creating a new location with parameters works, but with the following
> issues:
> 
>      - the mapset created at the end of the procedure is not a valid
> mapset as it does not contain all the necessary files
>      - when creating a lat-long location, it jumps immediately from the
> one-line description to the region extension, without letting me
> define the ellipsoid or other parameters. After the region
> definition, it creates the location, but emits a warning that the
> "projection information files were not created".
> 
> I'll keep trying whenever I have some time.

Good luck on this part. Glynn made a very rational suggestion awhile back.
Why not combine the various projection/ellipse file needed to create a new
location into a single, easily parsable file, with PROJ4-type projection
definitions. Then (with the planned update to g.proj) we could simply have a
GUI that lists projection parameters to be selected and sends the PROJ
string to g.proj.

Now that I've done a search engine for EPSG, the same thing could be done
for the other GRASS projection files. I'm not sure which of the many ascii
projection/ellipse files are actually needed or how they should be combined,
however. Anyone want to take this on?

Michael


__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton





More information about the grass-dev mailing list