Des modèles conceptuels vers des interfaces Java: GeoAPI

Le projet GeoAPI offre un ensemble d’interfaces Java pour les applications géo-spatiales. Dans une séries de paquets org.opengis.*, GeoAPI définit des structures représentant des méta-données, des systèmes de référence des coordonnées, ainsi que des opérations effectuant des projections cartographiques. Dans une partie qui n’est pas encore standardisée — dénommée pending — GeoAPI définit des structures représentant des images géo-référencées, des géométries, des filtres pouvant s’appliquer à des requêtes, et d’autres fonctionnalités. Ces interfaces suivent de très près les spécifications de l’OGC, tout en les interprétant et en les adaptant de manière à répondre aux attentes des développeurs Java — par exemple en se conformant aux conventions de nommage. Ces interfaces bénéficient à la fois aux applications clientes et aux bibliothèques:

Pour en savoir plus sur les origines du projet GeoAPI

Historique du projet GeoAPI

En 2001, le consortium Open GIS (l’ancien nom du consortium Open Geospatial) publia la spécification d’implémentation OGC 01-009: Coordinate Transformation Services. Cette spécification, élaborée par Computer Aided Development Corporation (Cadcorp), était accompagnée d’interfaces COM, CORBA et Java. À cette époque, la vague des services web n’avait pas encore éclipsé les interfaces de programmation classiques. Les interfaces de l’OGC anticipaient tout de même un monde connecté en réseau, mais misaient plutôt — dans le cas du Java — sur la technologie RMI (Remote Method Invocation). Bien que le projet GeoAPI n’existait pas encore, nous désignons rétrospectivement ces interfaces historiques sous le nom de « GeoAPI 1.0 ». Ces interfaces utilisaient déjà le nom de paquet org.opengis, qui sera adopté par GeoAPI.

En 2002, des développeurs de projets libres ont lancé un appel à la création d’un API géo-spatial. La proposition initiale suscita l’intérêt d’au moins cinq projets libres. Le projet fut créé sur SourceForge, qui héberge depuis lors le code source dans un dépôt Subversion. Le projet pris le nom de « GeoAPI » à ce moment là, et utilisa les interfaces de la spécification OGC 01-009 comme point de départ.

Quelques mois plus tard, l’OGC lança le projet GO-1: Geographic Objects, qui poursuivait des buts similaires à ceux de GeoAPI. Entre-temps, l’OGC avait abandonné certaines de leur spécifications en faveur des normes ISO. GeoAPI et GO-1 ont joint leurs efforts pour une refonte des interfaces de GeoAPI en les basant sur ces nouvelles normes ISO. La première mouture, GeoAPI 1.0, a servit de point de départ aux premières ébauches de la spécification OGC 03-064 du groupe de travail GO-1. La version finale de cette spécification est devenue un standard OGC en 2005, et GeoAPI 2.0 a été publiée à cette occasion.

Le projet GO-1 était porté essentiellement par une compagnie nommée Polexis. Son rachat par Sys Technology et le changement de priorité des nouveaux propriétaires ont causé l’arrêt des travaux de GO-1, et par ricochet un ralentissement des développements de GeoAPI. Afin de reprendre les développements, un nouveau groupe de travail « GeoAPI 3.0 » a été créé à l’OGC. Ce groupe a réduit les ambitions par rapport à GeoAPI 2.0 en se concentrant sur les interfaces les plus stables, et en plaçant les autres — notamment les géométries — dans un module nommé « pending », pour considérations futures. GeoAPI 3.0 est devenu un standard OGC en 2011. Cette version a été la première à être déployée dans le dépôt central de Maven.

GeoAPI est constitué de plusieurs modules. Les modules geoapi et geoapi-pending fournissent les interfaces dérivées des schémas UML des standards internationaux. Le modèle conceptuel sera expliqué en détails dans les chapitres décrivant l’implémentation Apache SIS. On peut toutefois avoir un aperçu de son contenu en consultant la page listant les types et méthodes de GeoAPI et les standards d’où ils proviennent. Ces modules ainsi que la correspondance entre GeoAPI et les standards internationaux sont décrits plus en détails en annexe.

Implémentations fournies par Apache SIS

Apache SIS implémente la plupart des interfaces de GeoAPI avec une classe du même nom que l’interface, mais préfixée de « Abstract », « Default » ou « General ». Les classes de Apache SIS qui sont préfixées par « Default » peuvent être instanciées directement par une instruction new DefaultXXX(…) ou par la méthode createXXX(…) correspondante d’une fabrique.

Example: pour représenter un système de référence de coordonnées projetées (Mercator, Lambert, etc): Une instance peut être créée par: Les deux approches attendent les mêmes arguments (omis dans cet exemple).

Dans la configuration par défaut de Apache SIS, utiliser FooFactory.createXXX(…) ou new DefaultXXX(…) revient presque au même excepté que les FooFactory peuvent retourner des instances existantes plutôt que de créer systématiquement de nouvelles instances, et que les exceptions en cas d’arguments invalides sont de types différents. Dans des configurations plus avancées, l’usage des Factory permet de réduire la dépendance directe d’une application envers SIS et de permettre une inversion de contrôle.

Le préfix « General » est parfois utilisé à la place de « Default » afin de signaler que des implémentations alternatives existent pour des cas spécifiques. Par exemple l’interface Envelope est implémentée par au moins deux classes de Apache SIS: GeneralEnvelope et Envelope2D. La première implémentation peut représenter des enveloppes de n’importe quelle dimension alors que la seconde implémentation est spécialisée pour les enveloppes à deux dimensions.

Les classes de Apache SIS qui sont préfixées par « Abstract » ne doivent pas – en principe – être instanciées. Il faut plutôt instancier une sous-classe non-abstraites. Toutefois plusieurs classes de SIS ne sont abstraites que conceptuellement, sans que la définition de la classe ne contienne le mot-clé abstract du Java. Ces classes peuvent être instanciées par l’instruction new AbstractXXX(…) – mais pas par les Factory – malgré qu’elles soient conceptuellement abstraites. Mais ces instanciations ne devraient être faites qu’en dernier recours, lorsqu’il n’est vraiment pas possible de déterminer le sous-type exact.