[GRASS-dev] G.proj requirements?

[Paul Kelly]

Hello Michael
I've re-organised g.proj a bit so it doesn't read the region and 
projection from the current location unless it has to. But the problem 
remains, in three places:
(a) G_gisint()
(b) G_tempfile()
(c) G__put_window()/G__fopen_new()

(a) All modules have to call G_gisinit() at the start, and among other 
things it checks for a valid current location and mapset. However the case 
we're discussing is a rare example of where that isn't needed. Most of the 
rest of what G_gisinit() does (from a quick skimming over the code) seems 
related to raster modules and might possibly be possibly avoided?

(b) If the call to G_gisinit() is simply commented out, the next problem 
is G_tempfile() [deep within GRASS gproj library] which tries to create a 
tempfile in the current mapset as far as I remember - is this a good/bad 
idea? Certainly bad if you don't have a current mapset.

(c) Hard-coding the tempfile path in lib/proj/datum.c instead of calling 
G_tempfile() gets as far as writing out the new WIND and DEFAULT_WIND. 
This is done by a call to G__put_window() in G__make_location().

G__fopen_new(), which is called by G__put_window(), makes a call to 
G__check_gisinit() which fails [because we haven't called G_gisinit()]. In 
many cases (particularly when working with elements of a raster map) I'm 
sure it is a very good idea to check at this stage whether G_gisinit() has 
been called because of the rastery stuff it does but here it really 
doesn't seem to be necessary and if I comment it out (in the library 
function), then g.proj completes successfully and creates the new 
location.

This would need quite a bit of re-engineering to fix in an elegant way, 
definitely worth thinking about though IMHO. For now, looks like a 
complicated workaround is required. :(

The default region is still an issue also, as Helena said. I know I should 
copy some code from r.in.gdal and v.in.ogr to g.proj to handle this as far 
as possible (i.e. match the default region in the new location to the 
georeferenced file - better than doing nothing). When there's some more 
time can maybe do that. And it will still be a problem with creating from 
EPSG code as the user is not forced or even reminded to set the region.

In case I forget, another tempfile issue is that g.tempfile (used in 
scripts) returns a tempfile with a Windows pathname which will then have 
problems in Msys.

Paul

On Sat, 16 Dec 2006, Michael Barton wrote:

> Paul,
>
> I've run some tests and understand what g.proj is doing and I understand
> why. Here are a few of the test results. I started GRASS without a .grassrc6
> file and tried to create a new location, using a georeferenced file. I
> modified the GISRC file in several ways prior to invoking the georeferenced
> file to define a new location. As I noted before, GRASS always makes a
> default GISRC file. If there is no pre-existing .grassrc6 file, the GISRC
> file sets GISDBASE to the current working directory, and both LOCATION_NAME
> and MAPSET to <UNKNOWN>.
>
> Test 1: started with no .grassrc6 file; no other modification
>
> =================================================================
> If you wish to resize the X monitor, do so now. Window size is
> locked while interactive modules are running.
> =================================================================
>
> access: No such file or directory
> ERROR: LOCATION << /Users/cmbarton/<UNKNOWN> >> not available
>
> ERROR: g.proj exited abnormally. Press <enter> to continue.
>
> ************************************************************
>
> Test 2: started with no .grassrc6 file; modified /tmp/.../GISRC file to
> change
>
> LOCATION_NAME: <UNKNOWN>
>
> to
>
> LOCATION_NAME: testloc
>
> =================================================================
> If you wish to resize the X monitor, do so now. Window size is
> locked while interactive modules are running.
> =================================================================
>
> access: No such file or directory
> ERROR: LOCATION << /Users/cmbarton/testloc >> not available
>
> ERROR: g.proj exited abnormally. Press <enter> to continue.
>
> ************************************************************
>
> Test 3: started with no .grassrc6 file; modified /tmp/.../GISRC file to name
> a location and mapset directory (testloc and PERMANENT); created
> $HOME/testloc/PERMANENT but did not put anything in directory
>
>
> =================================================================
> If you wish to resize the X monitor, do so now. Window size is
> locked while interactive modules are running.
> =================================================================
>
> ERROR: default region is not set
>
> ERROR: g.proj exited abnormally. Press <enter> to continue.
>
>
> So, it is clear that g.proj looks at the GISRC file, then verifies the
> existence of the location and mapset specified in the file, then looks for
> the WIND file inside the PERMANENT mapset of the specified location.
>
> This makes a lot of sense for most of g.proj functionality, specifically
> reporting the current projection information in various formats and
> modifying the projection information of the current location.
>
> However, it is problematic for creating a new location--that is, with the -c
> flag and a new location specified in the location=[new loc name] argument.
>
> There are ways to get around this currently, but it would be much better if
> the checks for a valid location, mapset, and WIND file were bypassed for
> using g.proj to create a new location. The only thing it needs to know to do
> this is a valid GISDBASE, and this is always specified in a GISRC file. So
> what are the chances of modifying g.proj in this way instead of requiring
> the startup scripts to make some fake locations and WIND files to satify
> g.proj?
>
> To start from scratch with something other than the current working
> directory, we'd need to replace this temporary GISRC file with whatever
> directory is specified in the GUI startup, but this isn't too difficult.
>
> Markus has produced a workaround in a bash script that is necessary because
> of the way g.proj functions. It makes and erases temporary location, mapset,
> and WIND files, and archives, replaces, and restores the .grassrc6
> file--regardless of whether or not you have a valid location already in
> existence. This worries me a bit as it makes more opportunities for
> corruption in the .grassrc6 file or GISDBASE path if something goes wrong in
> the process.
>
>
>
> Michael
>
>