Une communauté d’informations géospatiales est un ensemble de systèmes ou d’individus capables d’échanger leurs données géospatiales grâce à des définitions et des standards communs ainsi qu’une reconnaissance réciproque. Comme il existe une multitude de façons de représenter des informations géospatiales, chaque communauté est amenée à les structurer en fonction de ses centres d’intérêts. Cette diversité complique la tâche des utilisateurs de systèmes d’information géographiques (SIG) en les plaçant devant une variété apparemment chaotique de formats et de structures de données. Les caractéristiques de ces structures varient en fonction des phénomènes observés et des méthodes de mesure, ainsi que des habitudes des organisations produisant les données. Une telle variété agit comme un frein aux études qui requièrent des combinaisons de données hétérogènes, surtout lorsqu’elles proviennent de communautés traditionnellement distinctes. Par exemple, un chercheur étudiant le choléra peut s’intéresser aux populations de crevettes comme vecteur de propagation de la maladie. Mais les médecins et les océanographes n’ayant pas forcement l’habitude de partager leurs travaux, les participants à une telle étude peuvent être limités par les efforts qu’ils sont disposés à fournir pour convertir les données.
Nous ne pouvons pas imposer un format uniforme à l’ensemble des données, car la diversité des formats tient à des facteurs tels que les contraintes des appareils de mesure et la distribution statistique des valeurs. Une solution plus flexible consiste à assurer l’interopérabilité des données à travers une interface de programmation (API) commune. Cette API n’est pas forcement définie dans un langage de programmation; la tendance actuelle est plutôt de définir des conventions utilisant les protocoles web existants, que l’on peut transposer dans des langages de programmation. Mais pour que cette démarche puisse être pérennisée, l’API doit être largement accepté par des développeurs indépendants. Autrement dit, l’API doit s’approcher autant que possible des standards industriels.
Les accès aux bases de données relationnelles sont un exemple de tâche ayant bénéficié d’une standardisation relativement bien réussie. L’industrie a établie un langage commun — le standard SQL — que les concepteurs du Java ont enrobé dans des interfaces de programmation formant le standard JDBC. Ces interfaces sont aujourd’hui implementées par de nombreux logiciels libres et commerciaux. Comme pour les bases de données, des méthodes d’accès aux informations géographiques ont été standardisées. Mais les efforts en ce sens sont plus récents et leurs intégrations dans les logiciels, surtout les plus anciens, sont incomplètes et pas toujours cohérentes. Au moment d’écrire ces lignes, aucun produit de notre connaissance n’implémente la totalité des spécifications. Mais on trouve de nombreuses implémentations couvrant un spectre plus ou moins large. La bibliothèque Apache SIS™ décrite dans ce document en est une.
Apache SIS se caractérise par un effort soutenu de respect des standards. De manière générale, le respect des standards exige un effort plus grand que ce qu’aurait requis un développement isolé, mais se rentabilise par un double avantage: en plus d’accroître l’interopérabilité des données avec celles des projets externes, il nous indique aussi une voie robuste à suivre pour l’élaboration du modèle conceptuel qui sera reflété par l’API. En effet, les groupes d’experts qui conçoivent les standards anticipent des difficultés qui échappent parfois à l’ingénieur en début de projet, mais qui risquent de le rattraper avant la fin.