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

Sun Jun 3 05:09:15 PDT 2018

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

>On Fri, Jun 1, 2018 at 6:51 PM, Michael Barton <Michael.Barton at asu.edu>
>wrote:
>
>> As one of the most venerable desktop GIS packages and perhaps THE most
>> venerable still in existence, GRASS has some quirks that harken back to its
>> origins long ago. Most are simply quirky. But the folder hierarchy called a
>> “location” is very confusing in today’s GIS world. Originally, it did
>> primarily refer to maps referencing a geographic location in the world.
>> Although that meaning still exists in the ‘default region’, GRASS locations
>> primarily refer to a coordinate reference system (CRS). In fact, while the
>> CRS of a location cannot be changed (unless you manually alter some of the
>> files in the directory, at the risk of making maps unuseable), the default
>> region can be. So a location now refers to a fixed CRS and a changeable
>> geographic extent.
>>
>>
>>
>> Use of the anachronistic term “location” to refer to a CRS is a quirk that
>> makes GRASS more confusing to initial users.
>>
>
>I 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180603/9832313d/attachment.sig>