Ciao Jesse, before talking about a solution, I would first like to have some answers from the module mantainers of the features plugins to thee two questions:
1>Can I assume that features in EPSG:4326 are always Lon,Lat even if the CRS claims to be Lat,Lon as it happens with EPSG-HSQL authority? 2>Can I assume that features are ALWAYS lon,lat? Thanks guys, Simone. On 5/19/06, Jesse Eichar <[EMAIL PROTECTED]> wrote:
Hi Simone, I'm in agreement that this issue needs to be resolved. The problem is that I'm not 100% sure how to solve the problem. Do you have a suggestion? I apologize if you have put you suggestion in this email, I must have missed it. Jesse On 19-May-06, at 8:51 AM, Simone Giannecchini wrote: > Hi list, > this email is a follow-up of an informat chat I had with Jody a couple > of days ago about a problem I might have found which has consequences > for the use of all EPSG Authorities, Rendering and initially > Shapefile. > This issue is a BLOCKER issue for merging back to trunk, I hope at > least Jesse, Martin and Dave will give some feedback and propose > solutions. > > Here is the thing. >> Antefact< > Me and Alessio always use the EPSG-HSQL or EPSG-Postgresql as > authority data source, we neve use the epsg-wkt. > >> Problem< > I have developed a coverage plugin which is able to read and put > together a mosaic of image. It uses a shapefile as a catalog storing > for each image, the envelope as the geometry of the shape itself and > the location of the image on disk. > > When I connect to the catalog shapefile using EPSG:4326 Lat,Lon as a > CRS (the originating images where in WGS84 as well) and I try to get > the envelope of the loaded features, I get a JTS envelope with lon,lat > values while the CRS is Lat,Lon. > > Is this the expected behaviour, is this a bug, is this stupid me > asking useless questions? > > Should I assume that features in EPSG:4326 are always Lon,Lat even if > the CRS claims to be Lat,Lon? > Should I assume that features are ALWAYS lon,lat? > > This last question comes specifically adter having worked for a while > on the streaming renderer where most methods assume that the envelope > are ALWAYS lon,lat. Just take a look as an instance to the helper > methods in the RenderUtilities class and you will see what I mean. > >> Consequences< > This issue greatly impact the StreamingRenderer for example and > reprojections as well. If I use EPSG-HSQL and I try to reproject an > envelope got from a set of features, results are pretty unpredictable > depdending on the axis order of the CRS. > >> Objective< > I would like to know what the maintainers of the various features > modules think about what I said, especially if I should always expect > to see features in lon,lat for EPSG:4326. > >> Comments< > Jody pointed out that EPSG:4326 in OGC context should always be > lon,lat and suggested to write an authorithy to handle that. I think > it is a good solution in the mdeium term but not in the short term, > therefore I propose a quick hack for the short term and the authority > for the mid-long term. He was also proposing on using the OGC new way > for asking CRS, which is by URI. > > > Martin already implemented the OrderedAxisAuthorityFactory which > should take care of this. I used it and I have to say that it works > fine except that if I ask for an EPSG:4326 crs it gives, correctly, a > lon,lat WGS84 but with no identifiers related to EPSG, so basically it > is just a simple WGS84 geographic CRS with lon,lat axis and no > authorithy identification. This is not suitable for most use cases in > GeoServer since I need the Authority in order to be able to use the > code in GetCapabilities and such. > Point is that if I ask an EPSG:4326 CRS, I want an EPSG:4326 CRS, I > find strange that I get instead something that, at least formally, is > not EPSG:4326 ( I hope I made my point clearly, but I doubt it). > I think that with some adjustmens this OrderedAxisAuthorityFactory > could act as what Jody needed, we would just have to add suport for > URI. > > David is going to refactor the streaming renderer shortly, I think it > would be worth to tackle this problem before he start doing his job, > which btw is great since performances of the StreamingRenderer has > improved a lot. > > Grazie, > 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
