How to use EPSG geodetic dataset
The EPSG geodetic dataset is a de-facto standard providing
thousands of Coordinate Reference System (CRS) definitions
together with information about how to perform coordinate operations, their accuracies and their domains of validity.
The EPSG dataset is owned and maintained by the International Association of Oil & Gas producers.
Usage of EPSG dataset with Apache SIS is optional but strongly recommended:
without that geodetic dataset, only a small subset of CRS definitions will be available
(basically the constants enumerated in the
CommonCRS Java class)
unless full definitions are provided in Well Known Text (WKT) or Geographic Markup Language (GML) formats.
Furthermore, coordinate operations between any given pair of CRS may be less accurate
and their domains of validity may be unspecified if Apache SIS can not query EPSG.
- The EPSG Facilities are published by IOGP at no charge. Distribution for profit is forbidden.
- The data may be included in any commercial package provided that any commerciality is based on value added by the provider and not on a value ascribed to the EPSG Dataset which is made available at no charge.
- Ownership of the EPSG Dataset by IOGP must be acknowledged in any publication or transmission (by whatever means) thereof (including permitted modifications).
- Modification of parameter values is permitted as described in the table 1 to allow change to the content of the information provided that numeric equivalence is achieved.
In order to use the EPSG geodetic dataset with Apache SIS, apply one of the following choices:
Install a local copy with command-line tool
If the command-line tool has been downloaded and installed, just query any CRS. For example:
sis crs EPSG:6676
The first time that the command-line tool needs to query EPSG, it will prompt the user for authorization
copy of the EPSG geodetic dataset will be created and stored in the
Use the local copy in other applications
For using the installed EPSG geodetic dataset in your own application, apply one of the following choices:
- Set the
SIS_DATAenvironment variable to the path of
- Set the
derby.system.homeJava property to the path of
derby.system.home can be set to the path of any other directory which contain the same files.
Examples are shown below for Unix systems, assuming that the current directory is the directory where
has been unzipped:
export SIS_DATA=apache-sis-1.1/data java -classpath apache-sis-1.1/lib/sis-referencing.jar:myApp.jar myMainClass
SIS_DATA environment variable can not be set, Java property can be used as a fallback:
java -Dderby.system.home=apache-sis-1.1/data/Databases \ -classpath apache-sis-1.1/lib/sis-referencing.jar:myApp.jar \ myMainClass
Add a Maven dependency
if they add a
sis-embedded-data dependency (from
org.apache.sis.non-free group) in their project.
Those two approaches have advantages and inconvenient described in following sub-sections.
In both cases, we assume that developers who add those dependencies explicitely in their project agree with
As database installer
sis-epsg artifact on the classpath, Apache SIS will create a local copy of EPSG database when first needed.
The target database must be specified by users with one of the following choices:
- Set the
SIS_DATAenvironment variable to the path of an initially empty directory (recommended). The specified directory must exist, but sub-directories will be created as needed.
- Set the
derby.system.homeJava property to the path of an initially empty directory, or a directory that contain other Derby databases. The specified directory must exist.
- Register a
java:comp/env/jdbc/SpatialMetadataname in a JNDI directory (see next section). The database must exist but can be initially empty.
- Set a
DataSourcefrom Java code.
The Maven dependency is as below (the Derby dependency can be replaced by another database driver if that database is specified by JNDI):
<dependencies> <dependency> <groupId>org.apache.sis.non-free</groupId> <artifactId>sis-epsg</artifactId> <version>1.1</version> <scope>runtime</scope> </dependency> <!-- Following dependency can be omitted on Oracle JDK8 since that Java distributions contain Derby (a.k.a JavaDB). --> <dependency> <groupId>org.apache.derby</groupId> <artifactId>derby</artifactId> <version>10.14.2.0</version> <scope>runtime</scope> </dependency> </dependencies>
See the download page for more information about Maven dependency declaration.
As embedded database
sis-embedded-data artifact on the classpath, there is no need to setup environment variable, Java property or JNDI.
However this simplicity come with the following inconvenient:
- a larger download,
- no option for choosing which data to use (and consequently which license to accept),
- no possibility to choose the database engine (i.e. the database software is fixed to Derby),
- no possibility to add user data (i.e. the database is read-only),
- slower execution of
CRS.findCoordinateOperation(…)methods, unless the JAR file is uncompressed.
This dependency can be declared as below
(see the download page for more information about Maven dependency declaration).
sis-embedded-data should not be specified in the same project; only one is needed:
<dependencies> <dependency> <groupId>org.apache.sis.non-free</groupId> <artifactId>sis-embedded-data</artifactId> <version>1.1</version> <scope>runtime</scope> </dependency> </dependencies>
The performance issue can be avoided if the JAR file is uncompressed.
sis-embedded-data.jar file is more than 5 times larger than the compressed file.
CRS.findCoordinateOperation(…) should not be invoked too often,
and that performance degradation does not apply to the
CoordinateOperation instances created by those method calls,
the JAR file is distributed on the Maven repository in its compressed form.
If desired, better performance can be achieved by using one of the other configurations described in this page,
or by uncompressing the
sis-embedded-data.jar file locally.
Use Java Naming and Directory Interface
While Apache SIS uses Apache Derby by default, it is also possible to use another database software like HSQL or PostgreSQL.
For using an arbitrary database, register a
javax.sql.DataSource instance through the Java Naming and Directory Interface (JNDI).
That registration can be done programmatically (by Java code) or by configuring XML files in some environments.
The database must exist but can be empty, in which case it will be populated with an EPSG schema when first needed
org.apache.sis.non-free:sis-epsg:1.1 dependency is on the classpath
(see above section).
Registration by Java code
Registration can be done by the following Java code, provided that a JNDI implementation is available on the classpath:
// Example using PostgreSQL data source (org.postgresql.ds.PGSimpleDataSource) PGSimpleDataSource ds = new PGSimpleDataSource(); ds.setDatabaseName("SpatialMetadata"); // Server default to "localhost". // Registration assuming that a JNDI implementation is available Context env = (Context) InitialContext.doLookup("java:comp/env"); env.bind("jdbc/SpatialMetadata", ds);
If there is no JNDI environment, the
org.apache.sis.setup.Configuration class can be used as a fallback:
// Fallback if no JNDI environment is available. Configuration.current().setDatabase(() -> ds);
Registration in web application containers
JNDI implementations are provided by web application containers like Apache Tomcat. When Apache SIS is used in a JavaEE container, the data source can be configured as below:
Make the JDBC driver available to the web container and its applications. On Tomcat, this is accomplished by installing the driver’s JAR files into the
If using Derby, copy
$CATALINA_HOME/webappsdirectory and specify the directory where the Derby databases are located (skip this step if another database is used):
- Declare the JNDI name in application
<resource-ref> <description>EPSG dataset and other metadata used by Apache SIS.</description> <res-ref-name>jdbc/SpatialMetadata</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref>
- Configure the data source in
$CATALINA_HOME/conf/context.xmlor in application
META-INF/context.xmlfile (change attribute values as needed for the chosen JDBC driver):
<Context crossContext="true"> <WatchedResource>WEB-INF/web.xml</WatchedResource> <Resource name = "jdbc/SpatialMetadata" auth = "Container" type = "javax.sql.DataSource" username = "sa" password = "sa" driverClassName = "org.apache.derby.jdbc.EmbeddedDriver" url = "jdbc:derby:SpatialMetadata"/> </Context>
- If using Derby, verify on the
localhost:8080/derby/derbynetpage (skip this step if another database is used).
More advanced configurations are possible. For example Tomcat can invoke a custom Java method instead of
fetching the data source from the