<div dir="ltr"><div>Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 19, 2020 at 8:02 AM Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
It was great seeing some of you last night via jitsi !<br></blockquote><div><br></div><div>indeed! </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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.<br>
<br>
In the perspective where each location is a project we this would somehow get lost, as this concept invites duplication into each project.<br></blockquote><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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 ?).<br>
<br>
This would possibly allow to go further in the idea of organizing data by projects instead of locations, while also keeping<br>
the idea of avoiding data duplication (people could create base data projects with data common to many projects).<br>
<br>
How does that sound ?<br></blockquote><div><br></div><div>Certainly worth exploring, however this seems to be more advanced, so not sure how this would help in introducing new people to GRASS.</div><div><br></div><div>Anna </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Moritz<br>
_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/grass-dev</a></blockquote></div></div>