[GRASS-dev] Re: projshare not set

[Hamish]

Michael wrote:
> There is a mistake in the epsg code that is looking for the directory
> ³PROJSHARE² instead of doing a variable substitutions $PROJSHARE or
> $env(PROJSHARE). I fixed this, but it looks like I have no PROJSHARE
> variable set on my system. Nor can I find a place in init.sh to set
> it. I can recompile GRASS, but there ought to be someplace to set this
> without recompiling. 
> 
> Is this an oversight?

No, the file is "epsg_option.tcl.in" (note the ".in"). During 'make'
that is processed into epsg_option.tcl with PROJSHARE replaced with
whatever --with-proj-share ended up as (defaults to /usr/local/share/proj/
I think).

So it's not a Tcl or shell variable; by the time grass is installed the
value is hardcoded. Have a look in $GISBASE/etc/epsg_option.tcl to
see the processed version.

epsg_option.tcl takes this default version, or if you've changed it in
the "Path to the EPSG-codes file", whatever $browsedepsg is set to.


Paul:
> It isn't used for anything other than browsing and while including it
> in GRASS is definitely preferable to having to look for it wherever it
> was installed with PROJ, my preference would be to remove it
> altogether and instead in some way generate the lists from the .csv
> files in lib/proj that are actually used by g.proj to generate the
> location. Not sure how to do that but I think it's very confusing the
> way the file used for browsing is different from and potentially out
> of sync with the file used in the location generation.

I agree. The file is an anomaly and would be misleading if out of sync.
It's better to parse lib/proj/pcs.csv and friends directly as a basis
for a projection picking applet. Perhaps we should include the EPSG
file used to create the .csv files in lib/proj/ with the derivative
.csv files? -> We need to draw from one pool.

Could the work Glynn did last month WTR outputting supported datums
help?

Michael:
> configure should generate an error if the relevant proj directory is
> not found.

it does, but it is non-fatal.

Helena:
> And what I found very inconvenient was the fact already mentioned some
> time ago, that you are stuck with 1,1,1 default region unless you edit
> the file manually as there is no tool to modify the default region. 

Add a new flag to g.region which would "Set default region based on
current settings" with a if(strcmp(G_mapset(), "PERMANENT")) G_f_error();
test?

> Of course, automatically importing the file and setting region to its
> extent would be the best solution for the "new location from file"
> option, becuase then the user has a new location and can display the
> map right away.

Yes, if the location is created with a *.proj module, set DEFAULT_WIND
to the input map's extent. Good idea.

> Normally I don't use the default region,

it is used whenever you create a new mapset, so any badness propagates.



Hamish