Thanks Martin. FYI on the workflow stuff - OODT could be a good reference implementation there. Also on the metadata “checker” SIS would make an “awesome” one for that and there is great interest in the ESIP use case, along with the use case for NASA missions checking ISO metadata and also NASA archives.
Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Martin Desruisseaux <[email protected]> Organization: Geomatys Reply-To: "[email protected]" <[email protected]> Date: Tuesday, December 2, 2014 at 8:50 AM To: Apache SIS <[email protected]> Subject: Report from OGC meeting (1/2) >Hello all > >There is some notes about the OGC sessions that I saw yesterday and today. > >GeoAPI >---------------------------------------- >We presented the proposed content for GeoAPI 3.1 [1]. The slides >summarized the following points: > > * Guidelines applied in the process of deriving the Java interfaces > from UML. > * Three examples about why we should derive Java interfaces from UML, > not from XSD. > * Kind of compatible changes. > * Kind of incompatible changes. > * Aftermath: about 200 compatible changes and 30 incompatible ones. > * Mapping ISO internationalisation objects (PT_FreeText) to Java > (Locale, Charset, InternationalString). > > >They were no motion. The next work will be to update the GeoAPI >specification accordingly. > >OGC has a GitHub repository [2] where some standards, test suites or >educational materials are developed. Maybe we should move the GeoAPI >repository (currently on SourceForge) there. > > > >Metadata (ISO 19115): >---------------------------------------- >Work on XML schemas for the new ISO 19115:2014 standard is ongoing in an >ISO-TC211 repository on GitHub [3]. Maybe Apache SIS could start looking >at it for the transition to the new XML schema, now that we have >transitioned the Java API. However I think it would depend on volunteer >resources: if someone is interested in following ISO-TC211/XML work, >update SIS implementation accordingly and provide feedbacks to >ISO-TC211/XML, than would be great! Otherwise we may just wait for the >final XSD before to begin this work. > >The Earth Science Information Partners (ESIP) web site is worth to note. >For example in the "Documentation connections" page [4], "Documenting >Resource Identification", there is a mapping between concepts (e.g. >"resource title", "keyword", "bounding box", etc.) and various metadata >dialects (ISO, DIF, ECHO, ECS, FGDC, etc.). In Apache SIS, we currently >use ISO 19115 as the "lingua franca" of spatial metadata. So if someone >implemented a reader for the other formats, we could use those mapping >for storing the information in SIS metadata objects. > >ESIP also summarize the concepts that are recommended by the different >dialects. So we can see that the "title" is recommended by 7 different >metadata dialects, the "bounding box" by 5 different dialects, the >language by 2 different dialects, etc. This may be a way to prioritize >the information. > >The is a strong interest for a tools that quantify the metadata >completion. There is already an online tool on the NOAA web site (I >think). This is an other thing that SIS could do if there is volunteer. > > > >Geometries (ISO 19107) >---------------------------------------- >The group is at only two weeks of submitting the new ISO 19107 draft to >ISO as a community draft. Past that point, it would be much more >difficult to edit. The new standard greatly simplify the previous >version. Segmentations and boundary objects are replaced by ordinary >geometry objects. B-Splines and NURBES are considered mathematically >equivalent, so the new standard uses only polynomial spline interface. >The were also changes to harmonize with SQL/MM Spatial. > > > >Vertical CRS >---------------------------------------- >The meteo-oceanography group needs to be able to express the >transformations between various vertical CRS definitions, for example >from a z value measured as a pressure to a z value in metres. The usual >way to do this kind of work for horizontal CRS is to store the >transformation steps for various (sourceCRS, targetCRS) tuples in a >database, in particular the EPSG database [5]. However it is not yet >clear if this approach could be applicable to the kind of vertical >coordinate transformations done in the meteorological community because >of the large amount of definitions (e.g. at least one for each airport) >and there time-varying nature. One alternative approach that this group >wishes to explore is whether we should try to encore more explicit >information in the vertical datum [6] for allowing libraries to infer >the transformation steps without an EPSG-like database. > > > >Workflow: >---------------------------------------- >Similar to Web Processing Service (WPS), but discussion about: > > * Defining choices between alternative processes depending on which > data are available. > * Feedback or interaction mechanism (e.g. know if a job is stalled, >etc.). > * If a step in WPS requires a login/password, how to pass the request > in the chain of process up to the user. > >This is still in exploratory phase. > > Martin > > > > >[1] http://www.geoapi.org/snapshot/javadoc/content.html >[2] https://github.com/opengeospatial >[3] https://github.com/ISO-TC211/XML >[4] http://wiki.esipfed.org/index.php/Category:Documentation_Connections >[5] http://epsg-registry.org/ >[6] >http://www.geoapi.org/snapshot/javadoc/org/opengis/referencing/datum/Verti >calDatum.html >
