Discussion :

[pyrotech]

Bonjour,


Effectuant des recherches sur les moyens de lire les fichiers XML encodés en ISO19139, je suis tombé sur la librairie Geotoolkit.
Le survol des fonctions disponibles m'a interpellé, et j'ai donc décidé de tenter de les utiliser dans un projet de catalogage de données géographiques.
Cependant, il y a encore très peu de tutoriaux, et j'ai des difficultés à trouver les points d'entrée.

1. D'après ce que j'ai pu voir, le projet Geotoolkit contient une lib permettant le catalogage de métadonnée ISO19135 (geotk-metadata-sql.jar). Y a-t-il un tutorial décrivant comment utiliser cette librairie, ou un exemple me permettant de déployer la BD et de la tester.
2. J'ai réussi à lire un fichier ISO19119 avec Jaxb, mais je n'ai pas trouvé le moyen de lire du dublin core, ni de lire les métadonnées associées aux images (TIF, JPG, ...). La aussi, un tutorial ou quelques lignes de code pourraient m'aider à avancer un peu.
3. Je n'arrive pas a récupérer la chaine par défaut (présente dans l'élément gco:CharacterString) des chaines multilangues. Ce qui est dommage, c'est que l'information est présente dans l'objet FreeText lors de la désérialisation, mais cette information n'est pas reportée dans l'objet DefaultInternationalString par la classe InternationalStringAdapter.
   J'ai essayé de supprimer l'adapteur (

   Code :

   Sélectionner tout - Visualiser dans une fenêtre à part

   unmmarshaller.setAdapter(InternationalStringAdapter.class, null)

   ) pour le remplacer par un de ma conception, mais c'est toujours l'InternationalStringAdapter qui est appelé.
   Voici un exemple de code XML. Je voudrais récupérer la chaîne en Anglais.
   

   Code :

   Sélectionner tout - Visualiser dans une fenêtre à part

   1
   2
   3
   4
   5
   6
   7
   8
   9
                        <gmd:nameOfMeasure xsi:type="gmd:PT_FreeText_PropertyType">
                           <gco:CharacterString>Quantitative quality measure focusing on the effective class percent regarded to the total surface size</gco:CharacterString>
                           <gmd:PT_FreeText>
                              <gmd:textGroup>
                                 <gmd:LocalisedCharacterString locale="#locale-fra">Mesure qualité quantitative de type pourcentage de représentation de la classe par rapport à la surface totale</gmd:LocalisedCharacterString>
                              </gmd:textGroup>
                           </gmd:PT_FreeText>
                        </gmd:nameOfMeasure>

Je remercie d'avance toute personne qui pourra m'aider à avancer sur ce sujet.

[desruisseaux]

Bonjour

Nous manquons effectivement de tutoriels. Mais en attendant, voici quelque pistes qui aideront peut-être:

Concernant le premier point (enregistrement des métadonnées dans une base de données), il y a deux approches possibles:

1. Le module geotk-metadata-sql est un module "léger" et relativement simple, dans lequel chaque classe de méta-données correspond à une table et chaque attribut correspond à une colonne. Les tables et colonnes sont créées dynamiquement la première fois où elles sont nécessaires. C'est donc un schéma simple à comprendre pour ceux qui sont familiers avec la norme ISO 19115, mais avec plusieurs limitations. Par exemple les collections ne sont pas supportées (on ne peut enregistrer qu'une seule valeur par attribut).
2. Pour un outils plus puissant (au prix d'une plus grande complexité), il y a MD-Web qui est un projet séparé utilisant Geotk sous le capot: http://www.mdweb-project.org/

Dans le cas de metadata-sql, ça ne vaut pas un vrai tutoriel mais la classe de test suivante peut peut-être aider:

http://hg.geotoolkit.org/geotoolkit/...riterTest.java

Concernant le deuxième point (métadonnées d'images), s'agit-il des métadonnées fournies par javax.imageio.metadata.IIOMetadata? Si oui, c'est géré par le module geotk-coverage. Ça serait l'objet d'une autre réponse s'il s'agit bien de ces métadonnées.

Concernant le troisième point, je viens de créer une tâche à cet effet: GEOTK-107. Je vais tester dès que j'ai une opportunité. Merci pour avoir rapporté ce manque!

Martin.

[pyrotech]

Merci pour ta réponse, elle m'est bien utile.

1. Je vais faire quelques tests du côte de la librairie SQL geotk pour me faire une idée si ces limitations sont vraiment un problème. En cherchant du côté de MDWeb et de Geonetwork, j'ai d'ailleurs vu qu'il y avait une norme pour les services de recherche dans des catalogues (CSW). Il faudra que j'investigue un peu sur ce sujet également (par hasard, geotk n'a rien en stock à ce sujet ?)
   
2. Concernant les métadonnées de fichiers images, j'ai besoin de récupérer un maximum d'info pour initialiser un dublin core ou une arbo ISO19115. J'image pouvoir récupérer au minimum l'emprise et son référentiel, auteur et copyright.
   J'ai été voir la classe IIOMetadata, mais je n'ai pas l'impression qu'elle gère ces notions géographiques. De plus, j'ai cru comprendre que l'arbre de résultat dépend du format de la donnée. Je pense que Geotk devrait pouvoir m'aider car j'ai lu qu'il pouvait wrapper ces objets en objet ISO19115. J'espère que tu pourras me donner un petit coup de pouce pour commencer.
   
3. Concernant le dernier point, voici l'endroit ou j'ai relevé le problème, dans la classe org.geotoolkit.internal.jaxb.metadata.InternationalStringAdapter
   

   Code :

   Sélectionner tout - Visualiser dans une fenêtre à part

   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14
   15
   16
   17
   18
   19
   20
   21
   22
   23
   24
   25
   26
   27
   28
   29
   30
   31
   32
   33
   34
       @Override
       public final InternationalString unmarshal(final CharacterString value) {
           if (value != null) {
               if (value instanceof FreeText) {
                   final FreeText freeText = (FreeText) value;
                   final TextGroup textGroup = freeText.textGroup;
                   if (textGroup == null) {
                       return null;
                   }
                   final DefaultInternationalString ist = new DefaultInternationalString();
   
   // Le problème est à ce niveau : textGroup.getCharacterString() 
   // contenant la valeur par défaut n'est pas exploitée.
   // Il faudra trouver un moyen de stocker cette valeur par défaut dans le
   // DefaultInternationalString (sous un locale préconfiguré Locale.US ?) 
   // et ensuite pouvoir la sérialiser. Rien ne semble prévu à ce sujet dans
   // l'interface InternationalString.
   
                   for (final LocalisedCharacterString localized : textGroup.localised) {
                       ist.add(localized.locale, localized.text);
                   }
                   return ist;
               }
               String text = value.toString();
               if (text != null) {
                   text = text.trim();
                   if (text.length() != 0) {
                       return new SimpleInternationalString(text);
                   }
               }
           }
           return null;
       }

Encore merci.


Vincent

[eclesia]

Je reponds a une partie des questions

[LIST=1][*]Je vais faire quelques tests du côte de la librairie SQL geotk pour me faire une idée si ces limitations sont vraiment un problème. En cherchant du côté de MDWeb et de Geonetwork, j'ai d'ailleurs vu qu'il y avait une norme pour les services de recherche dans des catalogues (CSW). Il faudra que j'investigue un peu sur ce sujet également (par hasard, geotk n'a rien en stock à ce sujet ?)

MDWeb est construit sur MapFaces, et Mapfaces est fait avec ... GeotoolKit. En résumé oui, GeotoolKit possede un module client csw. (et un module serveur dans Constellation-sdi). Le module est dans geotoolkit-pending sous le nom : geotk-client-csw.

[pyrotech]

J'ai regardé le code de la classe de Test et essayé de l'appliquer dans un exemple simple d'ajout de donnée dans une BD Derby.

Voici le code utilisé:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
			final DefaultDataSource ds = new DefaultDataSource("jdbc:derby:memory:Test;create=true");
			try {
				MetadataWriter source = new MetadataWriter(MetadataStandard.ISO_19115, ds, null);
				source.add(metaData.getSeriesMetadata().getMDMetadata());
			} catch (SQLException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}

malheureusement, lors de l'exécution, l'exception suivante se produit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
java.sql.SQLSyntaxErrorException: Syntax error: Encountered "INHERITS" at line 1, column 97.
	at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
	at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
	at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
	at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
	at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
	at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
	at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
	at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown Source)
	at org.geotoolkit.metadata.sql.MetadataWriter.createTable(MetadataWriter.java:455)
	at org.geotoolkit.metadata.sql.MetadataWriter.add(MetadataWriter.java:262)
	at org.geotoolkit.metadata.sql.MetadataWriter.add(MetadataWriter.java:371)
	at org.geotoolkit.metadata.sql.MetadataWriter.add(MetadataWriter.java:187)
	at MetadataReader.test(MetadataReader.java:68)
	at MetadataReader.main(MetadataReader.java:47)
Caused by: java.sql.SQLException: Syntax error: Encountered "INHERITS" at line 1, column 97.
	at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
	at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source)
	... 14 more
Caused by: ERROR 42X01: Syntax error: Encountered "INHERITS" at line 1, column 97.
	at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
	at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(Unknown Source)
	at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
	at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
	at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source)
	... 8 more

Avez-vous déjà rencontré ce problème ?

Vincent

[desruisseaux]

Désolé pour le retard dans ma réponse. Je suis nouvellement inscrit sur ce forum et j'avais oublié de suivre le fil.

Concernant CSW, je ne connais pas bien cette partie mais les gens qui gravitent autour de MD-Web pourront donner une réponse plus utile.

Concernant les méta-données d'images, Geotk offre en effet quelques fonctionnalités. La classe IIOMetadata est une classe générique, qui peut contenir des métadonnées selon divers standards. Un objet IIOMetadata se parcours comme un arbre XML. Dans Geotk, nous en manipulons 3 formats de méta-données:

• Il y a le format natif, qui consiste à exposer directement l'en-tête d'un fichier d'image sans faire aucun traitement dessus. Chaque format d'image a sa propre arborescence. Ainsi, l'arborescence des méta-données du format PNG est complètement différente de l'arborescence des méta-données du format TIFF par exemple.
• Le Java définit un format "standard", dans laquelle les méta-données au format natif sont réorganisées selon une arborescence commune à tous les formats. Ce format standard est définit ici. Il contient essentiellement des informations sur le modèle de couleurs, etc. et pas d'informations géographiques.
• Geotk définit un autre format de métadonnées, dérivée de ISO 19115-2 (le -2 est "Metadata part 2: extensions for imagery and gridded data"). C'est en fait une arborescence 19115-2 simplifiée (en remplaçant certaines collection par des singleton, et omettant certains éléments, pour éviter d'avoir un arbre trop gigantesque): Classe SpatialMetadataFormat.

Les ImageReaders fournis par Geotk dans le package org.geotoolkit.image.io.plugins remplissent cette arborescence de leur mieux. Par exemple, si un fichier PNG est accompagné des fichiers PNW et PRJ, Geotk lira ces fichiers pour remplir l'arborescence qui accompagne le fichier PNG (pourvu que les décodeurs WorldFile sont déclarés comme documentés dans la javadoc du package).

La classe SpatialMetadata de Geotk fournit des méthodes de commodités qui donne accès aux données de cette arborescence sous forme d'objet ISO 19115. Méthode getInstanceForType(Class<?>). Cette méthode est implémentée à base de réflexions, donc il devrait à prime abord être capable de rendre la plupart des objets ISO 19115 pour laquelle l'arborescence de IIOMetadataFormat suit la structure des objets ISO 19115 (je veux dire un noeud pour chaque attribut avec le même nom, etc.).

Concernant le dernier point, en fait j'ai livré un patch vendredi dernier (merci beaucoup pour votre analyse en passant!). La correction devrait être présente dans les "snapshot" qui sont compilés chaque nuit, récupérable soit par Maven ou soit comme "bundles", à votre choix:

http://download.geotoolkit.org/SNAPSHOT/

La valeur par défaut est assignée au Locale "null" (on peut l'obtenir par InternationalString.toString(null)), excepté si une chaîne identique est défini dans un des éléments LocalizedCharacterString, auquel cas le Locale de ce dernier est conservé.

Note que si l'on fait InternationalString.toString(Locale.US) et qu'aucune chaîne n'est définit explicitement pour ce locale, le locale "null" sera utilisé en dernier recours (Locale.FRANCE ne sera pas utilisé puisque ce n'est pas la même lange ni le même pays).

[desruisseaux]

Concernant l'erreur reporté dans le deuxième message, il vient du fait que la version actuelle du module geotk-metadata-sql exige PostgreSQL version 8. Pour être plus précis, il utilise un modèle de base de données orientés objets, et cette fonctionnalité n'est disponible qu'à partir de PostgreSQL 8.

Par exemple dans la norme ISO 19115-2, l'interface GeographicBoundingBox étend l'interface GeographicExtent. Le module geotk-metadata-sql tente de refléter cette structure dans la base de données, avec une table "EX_GeographicBoundingBox" qui étend (INHERITS) "EX_GeographicExtent".

Je suis conscient que ce ne sont pas toutes les bases de données qui supportent cette fonctionnalités. Et même dans PostgreSQL 8, elle n'est que partiellement implémentée (la principale lacune est que les index ne sont pas encore hérités, alors qu'ils devraient l'être). Mais geotk-metadata-sql avait pour vocation d'être un petit module léger tentant de construire le schéma de base de données le plus "naturel" possible pour quelqu'un familier avec ISO 19115.

Dans une version future, il faudrait éventuellement prévoir un mécanisme pour contourner l'absence de support de la clause INHERITS sur les bases de données qui ne le supportent pas...

A tout hasard, la page suivante résume bien comment ça marche: http://www.postgresql.org/docs/curre...l-inherit.html

[pyrotech]

Merci pour toute ces réponses.

Concernant la lecture des métadonnées de fichier Image, j'ai trouvé la classe de test WorldFileImageReaderTest.java qui devrait pouvoir m'aider, ou de manière générale, le package de test org.geotoolkit.image.io.

A propos du bug sur la langue par défaut, je n'arrive pas à remettre la main sur une doc disant que la langue par défaut est toujours l'anglais. Voila pourquoi je proposais Locale.US. Cela étant, la proposition me va également.