content/developer-guide/annexes/geoapi/index.html

<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE html>  <html xmlns="http://www.w3.org/1999/xhtml" xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="en"> <head> <title>Standards</title> <meta charset="UTF-8"/> <link rel="stylesheet" type="text/css" href="../../book.css"/> </head> <body>  <section> <header> <h2 id="Standards">Standards and norms</h2> </header> <p> A geospatial information community is a collection of systems or individuals capable of exchanging their geospatial data through the use of common standards, allowing them to communicate with one another. As there are many ways to represent geospatial information, each community tends to structure this information in light of its areas of interest. This diversity complicates the task of Spatial Information System (<abbr>SIS</abbr>) users by confronting them with an apparently chaotic variety of data formats and structures. The characteristics of these structures vary according to the observed phenomenon and measurement methods, as well as the habits of the organizations producing the data. Such a variety represents an obstacle in studies that require heterogeneous combinations of data, especially when they originate in communities that are traditionally distinct. For example, a researcher studying cholera might be interested in populations of shrimp as a propagation vector of the disease. But as doctors and oceanographers may not be used to share their work, the participants of such a study may be limited by the effort required to convert the data. </p><p> We cannot impose a uniform format on all data collections, as the diversity of formats is tied to factors such as the constraints imposed by the measuring apparatus, and the statistical distribution of values. A more flexible solution is to ensure the interoperability of data across a common programming interface (<abbr title="Application Programming Interface">API</abbr>). This <abbr>API</abbr> is not necessarily defined in a programming language; the actual tendency is rather to define conventions that use existing web protocols, which we can translate into various programming languages. But in order for this approach to be viable, the <abbr>API</abbr> must be generally accepted by independent developers. In other words, the <abbr>API</abbr> must come as near as possible to industrial standards. </p><p> For example, one task that benefit from a successful standardization is the accessing of relational databases. The industry has established a common language — the <abbr title="Structured Query Language">SQL</abbr> standard — that the creators of Java have embedded in standard <abbr title="Java DataBase Connectivity">JDBC</abbr> programming interfaces. Today, these interfaces are implemented by many software programs, both free and commercial. Like databases, methods of accessing geographic information have been standardized. In this case, however, the efforts have been more recent, and their integration in software — especially in older programs — is incomplete and not always coherent. At the time of writing, no product to our knowledge has implemented all of the specifications in their entirety. However, there are many implementations that cover a fairly large spectrum. One of these is the Apache <abbr>SIS</abbr>™ library that is described in this document. </p><p> Apache <abbr title="Spatial Information System">SIS</abbr> is characterized by a sustained effort to comply with standards. In general, complying with standards demands a greater effort than would be required for an isolated development, but rewards us with a double advantage: not only does it improve the interoperability of our data with that of external projects, it also points towards a robust way of elaborating the conceptual model reflected in the <abbr>API</abbr>. In effect, the groups of experts who conceived the standards anticipated difficulties that sometimes escape the engineer at the beginning of a project, but which risk to hit them before the end. </p> <xi:include href="ConceptualModels.html"/> <xi:include href="GeoAPI.html"/> <xi:include href="Modules.html"/> <xi:include href="DefinitionProcess.html"/> <xi:include href="ReduceDependency.html"/> </section> </body> </html>

content/developer-guide/annexes/geoapi/index.html (61 lines of code) (raw):