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
