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.

> Mettre à disposition ses fichiers de données

GéoSource et GeoNetwork ont toujours permis de téléverser des fichiers de données dans le but de les rendre téléchargeables à partir des fiches de métadonnées. Pour cela, il faut :

• aller dans la section distribution,
• ajouter un élément ressource en ligne et
• sélectionner le protocole fichier à télécharger.

Le catalogue propose alors à l’éditeur un outil d’upload de fichier. Le fichier peut être un rapport, une étude, des images, ou des données géographiques. Les données sont alors accessibles dans la fiche :

> Publier des données via un service de visualisation et téléchargement (WMS, WFS)

Le catalogue est en mesure de « pousser » la donnée dans un serveur cartographique. En l’occurrence, GeoNetwork est capable de déployer une donnée dans GeoServer. L’idée est de simplifier le processus de publication des données sans avoir recours à une interface d’administration ou un fichier de configuration parfois complexe.

Les formats actuellement supportés sont :

• GeoTiff
• ESRI Shapefile
• Table PostGIS

Une fois les fichiers (ou les références aux tables) associés à une fiche, la publication dans le service cartographique est faite via l’interface suivante en quelques clics :

L’assistant ajoute les liens au service WMS et à la couche automatiquement à la fiche de métadonnée.

Si l’extension SLD Editor de GeoServer est installée, il vous sera également possible de définir le style des couches à partir du catalogue.

Pour activer l’outil de publication, il suffit de décommenter la ligne suivante dans le fichier WEB-INF/config-gui.xml :

<editor-geopublisher/>


Par défaut, la configuration utilise le composant GeoServer installé avec le catalogue, mais il est possible d’ajouter d’autres instances (eg. en test, en intranet, en internet) via le fichier de configuration WEB-INF/config-geoserverpublisher.xml.

> Gérer les privilèges d’accès et informer sur les contraintes d’accès

Dans la gestion des privilèges, il est alors possible d’autoriser ou pas le téléchargement ou la visualisation de ces données à un ou plusieurs groupes, voire au public.

Pour les fichiers, ils sont sous le contrôle du catalogue qui en gère les accès avec le privilège « télécharger ». Le privilège « carte interactive » indique au catalogue s’il doit présenter les informations concernant les liens WMS aux utilisateurs (ie. liens vers le WMS, boutons « ajouter à la carte »), il s’occupe de supprimer ces informations en fonction du profil de l’utilisateur. Quoiqu’il en soit, un utilisateur récupérant l’adresse du WMS par un autre moyen aura accès à l’information, celle-ci étant sous le contrôle du serveur WMS (il faudrait ici des processus de synchronisation des droits d’accès gérés par le catalogue et ceux du WMS).

Pour le téléchargement des données, le catalogue propose un assistant qui permet :

1. la sélection de tout ou partie des données uploadées
2. la présentation des contraintes légales et restrictions à l’utilisateur renseignées dans les métadonnées
3. le remplissage d’un formulaire d’identification
   
4. et enfin l’accès au téléchargement d’une archive contenant les métadonnées, les données demandées ainsi qu’un exemple de licence (rappelant la liste des fichiers, le titre de la donnée, les contraintes et l’utilisateur)

L’aspect génération de licence sera sans doute un point à améliorer mais permet d’ores et déjà d’utiliser le contenu des métadonnées pour générer un document de suivi de la donnée.

> Consulter le tout

L’intégration entre les métadonnées, les données et les services de visualisation est réalisée par l’interaction entre les résultats d’une recherche dans le catalogue et la visualisation cartographique des données.

Pour cela, GeoNetwork propose un module de cartographie interactive permettant d’afficher les couches référencées dans les métadonnées de données et d’ajouter des couches depuis un service référencé dans le catalogue. Ce module est désactivé dans la nouvelle interface utilisée par GéoSource.

Il présente les fonctionnalités standards d’une visionneuse cartographique :

• Navigation
• Gestion (ordre, transparence, …) et interrogation des couches
• Légende
• Impression PDF

Pour activer ce module dans GéoSource, dans le répertoire web/geosource/apps/search, modifiez les fichiers index.html et index_debug.html en supprimant :

<link rel="stylesheet" type="text/css" href="../css/hidemap.css"/>


Dans le fichier js/Settings.js et js/App-mini.js (version compressée) remplacez

GeoNetwork.MapModule = false;
par
GeoNetwork.MapModule = true;


Le module de cartographie interactive est maintenant disponible, il est alors possible de basculer de la perspective découverte à celle de visualisation. Notez également que la carte par défaut utilise les données OSM et donc que la projection est Mercator. Les services WMS utilisés doivent donc supporter cette projection.

> Interagir avec les sites existants

Concernant l’intégration avec des sites institutionnels ou un CMS, il est fréquent d’utiliser les modules RSS ou iFrame pour associer les informations du catalogue avec les pages du CMS. Le flux RSS disponible sur la page d’accueil du catalogue retourne les derniers ajouts. Il est également intéressant de savoir qu’il est possible de faire des recherches via RSS, ainsi il possible d’associer à un article sur un thème ou un territoire les résultats du catalogue correspondant. Par exemple, « http://localhost:8080/geosource/srv/fr/rss.search?any=savoie » retournera les informations sur la Savoie.

Voici donc un aperçu des fonctionnalités avancées disponibles dans GeoNetwork pouvant aider à mieux intégrer le catalogue au sein de votre SI géographique.

Le graphique ci-dessous montre les temps de traitement obtenus avec l’un et l’autre des deux composants. Attention, les échelles sont logarithmiques ; les gains de performance sont bien plus importants qu’il n’y parait à première vue donc.

Nous en avons profité pour publier la version 4.1.2 de Talend Spatial (cf. ici). Les composants Sextante, toujours en version bêta, sont disponibles dans un paquet séparé au même endroit.

• Vue par défaut
• Vue découverte ou INSPIRE
• Vue essentielle
• Vue ISO
• Vue avancée
• Vue XML

Ci-dessous, vous trouverez quelques pistes pour simplifier l’apparence du formulaire de saisie de GéoSource en reprenant quelques idées du projet EXPIRE :

• Un peu de CSS
  
• Désactivez les options non utilisées. Dans le fichier WEB-INF/config-gui.xml,
  • supprimez la gestion des relations entre métadonnées en mettant en commentaire :

    <!--
    <editor-metadata-relation/>
    -->

  • Cachez la vue essentielle et la vue XML tout en conservant tout de même la vue avancée qui sera la seule vous permettant (si un jour vous le souhaitez) d’ajouter l’ensemble des éléments du standard ISO19139. La vue découverte ou INSPIRE sera la vue affichée par défaut du fait de l’attribut « default » mis à « true ».

    <metadata-tab>
      <inspire flat="true" default="true"/>
      <advanced/>
    </metadata-tab>

• Configurez les listes de valeurs pour simplifier la saisie. En effet, il est possible d’ajouter un attribut « hideInEditMode » aux éléments « entry » dans le fichiers de configuration de ces listes (dans xml/schemas/iso19139/loc/fr/codelists.xml). Par exemple, pour ne pas proposer « Exécutant » pour le rôle des contacts :

  <entry hideInEditMode="true">
    <code>processor</code>
    <label>Exécutant</label>
    <description>Organisme qui a réalisé des
  traitements sur la ressource. Acteur qui est intervenu lors
   de la réalisation de la ressource</description>
  </entry>

   Cela permet de simplifier la saisie tout en restant compatible avec des métadonnées que vous pourriez moissonner et qui contiendraient ces valeurs.

• Modifiez le formulaire. Pour ceux d’entre vous que le language XSL ne rebute pas trop, il est possible de transformer les listes de choix en bouton radio pour avoir un aperçu rapide des options possibles (par exemple lorsque le nombre de valeurs possibles est inférieur ou égal à 3). Ceci nécessite une adaptation du mécanisme de génération de l’éditeur dans xsl/metadata-iso19139.xsl ligne 729.

  <xsl:variable name="maxNumberOfItemsForRadio" select="3"/>
  <xsl:variable name="nbItems" select="count($codelist/entry[not(@hideInEditMode)])"/>
  
  <xsl:choose>
    <xsl:when test="$nbItems <= $maxNumberOfItemsForRadio">
      <xsl:variable name="fieldName" select="concat('_', ../geonet:element/@ref, '_', name(.))"/>
  
      <input type="radio" name="{$fieldName}" id="{$fieldName}_" value=""/>
      <label for="{$fieldName}_">Inconnu</label>
      <xsl:for-each select="$codelist/entry[not(@hideInEditMode)]">
        <xsl:sort select="label"/>
          <input type="radio" name="{$fieldName}" id="{$fieldName}_{position()}">
            <xsl:if test="code=$value">
              <xsl:attribute name="checked">checked</xsl:attribute>
            </xsl:if>
            <xsl:attribute name="value"><xsl:value-of select="code"/></xsl:attribute>
          </input>
          <label for="{$fieldName}_{position()}"><xsl:value-of select="label"/></label>
        </xsl:for-each>
     </xsl:when>
     <xsl:otherwise>
       <!-- codelist in edit mode -->

  

• Cachez certains champs. L’organisation des champs mise en place dans GéoSource dans la vue découverte est inspirée de l’éditeur disponible sur le portail INSPIRE. Elle reprend les champs décrits dans les règles d’implémentation INSPIRE sur les métadonnées. Il est cependant possible de la modifier dans le fichier xsl/metadata-iso19139-inspire.xml. Par exemple, supprimez

  	../../gmd:fileIdentifier|
  	../../gmd:language|
  	../../gmd:metadataStandardName|
  	../../gmd:metadataStandardVersion|
  	../../geonet:child[string(@name)='language']|
  	../../gmd:characterSet|
  	../../geonet:child[string(@name)='characterSet']|

   vers la ligne 500 pour ne plus voir les champs identifiant, langue des métadonnées, nom et version du standard. En remplissant vos modèles de saisie par les valeurs adéquates, plus besoin « d’ennuyer » les éditeurs avec ces descripteurs, vous pourrez toujours si besoin passer en vue avancée pour changer les valeurs.

Voici donc un aperçu de quelques options de configuration de GeoNetwork & GéoSource.

Le problème se situe au niveau du calcul de la BBOX de la couche en coordonnées géographiques (WGS84), dont le résultat est exposé dans la balise EX_GeographicBoundingBox du GetCapabilities. Le calcul de cette BBOX se fait sans vérifier que le méridien d’origine de la projection source de la donnée est bien Greenwich, qui est celui utilisé par le WGS84. Dès lors, si vos données sont dans un système de référence utilisant le méridien de Paris comme origine (les Lambert français de la NTF par exemple, à la différence du Lambert 93 (RGF93) qui utilise Greenwich plus un décalage), la BBOX en WGS84 sera erronée car décalée de plus de 2 degrés vers l’ouest.

Bon, mais qu’est-ce que ça change en pratique ? Je suis sûr que nombre d’entre vous ont déjà utilisé MapServer en WMS 1.3.0 sur ce type de projection sans rencontrer de problème… Il se trouve que certains logiciels clients WMS (l’excellent QGis notamment), plus malins que d’autres, se servent de cette information pour déterminer l’emprise de la couche (quelle que soit la projection utilisée pour l’affichage d’ailleurs), et n’envoient donc pas de requête au serveur WMS quand la vue se situe à l’extérieur de cette emprise, afin de ne pas solliciter inutilement le serveur. Finaud donc. Si vous publiez des données France entière, il y aura recouvrement, et donc pas de problème (à moins peut-être de zoomer sur Strasbourg par exemple. A tester sur vos services WMS 1.3.0 préférés avec QGIS. J’en ai déjà trouvé un…). Mais si l’emprise de vos données est suffisamment étroite (une agglomération par exemple), vous ne verrez tout simplement rien là où vous comptiez les voir apparaître, car d’après le GetCapabilities les données ne se trouvent pas là du tout. Vous ne verrez non seulement rien, et certainement pas d’erreur, et vous risquez de passer quelque temps (je parle d’expérience) à vous creuser la tête pour comprendre ce qui ne va pas dans votre configuration. Sauf que la configuration va bien. Là où ça devient énervant, c’est que les clients WMS qui envoient comme des bourrins des requêtes au serveur où qu’on se situe, ignorant par là la présence et le rôle de la balise EX_GeographicBoundingBox, ces barbares donc, vont eux recevoir une réponse correcte, puisque la reprojection de la donnée elle-même fonctionne normalement. Funeste sort que celui des clients WMS les plus exigeants, les plus respectueux de l’esprit de l’inter-opérabilité, induits ainsi en erreur par un calcul approximatif.

Mais heureux dénouement qui voit les lecteurs assidus de ce blog non seulement informés mais dépannés par un patch tout frais déposé sur le bug-tracker de MapServer ! Pour l’utiliser, il suffit de l’appliquer (commande patch mapows.c wms_1.3.0.patch) au fichier source puis de recompiler et remplacer son mapserv par le nouveau. Il devrait également être rapidement disponible dans la version officielle.

Toutes nos félicitations à nos deux représentants nationaux, et n’hésitez pas à retrouver leurs prestations dans la rubrique webcasts du site de l’OSGIS 2010.

London at Night est une application permettant de calculer des temps de parcours en bus de nuit dans l’agglomération londonienne. On ne peut pas vraiment choisir sa ligne, mais pour un point donné on obtient la carte des endroits accessibles en moins de n minutes. Rien de révolutionnaire jusqu’ici. Sauf que le traitement et son rendu sont réalisés directement sur le client. Une immense matrice grise recouvre l’habituel fond Google (en mode nuit cependant), et c’est le passage en transparence complète des diverses cases qui illumine le fond pour mettre en avant la zone correspondant à vos critères. Outre la qualité visuelle du rendu, et la rapidité à laquelle il est obtenu, cette expérimentation ouvre sans doute la voie à d’autres dans une approche cliente du traitement raster. Son auteur, Stephan Wehrmeyer, présente sa démarche sur son blog.  A suivre donc. Par ailleurs, le code est disponible sous licence CC-by-nc-sa.

via GoogleMapsMania.