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

[Vaclav Petras]

I had an interesting relevant experience trying the current GitLab
interface: When logged in, I clicked the + button to create a new
repository. Well, I found New project, New group, and New snipped. I was
quite sure I don't want snipped and group, but for couple seconds I was not
convinced I want a project. My thinking was: "I don't want to start a new
project, I just want to put my files in a repo." So, there is the confusion
about what project means.

The word project at the end makes a lot of sense for GitLab context
(project is repo, issues and more), but it seems that project for GRASS
users can be anything: database ("grassdata"), location, or mapset and
partially also workspace which has the same position in GUI as projects in
many other software packages.

As a reminder, this should be considered in the context of redesign of the
new startup which focuses on how the concepts and functions are delivered
to the user rather than terminology (but terminology is naturally part of
it):

https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup



On Sun, Jun 17, 2018 at 4:38 AM, Pierre Roudier 
wrote:

> My two cents' worth: it is indeed an issue for beginners, and would be
> great to see new term for it, but I would stay away from using
> acronyms.
>
> P
>
> On 16 June 2018 at 23:28, Huidae Cho  wrote:
> > Dear All,
> >
> > I agree that this terminology needs to be changed. "Project" seems to
> > simplify this issue too much because one project doesn't always involve
> with
> > only one SRS. My database folder looks like this:
> >
> > aea@
> > epsg102681/
> > srorg7873/
> > utm52n@
> > xy/
> >
> > I try to be consistent in naming Locations and follow EPSG or SR-ORG
> names.
> > Symbolic links (*@) are just for me to remember "common" projection
> names.
> > Inside these Locations, project folders reside. In this sense, Mapset
> serves
> > as a project folder and there can be multiple Mapsets in different
> Locations
> > for one project. One issue with this approach is you have to actively
> look
> > into all Locations to find project-related Mapsets unless you remember
> which
> > SRSs you used for the project. Probably, combination of project and SRS
> > names?
> >
> > Maybe, it would be better to create a project "Database" and put all
> > project-related data (different SRSs, currently Locations, and possibly
> > different users, Mapsets) in that one Database, but I never had more than
> > one Database before. I can already see an issue with this approach. No
> > global data for all projects to share.
> >
> > I think the challenge here is how to organize data for one project in
> > different SRSs in a more intuitive and efficient way.
> >
> > Just my 2 cents.
> > Huidae
> >
> >
> > On Sun, Jun 3, 2018 at 8:09 AM, Nikos Alexandris <
> n...@nikosalexandris.net>
> > wrote:
> >>
> >> * Vaclav Petras  [2018-06-02 11:14:57 -0400]:
> >>
> >>
> >>> On Fri, Jun 1, 2018 at 6:51 PM, Michael Barton  >
> >>> 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 agree that the current situation is not satisfactory and I think your
> >>> description of the situation is very good. The "project location" or
> just
> >>> "project" or even "coordinate system" were all terms which were used in
> >>> the
> >>> 6.4 startup/welcome window:
> >>>
> >>>
> >>> https://trac.osgeo.org/grass/attachment/wiki/
> wxGUIDevelopment/New_Startup/
> >>> startup_grass_6.4_wxpython.png
> >>>
> >>> I though it will be much better in order to avoid confusion to go with
> >>> just
> >>> one term and properly explain it. Without changing anything, I of
> course
> >>> needed to go with location in the new startup window and documentation:
> >>>
> >>>
> >>> https://trac.osgeo.org/grass/attachment/wiki/
> wxGUIDevelopment/New_Startup/
> >>> startup_grass_7.5.png
> >>> https://grass.osgeo.org/grass74/manuals/grass_database.html
> >>>
> >>> However, I think it is still quite hard for users to understand and it
> >>> becomes difficult to 

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

[Pierre Roudier]

My two cents' worth: it is indeed an issue for beginners, and would be
great to see new term for it, but I would stay away from using
acronyms.

P

On 16 June 2018 at 23:28, Huidae Cho  wrote:
> Dear All,
>
> I agree that this terminology needs to be changed. "Project" seems to
> simplify this issue too much because one project doesn't always involve with
> only one SRS. My database folder looks like this:
>
> aea@
> epsg102681/
> srorg7873/
> utm52n@
> xy/
>
> I try to be consistent in naming Locations and follow EPSG or SR-ORG names.
> Symbolic links (*@) are just for me to remember "common" projection names.
> Inside these Locations, project folders reside. In this sense, Mapset serves
> as a project folder and there can be multiple Mapsets in different Locations
> for one project. One issue with this approach is you have to actively look
> into all Locations to find project-related Mapsets unless you remember which
> SRSs you used for the project. Probably, combination of project and SRS
> names?
>
> Maybe, it would be better to create a project "Database" and put all
> project-related data (different SRSs, currently Locations, and possibly
> different users, Mapsets) in that one Database, but I never had more than
> one Database before. I can already see an issue with this approach. No
> global data for all projects to share.
>
> I think the challenge here is how to organize data for one project in
> different SRSs in a more intuitive and efficient way.
>
> Just my 2 cents.
> Huidae
>
>
> On Sun, Jun 3, 2018 at 8:09 AM, Nikos Alexandris 
> wrote:
>>
>> * Vaclav Petras  [2018-06-02 11:14:57 -0400]:
>>
>>
>>> On Fri, Jun 1, 2018 at 6:51 PM, Michael Barton 
>>> 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 agree that the current situation is not satisfactory and I think your
>>> description of the situation is very good. The "project location" or just
>>> "project" or even "coordinate system" were all terms which were used in
>>> the
>>> 6.4 startup/welcome window:
>>>
>>>
>>> https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/New_Startup/
>>> startup_grass_6.4_wxpython.png
>>>
>>> I though it will be much better in order to avoid confusion to go with
>>> just
>>> one term and properly explain it. Without changing anything, I of course
>>> needed to go with location in the new startup window and documentation:
>>>
>>>
>>> https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/New_Startup/
>>> startup_grass_7.5.png
>>> https://grass.osgeo.org/grass74/manuals/grass_database.html
>>>
>>> However, I think it is still quite hard for users to understand and it
>>> becomes difficult to talk about location because of the general meaning
>>> of
>>> that word. Possible solutions include better interface (e.g. the new
>>> startup), change in paradigm (in interface or also in core), and a
>>> different name.
>>>
>>> Generally, the new name should be considered together the related terms,
>>> such as [default] region, database, mapset, and [vector] map.
>>>
>>> I'm not in favor of "CRS" because a CRS is description of the reference
>>> system. It is a property of the data or a name of particular part of
>>> metadata. Location in GRASS GIS is a collection of spatial data with a
>>> common CRS.
>>>
>>> I've tried to use "Location" (with capital L) and "GRASS Location" to
>>> make
>>> it clear what location we are talking about, but it suffers from the same
>>> issues as simple "location". For example: Is GRASS location directory on
>>> your computer where you have GRASS GIS installation?
>>>
>>> Best,
>>> Vaclav
>>
>>
>> Dear Vaclav,
>>
>> When you start explaining the data base structure, in GRASS GIS, where
>> do you start? Excluding the Mapsets (plus the PERMANENT Mapset) concept,
>>
>> I start with:
>> "
>> Think of a big box. Inside it, you can keep all items related to
>> your (specific) project. Now, let use create this box, it's a directory
>> (or folder). What will be its name? Name it the way you think is best,
>> for your needs, so you 

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

[Huidae Cho]

Dear All,

I agree that this terminology needs to be changed. "Project" seems to
simplify this issue too much because one project doesn't always involve
with only one SRS. My database folder looks like this:

aea@
epsg102681/
srorg7873/
utm52n@
xy/

I try to be consistent in naming Locations and follow EPSG or SR-ORG names.
Symbolic links (*@) are just for me to remember "common" projection names.
Inside these Locations, project folders reside. In this sense, Mapset
serves as a project folder and there can be multiple Mapsets in different
Locations for one project. One issue with this approach is you have to
actively look into all Locations to find project-related Mapsets unless you
remember which SRSs you used for the project. Probably, combination of
project and SRS names?

Maybe, it would be better to create a project "Database" and put all
project-related data (different SRSs, currently Locations, and possibly
different users, Mapsets) in that one Database, but I never had more than
one Database before. I can already see an issue with this approach. No
global data for all projects to share.

I think the challenge here is how to organize data for one project in
different SRSs in a more intuitive and efficient way.

Just my 2 cents.
Huidae


On Sun, Jun 3, 2018 at 8:09 AM, Nikos Alexandris 
wrote:

> * Vaclav Petras  [2018-06-02 11:14:57 -0400]:
>
>
> On Fri, Jun 1, 2018 at 6:51 PM, Michael Barton 
>> 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 agree that the current situation is not satisfactory and I think your
>> description of the situation is very good. The "project location" or just
>> "project" or even "coordinate system" were all terms which were used in
>> the
>> 6.4 startup/welcome window:
>>
>> https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopmen
>> t/New_Startup/
>> startup_grass_6.4_wxpython.png
>>
>> I though it will be much better in order to avoid confusion to go with
>> just
>> one term and properly explain it. Without changing anything, I of course
>> needed to go with location in the new startup window and documentation:
>>
>> https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopmen
>> t/New_Startup/
>> startup_grass_7.5.png
>> https://grass.osgeo.org/grass74/manuals/grass_database.html
>>
>> However, I think it is still quite hard for users to understand and it
>> becomes difficult to talk about location because of the general meaning of
>> that word. Possible solutions include better interface (e.g. the new
>> startup), change in paradigm (in interface or also in core), and a
>> different name.
>>
>> Generally, the new name should be considered together the related terms,
>> such as [default] region, database, mapset, and [vector] map.
>>
>> I'm not in favor of "CRS" because a CRS is description of the reference
>> system. It is a property of the data or a name of particular part of
>> metadata. Location in GRASS GIS is a collection of spatial data with a
>> common CRS.
>>
>> I've tried to use "Location" (with capital L) and "GRASS Location" to make
>> it clear what location we are talking about, but it suffers from the same
>> issues as simple "location". For example: Is GRASS location directory on
>> your computer where you have GRASS GIS installation?
>>
>> Best,
>> Vaclav
>>
>
> Dear Vaclav,
>
> When you start explaining the data base structure, in GRASS GIS, where
> do you start? Excluding the Mapsets (plus the PERMANENT Mapset) concept,
>
> I start with:
> "
> Think of a big box. Inside it, you can keep all items related to
> your (specific) project. Now, let use create this box, it's a directory
> (or folder). What will be its name? Name it the way you think is best,
> for your needs, so you know that its content is for one project.
>
> Next, you can place inside this box every spatial and non-spatial data
> related to the project. Raster and vector maps, data bases (like
> sqlite) or CSV files. And more.
>
> This is a/the GRASS GIS data base. You will need to know the full path
> name to this data base, sometimes, as an option to 

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

[Michael Barton]

Thanks Vaclav,

There needs to be some consensus on how we want to refer to this feature of 
GRASS: CRS, SRS, Project, something else…   Then we can move toward changing 
the interface text accordingly. I’ll check out the WIKI too.

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

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

From: Vaclav Petras 
Date: Saturday, June 2, 2018 at 8:15 AM
To: Michael Barton 
Cc: GRASS developers list 
Subject: Re: [GRASS-dev] a proposal to rename "location"



On Fri, Jun 1, 2018 at 6:51 PM, Michael Barton 
mailto:michael.bar...@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 agree that the current situation is not satisfactory and I think your 
description of the situation is very good. The "project location" or just 
"project" or even "coordinate system" were all terms which were used in the 6.4 
startup/welcome window:

https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/New_Startup/startup_grass_6.4_wxpython.png<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_attachment_wiki_wxGUIDevelopment_New-5FStartup_startup-5Fgrass-5F6.4-5Fwxpython.png=DwMFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=PSCKM1nOhoYWUHeLIZjbS3zeLVloaWYxm8piZtfaDXs=1fR0TEY_D6PoiI3Ai_qBAzJ4QNkbq9jR42xqjMlMgAY=>

I though it will be much better in order to avoid confusion to go with just one 
term and properly explain it. Without changing anything, I of course needed to 
go with location in the new startup window and documentation:

https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/New_Startup/startup_grass_7.5.png<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_attachment_wiki_wxGUIDevelopment_New-5FStartup_startup-5Fgrass-5F7.5.png=DwMFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=PSCKM1nOhoYWUHeLIZjbS3zeLVloaWYxm8piZtfaDXs=iMmYM2DD9zmSBSzSgZdQFI-MWeWn2Y_pM1S-uVYONyM=>
https://grass.osgeo.org/grass74/manuals/grass_database.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__grass.osgeo.org_grass74_manuals_grass-5Fdatabase.html=DwMFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=PSCKM1nOhoYWUHeLIZjbS3zeLVloaWYxm8piZtfaDXs=i1i0rqBzMG6RXgG-wilOxxwjGMPtSylfRNx1Za_Yn3c=>

However, I think it is still quite hard for users to understand and it becomes 
difficult to talk about location because of the general meaning of that word. 
Possible solutions include better interface (e.g. the new startup), change in 
paradigm (in interface or also in core), and a different name.

Generally, the new name should be considered together the related terms, such 
as [default] region, database, mapset, and [vector] map.

I'm not in favor of "CRS" because a CRS is description of the reference system. 
It is a property of the data or a name of particular part of metadata. Location 
in GRASS GIS is a collection of spatial data with a common CRS.

I've tried to use "Location" (with capital L) and "GRASS Location" to make it 
clear what location we are talking about, but it suffers from the same issues 
as simple "location". For example: Is GRASS location directory on your computer 
where you have GRASS GIS installation?

Best,
Vaclav
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Michael Barton]

Thanks for the response. I hope this can stimulate a discussion.

“Project” is a good option too. As I outlined in my message, there are 2 
aspects to this: 1) changing the wording in the GUI where “location” is used 
now, and 2) ultimately changing the location= argument in the modules where it 
is used.

I’ll take a look at the WIKI.

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

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

From: Helena Mitasova 
Date: Friday, June 1, 2018 at 6:33 PM
To: Michael Barton 
Cc: GRASS developers list 
Subject: Re: [GRASS-dev] a proposal to rename "location"

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://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_wiki_wxGUIDevelopment_New-5FStartup=DwMFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=roKvIbpelz8ddB2ERg5UJAHAkTJZvXky1tobOjigfBw=5C1rzhMVVbSX3gcHS56JRno6pJIwewY_Cev_NPBmtwQ=>

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 
mailto:michael.bar...@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<https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=DwMFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=roKvIbpelz8ddB2ERg5UJAHAkTJZvXky1tobOjigfBw=E8lF4b3V1hB_dqOYrViP5bwMb_K8xbAEbFxp6RrEJpg=>,
 
http://shesc.asu.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__shesc.asu.edu=DwMFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=roKvIbpelz8ddB2ERg5UJAHAkTJZvXky1tobOjigfBw=EVzZQEBTnPl0b3k2ynnTkvtB44xyMFQOInyMrnX-GFg=>

http://www.p

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

[Helmut Kudrnovsky]

>>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

"Scariness of and bad associations with terminal window/command line on
Windows (but consistency and most people seem to ignore it anyway)"

interesting note there. ;-)

as from my side, I don't want to miss the terminal/windows console in
winGRASS, as very helpfull things like gdal/ogr, R, python, grep etc can be
done like in linux.

it's a big and useful functionality addition; maybe a better communication
is needed.



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Vaclav Petras]

On Fri, Jun 1, 2018 at 9:33 PM, Helena Mitasova  wrote:
>
> 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
> ...
> Feel free to add summary of your ideas to the trac linked above,


As Helena suggested, I added this discussion as a subsection at:

https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup

I also added a note about this to the GRASS 8 page next to the note about
naming of "GISDBASE":

https://trac.osgeo.org/grass/wiki/Grass8Planning

And also linked together couple of other pages and issues related to this.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Vaclav Petras]

On Fri, Jun 1, 2018 at 9:33 PM, Nikos Alexandris 
wrote:
>
> Would think of SRS instead of CRS, so as to be in line with GDAL's
> terminology?


CRS versus SRS: Here are the definitions from OGC Glossary:

coordinate reference system (CRS):
A coordinate system that has a reference to the Earth. Consists of a
coordinate system and a datum.

spatial reference system:
As defined in the OpenGIS Abstract Specification Topic 2 and ISO 19111.
Position on or near the Earth's surface can be described by spatial
reference systems. These are of two basic types: those using coordinates;
and those based on geographic identifiers (for example postal addresses,
administrative areas). Spatial referencing by geographic identifiers is
defined in ISO 19112, Geographic information - "Spatial referencing by
geographic identifiers." The subject matter of The OpenGIS® Abstract
Specification Topic 2: "Spatial Referencing by Coordinates" is spatial
referencing by coordinates. Source: The OpenGIS® Abstract Specification
Topic 2: "Spatial Referencing by Coordinates"
http://www.opengis.org/techno/abstract/02-102.pdf

http://www.opengeospatial.org/ogc/glossary/c
http://www.opengeospatial.org/ogc/glossary/s
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Vaclav Petras]

On Fri, Jun 1, 2018 at 6:51 PM, Michael Barton 
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 agree that the current situation is not satisfactory and I think your
description of the situation is very good. The "project location" or just
"project" or even "coordinate system" were all terms which were used in the
6.4 startup/welcome window:

https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/New_Startup/
startup_grass_6.4_wxpython.png

I though it will be much better in order to avoid confusion to go with just
one term and properly explain it. Without changing anything, I of course
needed to go with location in the new startup window and documentation:

https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/New_Startup/
startup_grass_7.5.png
https://grass.osgeo.org/grass74/manuals/grass_database.html

However, I think it is still quite hard for users to understand and it
becomes difficult to talk about location because of the general meaning of
that word. Possible solutions include better interface (e.g. the new
startup), change in paradigm (in interface or also in core), and a
different name.

Generally, the new name should be considered together the related terms,
such as [default] region, database, mapset, and [vector] map.

I'm not in favor of "CRS" because a CRS is description of the reference
system. It is a property of the data or a name of particular part of
metadata. Location in GRASS GIS is a collection of spatial data with a
common CRS.

I've tried to use "Location" (with capital L) and "GRASS Location" to make
it clear what location we are talking about, but it suffers from the same
issues as simple "location". For example: Is GRASS location directory on
your computer where you have GRASS GIS installation?

Best,
Vaclav
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Stefan Sylla]

I agree very much, my "locations" also always have a CRS-name in them. Makes
a lot of sense to use "CRS" or "SRS" instead. That would also significantly
reduce the time that I always needed to figure out a proper name for my
location...



--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Michael Barton]

SRS is fine too. 

Michael Barton
School of Human Evolution  Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

> On Jun 1, 2018, at 6:28 PM, Nikos Alexandris  wrote:
> 
> * Michael Barton  [2018-06-01 22:51:14 +]:
> 
>> 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
> 
> Dear Michael,
> 
> I almost always name Locations after their spatial reference system.
> 
> +1 for this idea.
> 
> Would think of SRS instead of CRS, so as to be in line with GDAL's
> terminology?
> 
> Nikos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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 


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  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@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
hmit...@ncsu.edu
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.” 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Nikos Alexandris]

* Michael Barton  [2018-06-01 22:51:14 +]:


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


Dear Michael,

I almost always name Locations after their spatial reference system.

+1 for this idea.

Would think of SRS instead of CRS, so as to be in line with GDAL's
terminology?

Nikos


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Michael Barton]

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@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev