[GRASS-dev] Read-access to data in a different location with same SRS

Vaclav Petras wenzeslaus at gmail.com
Thu Nov 19 12:49:21 PST 2020


On Thu, Nov 19, 2020 at 1:16 PM Moritz Lennert <mlennert at club.worldonline.be>
wrote:

>
>
> Am 19. November 2020 15:52:18 MEZ schrieb "Anna Petrášová" <
> kratochanna at gmail.com>:
> >
> >On Thu, Nov 19, 2020 at 8:02 AM Moritz Lennert <
> mlennert at club.worldonline.be>
> >wrote:
> >>
> >> But maybe we could take this idea and create a more sophisticated
> >> mechanism, extending g.mapsets to allow creating a read-only access to
> >> mapsets even outside the current location, as long as the reference
> systems
> >> are identical (would just requiring the PROJ files to be identical be
> >> enough ? Too restrictive ?).
> >>
>
> ... And I think using g.mapsets (or whatever this would then be called) to
> add a subdirectory of another project to those available in the current
> project would not be such a daunting challenge to new users either.
>

This makes a lot of sense to me by itself. To extend the search path to
include mapsets in other locations (using the current terminology),
g.mapsets could accept full paths, check the CRS, and store the path in the
search path. The logic could be (most relevant pieces only):

If the path has no backslashes, add it to the search path (mapset in
current location).
If the path has exactly one backslash, try if it is a location in the
current database directory. If it is, check the CRS match and add it.
If the above path checks failed, make it absolute path and see if it
exists. If it does, check the CRS match and add it.

This also falls nicely into the "simply use paths" idea (i.e., a path
instead of triplet db/loc/mapset).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20201119/a7781cd3/attachment.html>


More information about the grass-dev mailing list