[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 <grass4u at 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 at nikosalexandris.net>
> wrote:
>>
>> * 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
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at 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 at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev