GeoTools
  1. GeoTools
  2. GEOT-2084

Consider making GeographicBoundingBoxImpl extend BoundingBox as well

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.5.9
    • Component/s: referencing
    • Labels:
      None

      Description

      I would suggest to consider making GeographicBoundingBoxImpl extend BoundingBox as well, in order to have the possibility to do operations on it and to use the methods from the BoundingBox interface since it would be nice to be interoperable with ReferencedEnvelope

        Activity

        Hide
        Martin Desruisseaux added a comment -
        It make sense, but many methods would need the referencing module in order to be implemented.

        Methods that could be implemented without referencing:

        * int getDimension()
        * double getMinX()
        * double getMaxX()
        * double getMinY()
        * double getMaxY()
        * double getWidth()
        * double getHeight()
        * boolean isEmpty()
        * double getMinimum(int dimension)
        * double getMaximum(int dimension)
        * double getMedian(int dimension)
        * double getSpan(int dimension)
        * void include(double x, double y)
        * boolean contains(double x, double y)

        Methods which would require the referencing module in order to be implemented:

        * CoordinateReferenceSystem getCoordinateReferenceSystem()
        * DirectPosition getLowerCorner()
        * DirectPosition getUpperCorner()
        * void setBounds(BoundingBox bounds)
        * void include(BoundingBox bounds)
        * boolean intersects(BoundingBox bounds)
        * boolean contains(BoundingBox bounds)
        * boolean contains(DirectPosition location)
        * BoundingBox toBounds(CoordinateReferenceSystem targetCRS) throws TransformException

        If we were to implement BoundingBox, we would need to decide what to do with the methods in the second list:

        * Throw an UnsupportedOperationException
        * Use reflection in order to use referencing API only if the module is on the classpath
        * Duplicate some referencing code in metadata.

        Note that we can't make metadata dependent on referencing, since it would introduce a cyclic dependency.
        Show
        Martin Desruisseaux added a comment - It make sense, but many methods would need the referencing module in order to be implemented. Methods that could be implemented without referencing: * int getDimension() * double getMinX() * double getMaxX() * double getMinY() * double getMaxY() * double getWidth() * double getHeight() * boolean isEmpty() * double getMinimum(int dimension) * double getMaximum(int dimension) * double getMedian(int dimension) * double getSpan(int dimension) * void include(double x, double y) * boolean contains(double x, double y) Methods which would require the referencing module in order to be implemented: * CoordinateReferenceSystem getCoordinateReferenceSystem() * DirectPosition getLowerCorner() * DirectPosition getUpperCorner() * void setBounds(BoundingBox bounds) * void include(BoundingBox bounds) * boolean intersects(BoundingBox bounds) * boolean contains(BoundingBox bounds) * boolean contains(DirectPosition location) * BoundingBox toBounds(CoordinateReferenceSystem targetCRS) throws TransformException If we were to implement BoundingBox, we would need to decide what to do with the methods in the second list: * Throw an UnsupportedOperationException * Use reflection in order to use referencing API only if the module is on the classpath * Duplicate some referencing code in metadata. Note that we can't make metadata dependent on referencing, since it would introduce a cyclic dependency.
        Hide
        Simone Giannecchini added a comment -
        Ciao Martin,
        thanks for the info.
        My suggestion/thought is simple, GeographicBoundingBox is a nice-to-have element when dealing with transformation, however the fact that GeographicBoundingBoxImpl does not implement BoundingBox or better, that it does not implement method similar to the ones we have in BoundingBox is a shame since WGS84 bboxes are all over in the OWS services;
        I think that it would nice to have a dedicated class that hides most of the complexity of doing transformations and everything when dealing with WGS84 bboxes, kind like a mixture of GeographicBoundingBox with BoundingBox. Let's call this a further restriction of a BBOX (which restrict Envelope already). What do you think?
        Show
        Simone Giannecchini added a comment - Ciao Martin, thanks for the info. My suggestion/thought is simple, GeographicBoundingBox is a nice-to-have element when dealing with transformation, however the fact that GeographicBoundingBoxImpl does not implement BoundingBox or better, that it does not implement method similar to the ones we have in BoundingBox is a shame since WGS84 bboxes are all over in the OWS services; I think that it would nice to have a dedicated class that hides most of the complexity of doing transformations and everything when dealing with WGS84 bboxes, kind like a mixture of GeographicBoundingBox with BoundingBox. Let's call this a further restriction of a BBOX (which restrict Envelope already). What do you think?

          People

          • Assignee:
            Simone Giannecchini
            Reporter:
            Simone Giannecchini
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: