On 5/22/06, Jody Garnett <[EMAIL PROTECTED]> wrote:
Simone Giannecchini wrote: > I would suggest the following two steps solution which should make > everyone happy (or unhappy which would basically be the same :-) ). I am already - you are understanding the issues. Last time I had this conversation I had to sit through 100 emails to make it this far! > 1>Refactor OrderedAxisAuthorityFactory as follows: > -Use a name similar to OGCOrderedAxisAuthorityFactory to state > clearly what this is > -Reorder CRS axes and operation axes for serving lon,lat data > -Remove the code that actually strips off and/or changes metadata > info like as EPSG:CODE from the returned crs or operation. Not sure I understand the last point.
Not so clear indeed. Let me clarify. Right now the OrderedAxisAuthorityFactory does much of what we need for point 1 but it also, intentionally as Martin pointed out, strips off all the metadata for the CRS, like as an instance the code. If you now register the OrderedAxisAuthorityFactory on the EPSG authority and ask for EPSG:4326 CRS you will get an object that does not claim to be EPSG:4326. This was intentionally done to point out the fact that axes has been reversed. In the solution I am proposing I would like to avoid this step. Reason is that since one is asking on purpose to reverse the axes of all CRSs, we can reasonably assume that this one knows what he is doing and, hopefully, that he will keep a consistent behaviour throughout all his code. In the end he will never get to see that CRSs he gets have axes reversed if compared to the original CRSs as found in the EPSG databse hence he will expect to use EPSG:CODE to instantiate crss, projections and such without caring to the fact that someon is reversing axes.
> This would be a short term solution. > > 2>Implement the based un URI as suggested by OGC (Jody would be able > to provide more details than me) which would strictly follow the > conventions found in the EPSG database. +1 And I can try and hunt down the format. > I am sure there would many well-defined objections to these > approaches, especially to the first one, but let me drop here below > some considerations: I can make objections but frankly you are the one willing to do the work, and a solution is needed. The solution you propose will allow uDig to pick up the epsg-hsql jar and that would be a good thing. +1 Lets get all the tools constructed and on the table, if you look at the FM branch (ever) you will see that making geotools work the way you intend for the task at hand has gotten a *lot* easier. Jody
I will ask alessio to take look, for the moment I am too busy, sorry. Simone. -- °°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°° Simone Giannecchini Software Engineer Freelance Consultant http://simboss.wordpress.com/ °°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°° ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
