It is possible to instantiate data structures programmatically in memory. But more often, data are read from files or other kinds of data stores. There is different ways to access those data, but an easy way is to use the DataStores.open(Object) convenience method. The method argument can be a path to a data file (File, Path, URL, URI), a stream (Channel, DataInput, InputStream, Reader), a connection to a data base (DataSource, Connection) or other kinds of object specific to the data source. The DataStores.open(Object) method detects data formats and returns a DataStore instance for that format.

DataStore functionalities depend on the kind of data (coverage, feature set, time series, etc.). But in all cases, there is always some metadata that can be obtained. Metadata allows to identify the phenomenon or features described by the data (temperature, land occupation, etc.), the geographic area or temporal period covered by the data, together with their resolution. Some rich data source provides also a data quality estimation, contact information for the responsible person or organization, legal or technical constraints on data usage, the history of processing apply on the data, expected updates schedule, etc. The metadata structures depends on the data formats, but Apache SIS translates all of them in a unique metadata model in order to hide this heterogeneity. This pivot model approach is often used by various libraries, with Dublin Core as a popular choice. For Apache SIS, the chosen pivot model is the ISO 19115 international standard. This model organizes metadata in a tree structure. For example if a data format can provides a geographic bounding box encompassing all data, then that information will always be accessible (regardless the data format) from the root Metadata object under the identification­Info node, then the extent sub-node, and finally the geographic­Element sub-node. For example, the following code read a metadata file from a Landsat-8 image and prints the declared geographic bounding box:

import org.opengis.metadata.Metadata;
import org.opengis.metadata.extent.GeographicBoundingBox;
import org.apache.sis.storage.DataStore;
import org.apache.sis.storage.DataStores;
import org.apache.sis.storage.DataStoreException;
import org.apache.sis.metadata.iso.extent.Extents;

void main() throws DataStoreException {
    try (DataStore store = DataStores.open(new File("LC81230522014071LGN00_MTL.txt"))) {
        Metadata overview = store.getMetadata();

        // Convenience method for fetching value at the "metadata/identification­Info/geographic­Element" path.
        GeographicBoundingBox bbox = Extents.getGeographicBoundingBox(overview);

        System.out.println("The geographic bounding box is:");
        System.out.println(bbox);
    }
}

Above example produces the following output (this area is located in Vietnam):

The geographic bounding box is:
Geographic Bounding Box
  ├─West bound longitude…………………………… 108°20′10.464″E
  ├─East bound longitude…………………………… 110°26′39.66″E
  ├─South bound latitude…………………………… 10°29′59.604″N
  └─North bound latitude…………………………… 12°37′25.716″N

Metadata are covered in more details in a latter chapter. Among metadata elements, there is one which will be the topic of a dedicated chapter: reference­System­Info. Its content is essential for accurate data positioning; without this element, even positions given by latitudes and longitudes are ambiguous. Reference systems have many characteristics that make them apart from other metadata: they are immutable, have a particular Well-Known Text representation and are associated to an engine performing coordinate transformation from one reference system to another.