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

On Thu, Nov 19, 2020 at 1:16 PM Moritz Lennert <[email protected]>
wrote:

>
>
> Am 19. November 2020 15:52:18 MEZ schrieb "Anna Petrášová" <
> [email protected]>:
> >
> >On Thu, Nov 19, 2020 at 8:02 AM Moritz Lennert <
> [email protected]>
> >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).

_______________________________________________
grass-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-dev