Hi Jody,
Yes clearly that is the case; I guess the question is should it be? :)
The docs for getMinX say:
Returns the |Envelope|s minimum x-value
but in the case of an NZTM referenced envelope, what it returns is the
minimum y value.
This discussion is going in a somewhat different direction to that which
I anticipated ... would it be worth moving the discussion to the
developers list do you think?
Thanks
Iain
On 15/12/2016 3:16 p.m., Jody Garnett wrote:
The getX and getY are just syntactic sugar for ordinate 0 and ordinate
1 as it stands now.
--
Jody Garnett
On 14 December 2016 at 12:16, Iain Matcham <[email protected]
<mailto:[email protected]>> wrote:
Hi Jody,
Thanks for your response.
I agree about the head hurting! Mine does already after only just
brushing the surface!
Unfortunately the exact same problem exists with WKT. In order to
make a valid WKT string for NZTM I would have to make a special
case to put the y axis first and the x axis second. Otherwise it
is just exactly the same as constructing geometries directly.
Now that I have done some more investigation trying out WKT as you
suggested, I am pretty certain this can be considered a bug in
ReferencedEnvelope; consider:
//NZMG is an x/y CRS
CoordinateReferenceSystem nzmg = CRS.decode("EPSG:27200");
//NZTM is a y/x CRS
CoordinateReferenceSystem nztm = CRS.decode("EPSG:2193");
Envelope env = new Envelope(2345678, 2345680, 6543210, 6543212);
ReferencedEnvelope refenv = ReferencedEnvelope.create(env, nzmg);
System.out.println("NZMG Envelope: " + refenv);
System.out.println("getMinimum(0): " + refenv.getMinimum(0));
System.out.println("getMinX(): " + refenv.getMinX());
refenv = refenv.transform(nztm, false);
System.out.println("NZTM Envelope: " + refenv);
System.out.println("getMinimum(0): " + refenv.getMinimum(0));
System.out.println("getMinX(): " + refenv.getMinX());
which outputs
NZMG Envelope: ReferencedEnvelope[2345678.0 : 2345680.0, 6543210.0
: 6543212.0]
getMinimum(0): 2345678.0
getMinX(): 2345678.0
NZTM Envelope: ReferencedEnvelope[5980771.101482246 :
5980773.102397159, 1435407.1134907207 : 1435409.1144056704]
getMinimum(0): 5980771.101482246
getMinX(): 5980771.101482246
which is all correct, EXCEPT the last line. The minimum X is NOT
the minimum of axis zero, and as ReferencedEnvelope is aware of
the CRS and in all other cases the CRS is aware that it is y/x
should not ReferencedEnvelope also be aware?
Were this to be fixed, might I suggest that then adding setMinX
(etc) methods to ReferencedEnvelope which were likewise CRS aware
would be a small step and (conveniently) would also resolve my
original situation!
Thoughts? Thanks!
Iain
On 10/12/2016 11:25 a.m., Jody Garnett wrote:
Wow that NZTM situation is a mess; getting the wrong definition
into the EPSG database takes some skill.
Can you construct the WKT representation of what you need (to
match your data as provided) and then use GeoTools to reproject
to your final answer? I have found that making special cases
based on axis order makes my head hurt, and if I set up my
definitions correct GeoTools can construct the required transform ...
--
Jody Garnett
On 6 December 2016 at 17:44, Iain Matcham <[email protected]
<mailto:[email protected]>> wrote:
Hi all,
I have an application where I want a user to be able to enter
a set of
bounds and a CRS and then the code will reproject their input
into a
default CRS for further processing. A fairly simple operation:
public ReferencedEnvelope getEnvelope(
double minEast, double maxEast,
double minNorth, double maxNorth,
CoordinateReferenceSystem crs) throws
TransformException,
FactoryException {
Envelope envelope = new Envelope(minEast, maxEast,
minNorth, maxNorth);
ReferencedEnvelope refEnv =
ReferencedEnvelope.create(envelope, crs);
return refEnv.transform(DEFAULT_CRS, true);
}
Except for NZTM. Thanks to LINZ, NZTM is has an axis order
y/x. The
above code falls over.
Following this (admittedly quite old) thread:
http://osgeo-org.1560.x6.nabble.com/Need-help-reprojecting-ReferencedEnvelope-td5069254.html
<http://osgeo-org.1560.x6.nabble.com/Need-help-reprojecting-ReferencedEnvelope-td5069254.html>
to the suggested resolution seems to be to "Make a special
case for
NZTM". Extending this to "make a special case for any y/x
CRS" means my
code now looks like:
public ReferencedEnvelope getEnvelope(
double minEast, double maxEast,
double minNorth, double maxNorth,
CoordinateReferenceSystem crs) throws
TransformException,
FactoryException {
AxisDirection axisDir =
crs.getCoordinateSystem().getAxis(0).getDirection();
Envelope envelope = axisDir == AxisDirection.NORTH ?
new Envelope(minNorth, maxNorth, minEast, maxEast) :
new Envelope(minEast, maxEast, minNorth, maxNorth);
ReferencedEnvelope refEnv =
ReferencedEnvelope.create(envelope, crs);
return refEnv.transform(DEFAULT_CRS, true);
}
which seems like a lot of faff for what should be an easy
operation.
But we haven't even started yet because I am pretty sure this
code is
incomplete. I _think_ the real question is not are we x/y or
y/x it is
are we right handed (x/y) or left handed (y/x). So my code
above would
actually have to handle not just NORTH/EAST (right) and
EAST/NORTH
(left) but also NORTH/WEST (right) or NORTHEAST/SOUTHEAST
(left) etc etc
and so on through all the permutations of AxisDirection.
So ... the only sensible resolution I can see without writing
an entire
novel of if/elses for all the possible pairs of
AxisDirections is to use
forceXY, but referring back to the discussion mentioned
above, Ben
strongly discourages this.
Does anyone have any suggestions how this can be handled in a
generic
non-complex way without forcing x/y axis ordering? Hopefully
someone can
help.
If not can I suggest a method
ReferencedEnvelope.create(Envelope env,
CoordinateReferenceSystem crs,
boolean envelopeIsGeometric)
which (if arg2 is true) treats the envelope as x/y and does any
necessary axis conversion internally so that this piece of
code can be
written once and doesn't need to be written by anyone and
everyone who
might need NZTM in their app?
Would anyone else find this useful?
Thanks
Iain
--
Sent from my ZX80
---
This email has been checked for viruses by Avast antivirus
software.
https://www.avast.com/antivirus <https://www.avast.com/antivirus>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
_______________________________________________
GeoTools-GT2-Users mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
<https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users>
--
Sent from my ZX80
------------------------------------------------------------------------
Avast logo
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
This email has been checked for viruses by Avast antivirus software.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
--
Sent from my ZX80
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
GeoTools-GT2-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
