L’OpenGeo Suite est un ensemble de logiciels destiné à la publication de web services cartographiques et de cartes interactives. Elle fonctionne avec des composants principaux bien connus pour leurs performances et leur stabilité :

• PostGIS pour le stockage des données (couplé à un importateur de Shapefiles)
• GeoServer pour la publication des services (dont OpenGeo fut l’initiateur et reste un des principaux contributeurs)

Associés à ces deux champions de l’OpenSource geospatial, on trouve des outils annexes destinés à faciliter la vie :

• Un système de gestion de cache cartographique tuilé (activé par défaut pour toutes les couches)
• Un module web d’édition des objets cartographiques. Il utilise, comme tous les composants web de la suite, OpenLayers dans une interface GeoExt.
• Un module d’édition des styles sommaire qui permet de générer des fichiers SLD à utiliser pour la publication des couches.
• Un module de consultation et de publication, permettant de composer des cartes à partir des couches de l’entrepôt de données et de les publier.

Associés à ces composants divers par leur rôle et leur technologie, l’intérêt principal de cette suite est à mon avis le Tableau de bord (Dashboard) qui donne accès à chacun d’entre eux depuis une interface unique.

L’ergonomie de chacun des composants est très variable puisqu’il ne s’agit pas d’un ensemble de composants homogènes mais plutôt d’une collection assemblée de manière à facilement fonctionner ensemble. Ainsi c’est PgAdmin qui s’ouvre quand on active le gestionnaire Postgis, et des interfaces web parfois très dissemblables pour les autres composants. Certains sont traduits en français (GeoServer notamment), d’autres pas. Tout cela peut faire ressentir un léger sentiment de confusion et de redondance peut-être (on peut intégrer des données dans PostGis et dans GeoServer par exemple). Regrouper les fonctionnalités d’édition, représentation et publication au sein d’un même composant apporterait sans doute en lisibilité.

L’ensemble reste néanmoins tout à fait opérationnel et permet en quelques minutes de pouvoir publier une carte dynamique dans le GeoExplorer sans beaucoup d’efforts. Par défaut, un joli fond MapQuest/OpenStreetMap l’agrémente, avec des effets de transition sur les tuiles des plus sophistiqués (au passage, merci LeafletJS d’avoir secoué un peu tout le monde sur cet aspect). On peut également obtenir une visualisation 3D via l’activation du GoogleEarth-Plugin, mais c’est un peu gadget.

Au final, les points forts de cette solution restent les composants de base utilisés, à savoir PostGIS et GeoServer, qui, bien optimisés, ne vous lâcheront pas et couvrent un vaste panorama de services OGC (WMS, WFS, WCS et WPS en prototype) ainsi que la sécurisation de leur accès. Les autres composants permettent d’avoir un rendu rapide, bien présenté, et facile à intégrer.

Vous aurez sans doute remarqué que l’OpenGeoSuite n’est cependant pas une Infrastructure de Données Spatiales car il lui manque un… catalogue ! Il y a sans doute là un choix délibéré lié au mode de commercialisation de l’OpenGeo Suite, qui intègre support et formation, et qui n’était donc pas forcément compatible avec l’adjonction d’une produit tiers. Mais qu’on se rassure, GeoNetwork fonctionnant sur les mêmes bases techniques que GeoServer (Java/Tomcat), il n’est pas bien compliqué de l’installer en parallèle et d’y référencer les données et services publiés par la suite. Quelques modules discrets permettent même de publier des données directement depuis GeoNetwork, c’est dire…

Quant au mode de commercialisation évoqué plus haut, il allie OpenSource et licence commerciale. La Community Edition présentée ici est proposée en GPL (attention à la contamination…) tandis que diverses versions commerciales permettent d’y intégrer du support, de la formation et de l’expertise, ainsi que quelques modules complémentaires.

]]> http://www.neogeo-online.net/blog/archives/1698/feed/ 5 http://www.neogeo-online.net/blog/archives/1660/ http://www.neogeo-online.net/blog/archives/1660/#comments Wed, 21 Dec 2011 17:33:31 +0000 François-Xavier Prunayre http://www.neogeo-online.net/?p=1660 Les principales nouveautés pour cette version 2.7.2 sont les suivantes :

• Amélioration des performances (facteur 10 à 20 pour l’interface de recherche ! Cliquez ici pour en savoir plus)
• Amélioration de la documentation avec l’intégration du guide de saisie des éléments de métadonnées INSPIRE
• Amélioration de l’aide de l’application en consultation et en édition
• Impression en mode HTML des différentes vues
• Sélection multiple dans les critères de recherche
  
  
• Filtrage XSL lors du moissonnage pour, par exemple, anonymer vos métadonnées lors de la publication entre un catalogue interne et un catalogue public
• CSW virtuel pour créer un point d’entrée pour un sous-ensemble de votre catalogue
• Historique du moissonnage pour avoir un récapitulatif complet des actions de moissonnage (eg. statistiques, erreurs)
  
  
• Nouveaux raccourcis clavier pour améliorer la navigation dans les résultats
  
  
• Ainsi que de nombreuses autres corrections …

Tous ces travaux ont été financés principalement en Europe par le MEDDTL/BRGM et l’Agence Européenne pour l’Environnement.

A noter également, la communauté des développeurs GeoNetwork vient d’accueillir un nouveau committer : Jesse Eichar qui travaille depuis maintenant 3 ans sur la mise en place de catalogues GeoNetwork ici ou là et qui, de part son expertise du monde géospatial et java (uDig, GeoTools, GeoServer), a toujours proposé des travaux bénéfiques pour le projet.

• JEQL : un langage de script dont la syntaxe est proche de SQL. Il ne s’agit pas d’une interface pour exécuter des requêtes sur une base de données relationnelle mais bien d’un outil pour écrire des traitements sur des données géospatiales avec des capacités de lecture/écriture supportant des formats tels que shapefile et KML. Pour plus d’infos et des exemples, jetez un œil ici et là ;
• Fiona : un module Python écrit par Sean Gillies dont le but est d’offrir une interface élégante à OGR. Il y a quelques mois ce projet se nommait encore WorldMill. Un exemple concis de lecture/écriture de shapefiles avec Fiona et Shapely : Yours truly, Fiona ;
• FDO Toolbox : une IHM graphique pour FDO écrite en .NET (il n’existe qu’une version pour Windows de cet outil) permettant d’accéder de manière unifiée à de nombreux formats de données. Cet outil permet de réaliser des conversions et des traitements de données. Il est possible d’écrire des scripts en Python. Il semblerait que cet outil ne doive plus évoluer (cf. ici).

Bien entendu, ces outils n’ont pas la richesse fonctionnelle d’un ETL tel que Talend Spatial. Ils n’en sont pas moins intéressants.

Qu’à cela ne tienne ! Suivez l’exemple de l’OACI (Organisation de l’aviation civile internationale – institution dépendant des Nations Unies tout de même) et référencez des produits et services très sexy (cf. illustration ci-dessous).

L’URL : http://www.icao.int/Search/pages/Results.aspx?k=7910

Vous verrez que vos utilisateurs ne pourront plus se passer de votre catalogue.

Il est tout à fait possible pour un service WFS d’informer ses applications clientes de l’existence de certaines contraintes sur les données qu’il publie. Cela passe par l’exploitation de l’opération DescribeFeatureType. Celle-ci décrit le modèle des données publiées. Par défaut, ce modèle est exprimé sous la forme d’un schéma XML. Si des listes de valeurs codées doivent être respectées, elles peuvent être définies dans le schéma. Voici un extrait d’un schéma décrivant les réseaux routiers d’INSPIRE :

 <simpleType name="FunctionalRoadClassValueType"> <annotation>[...]</annotation> <restriction base="string"> <enumeration value="mainRoad"> <annotation>[...]</annotation> </enumeration> <enumeration value="firstClass"> <annotation>[...]</annotation> </enumeration> [...] </restriction> </simpleType> 

Cet extrait indique essentiellement que le type FunctionalRoadClassValueType peut prendre l’une des valeurs suivantes : « mainRoad », « firstClass »… Bien sûr, d’autres types de restrictions peuvent être décrits dans les schémas XML (cf. ici).

Le schéma des données permet donc à l’application cliente de présenter un formulaire de saisie ou de recherche adapté à ce type de contrainte (une liste déroulante, une case à cocher ou des boutons radios). Encore faut-il que :

• le schéma publié par le service WFS reflète les contraintes définies au niveau de la base de données elle-même ;
• l’application cliente possède « l’intelligence » nécessaire à l’interprétation de ces contraintes.

En complément, on peut noter que :

• l’expression de contraintes sur les attributs peut également être exprimée à l’aide d’autres langages que les schémas XML. Les schémas JSON sont une alternative possible (cf. ici) ;
• les schémas n’ont pas été conçus pour transmettre aux applications clientes les traductions dans le langage naturel de l’utilisateur des valeurs codées utilisées par la base de données.

Comme souvent la notion d’éclaircissement s’accompagne d’une dose d’obscurcissement, voici un petit résumé de ce que j’ai pu en comprendre…

1. Comment tester ?
   Sans doute pour répondre aux divers besoins exprimés, le document prévoit 2 scénarii de test : soit on teste le service depuis son point d’accès sur internet, soit on le teste depuis l’intérieur de l’infrastructure informatique. Dans ce dernier cas, il faut retrancher le temps de transport réseau pour mesurer la performance. Il s’agit en fait d’établir la différence de temps de transfert entre ce mode et le mode précédent, et de l’appliquer aux résultat obtenus ainsi. C’est une sorte d’extrapolation des résultats qu’on aurait obtenus en testant depuis l’extérieur faite à partir de résultats obtenus depuis l’intérieur de l’infrastructure. Bon, pour la suite, on partira du principe qu’on suit le scénario 1…
2. Mesure de la performance.
   Il faut pouvoir récupérer une image de 470 Ko (800×600 pixels en 8 bits) en moins de 5 secondes, en situation normale. Mais il ne suffit pas que ça marche une fois. Le protocole de mesure indique qu’il faut effectuer plusieurs tests par heure (au moins 10), en n’interrogeant qu’une couche à la fois, mais en faisant varier la bbox pour éviter les effets d’une mise en cache éventuelle. Au final, 90% des mesures doivent être inférieures à ces 5 secondes (c’est la notion de situation normale).  Le chronométrage doit correspondre au premier bit reçu par le client, et non à la réception de l’ensemble de la réponse.
3. Mesure de charge
   Le nombre minimum de requêtes servies doit être de 20 par seconde.  Cette mesure doit être effectuée pendant 1 minute, en envoyant 20 requêtes simultanées par seconde (ce qui associé à l’exigence précédente suppose une bande passante d’au moins 75 Mbps). Pour éviter les biais, il est préférable de réaliser ce test en ayant désactivé l’accès public au service. Concrètement, un test avant la mise en production semble idéal, puis régulièrement (mensuellement selon la recommandation). Dans les 20 requêtes minimum envoyées par seconde, il faut prévoir 10 % de GetCapabilities et 90 % de GetMap (faits selon les exigences de performance vues précédemment).
4. Disponibilité.
   Le service doit être disponible (mais sans forcément atteindre les exigences précédente) 99 % du temps, soit 3,63 jours d’indisponibilité par an au maximum.  Il faut faire au minimum 10 requêtes par heure, qui peuvent être les mêmes que celles utilisées pour mesurer la performance. Néanmoins, les périodes de maintenance ne rentrent pas en compte dans cette mesure, pour peu qu’elles aient été signalées aux utilisateurs (via les portails ou une notification par mail) une semaine à l’avance.

En résumé, si l’on met de côté la mesure de charge qui est particulière, il faut mettre en place un système qui envoie des GetMap sur un layer, en 800×600 avec bbox variable (mais valide, c’est-à-dire incluse dans la bbox du layer tel qu’exposée par le GetCapabilities) plus de 10 fois par heure. Au moins 99 % de ces requêtes doivent aboutir à un résultat (HTTP 200 et image non vide), et le premier bit de ce résultat doit être obtenu en moins de 5s dans au moins 90% des cas. Vous remarquerez néanmoins sans doute un paradoxe : les ViewServices peuvent utiliser du WMS ou du WMTS, mais les indicateurs de QoS ne prévoient pas de mesure particulière sur du GetTile, équivalent en WMTS du GetMap. Si votre service de visualisation WMS ne répond pas aux exigences de qualité de service, vous n’avez donc plus qu’à le basculer en WMTS !

Aujourd’hui, le format par défaut de WFS est le GML. Le standard laisse néanmoins la porte ouverte à d’autres formats. Voici un exemple de requête GetFeature tiré de la version 2.0 des spécifications de WFS et qui demande une réponse en KML :

http://www.someserver.com/wfs.cgi?
SERVICE=WFS&
VERSION=2.0.0&
REQUEST=GetFeature&
TYPENAMES=PLACES&
BBOX=18.54,-72.3544,18.62,-72.2564&
OUTPUTFORMAT=KML

J’ai effectué une petite recherche pour essayer de déterminer si le format GeoJSON est une alternative répandue au format GML du côté des serveurs. Voici quelques exemples de listes de formats issues de services qui indiquent le support de JSON :

text/xml;subtype=gml/3.1.1
application/csv
application/javascript
application/shape
application/serialized.feature

text/xml; subtype=gml/3.1.1
text/xml; subtype=gml/2.1.2
application/json

text/xml; subtype=gml/3.1.1
GML2
GML2-GZIP
SHAPE-ZIP
csv
gml3
json
text/xml; subtype=gml/2.1.2

Plusieurs constats :

• le support de JSON et GeoJSON par les services WFS n’est pas rare mais est loin d’être supporté par toutes les implémentations ;
• certains de ces services supportent JSON mais pas GeoJSON ;
• la distinction entre les deux formats est impossible à faire en lisant les « capabilities » du service ;
• l’utilisation des types MIME n’est pas homogène d’une implémentation à une autre. Pour information, une discussion est en cours à l’OGC pour essayer de l’homogénéiser l’usage des types MIME ;
• les implémentations supportent souvent d’autres formats que GML pour l’opération GetFeature mais pas pour les autres opérations (DescribeFeatureType et Transaction notamment).

En conclusion, oui vous pouvez utiliser du GeoJSON en sortie d’un service WFS. Il y a un « mais » : la déclaration de ce format dans les capabilities des services WFS reste imparfaite ce qui peut entrainer des problèmes d’interopérabilité entre clients et services. Par ailleurs, son usage semble se limiter à l’opération GetFeature. On peut également noter que des initiatives au sein de l’OGC visent à définir des interfaces de services web respectant les principes de REST. Les travaux (propositions faites par ESRI et CubeWerx) allant dans ce sens font figurer JSON et GeoJSON en bonne place.

Note pour ceux qui utilisent MapServer : le support de JSON peut être ajouté en sortie d’un service WFS à l’aide de templates (cf. ici).

Dans le domaine du catalogage, le nombre de fiches augmente de plus en plus, il devient parfois délicat de trouver l’information. Il est alors primordial d’améliorer les mécanismes d’indexation (eg. indexer les ressources associées), les modes de recherches et de représentation des résultats.

Je propose ici 2 expérimentations rapides sur la notion de facettes en utilisant la bibliothèque de composants Javascript de GeoNetwork.

La première consiste à présenter sous forme d’un graphique les résultats de recherche :

La deuxième met en œuvre une recherche par facettes sur le catalogue :

Dans ce deuxième exemple, nous nous rendons compte que l’utilisateur peut rapidement avoir un aperçu des résultats, sans connaître le contenu du catalogue, et avoir une idée des domaines couverts. Le filtre appliqué ici concerne les données sur les océans au 20000e.

Tout cela reste du prototypage reposant sur le module de gestion des facettes ajouté dernièrement dans le moteur de recherche Lucene et sur des tests de cohabitation de Ext.js 3 et 4 pour les représentations graphiques. Rendre complètement opérationnels ces modes de recherche dans GeoNetwork nécessite d’y consacrer encore beaucoup de temps et d’énergie. N’hésitez pas à nous contacter si vous souhaitez faire progresser ces sujets.

• Ajout de la nouvelle interface de recherche et édition à GeoNetwork
• Refonte du système de gestion d’annuaires
• Mise à jour de l’interface de gestion des thésaurus
• Ajout du profil France de l’ISO19139 (iso19139.fra) via le mécanisme de chargement dynamique de profils

Ceci permettra probablement aux 2 projets d’évoluer conjointement plus facilement dans les mois qui viennent.

Pour améliorer la pertinence des recherches, une approche consiste à indexer le contenu des ressources associées (eg. documentation, études, cartes PDF, données géographiques) en plus de leurs métadonnées (un peu ce que font les moteurs de recherche tels que Google).

Prenons l’exemple d’une couche sur la « Liste des parcs et jardins » d’une grande ville. Sur le portail de cette ville, faisons une recherche sur « Buttes Chaumont ». Il est très peu probable que la couche sur les parcs et jardins soit trouvée avec ces critères étant donné que les noms de tous les jardins de la ville ne sont en général pas renseignés dans la fiche (La saisie des fiches serait alors plus que fastidieuse !).

Dans ce cas, l’analyse du contenu des ressources associées et l’ajout de ces informations à l’index permet l’amélioration de la pertinence des recherches.

Un « Proof Of Concept » (POC) a été réalisé avec GeoNetwork et le projet Apache Tika pour l’analyse des documents. Tika supporte de nombreux formats permettant entre autres d’analyser des documents PDF ou XML (eg. une requête GetFeature issue d’un service WFS). Ce POC a permis de valider les étapes suivantes :

• analyse de la métadonnée et identification des resources associées
• analyse des ressources avec Tika
• ajout des informations issues de l’analyse des ressources à l’index pour la fiche

Ces premiers travaux nécessitent des compléments :

• Comment l’intégrer dans l’interface du catalogue ?
• Comment déclencher l’analyse des ressources associées ? Manuellement par l’éditeur qui décide s’il est pertinent de les indexer?
• Est-il judicieux de mettre en place une tâche de fond qui réalise l’analyse pour l’ensemble des fiches du catalogue ? A quelle fréquence ?
• Améliorer les options de configuration et la détection des ressources associées
• Ajout de nouveaux formats dans Tika

Si ce type d’approche vous semble pertinente pour l’amélioration des recherches de votre catalogue, n’hésitez pas à nous contacter pour financer l’amélioration de la fonctionnalité et son intégration dans les projets GeoNetwork et GéoSource.

Contacter François Prunayre (fx.prunayre[--arobase--]neogeo-online.net) pour toute demande de précision.