Bonjour, je complète l'échange sur l'alimentation de geonetwork sans passer par la case interface graphique. François propose l'utilisation d'un ETL (Extract Transform Load), solution que je teste actuellement. J'utilise les produits GPL suivants :
* Talend Open Studio (Tos téléchargeable ici :
http://www.talend.com/download_form.php )
* son dérivé SDI (Spatial Data Integrator téléchargeable ici :
http://www.spatialdataintegrator.com/ ).
SDI comporte des composants spécifiques pour les objets géographiques et permet par exemple de créer une fiche métadonnées dans géonetwork à partir d'un shapefile. Il est possible de créer des fiches métadonnées directement dans la base ou bien de créer les fichiers XML à importer. Voici le fruit de notre réflexion :
Intégration directement dans la base de données :
Structure et Intégrité de la BDD
o
Une fiche métadonnées fait l'objet d'un enregistrement dans
la table metadata. Le champ data de type texte contient le
contenu XML de la fiche, à savoir ce que l'opérateur
renseigne avec l'interface.
o
La relation avec la table Metadatarating doit servir
uniquement si la fiche provient d'un moissonnage.
o
Une fiche peut être associée à 0 ou n catégories. Par défaut
aucune.
o
Une fiche peut être associée à 0 ou 1 utilisateur (table
users) : le propriétaire de la fiche.
o
Une fiche peut être associée à 0 ou 1 groupe (table groups)
: le groupe propriétaire de la fiche.
o
Une fiche ne peut être associée qu'à un groupe auquel
appartient l'utilisateur qui saisit dans l'interface
geonetwork. Cette contrainte est implémentée dans le code
logiciel et non dans la base sous forme de trigger par exemple.
o
La création d'une fiche par l'interface accorde les
privilèges 0, 1 , 3 et 5 (Publier, Télécharger, notifier et
Intercative Map) au groupe propriétaire. A noter que le
groupe All correspond à l'id 1 et le groupe Intranet à l'id
Création de la fiche
Certains champs nécessitent un traitement particulier lors de l'insertion :
o
id : série chronologique et clé primaire
o
uuid, source, harvestuuid : unicité
o
owner : clé externe sur la table users (champ id)
o
groupowner : clé externe sur la table groups (champ id)
o
le champ source : prend la valeur identifiant le serveur
geonetwork. Cette valeur est stockée dans la table settings
(id =12, parentid = 10, name = siteId, value = 'identifiant
recherché'). Ce champ est indépendant du contenu xml qui
comporte lui-même une entrée source.
o
Il n'y a pas de contrainte sur le champs UUID (présent aussi
dans le contenu du champ data) mais il est prudent de
laisser le système générer cette valeur (cas de l'import XML
notamment).
Génération de fichiers XML à importer :
* L'ETL TOS permet de créer les fichiers XML (Test en Dublin
Core) qu'il faut ensuite placer sur le serveur Geonetwork puis
importer en tant qu'administrateur.
Réflexion sur les 2 approches :
La création de fiches directement dans la base permet toute latitude, y compris la définition du propriétaire des fiches et l'apposition de permissions spécifiques ... En revanche elle peut oublier des traitements qui ne sont pas visibles directement mais qui sont réalisés par le logiciel geonetwork (index du contenu XML par exemple ...)
L'import XML est plus facile à implémenter mais nécessite le tranfert des fichiers sur le serveur Geonetwork avant un lancement manuel (ou par URL ?) du traitement d'import. Les valeurs par défaut sont utilisées (propriétaire des fiches et permissions notamment).
Alternative :
Utiliser l'import XML pour la création des fiches puis relancer un traitement permettant de compléter par l'ETL. La difficulté est de pouvoir identifier formellement les fiches une fois créées dans geonetwork. Les premiers tests seront réalisés avec des fiches au format Dublin Core et nous utiliserons le champ <dct:created>mes informations</dct:created> pour indiquer les informations que nous voulons ensuite exploiter (identifiant entrerise, propriétaire ... Une autre convention pourra être déterminée par la suite si besoin.
J'espère que ces informations pourront servir à certains d'entre-vous et peut-être seront complétées. Je n'en suis qu'à des tests de mécanisme très encourageants. Alain. ----------------------------------------------------------------------------------------------------------------- Date: Thu, 18 Feb 2010 16:29:50 +0100 From: Francois Prunayre <fx.prunayre@anonymised.com> Subject: Re: [GeoNetwork-users-fr] :automatisation du remplissage des fiches de métadonnées To: jerome.nowicki@anonymised.com Cc: geonetwork-users-fr@lists.sourceforge.net Message-ID: <625a08131002180729s404b6e5ci9803642b9415e0d1@anonymised.com> Content-Type: text/plain; charset=windows-1252 Bonjour, Le 18 février 2010 15:59, <jerome.nowicki@anonymised.com> a écrit :
>
> Bonjour,
> Nous souhaitons automatiser la saisie de nos fiches de métadonnées en effectuant
> des requêtes sur la base de données.
Que contient votre base de données ?
> Est-ce que parmi vous certains l?ont fait ? si oui, pour quelle volumétrie ? et
> combien de temps cela vous a pris ?
Quelques pistes et exemples [1]:
* utilisation d'un ETL :
* pour la génération de métadonnées pour des Shapefiles
* pour des cartes aux formats PDF
* par moissonnage de service web
> Autre question, peut-on faire de même pour les métadonnées de service ?
GeoNetwork dispose d'une interface de moissonnage pour les services
OGC et les bases ArcSDE.
Après fonction de votre format, il est sans doute nécessaire de mettre
en place la récupération des informations à partir des données.
Une fois générée, se pose également le problème de synchronisation
entre les données et les métadonnées (le moissonnage périodique répond
en partie à ce problème).
Salutations.
Francois