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

[Anna Petrášová]

Hi,

On Thu, Nov 19, 2020 at 8:02 AM Moritz Lennert <mlennert at club.worldonline.be>
wrote:

> Hi,
>
> It was great seeing some of you last night via jitsi !
>

indeed!

>
> In the context of the discussion of "location" vs "project", several of us
> pointed to the fact that we organize our data into locations by reference
> system with mapsets as project directories. PERMANENT (and other mapsets)
> can then be used for data that is common to many projects and can thus be
> accessed read-only from their respective mapsets. This helps avoiding data
> duplication across projects.
>
> In the perspective where each location is a project we this would somehow
> get lost, as this concept invites duplication into each project.
>

Right, just wanted to perhaps clarify my use case. I typically work with
high resolution data so my study areas tend to be fairly small. But they do
have common CRS (e.g. all study areas are in NC). So for me it makes sense
to create a new location (with the same CRS) for each project and then I
use mapsets to better organize my analysis, so that I don't have too many
maps in there. So the code duplication doesn't typically bother me, but I
of course I see your point.

>
> However, Luca raised an interesting point in the chat which we didn't get
> to discuss: it might be possible to define some mechanism to make data in
> one location readable from another location as long as they are in the same
> SRS. An easy and dirty way is obviously to just use symbolic links as Luca
> seemed to suggest, but that means there is no control over the actual
> correspondence of location definitions. Also I don't know how
> cross-platform this would be.
>

We started to use it on HPC, where we have backed-up storage with PERMANENT
location containing all the base data and only I have permissions to write
there and then other users including me symlink this mapset to their
locations in scratch spaces, so they can read from there and work on their
stuff. This has been working really well.

>
> 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 ?).
>
> This would possibly allow to go further in the idea of organizing data by
> projects instead of locations, while also keeping
> the idea of avoiding data duplication (people could create base data
> projects with data common to many projects).
>
> How does that sound ?
>

Certainly worth exploring, however this seems to be more advanced, so not
sure how this would help in introducing new people to GRASS.

Anna

>
> Moritz
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20201119/1ee62e9e/attachment-0001.html>