Skip to end of metadata
Comment: Migrated to Confluence 4.0
Go to start of metadata

Time

Meeting Time Change

The meeting time has been changed to 2000Z Tuesday, August 30, 2005. http://www.timeanddate.com/worldclock/fixedtime.html?month=8&day=30&year=2005&hour=20&min=0&sec=0&p1=0

Meeting purpose

  1. Review the distillation of previous observations, in particular the crystallization of three essential work areas:
    1. Internal Data Model (ISO 19123 or similar)
    2. Persistence model (Grid Coverage Exchange, version 2).
    3. Processing model (multidimensional JAI)
  2. Identify people with interest in particular aspects of the task.
  3. Solicit volunteers to investigate specific items or flesh out particular vagueries by the next meeting (~2 weeks from this one.)

Tentative agenda

  1. Introduction of new people: who are they and do they have spare time?
  2. Summary of interim work.
    1. Simone G., Hey, where's the page of JAI tips?
    2. Simone G., Update on cool developments in Grib, NetCDF, etc.
    3. Alex P., analysis of Image CRS in GML3.1.1 with respect to making an IIOMetadataFormat. Discussion.
    4. Martin D., progress report on ISO19123 in GeoAPI. Still on target for Oct? Additional helpers?
    5. If no one else is going to put their institutional info and interests on the CoverageSupportPlans page, I'll just go in and delete mine. I thought it would be a good idea...
    6. ...
  3. Internal Representation / Conceptual Framework : ISO 19123
    1. Bryce N., observations concerning ISO19123 and 4D + bands.
    2. Are previously noted restrictions on coverages (e.g., grids defined by offset vectors) real? Can other data types be represented?
  4. Persistence model: Grid Coverage Exchange, version 2 (GCE2)
    1. Does Bryce's high-level synopsis meet with approval:
      • GCE2 is conceptually analgous to an n-Dimensional, spatially aware J2SE ImageIO.
      • Spatial metadata (CRS, etc.) should be communicated from plugin to client code via a standardized IIOMetadataFormat.
      • Operations such as spatiotemporal subsetting, band selection, etc should be communicated to plugins using extensions to ImageReadParams or ImageWriteParams.
      • 2D + bands case should reduce to J2SE ImageIO.
      • What about multiple resolutions in same file / over the same extent?
    1. Have we found an acceptable IIOMetadataFormat in Image CRS for GML3.1.1?
    2. Should we drop the "Grid" in Grid Coverage Exchange? Can it be just a "Coverage Exchange" and the plugin can decide whether the data is regularly gridded or not?
  5. Processing model: Grid Coverage Processor
    1. Establish basic specifications, tentative starting point (discuss and add to this list):
      • Should be a deferred execution model.
      • Should reduce to JAI in the 2D+bands case.
      • Should leverage JAI whenever possible, especially lessons learned.
      • ...
    2. Need to more fully flesh this out. Discuss other potential issues.
      • What is necessary to specify a region of interest?
      • Each plugin needs to appropriately operate on image data and georeferencing metadata.
      • Is it sufficiently advantageous to develop a processing API specifically for the case where the data are gridded? Should this be a special case of a Coverage Processor?
      • ...

Notes

  • Simone has been examining the integration of his Grib code with J2SE IIO. He's started expressing his learning on: http://www.geotools.org/J2SE+ImageIO+in+2D.
    • Martin gave a short summary of IIOMetadata.

      <Martin> IIOMetadata is part of J2SE (so it is not our own API).
      <Martin> In my understanding, it is basically a XML tree.
      <Martin> bundled in images.
      <Martin> We can put whatever we want in it. Actually, the content of an IIOMetadata is image format-dependent.
      <Martin> However, J2SE provides a mechanism for translating an IIOMetadata from one format to an other.
      <Martin> So it is possible to defines a kind of "standard" IIOMetadata format to be understood by Geotools.

    • Simone's plugin reads Grib files and produces a 5D cube.
    • His current status is selecting a schema for use with the IIOMetadataFormat.
    • He notes that the rules for valid IIOMetadataFormat(s) are not necessarily enforced. Rule 1 at http://java.sun.com/j2se/1.4.2/docs/api/javax/imageio/metadata/IIOMetadataFormat.html states that you can't have text in an element. Can only have text in an attribute.
    • Martin has a different read on the rule. Storing text might be permitted.
    • Martin notes that you can store arbitrary java Objects in a IIOMetadata Tree. All plugins could just create their CRS and send to app.
    • IIOMetadataFormat should be invisible outside the ImageIO plugin / GridCoverageExchange relationship. No one else should see it...
    • Some discussion of format of CRS information, consensus to let Simone explore this further and decide later. Directions:
      1. Nodes of a DOM tree expressing some subset of GML 3.1.1 describing CRS or just return a CRS object
      2. If GML, what subset of GML?
  • Discussion of metadata content mechanisms
    • Using the current CRS to describe the dataset axes limits us to 5D, but that's enough for Simone and Bryce.
    • Martin notes that Stephanie Fellah proposed axes changes before. In the com.owsx.* packages of http://geoapi.sourceforge.net/pending/javadoc/overview-summary.html
    • Simone points out https://portal.opengeospatial.org/files/?artifact_id=8826, which describes Imagery Metadata, makes good use of ISO19115. Simone suggests that they have considered much more than just CRS and are worth a look.
    • Simone says that Image CRS in GML 3.1.1 limits CRS descriptions to 2D. Rightfully, he says we need more.
    • There is supposed to be an ISO19115-2 (for gridded data) coming out soon. Simone and Martin have heard of it, but have not actually seen it. Martin guesses that https://portal.opengeospatial.org/files/?artifact_id=8826 might give a fair preview of ISO19115-2.
    • Martin's ISO19123 interfaces are approx 2/3 done thanks to Wim Koolhaven, but they need revision. It's suggested that Norman and Alessio assist (neither of whom are present anymore).
    • The ISO 19123 and IIO work can go forward in parallel because there should be no interdependencies.
    • Martin's busy the next three weeks, but should be able to pick up after that.
  • Update on OSSIM
    • Currently exploring UDIG.
    • Comfortable with the J2SE IIO API.
    • They are implementing CRS and GridCoverage Interfaces now.
    • Eagerly waiting for ISO 19123 to get done.
    • The "chain" seems to be gdal->ossim->Coverage, as they are implementing Coverage directly.
  • Discovery of Coverages.
    • Discovery of our J2SE plugins and Coverage implementations are two separate things.
    • The OSSIM guys are implementing Coverage directly, thus won't be using the IIO mechanism.
    • There is no CoverageFactory in ISO19123, but Martin suggests we make a proposal for GeoAPI. This will be an open issue after completing the interfaces.
  • GCE2
    • Don't do it.
    • Rename Format to GridCoverageStore.
    • The GridCoverageStore provides all translation to and from the stored grid format.
    • In the case of the IIO plugins, it translates to the 2D+bands geometry.

Stuckees

  • Simone is going to check on the nuances of Rule 1: "Thou shalt not store text."
  • Simone will investigate translating https://portal.opengeospatial.org/files/?artifact_id=8826 into an IIOMetadataFormat.
  • Martin will make a wiki page with the status of the ISO19123 interfaces, using it to delegate work to volunteers.
  • Alessio and Norman are volunteered to help with ISO19123.

IRC log

After meeting, put IRC log here.

High level summary of contents

A day or so after meeting, summarize main issues and conceptual points here.

Labels
  • None