[
https://issues.apache.org/jira/browse/SIS-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-338:
------------------------------------
Description:
Apache SIS has some pre-defined metadata constants. In particular, the
{{Citation}} class from ISO 19115 is often used for specifying the organization
that defines Coordinate Reference System codes (EPSG, OGC, _etc._). Currently,
we have a {{Citation EPSG}} constant with hard-coded properties like title,
alternate title, URL, responsible party, _etc._, a {{Citation OGC}} constant
with similar properties, and so on for many constants. This is unconvenient to
program and quite incomplete since we do not provide all information that we
have.
The problem become more acute as we progress in the development of
{{sis-earth-observation}} module, which also has hard coded metadata. For
example Landsat 8 needs the description of 11 bands, and those bands are only
partially described in the Landsat file that we parse. The remaining (e.g. the
actual wavelength that we are measuring) must be hard-coded in our Landsat
metadata reader. The ability to provides those information in a database would
be convenient.
This approach is expected to be let more useful when we will parse data from
the World Meteorological Organization (WMO), which make extensive use of large
table. The NetCDF format too have a list of standardized phenomenon names. All
those things are natural candidates for inclusion in a metadata database.
was:
Apache SIS has some pre-defined metadata constants. In particular, the
{{Citation}} class from ISO 19115 is often used for specifying the organization
that defines Coordinate Reference System codes (EPSG, OGC, _etc._). Currently,
we have a {{Citation EPSG}} constant with hard-coded properties like title,
alternate title, URL, responsible party, _etc._, a {{Citation OGC}} constant
with similar properties, and so one for many constants. This is unconvenient to
program and quite incomplete since we do not provide all information that we
have.
The problem become more acute as we progress in the development of
{{sis-earth-observation}} module, which also has hard coded metadata. For
example Landsat 8 needs the description of 11 bands, and those bands are only
partially described in the Landsat file that we parse. The remaining (e.g. the
actual wavelength that we are measuring) must be hard-coded in our Landsat
metadata reader. The ability to provides those information in a database would
be convenient.
This approach is expected to be let more useful when we will parse data from
the World Meteorological Organization (WMO), which make extensive use of large
table. The NetCDF format too have a list of standardized phenomenon names. All
those things are natural candidates for inclusion in a metadata database.
> Stores pre-defined metadata in the SpatialMetadata database
> -----------------------------------------------------------
>
> Key: SIS-338
> URL: https://issues.apache.org/jira/browse/SIS-338
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
> Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7, 0.8
> Reporter: Martin Desruisseaux
> Assignee: Martin Desruisseaux
> Priority: Major
> Fix For: 1.0
>
>
> Apache SIS has some pre-defined metadata constants. In particular, the
> {{Citation}} class from ISO 19115 is often used for specifying the
> organization that defines Coordinate Reference System codes (EPSG, OGC,
> _etc._). Currently, we have a {{Citation EPSG}} constant with hard-coded
> properties like title, alternate title, URL, responsible party, _etc._, a
> {{Citation OGC}} constant with similar properties, and so on for many
> constants. This is unconvenient to program and quite incomplete since we do
> not provide all information that we have.
> The problem become more acute as we progress in the development of
> {{sis-earth-observation}} module, which also has hard coded metadata. For
> example Landsat 8 needs the description of 11 bands, and those bands are only
> partially described in the Landsat file that we parse. The remaining (e.g.
> the actual wavelength that we are measuring) must be hard-coded in our
> Landsat metadata reader. The ability to provides those information in a
> database would be convenient.
> This approach is expected to be let more useful when we will parse data from
> the World Meteorological Organization (WMO), which make extensive use of
> large table. The NetCDF format too have a list of standardized phenomenon
> names. All those things are natural candidates for inclusion in a metadata
> database.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
