Geomatys et l'IRD annoncent la sortie de la version 2.3 de l’outil libre de catalogage et de localisation, MDweb. 

Initié en 2003 et ayant connu un important changement de cap technologique en 2010, MDweb continue à progresser, renforçant les capacités de son socle technologique ainsi que sa couverture fonctionnelle. Avec la version 2.3,  l’outil bénéficie aujourd’hui d’une importante mise à jour. 

Concernant les améliorations portées sur la version 2.3, nous tenons notamment à remercier pour leurs contributions : l’EID Méditerranée et le Conseil General de Corse du Sud (CG2A) ainsi que le projet européen GEONETCAB.

Quoi de neuf ?

Un soin particulier a été apporté à la refonte des formulaires d’édition facilitant ainsi la saisie des métadonnées,

Le client cartographique du module de recherche peut à présent afficher conjointement les fonds cartographiques Google, OpenStreetMap ou Geoportail IGN,

La mise en place de la gestion des contacts permettant de raccourcir les temps de saisie de lots de métadonnées.

A présent, l’importation de métadonnées en ISO 19139 est réalisée indépendamment des profils de métadonnées existants dans MDweb. L’ensemble des métadonnées importées sont ingérées et peuvent par la suite être éditées hors profil, 

Enfin, l'utilisation de composants Facelets assure un chargement des clients de recherche, d’édition ou d’administration beaucoup plus performant. 

D’autres améliorations sont à  noter :

• • L’intégration du standard  ISO 19110 permettant de décrire les dictionnaires de données, 
• • La mise en place d’une interface utilisateur pour assurer le moissonnage des catalogues distants via le service CSW, 
• • La prise en compte des guillemets pour rechercher précisément une expression,
• • L’amélioration du composant de saisie des catalogues en recherche,

Une partie des fonctionnalités citées ci-dessus sont présentées dans des vidéos, il suffit de cliquer sur le lien associé pour les visualiser

Vidéos de présentation:

Une série de courtes vidéos ci-dessous, présentent certaines caractéristiques ou fonctionnalités de l'outil.

Mise à jour depuis la version précédente:

Il est désormais possible de procéder à une mise à jour automatisée de la base MDweb, directement depuis l'interface d'installation de la nouvelle version.

Affichage cartographique amélioré:

Une des plus significative est la possibilité de proposer de la reprojection à la volée avec des niveaux de performances élevées. Dans cette présentation, MDweb utilise un fond de référence Google dans sa projection pseudo-Mercator, sur lequel est reprojeté le fond d'orthophotos du Geoportail qui lui est en Lambert 93. Pour cela chacune des tuiles du service WMS-C du Geoportail sont reprojetées et réassemblées à la volée.

Et bien entendu de très nombreuses autres corrections ...

Démonstration en ligne 

Cette nouvelle version est accessible en démonstration à l’adresse suivante : 

http://demo.geomatys.com/mdweb/

Où téléchargez la nouvelle version de MDweb

Vous pouvez la télécharger sur le site officiel MDweb  ou la rubrique Téléchargements du site MDweb ou l'adresse suivante : 

http://www.mdweb-project.org/files/releases/mdweb-2011.09-2.3.war

La documentation 

Sont également disponibles les documentations nécessaires à son installation et son utilisation à l’adresse suivante http://www.mdweb-project.org/files/documentation/2011.09/

- Manuel d’installation  (QuickStart_2.3.pdf)

- Manuel de l’utilisateur (Manual_2.3.pdf)

La mailing list et forum d’échanges MDweb-project

Une mailing list et un forum ont été crée pour permettre l’échange d’informations sur MDweb. http://mdweb-project.869954.n3.nabble.com

Geomatys a réalisé le développement de la version 1.3 en reprenant l'application existante en version 1.2. Le travail a notamment porté sur la documentation, la correction d'anomalies, la création d'une interface d'administration et des programmes d'installation pour Linux, Windows et Mac. L'application est maintenant compatible avec MDWeb et la plupart des autres outils de catalogage de métadonnées.

EXPIRE a été développée à l'initiative de l'Agence de Développement et d'Urbanisme du Grand Amiénois et du Conseil Régional de Picardie durant l'été 2009 (version 1.1), puis améliorée au 2ème semestre 2010 (version 1.2). Le Conseil Général de Corse du Sud ainsi que les partenaires du projet LIFE08ENV/F/000488 (Conseils Généraux de Guyane et de Martinique, EID Méditerranée et EID Rhône-Alpes) ont pris en charge des développements complémentaires réalisés par Geomatys au 1er semestre 2011 (version 1.3).

Les métadonnées saisies sont conformes aux normes ISO 19115 (données géographiques) et ISO 19110 (catalogue d'attributs). L’application permet d’exporter des métadonnées sous forme d’archives ZIP, mais aussi de charger des métadonnées issues d’Expire, de Géosource, de Geonetwork ou de MDweb. Ces données sont ainsi directement importables dans Géosource 2.1+, Geonetwork 2.5+ et Mdweb 2.2.3.

Liste des améliorations majeures de la version 1.3 :

- Création d’une page de diagnostic préalable à l’installation (vérification de la présence d’un serveur et de la version de PHP)

- Création d’installeurs (Windows, Linux et Mac) permettant de combiner l’installation d’EXPIRE et d’un serveur (xampp).

- Ajout d'une page d'administration permettant de configurer facilement certains aspects de l'interface de saisie :

• paramétrage de l'alerte mail,

• gestion du dossier de sauvegarde des fichiers XML,

• gestion du logo de l'application,

• gestion du formatage français pour les champs 'téléphone' et 'code postal',

• gestion des mots-clés,

• gestion des emprises géographiques,

• gestion des systèmes de références spatiales,

• gestion des contacts,

• gestion des spécifications.

- Export PDF et impression des fiches ISO 19139 / ISO 19110.

Liste des améliorations majeures de la version 1.2 :

-Chargement de métadonnée : soit une archive ZIP , soit des fichiers XML issus d’Expire ou de Géosource/Geonetwork.

- Enregistrement d’une métadonnée complète ou non complète en local.

- Double export : une archive compatible avec Géosource 2.1 et 2.2, et une archive compatible avec Géosource 2.3, Geonetwork 2.5 et MDWeb 2.2.

- Possibilité d’enregistrer et de charger des contacts.

Où trouver EXPIRE 1.3 ?

L'application et sa documentation sont disponibles sur Sourceforge : http://sourceforge.net/projects/expire/

Une version de test à été mis en place par Nicolas Rochard de l'ADUGA : http://www.aduga.org/expire_test/

Pour toute question outre Georezo vous pouvez aussi poster ici: http://www.forumsig.org/forumdisplay.php?f=97

Bon catalogage !!!

À la même époque, un effort similaire démarrait à l'OGC : le projet GO-1. Ces deux initiatives ont très rapidement joints leurs efforts, dans le but de donner le cadre structurant de l'OGC au projet GeoAPI et l'inscrire dans la dynamique d'évolution des standards proposés par le consortium. À l'époque, et par manque de ressources, le projet avait été abandonné comme standard OGC, mais continuait à vivre en tant que projet de logiciel libre. En 2009, Geomatys, membre actif de l'OGC, a décidé d'en entreprendre la réactivation, prenant à sa charge l'animation du GeoAPI Standard Working Group à l'OGC.

Le standard couvrant pour l'instant les volets "Utility", "Metadata" et "Référencing" ont été dans un premier temps mis en application en langage Java. La viabilité du modèle a été testé au travers de Geotoolkit.org, son implémentation de référence. Les travaux vont continuer à évoluer de façon à compléter la réalisation de nouvelles interfaces, certaines étant en cours d'élaboration dans la partie "Pending" du projet, avec en particulier la réalisation des interfaces "Geometry" correspondant à la norme ISO19107.

Bien que le projet continue d'évoluer et couvrir un spectre de plus en plus large en matière de fonctionnalités, il est désormais important de confronter ces interfaces à d'autres langages de programmation afin d'en améliorer encore la généricité. A l'heure où le succès des logiciels libres favorisent l'utilisation de bibliothèques et leur inclusion dans des solutions libres et propriétaires (GDAL en est certainement le meilleur exemple), la mise en pratique de ces interfaces sur de nouveaux projets aurait un effet bénéfique sur la maintenabilité de solutions techniquement hétérogènes, et simplifierait grandement les interactions entre projets.

L'OGC vient de voter l'adoption de GeoAPI comme standard, il reste désormais au projet à susciter l'intérêt de communautés libres et des éditeurs pour étendre l'initiative à d'autres langages.

Ce projet est intéressant à plus d'un titre puisqu'il a été l'occasion de mettre en application différentes solutions techniques développées par nos équipes et de les intégrer à la solution de portail Liferay pour en faire une véritable solution de type Géoportail.

Geoviewer : un visualisateur cartographique sous forme de portlet

Le socle technologique

Liferay est une solution de portail d'entreprise développée en Java/JEE, respectant les standards édictés dans le cadre du Java Community Process pour la confection de solutions de portail. L'usage des standards a permis à Liferay de constituer un "Portlet Container", réceptacle technique destiné à accueillir des "portlets" ou composants applicatifs reposant sur le standard JSR 286. De plus, il définit un mode de communication lui aussi standardisé (Inter-Portlet Communication) permettant de faire interagir des portlets pourtant réalisés dans des contextes parfaitement isolés, voire même avec des technologies ou des langages différents. Nous verrons que ces atouts ont été particulièrement précieux dans le cadre de ce projet.

Mais concentrons nous sur la plate-forme :

Outre l'exécution de portlets, Liferay apporte tout un environnement permettant de proposer une intégration poussée dans un environnement d'entreprise. Communication avec des annuaires LDAP, intégration à des solutions d'authentification SSO, CAS, OpenID, possibilité de compartimenter le portail en communautés régies par des droits et des rôles utilisateurs spécifiques, et bien d'autres choses encore.
Liferay embarque notamment une grande quantité de portlets permettant la mise en place de solutions plus classiques de gestion de contenu, d'agendas partagés et de toute une panoplie d'applications utilitaires.

Les composants applicatifs

L'enjeu du projet Sextant était de développer plusieurs composants applicatifs distincts et de les intégrer étroitement de façon à élaborer une application ne laissant transparaître une quelconque hétérogénéité. Dans ce contexte, il était alors nécessaire de mettre en oeuvre tous les avantages proposés par le standard JSR286 et proposer des portlets offrant des interfaces web riches en Javascript autour d'un noyau écrit en Java et communiquant entre eux via le protocole IPC.

Depuis trois ans maintenant, les équipes de Geomatys développent MapFaces une solution hybride mixant Java/JEE et Javascript avec pour objectif de proposer des clients WebSIG parfaitement intégrés en environnement JEE. Notre objectif était depuis longtemps tourné vers le portail et ses standards, c'est donc tout naturellement que nous avons utilisé ce framework cartographique pour concevoir les deux portlets que nous avions été chargés de développer.

MapFaces reposant sur le framework de présentation JSF élaboré dans le cadre du JCP (JSR 314), il a donc naturellement hérité d'une bonne aptitude à supporter la structuration en portlets et à proposer une parfaite intégration avec Liferay.

Le portlet Geoviewer est le composant de visualisation cartographique du portail. Cet outil permet de visualiser un grand nombre de couches cartographiques provenant d'une multitude de services WMS. Ces derniers sont fournis par des solutions variées, telles que Mapserver ou Constellation-SDI pour les sources d'informations multidimensionnelles. Ce geovisualiseur comporte toutes les fonctions classiques de ce type d'outil avec, en plus, la capacité d'interroger les services multidimensionnels et notamment les modèles Coriolis, Mars2D ou Mars3D.

MapFaces a été développé parallèlement à Constellation-SDI, nous nous sommes donc efforcés de proposer un module client pour chaque Web service proposé par Constellation. Ainsi, le Geoviewer est déjà en mesure d'interroger le service de consultation de données issues de capteurs (SOS / SOS-T) par ailleurs mis en place pour servir les informations in-situ des flotteurs fixes et dérivants gérés par l'IFREMER. Dans une dimension prospective, il y a fort à parier que les évolutions de Sextant pourront proposer la consultation de ces sources d'informations au moyen de composants additionnels.

Le portlet Panier est un module d'extraction de données reposant sur une solution en mode "batch". L'interface permet simplement de définir des jeux de données, de spécifier le système de référence spatial des données en sortie, de saisir une emprise, et de lancer la commande qui exécutera alors la tâche. Une fois l'extraction terminée, l'utilisateur sera informé par mail de la disponibilité des couches de données sur un serveur de téléchargement. Ce module se greffe à des services d'extraction existants au sein du système d'Information de l'institut et apporte une capacité d'interaction avec les autres portlets du projet. 

Interactions au sein du portail Sextant

L'intégration des portlets

Ce dernier volet illustre pleinement les avantages d'une solution de portail mise en place dans un contexte multi-prestataires. Comme évoqué au début de cet article, l'Ifremer a eu recours à deux prestataires pour la réalisation des composants du portail. Le premier en charge de la mise en oeuvre du catalogue et du client qui l'exploite, le second (Geomatys en l'occurrence) en charge des deux composants sus-mentionnés et de l'intégration de l'ensemble des portlets sur le portail Liferay ainsi que de leur communication et leur configuration.
Pour ce projet, le portlet Catalogue étant développé par un autre prestataire, des technologies différentes aux nôtres ont été employées (en l'occurrence une association OpenLayers/JQuery). Nous avons récupéré les développements fournis au cours de la réalisation du projet et les avons encapsulés à du code Java afin de permettre la configuration globale dans le portail.
Enfin, après avoir intégré les trois modules métiers dans Liferay, nous avons travaillé à les faire communiquer entre eux en mode IPC. Ainsi il a été possible de faire interagir des composants développés avec des solutions techniques différentes pour en faire une solution d'apparence homogène.

Utilisation de l'IPC dans un contexte de portlets hétérogènes

Ici l'utilité de la solution portlet est double puisque cela permet aux composants de communiquer entre eux avec un niveau de granularité très fin (une action sur un bouton dans le portlet A peut provoquer une action sur un des composants dans le portlet B). Par ailleurs, les règles de gestion des droits fournies au niveau du "portlet container" s'appliquent de façon transparente à tous les portlets conçus à cet effet.

Aussi, ce concept de portlets et la capacité d'interaction apportée par ce standard ouvrent des perspectives encourageantes en matière de modularité et d'évolutions fonctionnelles pour des applications Web-SIG structurées sous formes de Géoportail. Il est important de ne pas les confondre avec certaines pratiques mettant en oeuvre des Iframes (il existe également des portlets encapsulant des Iframes), car il est alors impossible de proposer une quelconque interaction directe entre les modules.

Dans le cadre de ce projet, le portail Liferay a également été enrichi afin de permettre une gestion globale et évolutive de la configuration cartographique de chacun des portlets pour chacune des communautés. D'une manière simple, il est possible de paramétrer l'étendue initiale des contextes cartographiques, des zooms prédéfinis, l'URL du fichier de contexte cartographique à charger dans tel ou tel portlet, l'URL du serveur CS-W pour le portlet Catalogue etc... Bref, chaque communauté (ou "sous-portail" comportant ses propres portlets) est en capacité d'utiliser les mêmes modules de base, mais configurés de manières totalement différentes.

Gestion des configurations dans Sextant

L'application est consultable à l'adresse suivante : http://www.ifremer.fr/sextant

Cela impose également  le développement d'une architecture d'échange entre les différents domaines d'application représentés au sein de l'OGC (météorologie, aviation, urbanisme, ...). Ces questions ont été discutées par le groupe de travail « Simple Features ». La principale réflexion porte sur le niveau de granularité que le groupe de travail doit adopter pour ses futurs travaux basés sur la géométrie (ISO 19125, 19107, ...). La proposition serait d'utiliser des classes de conformité afin de définir des profils à la manière de « GML Point Profile ». La question de l'ajout et de l'utilisation de primitives plus complexes a été également abordé par le groupe de travail. Cette question a conduit à une explication théorique sur les courbes paramétriques telles que Bézier, B-Spline et NURBS.

Cette même dynamique autour des courbes était également présente durant la présentation du groupe « Aviation DWG ». Leur problématique principale est clairement basée sur une volonté d’une utilisation de GML. Pour cela, le groupe a exposé l'ensemble des contraintes lié à leur domaine (spécification obligatoire du sens d'une courbe, système de référencement propre, utilisation d'arcs). Les algorithmes géométriques présentés peuvent être développés dans le cadre du « Geometry WG ». Le « SF WG » a d'ailleurs proposé une réunion « Géométries pour les SIG » avant le TC de Boulder en septembre 2011.

D'autre part, GEOMATYS développe actuellement une démo pour cette occasion avec une extension du projet Globe3D. Ce prototype a pour but de mettre en avant les avantages de l'utilisation de ces géométries (figure 1), par exemple dans le domaine aérien avec de l'analyse 3D. Les acteurs du Foss4G seront également de la partie pour une discussion plus globale.

Figure 1 : Trajectoire d'un aéronef en GM_CubicSpline (Catmull-Rom)

Le laboratoire LSIS  en partenariat avec la société GEOMATYS a présenté un module décisionnel « Dispatcher » (voir figure 1) s'appuyant sur la norme ISO 19107:2003. Le prototype développé (Globe 3D) introduit la possibilité d'utiliser une représentation homogène des primitives géométriques, en utilisant des objets 2D/3D paramétriques. Par exemple, l'application modélise le globe Terrestre avec une sphère rationnelle (NURBS), les routes utilisent la même représentation générique. L’analyse peut donc se résumer à des opérations entre deux mêmes objets. Cela a pour but de simplifier grandement le développement du module d'analyse. D'ici peu de nouvelles primitives seront traduites sous forme rationnelle et ajoutées à Globe 3D.

Figure 1 : interaction Dispatcher/ISO 19107 

Ces courbes peuvent être classifiées en 4 familles distinctes. La première représente les interpolations linéaires (segment), la seconde définit les courbes circulaires comme un arc ou un cercle. Les deux dernières regroupent les courbes polynomiales, les interpolantes (type Hermite) et les approximantes (Bézier, B-Spline). Des premiers résultats d'implémentation de ces courbes ont été également donnés.

La problématiques c'est ensuite tournée vers une proposition d'intégration dans GeoAPI d'un nouveau type de courbe contenu dans la version draft de la norme ISO19107 éditée en 2007. Cette nouvelle courbe paramétrique (Nurbs) est une formulation générale des courbes déjà présentes dans la norme ISO 19107:2003. Elle permettrait d'obtenir un unique type d'objet courbe (représentation rationnelle) .Cela aurait pour conséquence directe de simplifier les méthodes d'analyse. Ce type de courbe est aussi très utilisé en CAO et favoriserait la mise en place d'un pont entre les 2 secteurs de marché. GEOMATYS a d'ores et déjà débutée le développement des interfaces GeoAPI nécessaires à son utilisation de manière transparente pour l'utilisateur final.

En-effet, GeoApi permettra de rendre automatique la formulation et l'utilisation de ce type de courbe pour l'analyse. Un premier prototype devrait sortir en 2011. Une proposition d’extension pour GeoAPI s'en suivra dans la librairie open source http://www.geotoolkit.org.