content/fr/developer-guide/overview/GetMetadataElement.html

<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE html>  <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr"> <head> <title>GetMetadataElement</title> <meta charset="UTF-8"/> <link rel="stylesheet" type="text/css" href="../book.css"/> </head> <body>  <section> <header> <h2 id="GetMetadataElement">Parcourir les méta-données</h2> </header> <p> L’utilisation de méthodes telles que <code class="GeoAPI">getExtents()</code> est efficace lorsque l’on cherche un élément bien précis, connu au moment de la compilation. Mais le fait que l’élément recherché peut être assez loin dans l’arborescence et que beaucoup d’éléments soient optionnels ou membres de collections rend parfois le parcourt laborieux. Pour quelques éléments fréquemment demandés, des méthodes de commodité existent. Elles sont généralement définies sous forme de méthodes statiques dans une classe dont le nom est au pluriel. Par exemple la classe <code>Extents</code> définie des méthodes statiques pour extraire plus facilement certaines informations à partir de l’élément de méta-donnée <code>Extent</code>. Ainsi la ligne suivante prendra en charge le travail un peu fastidieux de parcourir les différentes branches possible pouvant aboutir aux limites nord, sud, est et ouest de la donnée: </p> <pre><code>GeographicBoundingBox bbox = Extents.getGeographicBoundingBox(extent);</code></pre> <p> Ces méthodes de commodité sont définies sous forme de méthodes statiques afin de permettre leur utilisation avec différentes implémentations des éléments de méta-données. Même dans Apache <abbr>SIS</abbr>, la classe <code>DefaultExtent</code> n’est pas la seule implémentation de l’interface <code>Extent</code>. Il y a aussi d’autres implémentations qui puiseront leur information à la demande dans une base de données, ou des implémentations conçues spécifiquement pour des formats de données particuliers. D’autres exemples de classes fournissant des méthodes statiques dédiées à une interface sont <code>Citations</code>, <code>Envelopes</code>, <code>Matrices</code> et <code>MathTransforms</code>. </p><p> Ces méthodes statiques parcourent une plus grande portion de l’arbre de méta-données afin de trouver ou dériver l’élément demandé, mais ce dernier reste un élément dont le type et au moins une partie du chemin sont connus au moment de la compilation. Il arrive que l’on veuille plutôt accéder à des éléments qui ne sont connus qu’au moment de l’exécution, ou encore parcourir tous les éléments. Dans ces cas, on peut utiliser une vue sous forme de <code>java.util.Map</code> comme dans l’exemple suivant: </p> <pre><code>Map<String,Object> elements = MetadataStandard.ISO_19115.asValueMap( metadata, // N’importe quelle instance du paquet org.opengis.metadata ou d’un sous-paquet. null, // Utilisé pour résoudre des ambiguïtés. Peut être ignoré pour cet exemple. KeyNamePolicy.JAVABEANS_PROPERTY, // Les clés seront les noms des méthodes mais sans le prefix « get ». ValueExistencePolicy.NON_EMPTY); // Les entrés dont la valeur est nulle ou vide seront omises. /* * Affiche les noms de tous les éléments à la racine de la méta-données qui ont une valeur. * Cette bouche ne va pas descendre dans les enfants (pas de récursivité). */ for (String name : elements.keySet()) { System.out.println(name); }</code></pre> <p> Le <code>Map</code> retourné par <code class="SIS">asValueMap(…)</code> est une vue « vivante »: tout changement dans l’instance <code>metadata</code> se reflétera immédiatement dans la vue. En fait, chaque appel à <code>map.get("foo")</code> se traduit par un appel à la méthode <code>metadata.getFoo()</code> correspondante. Réciproquement, toute opération <code>map.put("foo", …)</code> ou <code>map.remove("foo")</code> effectuée sur la vue sera traduite en appel à la méthode <code>metadata.setFoo(…)</code> correspondante si cette dernière existe. Cette vue est assez souple sur les clés données en argument aux méthodes de <code>Map</code>: elles peuvent être le nom de la propriété (<code>"foo"</code>), le nom de la méthode (<code>"getFoo"</code>), ou le nom utilisé dans les diagrammes <abbr>UML</abbr> de la norme <abbr>ISO</abbr> 19115 (assez proche du nom de la propriété mais pas toujours identique). Les différences entre majuscules et minuscules sont ignorées si elles ne causent pas d’ambiguïtés. Pour plus d’information sur ce mécanisme de vues sur les méta-données, voir la Javadoc du paquet <a href="../../apidocs/org/apache/sis/metadata/package-summary.html#package.description"><code>org.apache.sis.metadata</code></a>. </p><p> Parmi les éléments de méta-données présentés dans ce chapitre, il en est un qui fera l’objet d’un <a href="#Referencing">chapitre dédié</a>: <code class="OGC">referenceSystemInfo</code>. Son contenu est essentiel pour positionner précisément les données. Sans lui, même les positions exprimées sous forme de latitudes et longitudes sont ambigües. Les systèmes de références ont plusieurs caractéristiques qui les différencient des autres méta-données: ils sont immuables, ne peuvent pas être parcourus par <code class="SIS">MetadataStandard.ISO_19115.asValueMap(…)</code>, ont une représentation sous forme de texte particulière, et sont associés à un mécanisme permettant de transformer des coordonnées d’un référentiel vers un autre. </p> </section> </body> </html>

content/fr/developer-guide/overview/GetMetadataElement.html (78 lines of code) (raw):