Read-access to data in a different location with same SRS

Moritz Lennert <[email protected]>
Newsgroups gmane.comp.gis.grass.devel
Message-ID <[email protected]>
Hi,

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

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.

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.

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 ?

Moritz
_______________________________________________
grass-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.