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

GRASS GRASS developer
1

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

2

* Michael Barton <Michael.Barton@asu.edu> [2018-06-01 22:51:14 +0000]:

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

3

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 <Michael.Barton@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@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@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.”

4

SRS is fine too.

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

...Sent from my iPad

On Jun 1, 2018, at 6:28 PM, Nikos Alexandris <nik@nikosalexandris.net> wrote:

* Michael Barton <Michael.Barton@asu.edu> [2018-06-01 22:51:14 +0000]:

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

5

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

6

On Fri, Jun 1, 2018 at 6:51 PM, Michael Barton <Michael.Barton@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

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

7

On Fri, Jun 1, 2018 at 9:33 PM, Nikos Alexandris <nik@nikosalexandris.net> 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

8

On Fri, Jun 1, 2018 at 9:33 PM, Helena Mitasova <hmitaso@ncsu.edu> 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.

9

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. :wink:

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

10

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 hmitaso@ncsu.edu
Date: Friday, June 1, 2018 at 6:33 PM
To: Michael Barton Michael.Barton@asu.edu
Cc: GRASS developers list grass-dev@lists.osgeo.org
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

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@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@lists.osgeo.org
grass-dev Info Page

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@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.”

11

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 wenzeslaus@gmail.com
Date: Saturday, June 2, 2018 at 8:15 AM
To: Michael Barton Michael.Barton@asu.edu
Cc: GRASS developers list grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] a proposal to rename “location”

On Fri, Jun 1, 2018 at 6:51 PM, Michael Barton <Michael.Barton@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

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

12

* Vaclav Petras <wenzeslaus@gmail.com> [2018-06-02 11:14:57 -0400]:

On Fri, Jun 1, 2018 at 6:51 PM, Michael Barton <Michael.Barton@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

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

Before "placing" actually any data inside the data base, let's
understand more of it.

Inside this box, we can and will need to create smaller boxes. Each of
the small boxes, will be defined by one and only (spatial) reference system.

In GRASS GIS' terminology, these are Locations. Why so? Your data may show the
same locations on earth, yet defined in different coordinate systems.
You can make use of the Locations to group your data based on their spatial
reference system definition. And, of course, you can move data and maps,
between the different Locations. That will be a re-projection action.

Using Locations helps you in _not_ mixing different coordinate systems,
as it can and does happen often with other GISes (especially with ESRI
Shapefiles).

Next...
"

I think the GRASS GIS data base, or project, or name it the way you
like, deserves equally, or perhaps more, attention.

In general, I think descriptions, whether they refer to a module or its
flags and options, or to a concept, should be kept to the minimum
"length" (as in number or words used) possible. Yet, they should be
fully spelled out--no shortcuts here (as in how long a word for an
option, a module name or a concept term is).

Perhaps CS as in Coordinate System, which is shorter, would be a better
candidate than either of CRS or SRS, since it includes unprojected
locations, which GRASS GIS supports.

In texts related to GRASS GIS, I write Location, with "L". Never location.
If I have done the latter, it's a mistake of mine. I tend to avoid
LOCATION (variable names in scripts excluded), simply because CAPITAL
LETTERS ARE NOT MORE legible than simply capitalising the first letter
of a word (or maybe using CamelCase or small caps if available).

The "characteristic" property, or name it attribute, of a Location, in
GRASS GIS, is the coordinate system. I think the
word Location is a good choice. The coordinate system in GRASS GIS
(excluded the unprojcted) means to locate information in space. Right?

The problem, as Michael well explains, arises from the many different
things that the common word location can point to.
The text in https://grass.osgeo.org/grass75/manuals/grass_database.html
does well in trying to explain what a Location is.

What about very definition of the Location concept in the programmer's
manual? This could help in re-naming, perhaps, the Location?

Coming back in organising a project, grouping many Locations under the
same GRASS GIS data base directory (or folder), is common. What is the
best way, then, to name the different Locations?

I work with data for Europe. So, the data "show" Europe. Yet, the
data are defined in, say, geographic or projected coordinates. How can I
reflect this difference between "files" that actually depict exactly the
same area? My answer to this has been always the spatial reference
system.

I.e. a "Europe/" GRASS GIS data base with the following locations:
etrs89, wgs84, unprojected, et.c.

This is, mostly, the way I try to explain the concept in others who ask
me about it. How do you name your Locations?

The part of the description in
"https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/New_Startup/startup_grass_7.5.png&quot;
"One Location can be one project" is not wrong. But I feel it can be
easily misunderstood. Language barriers might lead someone into
thinkgin that a Location "should" be one project.

Nikos, learning through mistakes

13

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 <nik@nikosalexandris.net> wrote:

On Fri, Jun 1, 2018 at 6:51 PM, Michael Barton <Michael.Barton@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

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

Before “placing” actually any data inside the data base, let’s
understand more of it.

Inside this box, we can and will need to create smaller boxes. Each of
the small boxes, will be defined by one and only (spatial) reference system.

In GRASS GIS’ terminology, these are Locations. Why so? Your data may show the
same locations on earth, yet defined in different coordinate systems.
You can make use of the Locations to group your data based on their spatial
reference system definition. And, of course, you can move data and maps,
between the different Locations. That will be a re-projection action.

Using Locations helps you in not mixing different coordinate systems,
as it can and does happen often with other GISes (especially with ESRI
Shapefiles).

Next…
"

I think the GRASS GIS data base, or project, or name it the way you
like, deserves equally, or perhaps more, attention.

In general, I think descriptions, whether they refer to a module or its
flags and options, or to a concept, should be kept to the minimum
“length” (as in number or words used) possible. Yet, they should be
fully spelled out–no shortcuts here (as in how long a word for an
option, a module name or a concept term is).

Perhaps CS as in Coordinate System, which is shorter, would be a better
candidate than either of CRS or SRS, since it includes unprojected
locations, which GRASS GIS supports.

In texts related to GRASS GIS, I write Location, with “L”. Never location.
If I have done the latter, it’s a mistake of mine. I tend to avoid
LOCATION (variable names in scripts excluded), simply because CAPITAL
LETTERS ARE NOT MORE legible than simply capitalising the first letter
of a word (or maybe using CamelCase or small caps if available).

The “characteristic” property, or name it attribute, of a Location, in
GRASS GIS, is the coordinate system. I think the
word Location is a good choice. The coordinate system in GRASS GIS
(excluded the unprojcted) means to locate information in space. Right?

The problem, as Michael well explains, arises from the many different
things that the common word location can point to.
The text in https://grass.osgeo.org/grass75/manuals/grass_database.html
does well in trying to explain what a Location is.

What about very definition of the Location concept in the programmer’s
manual? This could help in re-naming, perhaps, the Location?

Coming back in organising a project, grouping many Locations under the
same GRASS GIS data base directory (or folder), is common. What is the
best way, then, to name the different Locations?

I work with data for Europe. So, the data “show” Europe. Yet, the
data are defined in, say, geographic or projected coordinates. How can I
reflect this difference between “files” that actually depict exactly the
same area? My answer to this has been always the spatial reference
system.

I.e. a “Europe/” GRASS GIS data base with the following locations:
etrs89, wgs84, unprojected, et.c.

This is, mostly, the way I try to explain the concept in others who ask
me about it. How do you name your Locations?

The part of the description in
“https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/New_Startup/startup_grass_7.5.png”
“One Location can be one project” is not wrong. But I feel it can be
easily misunderstood. Language barriers might lead someone into
thinkgin that a Location “should” be one project.

Nikos, learning through mistakes

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

–

Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP
Senior Geospatial Engineer, MapAnything
Open Source GIS Developer, GRASS GIS Development Team

14

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 <grass4u@gmail.com> 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 <nik@nikosalexandris.net>
wrote:

* Vaclav Petras <wenzeslaus@gmail.com> [2018-06-02 11:14:57 -0400]:

On Fri, Jun 1, 2018 at 6:51 PM, Michael Barton <Michael.Barton@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

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

Before "placing" actually any data inside the data base, let's
understand more of it.

Inside this box, we can and will need to create smaller boxes. Each of
the small boxes, will be defined by one and only (spatial) reference
system.

In GRASS GIS' terminology, these are Locations. Why so? Your data may show
the
same locations on earth, yet defined in different coordinate systems.
You can make use of the Locations to group your data based on their
spatial
reference system definition. And, of course, you can move data and maps,
between the different Locations. That will be a re-projection action.

Using Locations helps you in _not_ mixing different coordinate systems,
as it can and does happen often with other GISes (especially with ESRI
Shapefiles).

Next...
"

I think the GRASS GIS data base, or project, or name it the way you
like, deserves equally, or perhaps more, attention.

In general, I think descriptions, whether they refer to a module or its
flags and options, or to a concept, should be kept to the minimum
"length" (as in number or words used) possible. Yet, they should be
fully spelled out--no shortcuts here (as in how long a word for an
option, a module name or a concept term is).

Perhaps CS as in Coordinate System, which is shorter, would be a better
candidate than either of CRS or SRS, since it includes unprojected
locations, which GRASS GIS supports.

In texts related to GRASS GIS, I write Location, with "L". Never location.
If I have done the latter, it's a mistake of mine. I tend to avoid
LOCATION (variable names in scripts excluded), simply because CAPITAL
LETTERS ARE NOT MORE legible than simply capitalising the first letter
of a word (or maybe using CamelCase or small caps if available).

The "characteristic" property, or name it attribute, of a Location, in
GRASS GIS, is the coordinate system. I think the
word Location is a good choice. The coordinate system in GRASS GIS
(excluded the unprojcted) means to locate information in space. Right?

The problem, as Michael well explains, arises from the many different
things that the common word location can point to.
The text in https://grass.osgeo.org/grass75/manuals/grass_database.html
does well in trying to explain what a Location is.

What about very definition of the Location concept in the programmer's
manual? This could help in re-naming, perhaps, the Location?

Coming back in organising a project, grouping many Locations under the
same GRASS GIS data base directory (or folder), is common. What is the
best way, then, to name the different Locations?

I work with data for Europe. So, the data "show" Europe. Yet, the
data are defined in, say, geographic or projected coordinates. How can I
reflect this difference between "files" that actually depict exactly the
same area? My answer to this has been always the spatial reference
system.

I.e. a "Europe/" GRASS GIS data base with the following locations:
etrs89, wgs84, unprojected, et.c.

This is, mostly, the way I try to explain the concept in others who ask
me about it. How do you name your Locations?

The part of the description in

"https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/New_Startup/startup_grass_7.5.png&quot;
"One Location can be one project" is not wrong. But I feel it can be
easily misunderstood. Language barriers might lead someone into
thinkgin that a Location "should" be one project.

Nikos, learning through mistakes

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

--
Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP
Senior Geospatial Engineer, MapAnything
Open Source GIS Developer, GRASS GIS Development Team

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

15

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 <pierre.roudier@gmail.com> 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 <grass4u@gmail.com> 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 <nik@nikosalexandris.net>
wrote:

On Fri, Jun 1, 2018 at 6:51 PM, Michael Barton <Michael.Barton@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

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

Before “placing” actually any data inside the data base, let’s
understand more of it.

Inside this box, we can and will need to create smaller boxes. Each of
the small boxes, will be defined by one and only (spatial) reference
system.

In GRASS GIS’ terminology, these are Locations. Why so? Your data may show
the
same locations on earth, yet defined in different coordinate systems.
You can make use of the Locations to group your data based on their
spatial
reference system definition. And, of course, you can move data and maps,
between the different Locations. That will be a re-projection action.

Using Locations helps you in not mixing different coordinate systems,
as it can and does happen often with other GISes (especially with ESRI
Shapefiles).

Next…
"

I think the GRASS GIS data base, or project, or name it the way you
like, deserves equally, or perhaps more, attention.

In general, I think descriptions, whether they refer to a module or its
flags and options, or to a concept, should be kept to the minimum
“length” (as in number or words used) possible. Yet, they should be
fully spelled out–no shortcuts here (as in how long a word for an
option, a module name or a concept term is).

Perhaps CS as in Coordinate System, which is shorter, would be a better
candidate than either of CRS or SRS, since it includes unprojected
locations, which GRASS GIS supports.

In texts related to GRASS GIS, I write Location, with “L”. Never location.
If I have done the latter, it’s a mistake of mine. I tend to avoid
LOCATION (variable names in scripts excluded), simply because CAPITAL
LETTERS ARE NOT MORE legible than simply capitalising the first letter
of a word (or maybe using CamelCase or small caps if available).

The “characteristic” property, or name it attribute, of a Location, in
GRASS GIS, is the coordinate system. I think the
word Location is a good choice. The coordinate system in GRASS GIS
(excluded the unprojcted) means to locate information in space. Right?

The problem, as Michael well explains, arises from the many different
things that the common word location can point to.
The text in https://grass.osgeo.org/grass75/manuals/grass_database.html
does well in trying to explain what a Location is.

What about very definition of the Location concept in the programmer’s
manual? This could help in re-naming, perhaps, the Location?

Coming back in organising a project, grouping many Locations under the
same GRASS GIS data base directory (or folder), is common. What is the
best way, then, to name the different Locations?

I work with data for Europe. So, the data “show” Europe. Yet, the
data are defined in, say, geographic or projected coordinates. How can I
reflect this difference between “files” that actually depict exactly the
same area? My answer to this has been always the spatial reference
system.

I.e. a “Europe/” GRASS GIS data base with the following locations:
etrs89, wgs84, unprojected, et.c.

This is, mostly, the way I try to explain the concept in others who ask
me about it. How do you name your Locations?

The part of the description in

“https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/New_Startup/startup_grass_7.5.png”
“One Location can be one project” is not wrong. But I feel it can be
easily misunderstood. Language barriers might lead someone into
thinkgin that a Location “should” be one project.

Nikos, learning through mistakes

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

–
Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP
Senior Geospatial Engineer, MapAnything
Open Source GIS Developer, GRASS GIS Development Team

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

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