Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Hello UCAR maintainersThis 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
netcdf-java
archives: