[GRASS-dev] [grass-code R][428] Warn about wrong epsg code when creating a location in grass 6.2

code R item #428, was opened at 2007-06-16 18:39
Status: Open
Priority: 3
Submitted By: Daniel Victoria (dvictori)
Assigned to: Nobody (None)
Summary: Warn about wrong epsg code when creating a location in grass 6.2
Issue status: None
GRASS component: startup
Operating system: None
Operating system version: Linux

Initial Comment:
When creating a location based on a georeferenced files, if the EPSG code is wrong there is no clear warning and no location gets created. This feature is already present in 6.3. Could it be backported?

Also, if a wrong EPSG code is input a tmp directory sometimes is created
thanks
Daniel

----------------------------------------------------------------------

You can respond by visiting:
http://wald.intevation.org/tracker/?func=detail&atid=188&aid=428&group_id=21

http://wald.intevation.org/tracker/?func=detail&atid=188&aid=428&group_id=21

code R item #428, was opened at 2007-06-16 18:39
Submitted By: Daniel Victoria (dvictori)
Summary: Warn about wrong epsg code when creating a location in grass
6.2
GRASS component: startup

..

When creating a location based on a georeferenced files, if the EPSG
code is wrong there is no clear warning and no location gets created.

in 6.2 lib/init/epsg_option.tcl.in calls this:

exec -- $env(GISBASE)/etc/grass-xterm-wrapper -e \
   $env(GISBASE)/etc/make_location_epsg.sh \
   $epsg_code $epsgLocation $locpath >@stdout 2>@stderr;

make_location_epsg.sh.in then checks if "g.proj -c" worked, and exits
with an error if it didn't, but the xterm closes as soon as the script
is done so you don't see the error message and epsg_option.tcl doesn't
check the return code to make its own error message.

One option is to be like grass-run.sh and do something like:

if [ $EXIT_VAL -ne 0 ] ; then
   echo
   echo "ERROR: $1 exited abnormally. Press <enter> to continue."
   read
fi

but make_location_epsg.sh is not just used by the startup GUI, so
making it interactive might be bad. A compromise might be to do that,
but give the `read` a timeout:

read -t 10 -n 1 -p "Press any key to continue ... (or wait 10 seconds)"

but AFAIK -t and -n are not portable. maybe

echo "ERROR: ..."
sleep 5
? :-/

We could catch the "exec grass-xterm-wrapper" in epsg_option.tcl.in and
check the exit code (I've no idea how to do that correctly). That
doesn't help show what the g.proj error was though, just that
make_location_epsg.sh.in failed.

This feature is already present in 6.3. Could it be backported?

No, in 6.3 it is totally different, a Tcl script makes the location.
But maybe we can find another solution.

Also, if a wrong EPSG code is input a tmp directory sometimes is
created

6.2's lib/init/make_location_epsg.sh.in goes:
[...]
# create new location:
g.proj -c proj4='+init=epsg:'$EPSG location=$LOCATION

if [ $? -eq 1 ] ; then
  echo "An error occured. Stop."
  exit 1
fi

#restore previous .$GRASSRC
if test -f "$GISDBASE"/"$TEMPDIR"/$GRASSRC ; then
   mv "$GISDBASE"/"$TEMPDIR"/$GRASSRC "$HOME"/.$GRASSRC
fi

#cleanup:
rm -rf $GISDBASE/$TEMPDIR
[...]

so cleanup isn't done if "g.proj -c" had an error.

Hamish

AFAICT, there is no way for the GUI to know if an EPSG code is bad. Perhaps
g.proj can test for this, but I wouldn't count on it.

The procedure to create a location from a georeferenced file is different
from the procedure to create it from an EPSG code, so I'm not sure what you
are referring to below.

Michael

On 6/16/07 2:39 PM, "grass-coder@wald.intevation.org"
<grass-coder@wald.intevation.org> wrote:

code R item #428, was opened at 2007-06-16 18:39
Status: Open
Priority: 3
Submitted By: Daniel Victoria (dvictori)
Assigned to: Nobody (None)
Summary: Warn about wrong epsg code when creating a location in grass 6.2
Issue status: None
GRASS component: startup
Operating system: None
Operating system version: Linux

Initial Comment:
When creating a location based on a georeferenced files, if the EPSG code is
wrong there is no clear warning and no location gets created. This feature is
already present in 6.3. Could it be backported?

Also, if a wrong EPSG code is input a tmp directory sometimes is created
thanks
Daniel

----------------------------------------------------------------------

You can respond by visiting:
Wald: Exiting with error

__________________________________________
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

Michael Barton wrote:

AFAICT, there is no way for the GUI to know if an EPSG code is bad. Perhaps
g.proj can test for this, but I wouldn't count on it.

GDAL's epsg_tr.py can do it:

$ epsg_tr.py 1333

ERROR 6: EPSG PCS/GCS code 1333 not found in EPSG support files. Is
this a valid
EPSG coordinate system?
Unable to lookup 1333 , either not a valid EPSG
code, or it the EPSG csv files are not accessable.

The procedure to create a location from a georeferenced file is different
from the procedure to create it from an EPSG code,

But doesn't it depend on extracting the EPSG code from a georeferenced
file? So if the extracted code was invalid (ie. the file's georeference
info was corrupted) it could react same as for an invalid EPSG code
entered?

Maciek

On 6/25/07 10:16 AM, "Maciej Sieczka" <tutey@o2.pl> wrote:

Michael Barton wrote:

AFAICT, there is no way for the GUI to know if an EPSG code is bad. Perhaps
g.proj can test for this, but I wouldn't count on it.

GDAL's epsg_tr.py can do it:

$ epsg_tr.py 1333

ERROR 6: EPSG PCS/GCS code 1333 not found in EPSG support files. Is
this a valid
EPSG coordinate system?
Unable to lookup 1333 , either not a valid EPSG
code, or it the EPSG csv files are not accessable.

The question then is how (or if) we can trap and display such an error. I'd
rather it fail gracefully (i.e., simply not create a location and keep
running) than to crash, but an informative message to the user is even
better.

The procedure to create a location from a georeferenced file is different
from the procedure to create it from an EPSG code,

But doesn't it depend on extracting the EPSG code from a georeferenced
file? So if the extracted code was invalid (ie. the file's georeference
info was corrupted) it could react same as for an invalid EPSG code
entered?

I guess I don't know. If so, I didn't realize this. This would explain the
email (and my confusion).

Michael

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

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