GeoAPI
  1. GeoAPI
  2. GEO-82

Coverage IWUG 2: Basic Grid Elements

    Details

    • Type: New Feature New Feature
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: coverage
    • Labels:
      None
    • Number of attachments :
      0

      Description

      This proposal includes a number of interfaces which provide basic gridded data access. These interfaces are inspired more or less directly by ISO 19123, with major departures noted as follows:

      • Children of CV_Grid have been retooled as independent objects to be composed with CV_Grid. This avoids multiple inheritance.
      • Addition of a class to permit the specification of Map projections (e.g., non-affine coordinate conversions).
      • A convenience method to retrieve a MathTransform is provided for RectifiableGrid objects (and children).

      The latest specification can be found on:
      http://docs.codehaus.org/download/attachments/46835/BasicGridElements.pdf
      http://docs.codehaus.org/download/attachments/46835/BasicGridElements.odt

        Issue Links

          Activity

          Hide
          Alex Petkov added a comment -

          I copied already defined ISO19123 interfaces from coverage.grid to coverage.grid.quadrilateral, and altered the code wherever necessary to comply with the UML diagram in the "BasicGridElements" document (see link above).

          As a result, there are now a few duplicate interfaces in org.opengis.coverage.grid and org.opengis.coverage.grid.quadrilateral.
          Shouldn't those exist in a single place (to avoid duplicating code)?

          Show
          Alex Petkov added a comment - I copied already defined ISO19123 interfaces from coverage.grid to coverage.grid.quadrilateral, and altered the code wherever necessary to comply with the UML diagram in the "BasicGridElements" document (see link above). As a result, there are now a few duplicate interfaces in org.opengis.coverage.grid and org.opengis.coverage.grid.quadrilateral. Shouldn't those exist in a single place (to avoid duplicating code)?
          Hide
          Alex Petkov added a comment -

          The work from my prev. comment was comitted to SVN some time ago.

          Show
          Alex Petkov added a comment - The work from my prev. comment was comitted to SVN some time ago.
          Hide
          Alex Petkov added a comment -

          This task is mostly done, with the exception of some duplicate interfaces that exist in both coverage.grid and coverage.grid.quadrilateralI. I am looking for some feedback whether or not will be OK to remove duplicate code, then we should be able to close this.

          Show
          Alex Petkov added a comment - This task is mostly done, with the exception of some duplicate interfaces that exist in both coverage.grid and coverage.grid.quadrilateralI. I am looking for some feedback whether or not will be OK to remove duplicate code, then we should be able to close this.
          Hide
          Martin Desruisseaux added a comment -

          For the record, there is the link to "ISO 19123 primer":

          https://docs.codehaus.org/display/GEOTOOLS/ISO+19123+progress+and+future+plan

          Show
          Martin Desruisseaux added a comment - For the record, there is the link to "ISO 19123 primer": https://docs.codehaus.org/display/GEOTOOLS/ISO+19123+progress+and+future+plan
          Hide
          Martin Desruisseaux added a comment -

          Would it be possible to explain again why having GridValueMatrix, RectifiedGrid and ReferenceableGrid extends Grid is a problem please? I have browsed the Basic Grid Elements and ISO 19123 primer documents, and this issue is still unclear to me...

          In the main time, I tried to remove as much duplication as I can from the org.opengis.coverage.grid.quadrilateral package as below:

          • Deleted the interfaces from which were identical to the interfaces in org.opengis.coverage.grid.
          • For interfaces which were identical to org.opengis.coverage.grid with a few additions, defined them as extending the above interfaces, removed the duplicated methods and keep only the new ones.
          • For interfaces having a different hierarchy, keep them mostly unchanged but edited the javadoc in order to state that those interfaces are a proposal with modified hierarchy.

          Commited on trunk as of revision 1229.

          Show
          Martin Desruisseaux added a comment - Would it be possible to explain again why having GridValueMatrix , RectifiedGrid and ReferenceableGrid extends Grid is a problem please? I have browsed the Basic Grid Elements and ISO 19123 primer documents, and this issue is still unclear to me... In the main time, I tried to remove as much duplication as I can from the org.opengis.coverage.grid.quadrilateral package as below: Deleted the interfaces from which were identical to the interfaces in org.opengis.coverage.grid . For interfaces which were identical to org.opengis.coverage.grid with a few additions, defined them as extending the above interfaces, removed the duplicated methods and keep only the new ones. For interfaces having a different hierarchy, keep them mostly unchanged but edited the javadoc in order to state that those interfaces are a proposal with modified hierarchy. Commited on trunk as of revision 1229.
          Hide
          Bryce Nordgren added a comment -

          The problem is conceptual, and it is with the design in 19123 rather than the implementation in GeoAPI.

          From the text of 19123, the intent is to provide a mechanism whereby the grid's values are supplied by a GridValueMatrix and the geolocation of grid cells is performed by either a RectifiedGrid or a ReferencableGrid (but not both.)

          This intent is best expressed by composition, and is not expressed at all by inheritance. Even in a language which supports multiple inheritance, you would not use inheritance in this way to express this intent. In Java, we have to use interfaces to simulate multiple inheritance, but there is no practical way to enforce the constraint that a class may implement either RectifiedGrid or ReferencableGrid, but not both.

          The authors of 19123 invented a notion of "partitions of children" to express their intent, but I have not met any programming language which supports this idea. Perhaps the best way to express what I've done to the design is that I've transformed the "partitions" into compositions. I tried to do as little as possible to the class hierarchy while retaining the intent of the text (and the mutant UML diagram).

          (I did add a class too, for the separate reason that map projections were omitted/silently prohibited by the original schema. Feel free to nuke that if you feel it is an inappropriate addition to the API.)

          Show
          Bryce Nordgren added a comment - The problem is conceptual, and it is with the design in 19123 rather than the implementation in GeoAPI. From the text of 19123, the intent is to provide a mechanism whereby the grid's values are supplied by a GridValueMatrix and the geolocation of grid cells is performed by either a RectifiedGrid or a ReferencableGrid (but not both.) This intent is best expressed by composition, and is not expressed at all by inheritance. Even in a language which supports multiple inheritance, you would not use inheritance in this way to express this intent. In Java, we have to use interfaces to simulate multiple inheritance, but there is no practical way to enforce the constraint that a class may implement either RectifiedGrid or ReferencableGrid, but not both. The authors of 19123 invented a notion of "partitions of children" to express their intent, but I have not met any programming language which supports this idea. Perhaps the best way to express what I've done to the design is that I've transformed the "partitions" into compositions. I tried to do as little as possible to the class hierarchy while retaining the intent of the text (and the mutant UML diagram). (I did add a class too, for the separate reason that map projections were omitted/silently prohibited by the original schema. Feel free to nuke that if you feel it is an inappropriate addition to the API.)

            People

            • Assignee:
              Martin Desruisseaux
              Reporter:
              Bryce Nordgren
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: