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 > <[email protected]> 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 > >
