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
