Menu
▾
▴
Re: [Geoserver-devel] Re: [Geotools-devel] Re: Blocking Issue affecting CRS, features and streaming renderer.
|
From: Rob A. <ro...@so...> - 2006-05-20 13:08:20
|
Ahh yes - dont we always get into trouble when we get poor separation of concerns! The problem is that axis order is a representation issue, and the rest of the CRS is a definition of the geometry. The use of the EPSG code as (an) authority to carry the definition for OGC protocol usage was independent of the serialisation of axis order. Some time after this practice (defensible) was established, and demonstrated pragmatic utility, a number of OGC heavyweights decided that we needed to take the whole representation + definition semantics and change (almost) everything. The issues - it doent match actual practice (at the time, we now how a mixture I suspect) and WMS BBOX was somehow exempted. The solution might have been trivial - declare that the representation was to be ignored, in favour of consistent lon/lat, and allow for an optional explicit representational syntax to be declared in the protocol where representations matter. SRS= axis_order= microformat=DMS CRS:84 I think has been defined by the OGC - maybe we lobby for an effort to move all existing WMS services to supporting it. Rob A Paul Ramsey wrote: > Just for fun, here's the record for 63266405: > > coord_ref_sys_code | 63266405 > coord_ref_sys_name | WGS 84 (deg) > area_of_use_code | 1262 > coord_ref_sys_kind | geographic 2D > coord_sys_code | 6405 > datum_code | > source_geogcrs_code | 4326 > projection_conv_code | 101 > cmpd_horizcrs_code | > cmpd_vertcrs_code | > crs_scope | Used by the GPS satellite navigation system. > Recommended > coordinate axis representation for computer interchange. > remarks | See CRS code 4326 for recommended coordinate > axis represe > ntation for the human interface. > information_source | EPSG > data_source | EPSG > revision_date | 2002-11-22 > change_id | > show_crs | 0 > deprecated | 1 > > Unfortunately it has a deprecated flag! I don't know *what* they > expect people to use for WGS84 data in Lon/Lat order now... > > P. > > On May 19, 2006, at 1:21 PM, Paul Ramsey wrote: > >> Simone, >> >> On May 19, 2006, at 11:26 AM, Simone Giannecchini wrote: >> >>> 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? >> >> >> Question for you: how do you define the CRS of your Shapefile? The >> problem here is not the CRS definition, it is the fact that your >> Shapefile probably stores the data on disk at lon/lat. And then you >> tell the datastore via your CRS definition (EPSG:4326) that it is >> lat/lon. Maybe you should use the "official" EPSG number of "WGS 84 >> with reversed axes" which is, wait for it... 63266405. You can tell >> they added these entries under duress, can't you? >> >>> 2>Can I assume that features are ALWAYS lon,lat? >> >> >> Well, it seems best to assume the features are always in the order >> you say they are. When you say they are 4326, you are saying that >> they are lat/lon. So stop saying that :) >> >> It is worth noting that a plain .prj file with a simple WKT >> description of WGS 84 will work perfectly well, because the default >> interpretation of WKT in geotools, if axis order is *not* specified >> is to use an x/y (lon/lat) ordering (thanks Martin!) >> >> Paul >> >>> >>> >>> >>> Thanks guys, >>> >>> Simone. >>> On 5/19/06, Jesse Eichar <je...@re...> 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 >>> Geo...@li... >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> >> >> >> >> ------------------------------------------------------- >> 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 >> _______________________________________________ >> Geoserver-devel mailing list >> Geo...@li... >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > > > > ------------------------------------------------------- > 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_______________________________________________ > > Geoserver-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geoserver-devel |