[GRASS-dev] Re: updates to grass startup

[Helena Mitasova]

Just a note regarding my experiences with testing various startup  
options
with the new data set.
It worked from the existing file smoothly, EPSG code did not work -  
but I think
that the recently submitted fixes from Maris should have fixed the  
problem (I will
update and test). The third option, leading to the old, text based  
interface
did not work for sp and ll but that was fixed too.

But the main reason I am writing is that when working with locations  
created
from the file or EPSG, the region is set to default 1,1,1 (as opposed  
to the
"old way" when you are required to set the default region for the new  
location).
This is OK if you are experienced user and you know that you have
to import something with option to expand the region to this file or  
to define
a meaningful  "starting region" using g.region, but it may be  
confusing for new users.
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. Normally I don't  
use the default
region, but in this case I was using many different regions as I was  
importing
different types of data and it would have been nice to have a region  
to get back to.

Maybe just modifying the message that you get when creating the region
from file or EPSG that you need to "restart grass and define your  
region using
g.region" would be helpful. 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.

It is great to see this long neglected part of GRASS moving forward

Helena


On Dec 13, 2006, at 3:45 PM, Maris Nartiss wrote:

> (en route form offlist conversation)
> Hi,
>
> Michael: As I understood, PROJSHARE is one of variable strings, that
> gets replaced by exact value by make process. It's done with sed in
> lib/init/Make file line 175. You can replace it by hand or run Make.
>
> Unfortunately till weekend i will have no time to digg deeply in code,
> but I THINK, that my changes in code SHOULD not affect location/mapset
> ordering, as I only added crash preventing code.
>
> About that georeferenced file problem - it's a "chicken and egg" type
> problem. Currently to create new location from georeferenced file,
> user needs valid location to run "g.proj -c georef=". If user has no
> existing locations and only georeferenced file, user can't* create new
> (first) location from that file, as he needs location to create
> location from georeferenced file, what needs valid location to create
> location from georeferenced file and so on in endless loop ;)
> I took short look in to "make_location_epsg.sh.in". It could be easely
> converted to similar "make_location_georef.sh.it". But problem how to
> notify user about failed process still remains (hint - there is some
> code, that catches g.* error in gis.m mapcanvas.tcl).
>
> * User still can create new (first) location in other ways - by EPSG
> code or proj values.
>
> IMHO for current code there is no use in including copy of proj epsg
> file in GRASS. IF code is changed in such way, that allows search and
> select in those epsg codes, then there could be some benefit from
> keeping an fallback epsg code file inside GRASS (like, if
> --with-proj-share-dir is not set, then use internal version).
>
> Just my 0.02 cents,
> Maris.
>
> PS. I'm happy to see, that few lines of code can triger such HUGE
> activity from others ;)
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev