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
