I notice that the ReferencedEnvelope3D issue
(https://jira.codehaus.org/browse/GEOS-5148) is still marked as in progress.
Do you have anything to add to the discussion Niels? I do not want to step on
your toes, but I also need to sort out a fix promptly.
--
Jody Garnett
On Wednesday, 28 November 2012 at 6:57 PM, Jody Garnett wrote:
> TLDR:
>
> I have found a regression: The constructor ReferencedEnvelope(
> CoordinateReferenceSystem ) can now fail (previously it would always work).
> This change is introducing issues in downstream software (such as
> https://jira.codehaus.org/browse/GEOS-5474).
>
> Discussion:
>
> Andrea has commented on https://jira.codehaus.org/browse/GEOT-4325 - asking
> me to take the discussion to the email list….
>
> I am currently working on a couple of Oracle tasks:
> - SDOOnlineTest <-- restored to master (pending a review from Andrea)
> - Confirm GDA94 support for OracleDataStore
>
> The following line is used in many of the getBounds() implementations:
>
> ReferencedEnvelope bounds = new ReferencedEnvelope( crs );
>
> The trouble is, this is no longer "safe" - it is willing to throw an
> exception, if the provided CRS (has 3 or more) dimensions.
>
> We could change all the code examples to be the following:
>
> ReferencedEnvelope bounds = crs.getCoordinateSystem().getDimension() >= 3 ?
> new ReferencedEnvelope3D( crs ) : new ReferencedEnvelope( crs );
>
> I have created a factory method with similar logic for GEOT-4325. The
> ReferencedEnvelope class now provides the following factory methods:
>
> ReferencedEnvelope.reference( BoundingBox )
> ReferencedEnvelope.reference( Envelope )
> ReferencedEnvelope.reference( Envelope )
> ReferencedEnvelope.reference( Envelope, CoordinateReferenceSystem )
>
> ReferencedEnvelope.reference( CoordinateReferenceSystem ) <-- this one is new
>
> So while this will give me the tools to "fix" Oracle smoothly, we still have
> some technical debt due to the introduction of ReferencedEnvelope3D as a
> class, but not updating the geotools codebase to make use of it.
>
> I expect we should deprecate these two constructors, suggesting the factory
> method as the replacement, and then (at least in our codebase) update
> GeoTools to use the factory method. This would restore the code base to
> previous functionality.
> --
> Jody Garnett
>
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
