<div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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):<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup">https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup</a></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 17, 2018 at 4:38 AM, Pierre Roudier <span dir="ltr"><<a href="mailto:pierre.roudier@gmail.com" target="_blank">pierre.roudier@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">My two cents' worth: it is indeed an issue for beginners, and would be<br>
great to see new term for it, but I would stay away from using<br>
acronyms.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
P<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
On 16 June 2018 at 23:28, Huidae Cho <<a href="mailto:grass4u@gmail.com">grass4u@gmail.com</a>> wrote:<br>
> Dear All,<br>
><br>
> I agree that this terminology needs to be changed. "Project" seems to<br>
> simplify this issue too much because one project doesn't always involve with<br>
> only one SRS. My database folder looks like this:<br>
><br>
> aea@<br>
> epsg102681/<br>
> srorg7873/<br>
> utm52n@<br>
> xy/<br>
><br>
> I try to be consistent in naming Locations and follow EPSG or SR-ORG names.<br>
> Symbolic links (*@) are just for me to remember "common" projection names.<br>
> Inside these Locations, project folders reside. In this sense, Mapset serves<br>
> as a project folder and there can be multiple Mapsets in different Locations<br>
> for one project. One issue with this approach is you have to actively look<br>
> into all Locations to find project-related Mapsets unless you remember which<br>
> SRSs you used for the project. Probably, combination of project and SRS<br>
> names?<br>
><br>
> Maybe, it would be better to create a project "Database" and put all<br>
> project-related data (different SRSs, currently Locations, and possibly<br>
> different users, Mapsets) in that one Database, but I never had more than<br>
> one Database before. I can already see an issue with this approach. No<br>
> global data for all projects to share.<br>
><br>
> I think the challenge here is how to organize data for one project in<br>
> different SRSs in a more intuitive and efficient way.<br>
><br>
> Just my 2 cents.<br>
> Huidae<br>
><br>
><br>
> On Sun, Jun 3, 2018 at 8:09 AM, Nikos Alexandris <<a href="mailto:nik@nikosalexandris.net">nik@nikosalexandris.net</a>><br>
> wrote:<br>
>><br>
>> * Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com">wenzeslaus@gmail.com</a>> [2018-06-02 11:14:57 -0400]:<br>
>><br>
>><br>
>>> On Fri, Jun 1, 2018 at 6:51 PM, Michael Barton <<a href="mailto:Michael.Barton@asu.edu">Michael.Barton@asu.edu</a>><br>
>>> wrote:<br>
>>><br>
>>>> As one of the most venerable desktop GIS packages and perhaps THE most<br>
>>>> venerable still in existence, GRASS has some quirks that harken back to<br>
>>>> its<br>
>>>> origins long ago. Most are simply quirky. But the folder hierarchy<br>
>>>> called a<br>
>>>> “location” is very confusing in today’s GIS world. Originally, it did<br>
>>>> primarily refer to maps referencing a geographic location in the world.<br>
>>>> Although that meaning still exists in the ‘default region’, GRASS<br>
>>>> locations<br>
>>>> primarily refer to a coordinate reference system (CRS). In fact, while<br>
>>>> the<br>
>>>> CRS of a location cannot be changed (unless you manually alter some of<br>
>>>> the<br>
>>>> files in the directory, at the risk of making maps unuseable), the<br>
>>>> default<br>
>>>> region can be. So a location now refers to a fixed CRS and a changeable<br>
>>>> geographic extent.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Use of the anachronistic term “location” to refer to a CRS is a quirk<br>
>>>> that<br>
>>>> makes GRASS more confusing to initial users.<br>
>>>><br>
>>><br>
>>> I agree that the current situation is not satisfactory and I think your<br>
>>> description of the situation is very good. The "project location" or just<br>
>>> "project" or even "coordinate system" were all terms which were used in<br>
>>> the<br>
>>> 6.4 startup/welcome window:<br>
>>><br>
>>><br>
>>> <a href="https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/New_Startup/" rel="noreferrer" target="_blank">https://trac.osgeo.org/grass/<wbr>attachment/wiki/<wbr>wxGUIDevelopment/New_Startup/</a><br>
>>> startup_grass_6.4_wxpython.png<br>
>>><br>
>>> I though it will be much better in order to avoid confusion to go with<br>
>>> just<br>
>>> one term and properly explain it. Without changing anything, I of course<br>
>>> needed to go with location in the new startup window and documentation:<br>
>>><br>
>>><br>
>>> <a href="https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/New_Startup/" rel="noreferrer" target="_blank">https://trac.osgeo.org/grass/<wbr>attachment/wiki/<wbr>wxGUIDevelopment/New_Startup/</a><br>
>>> startup_grass_7.5.png<br>
>>> <a href="https://grass.osgeo.org/grass74/manuals/grass_database.html" rel="noreferrer" target="_blank">https://grass.osgeo.org/<wbr>grass74/manuals/grass_<wbr>database.html</a><br>
>>><br>
>>> However, I think it is still quite hard for users to understand and it<br>
>>> becomes difficult to talk about location because of the general meaning<br>
>>> of<br>
>>> that word. Possible solutions include better interface (e.g. the new<br>
>>> startup), change in paradigm (in interface or also in core), and a<br>
>>> different name.<br>
>>><br>
>>> Generally, the new name should be considered together the related terms,<br>
>>> such as [default] region, database, mapset, and [vector] map.<br>
>>><br>
>>> I'm not in favor of "CRS" because a CRS is description of the reference<br>
>>> system. It is a property of the data or a name of particular part of<br>
>>> metadata. Location in GRASS GIS is a collection of spatial data with a<br>
>>> common CRS.<br>
>>><br>
>>> I've tried to use "Location" (with capital L) and "GRASS Location" to<br>
>>> make<br>
>>> it clear what location we are talking about, but it suffers from the same<br>
>>> issues as simple "location". For example: Is GRASS location directory on<br>
>>> your computer where you have GRASS GIS installation?<br>
>>><br>
>>> Best,<br>
>>> Vaclav<br>
>><br>
>><br>
>> Dear Vaclav,<br>
>><br>
>> When you start explaining the data base structure, in GRASS GIS, where<br>
>> do you start? Excluding the Mapsets (plus the PERMANENT Mapset) concept,<br>
>><br>
>> I start with:<br>
>> "<br>
>> Think of a big box. Inside it, you can keep all items related to<br>
>> your (specific) project. Now, let use create this box, it's a directory<br>
>> (or folder). What will be its name? Name it the way you think is best,<br>
>> for your needs, so you know that its content is for one project.<br>
>><br>
>> Next, you can place inside this box every spatial and non-spatial data<br>
>> related to the project. Raster and vector maps, data bases (like<br>
>> sqlite) or CSV files. And more.<br>
>><br>
>> This is a/the GRASS GIS data base. You will need to know the full path<br>
>> name to this data base, sometimes, as an option to modules.<br>
>><br>
>> Before "placing" actually any data inside the data base, let's<br>
>> understand more of it.<br>
>><br>
>> Inside this box, we can and will need to create smaller boxes. Each of<br>
>> the small boxes, will be defined by one and only (spatial) reference<br>
>> system.<br>
>><br>
>> In GRASS GIS' terminology, these are Locations. Why so? Your data may show<br>
>> the<br>
>> same locations on earth, yet defined in different coordinate systems.<br>
>> You can make use of the Locations to group your data based on their<br>
>> spatial<br>
>> reference system definition. And, of course, you can move data and maps,<br>
>> between the different Locations. That will be a re-projection action.<br>
>><br>
>> Using Locations helps you in _not_ mixing different coordinate systems,<br>
>> as it can and does happen often with other GISes (especially with ESRI<br>
>> Shapefiles).<br>
>><br>
>> Next...<br>
>> "<br>
>><br>
>> I think the GRASS GIS data base, or project, or name it the way you<br>
>> like, deserves equally, or perhaps more, attention.<br>
>><br>
>><br>
>> In general, I think descriptions, whether they refer to a module or its<br>
>> flags and options, or to a concept, should be kept to the minimum<br>
>> "length" (as in number or words used) possible. Yet, they should be<br>
>> fully spelled out--no shortcuts here (as in how long a word for an<br>
>> option, a module name or a concept term is).<br>
>><br>
>> Perhaps CS as in Coordinate System, which is shorter, would be a better<br>
>> candidate than either of CRS or SRS, since it includes unprojected<br>
>> locations, which GRASS GIS supports.<br>
>><br>
>><br>
>> In texts related to GRASS GIS, I write Location, with "L". Never location.<br>
>> If I have done the latter, it's a mistake of mine. I tend to avoid<br>
>> LOCATION (variable names in scripts excluded), simply because CAPITAL<br>
>> LETTERS ARE NOT MORE legible than simply capitalising the first letter<br>
>> of a word (or maybe using CamelCase or small caps if available).<br>
>><br>
>><br>
>> The "characteristic" property, or name it attribute, of a Location, in<br>
>> GRASS GIS, is the coordinate system. I think the<br>
>> word Location is a good choice. The coordinate system in GRASS GIS<br>
>> (excluded the unprojcted) means to locate information in space. Right?<br>
>><br>
>> The problem, as Michael well explains, arises from the many different<br>
>> things that the common word location can point to.<br>
>> The text in <a href="https://grass.osgeo.org/grass75/manuals/grass_database.html" rel="noreferrer" target="_blank">https://grass.osgeo.org/<wbr>grass75/manuals/grass_<wbr>database.html</a><br>
>> does well in trying to explain what a Location is.<br>
>><br>
>> What about very definition of the Location concept in the programmer's<br>
>> manual? This could help in re-naming, perhaps, the Location?<br>
>><br>
>><br>
>> Coming back in organising a project, grouping many Locations under the<br>
>> same GRASS GIS data base directory (or folder), is common. What is the<br>
>> best way, then, to name the different Locations?<br>
>><br>
>> I work with data for Europe. So, the data "show" Europe. Yet, the<br>
>> data are defined in, say, geographic or projected coordinates. How can I<br>
>> reflect this difference between "files" that actually depict exactly the<br>
>> same area? My answer to this has been always the spatial reference<br>
>> system.<br>
>><br>
>> I.e. a "Europe/" GRASS GIS data base with the following locations:<br>
>> etrs89, wgs84, unprojected, et.c.<br>
>><br>
>> This is, mostly, the way I try to explain the concept in others who ask<br>
>> me about it. How do you name your Locations?<br>
>><br>
>><br>
>> The part of the description in<br>
>><br>
>> "<a href="https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/New_Startup/startup_grass_7.5.png" rel="noreferrer" target="_blank">https://trac.osgeo.org/grass/<wbr>attachment/wiki/<wbr>wxGUIDevelopment/New_Startup/<wbr>startup_grass_7.5.png</a>"<br>
>> "One Location can be one project" is not wrong. But I feel it can be<br>
>> easily misunderstood.  Language barriers might lead someone into<br>
>> thinkgin that a Location "should" be one project.<br>
>><br>
>><br>
>> Nikos, learning through mistakes<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> grass-dev mailing list<br>
>> <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/grass-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP<br>
> Senior Geospatial Engineer, MapAnything<br>
> Open Source GIS Developer, GRASS GIS Development Team<br>
><br>
> ______________________________<wbr>_________________<br>
> grass-dev mailing list<br>
> <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/grass-dev</a><br>
______________________________<wbr>_________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/grass-dev</a></div></div></blockquote></div><br></div></div>