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]> 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]> 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-R
>> eferencedEnvelope-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
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> 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]
>> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>>
>
>
> --
> Sent from my ZX80
>
>
>
> ------------------------------
> [image: 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>
>
>
------------------------------------------------------------------------------
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
