Re: [Geotools-devel] Regression introduced by ReferencedEnvelope3D work
Hi Jody, That issue should have already been resolved ages ago, sorry about that. Your solution sounds perfect. Kind Regards Niels Charlier On 28/11/12 10:05, 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 GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Regression introduced by ReferencedEnvelope3D work
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 re
Re: [Geotools-devel] Regression introduced by ReferencedEnvelope3D work
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
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Regression introduced by ReferencedEnvelope3D work
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 GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Regression introduced by ReferencedEnvelope3D work
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 GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
