* Michael Barton <[email protected]> [2018-06-01 22:51:14 +0000]:
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 suggest we consider beginning to migrate the term “location” to “CRS”. The term “location” does not occur in a large number of module interfaces: those (like g.mapset) for changing to a new working directory on the fly, vector and raster reprojection modules, and maybe a couple of others. It occurs in the GUI at startup, in the location wizard of course, and in some tools for georeferencing. We could initially maintain backward compatibility and increase understandability by simply referring to “location” as something like “location/CRS” where ever it shows up in the GUI, but leave module arguments alone. A next step would be to have modules that require “location=” as an argument accept either “location=” or “CRS=”. And maybe that is enough. We could keep “location” where it currently occurs in existing command modules and scripts as a legacy option. Likewise, we could keep it in current code, only changing during code rewrites. Any new modules that need to refer to this file hierarchy would use “CRS”. Thoughts? Michael
Dear Michael, I almost always name Locations after their spatial reference system. +1 for this idea. Would think of SRS instead of CRS, so as to be in line with GDAL's terminology? Nikos
signature.asc
Description: PGP signature
_______________________________________________ grass-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-dev
