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