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. ------------------------------------------------------- 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
