[GRASS-dev] a proposal to rename "location"

[Helena Mitasova]

Michael,

we are all aware of this issue and I think that this should be part of the discussion 
of how to make the GRASS startup more friendly for newcomers.
Here is a summary of some ideas from the recent discussion on the list and in our lab:
https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup <https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup>

as you can see the proposals refer to a project (it was also called "project location"), 
but as we discussed it this week in our lab it can get complicated. CRS may be confusing 
to new users as well because there can be many different locations with the same CRS for
different projects.

Feel free to add summary of your ideas to the trac linked above,

Helena


> On Jun 1, 2018, at 6:51 PM, Michael Barton <Michael.Barton at asu.edu> wrote:
> 
> As one of the most venerable desktop GIS packages and perhaps THE most venerable still in existence, GRASS has some quirks that harken back to its origins long ago. Most are simply quirky. But the folder hierarchy called a “location” is very confusing in today’s GIS world. Originally, it did primarily refer to maps referencing a geographic location in the world. Although that meaning still exists in the ‘default region’, GRASS locations primarily refer to a coordinate reference system (CRS). In fact, while the CRS of a location cannot be changed (unless you manually alter some of the files in the directory, at the risk of making maps unuseable), the default region can be. So a location now refers to a fixed CRS and a changeable geographic extent.
>  
> Use of the anachronistic term “location” to refer to a CRS is a quirk that makes GRASS more confusing to initial users. I suggest we consider beginning to migrate the term “location” to “CRS”. The term “location” does not occur in a large number of module interfaces: those (like g.mapset) for changing to a new working directory on the fly, vector and raster reprojection modules, and maybe a couple of others. It occurs in the GUI at startup, in the location wizard of course, and in some tools for georeferencing.
>  
> We could initially maintain backward compatibility and increase understandability by simply referring to “location” as something like “location/CRS” where ever it shows up in the GUI, but leave module arguments alone. A next step would be to have modules that require “location=” as an argument accept either “location=” or “CRS=”. And maybe that is enough. We could keep “location” where it currently occurs in existing command modules and scripts as a legacy option. Likewise, we could keep it in current code, only changing during code rewrites. Any new modules that need to refer to this file hierarchy would use “CRS”.
>  
> Thoughts?
>  
> Michael
>  
> ______________________________
> C. Michael Barton 
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Head, Graduate Faculty in Complex Adaptive Systems Science
> Arizona State University
> Tempe, AZ  85287-2402
> USA
>  
> voice:    480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax:          480-965-7671(SHESC), 480-727-0709 (CSDC)
> www:      http://csdc.asu.edu, http://shesc.asu.edu
>                                 http://www.public.asu.edu/~cmbarton
>  
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
Associate director and faculty fellow at the Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmitaso at ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html <http://geospatial.ncsu.edu/osgeorel/publications.html>

"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.” 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180601/517ee4a2/attachment.html>