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 <gras...@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 <n...@nikosalexandris.net> > wrote: >> >> * Vaclav Petras <wenzesl...@gmail.com> [2018-06-02 11:14:57 -0400]: >> >> >>> On Fri, Jun 1, 2018 at 6:51 PM, Michael Barton <michael.bar...@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@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@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev