Okay sorted out my next approach (for when the dimensions do not match):
a) For ReferencedEnvelope3D -> transform to DefaultGeographic.WGS84_3D and drop
down to WGS84 manually, and then transform to the target CRS
b) For ReferencedEnvelope -> Transform to WGS84 and then and in NaN when
manually creating a WGS84_3D, and then transform to the target CRS
For (a) above I may indeed be able to make use of getHorizontalCRS.
--
Jody Garnett
On Thursday, 29 November 2012 at 1:46 AM, Jody Garnett wrote:
> Yeah not very happy trying to pass the following test case - any suggestions?
>
>
> public void testTransformToWGS84() throws Exception {
> String wkt = "GEOGCS[\"GDA94\","
> + " DATUM[\"Geocentric Datum of Australia 1994\","
> + " SPHEROID[\"GRS 1980\", 6378137.0, 298.257222101,
> AUTHORITY[\"EPSG\",\"7019\"]],"
> + " TOWGS84[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0], "
> + " AUTHORITY[\"EPSG\",\"6283\"]], "
> + " PRIMEM[\"Greenwich\", 0.0, AUTHORITY[\"EPSG\",\"8901\"]],"
> + " UNIT[\"degree\", 0.017453292519943295], "
> + " AXIS[\"Geodetic longitude\", EAST], " + " AXIS[\"Geodetic
> latitude\", NORTH], "
> + " AXIS[\"Ellipsoidal height\", UP], " + "
> AUTHORITY[\"EPSG\",\"4939\"]]";
>
> CoordinateReferenceSystem gda94 = CRS.parseWKT(wkt);
>
> ReferencedEnvelope bounds = new
> ReferencedEnvelope3D(130.875825803896, 130.898939990319,
> -16.4491956225999, -16.4338185791628, Double.NaN, Double.NaN,
> gda94 );
>
> ReferencedEnvelope bounds1 = bounds.transform(
> DefaultGeographicCRS.WGS84_3D, true );
> ReferencedEnvelope bounds2 = bounds.transform(
> DefaultGeographicCRS.WGS84, true ); // FAIL!
> }
>
>
> I am experimenting with CRS.getHorizontalCRS (but it does not feel like the
> right approach):
>
> SingleCRS flatCRS = CRS.getHorizontalCRS( crs );
> SingleCRS flatTargetCRS = CRS.getHorizontalCRS( targetCRS );
>
>
> Is there a reason why the math transforms cannot handle coordinate
> conversion? I would expect a transform to be capable of making a formula for
> each target ordinate (making use of any number of source ordinates) and
> calculate away as needed.
>
> --
> Jody Garnett
>
>
> On Wednesday, 28 November 2012 at 7:05 PM, Jody Garnett wrote:
>
> > 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
