sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Desruisseaux (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SIS-338) Stores pre-defined metadata in the SpatialMetadata database
Date Tue, 24 Jul 2018 14:31:00 GMT

     [ 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)

Mime
View raw message