wxGUI: Minimal changes to rename location to project

[wenzeslaus]

This renames location to project in user messages in wxGUI.

This does not change any documentation or variable names. It does not change names outside of wxGUI.

This changes only location to project. It leaves mapset as is because there seems to be much higher consensus about renaming location to project than about renaming mapset in general.

[marisn]

Are we heading for another field/layer type of confusion?

[HuidaeCho]

Are we heading for another field/layer type of confusion?

I guess so. In addition, this PR could potentially lead to misleading names of existing "locations" because not all location names are project names and vice versa. I think this change deserves a "major" version because it's such a big (at least to me) change in semantics.

[HuidaeCho]

there seems to be much higher consensus about renaming location to project than about renaming mapset in general.

I think I have missed this discussion. Any link to this consensus would be great!

[HuidaeCho]

field/layer

Even worse, column vs. field/layer :-(

[wenzeslaus]

Notes from GRASS GIS at OSGeo Community Sprint 2022 discussing also other possible renames (not considered now): https://grasswiki.osgeo.org/wiki/GRASS_GIS_at_OSGeo_Community_Sprint_2022#Discuss_naming_and_presentation_of_GRASS_GIS_data_hierarchy

[veroandreo]

some other edits suggested :)

[cmbarton]

I have long thought that changing the name of locations to something else could make GRASS more approachable, especially for new users. The reason is that locations are how GRASS manages projections (CRS), and do not represent a particular geographic "location". That may have been the original usage, but it is no longer the case.

However, changing the name to "project" does not help and in fact will add more confusion. To most people, a "project" implies a collection of maps, the way they are overlayed, and displayed, and perhaps any ancillary visualizations or analyses to go with them. This is the case for other widely used GIS platforms that users may encounter.

For ArcGIS: " A project is a collection of related items—which may include maps, layouts, item connections, and many other resources—that contribute to a common purpose."

For QGIS: "The state of your QGIS session is called a project." It includes much of the same range of geospatial data as ArcGIS projects.

In GRASS, a "workspace" is most analogous to projects in Arc and Q. But "workspace" is also a widely understood term and seems OK in this context.

Calling a location a project suggests that it is analogous to the way the term is used in other GIS platforms and that is very misleading. A location has a single CRS/projection and all maps stored in a location folder must use that same CRS/projection.

A GRASS location does not represent the state of a GRASS session, the maps displayed, the layouts, the view extent ("region"), styles, colors, etc. Its only purpose is to ensure that all maps (and all mapsets) in a location use the same projection/CRS and will accurately overlay.

Changing the name of locations to "projection" or "CRS" are accurate terms for what locations do.

Calling them "projects" is as misleading (or more so) than calling them locations and will only further confuse future GRASS users.

[marisn]

Yes! Workspaces sound better. Thank you @cmbarton for the great idea!

[cmbarton]

To be clear, I was not recommending that locations be renamed to workspaces, though that is less confusing than locations or projects. Currently the term "workspace" is used in GRASS in the same way that the term "project" is used in ArcGIS, QGIS, and other programs. If we rename locations to workspaces, we would also need to rename workspaces to something like projects.

[wenzeslaus]

Might be helpful for reference: Terminology comparison between ArcGIS and GRASS GIS

[wenzeslaus]

Project is a word with a broad meaning. For software, it often refers to whatever is the main native thing the software deals with unless there is another more common name (document, image, database). However, it is a common word outside of GIS and software and people are used to the word coming with different definitions in different contexts.

Reading little further in that ArcGIS Pro documentation page:

A project contains two types of items. One type includes maps, scenes, layouts, and other views of your data. The other type is connections that provide access to the contents of folders, databases, and other resources.
...
A project is stored on your computer as a file with the extension .aprx. By default, it is stored in a system folder created with the project. The project file is associated with a geodatabase and a toolbox. Other folders and files, such as the project index and the backup project file, are created with the project or during your ArcGIS Pro session.

The ArcGIS Pro project files are grouped together with actual data storage, not just views or links to data.

While QGIS project does not store data, it stores auxiliary data and it can be stored inside a GeoPackage with the data (so go as far as saying [QGIS] GeoPackage Project.

In cases of ArcGIS and QGIS, actual data storage can be part of the project, so it is not just purely state of the GUI. For wxGUI, the workspace file referred originally to state of the GUI (some windows, added layers, d-command styling, 3D) and now it includes also path to mapset.

The word workspace is used in ArcGIS:

Tools that honor the Current Workspace environment use the workspace specified as the default location for geoprocessing tool inputs and outputs. ... In ArcGIS Pro, the default value for the Scratch Workspace and Current Workspace environments is the project default geodatabase.

So the two closet things we have are what is currently called mapset (not location!) and current working directly (pwd, os.getcwd(), getwd()).

And QGIS documentation uses that to refer to whatever sort of the state of the GUI thing:

QGIS can save the state of your workspace into a QGIS project file using the menu options Project ► Save or Project ► Save As….

That would be the GUI workspace file, except that QGIS project can have associated external data like Shapefile on the disk and the workspace file cannot. However, GRASS GIS can do it in a location, or more precisely in a mapset (v.external, r.external).

A GRASS location (or mapset) does represent the state of what the user was doing in a sense that it has all the data you were working with, history of what you were doing, current computation extent and resolution, default extent, bookmarked extents (spatial bookmarks aka saved regions), associated styles when stored as color tables, labels for cartography (v.label, d.label), links to external data, even your selected CRS.

One may argue that the state of the GUI is missing. I would agree. I think what is now a workspace file would make most sense as part of a mapset (I'm thinking that since I saw the low uptake of workspace file with stored mapset path and the much more successful data management panel).

While projection or CRS is an import part of what location is in GRASS GIS, both projection and CRS refer to something completely different than data storage and what locations do is storing data. They store them in a particular way which involves data format and CRS, but they are more than just data storage, they also store much of the information users generates when working with the software.

[hellik]

From time to time I'm using ArcGIS Pro, here some experiences and thoughts.

• Starting ArcGIS Pro for a new work, for saving a "project" (.aprx), you have to choose a ArcGIS project folder in your file system where .aprx will be saved
• this ArcGIS project folder can be anywhere on your file system; ideally on a dedicated drive or as a subfolder in a dedicated GIS work folder. GRASS GIS is here more structured in a clean way with its GRASS data base, here simplified known as 'GRASSDATA' in the many tutorials (in GRASS > 8 with the nice addition to add more GRASS data bases into the tree).
• data linked in a ArcGIS Pro "project" (.aprx) can be (copied) in the ArcGIS project folder or can be anywhere in the file system. GRASS eqivalent here is r.external/v.external. with the main and important difference that ArcGIS Pro re-projects on the fly while in GRASS GIS all data has to be in the same SRS (side note here: I like the GRASS GIS approach here as some kind of a data integrity check while bringing your data into the same SRS before analysis is done)
• data produced in an ArcGIS work is stored by default into the ArcGIS project folder, e.g. vector data into a file geodatabase and raster data as a raster data file itself or also into a file geodatabase; though a user can define also another place outside of the ArcGIS project folder. again, in GRASS GIS it is a bit more strictly structured as resulting products are stored into the active mapset; additionally, AFAIK GRASS module output can't be saved directly outside a mapset. an extra step is here needed with r.out.gdal/v.out.ogr.
• ArcGIS Pro "project" (.aprx) is partly equivalent to a GRASS GIS workspace file
• ArcGIS PRO is a bit more flexible in saving resulting data comparing to the strict GRASS GIS approach
• with ArcGIS Pro switching to the ArcGIS project folder concept, IMHO GRASS GIS and ArcGIS Pro are not really far away in structuring GIS data, with the main difference of on-the-fly-re-projection ability.
• IMHO, QGIS follows the approach of the now 'old' ArcGIS Map concept; it is not a bad concept, it is one of many concept ideas how GIS data can be structured within your workflows.
• with increasing GIS data amount and GIS data file size nowadays, IMHO a structured data management is the way to go; and GRASS GIS is here with its well founded data concept on a good way.
• to sum it up, it seems to be here more some kind of naming question, and not a concept question.
• here and there there are complaints (thus this PR) that users are not used to GRASS GIS data concepts and naming (location/mapset, etc), on the other hand no one of these people have contributed some input to the discussion
• while re-reading the PR title "Rename location to project", from my own user point of view ;-) : a GIS project is where I store all of my client's data and do my GIS analysis :-)

[wenzeslaus]

...I think what is now a workspace file would make most sense as part of a mapset...

A proof of concept available in PR #3113.

[cmbarton]

"Project" capitalized or not:
I think for distinguishing between GRASS project and a general project or any other project, we will need to anyway say "GRASS project". For that, project or Project does not make much difference. The capitalized project also does not really come through when speaking, so lectures, workshops, videos anyway need to use context and GRASS as adjective to make the distinction.
Seeing how things work in the code, when the standard is not automatically enforced by CI, there is little hope that it will be applied by everyone. Given that, I don't have much hope that getting it right in a tutorial in 2024 will particularly help to promote the practice beyond the most active contributors.
With that said, I'm waiting with the merge until this is resolved. While I won't be chasing every mention on mapset to capitalize it, I'm willing to modify the PRs to capitalize project (and mapset) when applicable.
Are there any other opinions on this?

When I read @cmbarton explanation I went like: oh, yes, capitalized Project, that sounds good. Now, after reading @wenzeslaus explanation, I'm trying to think on the usage of these concepts once this is merged, and I wonder why capitalizing? Why putting an extra layer of complexity and maintenance burden on ourselves? We sometimes complain or more often hear complaints like this is too complex to explain, people get confused, why all this and such... Capitalizing does not seem to go in the direction of trying to simplify explanations or making the concepts and GRASS database structure sound more natural, i.e., look GRASS has a native format and so you need to convert your data to it, luckily GRASS offers a nice system to store your data in a database organized in projects, these have folders inside or mapsets that help you organize your maps in topics, areas, whatever. The important thing of projects is that they are defined by a CRS, so all maps inside a project will share the same CRS. Do we need to use GRASS database and GRASS projects or GRASS mapsets? We can, but maybe we do not need to... On these lines, I'm more inclined to keep it as simple as possible, so, just project and mapset...

The reason is similar to why we spell it GRASS instead of grass. I realize that GRASS is also an acronym but it distinguishes the special usage of it in GRASS from the common usage of a word. Project is a very common word and as proposed, a Project has a specific meaning in GRASS (like Location vs. location).

It's not a huge issue, but it would nice to 1) be consistent, which it is not currently, and 2) clearly signal to users what a GRASS Project is. It is not a matter of trying to force others to use it this way, but my suggestion is that in our docs to be consistent and use capitalization to make usage more clear. For example, "You will need to project all the maps that you use in a project to the same CRS. A GRASS Project is a place to store all the maps from your project that have the same projection." Capitalizing GRASS Project (or even all caps PROJECT) makes these sentences more understandable than they would be otherwise.

[petrasovaa]

It's not a huge issue, but it would nice to 1) be consistent, which it is not currently, and 2) clearly signal to users what a GRASS Project is. It is not a matter of trying to force others to use it this way, but my suggestion is that in our docs to be consistent and use capitalization to make usage more clear. For example, "You will need to project all the maps that you use in a project to the same CRS. A GRASS Project is a place to store all the maps from your project that have the same projection." Capitalizing GRASS Project (or even all caps PROJECT) makes these sentences more understandable than they would be otherwise.

Consistency would be easier to achieve with lower case in my opinion. I think it's common to use lower case, e.g. QGIS project. Clarity can be achieved by other means, e.g. in your sentence you can simply drop the lower case project word and it will work just as well. So I would vote for lower case.

[wenzeslaus]

@cmbarton is for Project with capital P or possibly for all caps PROJECT. @veroandreo and @petrasovaa are for all lowercase project.

While I'm author of most of the occurrences of Location with capital L, I must say I did not see much buy-in (no one came up and said, "hey, let's change it everywhere") and I definitively did not see any significant improvement in understanding of Location as a result of that (if there would be any, we would not be here renaming location to project).

Given the difficulties with enforcement of this, lack of application of the same uppercase logic to other concepts (mapset, vector, raster, ...), and the experience with Location with upper case L, I'm for an all lowercase project.

I'm going with project.

Approving reviews would help merging this.

[cmbarton]

I'm certainly not going to block this. I do want to clarify a couple things. When I recommend using Project instead of project, I'm only referring to places where users will see the word: in official GRASS documentation and perhaps in GUI tooltips. This is to distinguish the Project folder and concept from the other uses of this common word.

For commands, lower case project is good. And case insensitive is even better so that, for example g.mapsets project= , g.mapsets Project= , g.mapsets PROJECT= all are recognized as the same.

The same thing would go for any use in C or Python code.

Since you are doing a batch replace of Location, this should be pretty easy--except for having to manually look at "location" in documentation to see what is meant (the same thing I suggest to avoid).

We can't police how other people should write this outside of official GRASS documentation, though we have (or should have) standards for writing documentation for commands.

[echoix]

I'd just like to pitch in, also in favor of lowercase, that it might be easier overall in other languages. We were having a pretty deep debate on an English-specific writing conviention, without thinking if a distinction of the sort is even possible for other of our supported languages. Does that special meaning really stay? All of us in this project come from different countries and we certainly all speak and write another language than English, some of us being English not even being our mother-tongue, so we probably could be able to reflect on this.

Also in favour of lowercase, is a more practical reason: it's way easier to have tooling to help us standardize if we are not inventing a grammar rule :) I'm talking about spell checking, grammar checking, translation management, ML translations, etc.

[neteler]

I found a bunch of other candidates: shall I list them here or edit the PR?

[wenzeslaus]

This really aims at minimal changes in wxGUI. Do you think your changes are necessary for the scope of the PR or can we merge this and other open PRs and do the other changes afterwards?

…

On Sat, Mar 16, 2024, 9:19 AM Markus Neteler ***@***.***> wrote: I found a bunch of other candidates: shall I list them here or edit the PR? — Reply to this email directly, view it on GitHub <#2993 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJSKZGDHWLR6XOT3C3ERRTYYRBHPAVCNFSM6AAAAAAYYKTBCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBRHE4DKMJUGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[neteler]

Right, I overlooked "wxGUI only". So they can wait, no problem.

[wenzeslaus]

Do you want to review this one so we can start merging?

…

On Sat, Mar 16, 2024, 9:35 AM Markus Neteler ***@***.***> wrote: Right, I overlooked "wxGUI only". So they can wait, no problem. — Reply to this email directly, view it on GitHub <#2993 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJSKZEULQXHIW3ZATJGXULYYRDBFAVCNFSM6AAAAAAYYKTBCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBRHE4DQOJSGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[echoix]

Smaller PRs that require review/feedback by only one person, one subject/skill set are faster to go through

[neteler]

Do you want to review this one so we can start merging?

I went through and added some change suggestions/comments.

[echoix]

Just a question on the side since we're undertaking a full review of the docs soon: is the implementation of using markdown docs ready or not close enough? That change will be progressive, it will still need another full review of docs. Or was is only ready for the parser output?

[veroandreo]

Let's go!