Hello UCAR maintainers
This is a proposal related to the "THREDDSMetadata" thread. The NcISO software
translates NetCDF metadata to ISO 19115-2 using XSL files. I'm in the process of
translating the XSL logic to pure Java code for programmatic convenience,
performance, /etc./ However because this work depends very strongly on
NetCDF/THREDDS conventions, I feel that it would be better to have it as a
module of the UCAR NetCDF-Java library. Would the UCAR maintainers be
interrested to take the code once I finished it? I would be happy to give it.
Notes:
* It can be a separated module; it doesn't need to live in the NetCDF core
module.
* The public API depends on NetCDF core and GeoAPI 3.0.0 interfaces
o GeoAPI 3.0.0 is now an OGC standard (since April)
o GeoAPI is deployed on Maven Central
o The GeoAPI governance follow OGC rules (voting process, etc.).
* A GeoAPI implementation is required, but you have the choice:
o Simple implementation based on HashMap (public domain)
o Or the Geotoolkit.org implementation (which I'm using)
+ You need only the metadata module; you can ignore referencing.
+ Also deployed on Maven Central.
The Java code looks like below:
final DefaultMetadata metadata = new DefaultMetadata();
metadata.setFileIdentifier(getThreddsOrGlobalAttribute("id"));
metadata.getHierarchyLevels().add(ScopeCode.DATASET);
if (services != null) {
metadata.getHierarchyLevels().add(ScopeCode.SERVICE);
}
/*
* Add the ResponsibleParty which is declared in global attributes.
*/
ResponsibleParty contact = createResponsibleParty(
getAttribute("creator_name"),
getAttribute("institution"),
getAttribute("creator_email"),
createOnlineResource(getAttribute("creator_url"), null, null),
Role.POINT_OF_CONTACT);
if (contact != null) {
metadata.getContacts().add(contact);
}
// etc...
So the Java code is pretty much straight-forward, the "real" work is to apply
NetCDF convention, which is why I feel this code would be better served if it
lived as a module of the NetCDF library.
Any interest?
Martin
