Martin Desruisseaux <[EMAIL PROTECTED]> wrote on 05/23/2006 04:24:55 PM:
> If we agree than starting from now, "EPSG:whatever" should be > understood as being always > (longitude,latitude) axis order (as OGC decided recently in my > understanding of a recent Jody's > mail), then it is a new authority factory derived from the previours I wouldn't agree to that. Now we cannot handle data which correctly declares that it is EPSG:4326. Same problem different direction. Even if *I* agreed to that, *I* don't make data. For this to work, all data producers in the world need to agree to this convention. The source of the problem is "out in the world somewhere", is not party to this discussion, and hence will remain ignorant of any agreements made on this list. GT will continue to encounter both axes orderings using the same moniker, and it is not our place to decide which is right or wrong. GT _should_ make it easy to write an app. that lets a human choose the correct axes order regardless of what the file claims. > The work I'm currently doing in the referencing module is > rather "make Geotools paranoiac" > than "add some hacks". My point was that the CRS in the file does not have to be the CRS returned by the DataSource. The referencing module should not be involved, except perhaps to provide a DerivedCRS which swaps axes from the BaseCRS (...and returns a DerivedOperation which swaps axes, etc.). Every module except the Data Sources should trust that the CRS provided is accurate. Data Sources should adopt a convention of either trusting files or not trusting files, but honoring a human override in either case. But what it boils down to is: if we're solving this problem using the referencing module, it's a hack. (Even if it's a well-written hack) This problem needs to be addressed at the point data enters the system. Bryce ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
