Maybe I'm just being pedantic, but it seems to me that we are missing
the point a little here.
Axis order appears in serialisations of coordinate tuples, triples etc.
So, the three places where it may occur are :
a) in the source data
b) in the serialised input/output (eg GML)
c) in the internal data models
I think we can assume that we can live with these being assumed to be
homogenous at each layer, but we cant, and dont need to, and dont want
to, assume they need to be the same for al three layers. There is no
reason why the internal data models should not always force X,Y (for
north oriented cartesian CRS's! )
Then, the hint is not a system one, but simply needs to be applied per
data store (thus allowing one data store to be different from the others
and the system to keep working).
Control over the serialisation to output formats could take the
requested CRS as the authority, or use the system hint as described.
This would need to apply anyway, regardless of the internal axis order
rules.
My reading of the discussion is that we are creating an extra level of
translation around how we interpret the internally stored models, when
we already had to support this at both ends of the I/O between the
service interfaces and the persistence layer, on a case by case basis.
IMHO it is simpler to force a normative internal representation.
I admit I havent thought enough about how this would extend to
non-cartesian projections - but I suspect we dont handle those very well
anyway :-)
Rob A
Adrian Custer wrote:
> The Geotools axis order policy appears to be:
>
> in 2.2 and earlier, the order of coordinates One and Two is
> long/lat
> Users are expected to transform their data to fit
>
> in 2.3 and later, the order of coordinates follows the crs
> Users are expected to generate a correct CRS for their
> data
>
> epsg-wkt generates long-lat order info
> epsg-* generates lat-long order info
> pre-built convenience CRS's in Geotools are long-lat
> Factories/Builders will follow:
> (1) the system wide preset if it has been set
> -Dorg.geotools.forcelongitude...
> (2) the hinting mechanism if it has been set
> (3) the authority in use
> and users are expected to be aware of
> the order in the authority they are
> using.
>
> A policy such as this seems workable, especially if we have a well
> written explanation for workarounds. Something like
> CRSFactory.makeLongFirst(CRS)
> CRSFactory.makeLatFirst(CRS)
> if users have the right CRS and the wrong order.
>
> This is how I understand things today. Please let me know if things are
> different because I'll eventually write this up. Thanks, adrian
>
>
>
> <acuster> simboss, can you explain the axis order to me?
> <simboss> ;-(
> <acuster> I just noticed in 2.2. I have to have coordinates long/lat to
> work with the default crs
> <acuster> in 2.3 this has changed?
> <simboss> we finally found kind of an agreement
> <aaime> The problem occurs when you have lat/long
> <simboss> go ahead andrea
> <aaime> (swapped axis)
> <acuster> wait
> <acuster> let's start from 2.2.0
> <acuster> it expects what order?
> <aaime> 2.2.0 works properly with long/lat, but not lat/long
> <acuster> good
> <acuster> and 2.3.0 is the other way around, or something more complex?
> <aaime> That is, all code is written as if the axis are oriented as
> standard x/y cartesian ones
> <aaime> 2.3.0 tries to make things work with lat/long too
> <aaime> If you think about it, x and y are swapped like this
> <aaime> x pointing northwards, y eastwards
> <aaime> All the code needs to inspect the axis orientation before making
> assumptions about grid shape or envelope shape
> <aaime> So the code touches literally everything that's related to
> filters and rendering
> <acuster> okay, so let's think about the users who have data the
> opposite way
> <aaime> and coverages too (a lot)
> <aaime> With 2.3 it should work just fine
> <acuster> in 2.2.0 users have to have coordinates in the right order or
> <aaime> Or it does not work at all
> <acuster> good
> <acuster> that's easy and clear
> <acuster> oh no.
> <aaime> Because you write (lat/lon) -> (20, 10) and the code understands
> 20 lon, 10 lat
> <aaime> On trunk, if the crs is properly defined
> <acuster> right, i'm trying to understand how to warn users and give
> them advice if they have data in the opposite order
> <aaime> a ton of code has been adapted to look at axis order
> <acuster> for 2.2.0, you have to have long/lat
> <aaime> and to understand it properly
> <aaime> Yes
> <acuster> in 2.3.0, you have to have a crs defined
> <aaime> In 2.3.0, provided that the CRS declares the axis as lat/lon
> (that is, swapped)
> <aaime> the code should manage this properly
> <aaime> _should_ that's the key
> <aaime> when you modify a library as big as geotools
> <aaime> you're bound to forget something some place
> <aaime> that's why we do need testing (among other things)
> <acuster> fine, I'm not worried about bugs, I'm worried about announcing
> the working principles
> <aaime> I see. The working principle of 2.2.0 is lon/lat or be damned
> <acuster> okay
> <aaime> The working principle of 2.3.0 is whatever you like and say your
> prayers :-)
> <acuster> in 2.3, if you have long/lat data, can you easily create an
> "inverted" crs?
> <aaime> Hum, I do think it's easy for coverages
> <aaime> Don't think anybody ventured in the vector land?
> <aaime> But we do have a reprojecting reader that _should_ work
> <acuster> all the default crses are lat/long though, in 2.3, correct?
> <aaime> I just haven't tested it
> <aaime> Simboss?
> <aaime> No, long/lat
> <simboss> no
> <simboss> it depdens on various aspects
> <aaime> It just works fine with lat/long as well
> <simboss> 1>the authorithy you uses
> <aaime> Going to grab a beer, brb
> <simboss> epsg-wkt
> <simboss> is long-lat
> <simboss> always
> <simboss> the others are lat-long by default as far as talking about
> most geographic crs
> <simboss> like wgs84
> <simboss> but we introduced
> <simboss> two switches to force them to lon-lat
> <simboss> as most people wuld expect
> <simboss> a>there is a system wide java option
> <simboss> something like
> <acuster> "the others" equals the other epsg databases?
> <simboss> -Dorg.geotools.forcelogitude_something=true
> <simboss> (yeah)
> <simboss> b>use a proper Hints' key when asking for a crs
> <simboss> something like
> <simboss> HInts.FOrceblahblah
> <simboss> in general
> <simboss> in 2.3.x
> <simboss> we are starting to admit
> <simboss> that the problem exists
> <simboss> and we are starting with some solutions
> <simboss> so far
> <simboss> the problem has just been denied
> <simboss> that is
> <simboss> udig and geoserver
> <acuster> If we have a clear policy, and an easy way for users to flip
> if their data shows up wrong, it's not going to be an issue
> <simboss> use usually
> <simboss> epsg-wkt
> <aaime> Adrian, in this particular case, the policy was not the issue,
> it was the amount of code that needed to be changed
> <acuster> what are the helper classes?
> <aaime> And thus the denial
> <simboss> and that code
> <simboss> might still be changed
> <acuster> well you have done the bulk of the work right? :-)
> <simboss> but
> <simboss> on my side
> <simboss> coverage
> <simboss> me and aaime
> <simboss> did as much as possible
> <aaime> C'mon Simone, you, period
> <aaime> what I have done is a drop in a sea
> <simboss> yeah
> <simboss> whatever :-)
> <acuster> org.geotools.referencing.CRS is what order
> <simboss> the point is
> <simboss> IMHO
> <simboss> that we need
> <simboss> way more testing
> <simboss> I would like toport
> <simboss> udig to 2.3.x
> <simboss> but I have really no time
> <simboss> (unlesss someone pays me :-) )
> <aaime> Hmm... you may have better luck with Geoserver, since with wcs
> you have already done half of the work (may 90%?)
> <simboss> that would give a big hand with spotting bugs
> <simboss> sure
> <simboss> but WCS
> <simboss> and raster in general are just raster
> <simboss> I won't go touching WFS
> <simboss> :-)
> <aaime> Wait, WMS should enjoy improved raster support
> <aaime> that's where you can have your test
> <acuster> org.geotools.referencing.crs.DefaultGeographicCRS.WGS84
> <simboss> sure
> <aaime> (you know, the new methods for creating a MapLayer out of a
> coverage reader?)
> <simboss> I am not afraid of what I can control
> <simboss> (raster everywhere)
> <simboss> but of what I cannot control
> <simboss> that is feaeture
> <aaime> Well, WMS manages features as well
> * acuster is leaking java vm's all over the place
> <simboss> yeah
> <simboss> that is the point
> <simboss> :-)
> <aaime> and I think it's the path of least resistance
> <simboss> at least
> <aaime> Adrian, what's happening to you? :-)
> <simboss> is the one we will sort out first for sure
> <aaime> Yep, better not start with things that may hurt badly
> <aaime> Start gentle and ramp up
> <aaime> Ok, I really finished my time.
> <aaime> I'm going to post this part of the discussion as well since I do
> believe it's of general interest
> <acuster> can you answer that last qestion
> <acuster> what order the convinience crs's are in?
> <aaime> Which one?
> <aaime> Long/lat afaik? Simone knows better
> <acuster> and epsg-wkt is here to stay for the forseeable future?
> <simboss> what do you mean exactly adrian
> <simboss> ?
> <aaime> I'd say so. You can't just drop what worked for two big projects
> overnight
> <acuster> geotools has some predefined CRS's
> <aaime> Plus there is lots of hand tweaking in epsg-wkt
> <acuster> which include predefined coordinate systems
> <acuster> persumably all of this should be in one or the other order but
> not mixed
> <acuster> for 2.2. this is long/lat, since everything is long/lat
> <acuster> what will it be for 2.3?
> <simboss> there are two ansers
> <simboss> 1>it depends on the user
> <simboss> 2>it depends on the authority you frop in the classpath
> <acuster> GeographicCRS geoCRS =
> org.geotools.referencing.crs.DefaultGeographicCRS.WGS84;
> <acuster> GeodeticDatum wgs84Datum =
> org.geotools.referencing.datum.DefaultGeodeticDatum.WGS84;
> <acuster> PrimeMeridian greenwichMeridian =
> org.geotools.referencing.datum.DefaultPrimeMeridian.GREENWICH;
> <acuster> CartesianCS cartCS =
> org.geotools.referencing.cs.DefaultCartesianCS.GENERIC_2D;
> <acuster> CoordinateSystemAxis latAxis =
> org.geotools.referencing.cs.DefaultCoordinateSystemAxis.GEODETIC_LATITUDE;
> <acuster> things like that, exist in Geotools itself, not anywhere else
> <acuster> not in the user code
> <acuster> not in the authorities
> <simboss> but we are talking about something different
> <simboss> we are talking about something like
> <acuster> are all those expected to be in one order?
> <simboss> crs= CRS.decode("EPSG:4326)
> <acuster> yes, you are talking about something else
> <simboss> which is not hardcoded
> <acuster> I understand that part
> <simboss> thos things you listed
> <acuster> I want to know about the hardcoded stuff
> <simboss> are like that
> <aaime> Going away. Haven't posted this part. Can you?
> <simboss> and they will never change
> <simboss> (hopefully :-) )
> <acuster> sure aime
> <acuster> simboss, so they are long/lat in 2.2 and will stay that way?
> <simboss> sure
> <acuster> thanks
> <simboss> because they are built that way
> <simboss> the conflict
> <acuster> that's what I wanted to know
> <simboss> is because
> <simboss> epsg-wkt
> <simboss> is incorrect strictly talking
> <acuster> I thought maybe you had changed them in 2.3
> <simboss> and because
> <simboss> OGC made a mess
> <acuster> yes, I understand the bigger picture as well
> <simboss> with axes order during years
> * aaime ([EMAIL PROTECTED]) has left
> #geotools
> <simboss> switching from lat-long to long-lat
> <simboss> intermittently
> <acuster> but I need to be able to tell users (1) what's going on (2)
> how to deal with problems
> <acuster> thanks, I'm done
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
