You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.com> on 2015/11/23 13:47:11 UTC
Which directory for referencing data?
Hello all
With the new support for datum shift grid files and the support for EPSG
database which will start this week, we reach a point where SIS needs a
directory for storing its data on the user's machine. This is not about
user's data (Shapefile, GeoTIFF, etc.), but rather about data needed for
SIS working:
* Map projection definitions and coordinate transformation methods
(EPSG database).
* Datum shift grids (for transforming coordinates from old systems to
newer systems): NADCON in USA, NTv2 in Canada and other countries,
GR3DF97A in France.
The Proj.4 library on Unix puts those data in the
"/usr/local/share/proj" directory. This directory is shared by all users
on a system but require administrative rights. Those data are provided
by the "proj-data" package on Linux systems. We can not use easily the
Proj.4 data however since they are either rewritten in their own syntax,
or use different grids than the ones that we expect.
The user may have to download and install himself some files in the
Apache SIS application data directory, for example the datum shift grid
files for his particular country. I presume that it may be easier for
the user if the directory is located in the standard location for his
platform. So I propose the following algorithm, in that order:
1. If the environment variable given by
System.getenv("APACHE_SIS_DATA") is defined, use the directory given
by that variable.
2. Otherwise if the Java property given by
System.getProperty("apache.sis.data") is defined, use the directory
given by that variable.
3. Otherwise default to a system-dependent directory:
* Windows: System.getEnv("APPDATA") + "\Apache\SIS"
o or if the APPDATA environment variable is not defined,
default to "Application Data\Apache\SIS" in user's home
directory.
* MacOS: "Library/Application Support/Apache/SIS" in user's home
directory [1].
* Other (presumed Unix): ".apache/sis" in user's home directory.
Order of choices 1 and 2 (environment variable having precedence over
the -D options passed to java) may seem counter-intuitive. This ordering
is an attempt to ease deployment on Docker [2]. However if it is at risk
of being too surprising to users, we may try to find other approach for
Docker.
An inconvenient of the default directory suggested at step 3 is that the
data are not shared by other users on the same machine (contrarily to
what Proj.4 does for instance).
I did not included Java preferences (java.util.prefs.Preferences) in the
above list, but this choice could also be explored.
Any feedbacks?
Martin
[1] http://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/MacOSXDirectories/MacOSXDirectories.html
[2] https://en.wikipedia.org/wiki/Docker_%28software%29
Re: Which directory for referencing data?
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Adam
Le 23/11/15 15:21, Adam Estrada a écrit :
> I would venture to guess that the best practice would be to set an environment variable. One would be SIS_HOME and the other would be SIS_DATA.
Yes, my previous email was proposing first an environment variable, next
(if no environment variable) a Java property, and as a last fallback a
default directory. So we may reformulate the question as: do we want a
default directory as a last fallback, or to raise an error if no
environment variable or Java property is set?
Also should the environment variable name be "SIS_DATA" or
"APACHE_SIS_DATA"? I noticed that a search for "SIS" on Google gives a
lot of hits for something called "Science in sports".
Martin
Re: Which directory for referencing data?
Posted by Adam Estrada <es...@gmail.com>.
I like this because it resembles existing workflows from gdal, etc. In other words...folks thinking about using sis would not have to make too many changes to get up and running. They will already be familiar with setting an environment variable for their geolib
A
Sent from my iPhone
> On Dec 1, 2015, at 5:42 PM, Martin Desruisseaux <ma...@geomatys.com> wrote:
>
> Le 23/11/15 15:21, Adam Estrada a écrit :
>> I would venture to guess that the best practice would be to set an environment variable. One would be SIS_HOME and the other would be SIS_DATA.
>
> So I propose the following policy:
>
> * Only a SIS_DATA environment variable. No Java property, no default
> directory for now.
> * The $SIS_DATA directory must exist - Apache SIS will not create it
> itself (for reducing the risk of messing with user's machine).
> * Some sub-directories inside $SIS_DATA directory will be created by
> Apache SIS. Those sub-directories would be:
> o "DatumChanges" for NADCON, NTv2 and other datum shift data. I
> propose a directory name more generic than "DatumShiftGrids" for
> allowing files that use other algorithms than shifts (e.g. some
> vertical transformation algorithms use spherical harmonics).
> o "DomainsOfValidity" for the polygons that describe the
> geographic areas where Coordinate Reference Systems are valid.
> EPSG distribute those polygons in Shapefile format.
> o "Metadata" for the database used by SIS, including the EPSG
> database (here considered as a special kind of metadata).
>
> SIS would create those sub-directories with a "README.txt" file inside,
> but would not yet put any other files. For unresolved licensing reasons,
> most of those files would have to be downloaded manually by the users
> (the README would provide the links).
>
> Is there any comments?
>
> Martin
>
>
Re: Which directory for referencing data?
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 23/11/15 15:21, Adam Estrada a écrit :
> I would venture to guess that the best practice would be to set an environment variable. One would be SIS_HOME and the other would be SIS_DATA.
So I propose the following policy:
* Only a SIS_DATA environment variable. No Java property, no default
directory for now.
* The $SIS_DATA directory must exist - Apache SIS will not create it
itself (for reducing the risk of messing with user's machine).
* Some sub-directories inside $SIS_DATA directory will be created by
Apache SIS. Those sub-directories would be:
o "DatumChanges" for NADCON, NTv2 and other datum shift data. I
propose a directory name more generic than "DatumShiftGrids" for
allowing files that use other algorithms than shifts (e.g. some
vertical transformation algorithms use spherical harmonics).
o "DomainsOfValidity" for the polygons that describe the
geographic areas where Coordinate Reference Systems are valid.
EPSG distribute those polygons in Shapefile format.
o "Metadata" for the database used by SIS, including the EPSG
database (here considered as a special kind of metadata).
SIS would create those sub-directories with a "README.txt" file inside,
but would not yet put any other files. For unresolved licensing reasons,
most of those files would have to be downloaded manually by the users
(the README would provide the links).
Is there any comments?
Martin
Re: Which directory for referencing data?
Posted by Adam Estrada <es...@gmail.com>.
Martin,
I would venture to guess that the best practice would be to set an environment variable. One would be SIS_HOME and the other would be SIS_DATA.
Adam
> On Nov 23, 2015, at 8:00 AM, Martin Desruisseaux <ma...@geomatys.com> wrote:
>
> I forgot to ask the obvious question: is there a foundation-wide "best
> practice" recommendation about where to put application data? The
> proposal in my previous email creates an "Apache" directory somewhere,
> then a "SIS" sub-directory inside. I would guess that the "Apache"
> parent directory could be of concern to a wider audience than SIS.
>
> Martin
>
>
Re: Which directory for referencing data?
Posted by Martin Desruisseaux <ma...@geomatys.com>.
I forgot to ask the obvious question: is there a foundation-wide "best
practice" recommendation about where to put application data? The
proposal in my previous email creates an "Apache" directory somewhere,
then a "SIS" sub-directory inside. I would guess that the "Apache"
parent directory could be of concern to a wider audience than SIS.
Martin