Methods like getExtents()
are efficient when looking for a particular element known at compile-time.
But those elements may be deep in the tree structure and may require traversal of many optional elements and collection members,
which is sometimes tedious. For a few frequently-used elements, some convenience methods are provided.
Those conveniences are generally defined as static methods in classes having a name in plural form.
For example the Extents
class defines static methods for fetching more easily some information from Extent
metadata elements.
For example the following method navigates through different branches where North, South, East and West data bounds may be found:
GeographicBoundingBox bbox = Extents.getGeographicBoundingBox(extent);
Those conveniences are defined as static methods in order to allow their use with different metadata implementations.
Some other classes providing static methods for specific interfaces are
Citations
, Envelopes
, Matrices
and MathTransforms
.
Above static methods explore fragments of metadata tree in search for requested information,
but the searches are still targeted to elements whose types and at least part of their paths are known at compile-time.
Sometimes the element to search is known only at runtime, or sometimes there is a need to iterate over all elements.
In such cases, one can view the metadata as a java.util.Map
like below:
Map<String,Object> elements = MetadataStandard.ISO_19115.asValueMap(
metadata, // Any instance from the org.opengis.metadata package or a sub-package.
null, // Used for resolving ambiguities. We can ignore for this example.
KeyNamePolicy.JAVABEANS_PROPERTY, // Keys in the map will be getter method names without "get" prefix.
ValueExistencePolicy.NON_EMPTY); // Entries with null or empty values will be omitted.
/*
* Print the names of all root metadata elements having a value.
* This loop does not iterate recursively in children.
*/
for (String name : elements.keySet()) {
System.out.println(name);
}
The Map
object returned by asValueMap(…)
is live:
any change in the metadata
instance will be immediately reflected in the view.
Actually, each map.get("foo")
call is forwarded to the corresponding metadata.getFoo()
method.
Conversely, any map.put("foo", …)
or map.remove("foo")
operation applied on the view
will be forwarded to the corresponding metadata.setFoo(…)
method, if that method exists.
The view is lenient regarding keys given in arguments to Map
methods:
keys may be property names ("foo"
), method names ("getFoo"
),
or names used in ISO 19115 standard UML diagrams
(similar to property names but not always identical).
Differences in upper cases and lower cases are ignored when this tolerance does not introduce ambiguities.
For more information on metadata views, see
org.apache.sis.metadata
package javadoc.