Andrea, You're correct; I reported the Lat/Lon bounding box computed from the native bounds. The native bounding box is:
293,568.683, 4,826,563.776, 335,747.204, 4,857,106.675 If you're interested in the shapefile I'm experimenting with, it can be found at: http://www.toronto.ca/open/datasets/wards/wards_may2010.zip . I appreciate your comment that there is no "exact result" and I probably wouldn't have even noticed an error in the range of 4-10 m. However, a difference of 0.003 degrees is several hundred meters by my calculation. And the 32190 result has me baffled - I must have done something wrong, but not sure what. Thanks for your help and insight, Rick On Jan 9, 2011, at 3:03 PM, Andrea Aime wrote: > On Sat, Jan 8, 2011 at 11:20 PM, Rick Workman <ridgewo...@mac.com> wrote: >> I have imported a shape file into GeoServer (2.0.2 or 2.1-beta3) whose >> native and declared SRS is EPSG:2019 (NAD27(76) / MTM zone 10 ). When I view >> the layer from a WorldWind client whose WMS request uses EPSG:4236 (WGS 84) >> overlaid on a MS virtual earth image layer, it appears to be offset from >> the image. And I get the same effect using Google Earth as a client. >> >> Now if I use Quantum GIS to reproject the original shape file to EPSG:4326 >> and import that shape file into Geoserver, the resultant layer seems to be >> correctly aligned. >> >> If I go back to the layer definitions in the Geoserver admin interface, the >> computed Lat/Lon Bounding Box for the two layers is slightly different: >> >> Original (EPSG:2019): -79.64, 43.578, -79.115, 43.854 >> QGIS altered (EPSG:4326): -79.639, 43.581, -79.115, 43.855 >> (correct values, as far as I can tell) >> >> The discrepancy between the two sets of values seems to correspond fairly >> well with the offset displayed by the clients (WorldWind and Google Earth). >> >> So unless I'm missing some setting in the layer definition process, it looks >> like Geoserver is not accurately projecting at least the EPSG:2019 SRS. >> >> On further investigation, it I can't find too many SRS systems that do seem >> to work. For example, the same shape file converted (in QGIS) to a native >> SRS of EPSG:26717 ("NAD27 / UTM zone 17N") has slightly larger errors: >> >> EPSG:26717: -79.643, 43.575, -79.113, 43.862 >> >> and EPSG:32190 ("NAD83 / MTM zone 10") seems to have correct native bounding >> box lat/lon values, but the computed Lat/Lon bounding Box is nonsensical: >> >> EPSG:32190: -82.238, 0, -82.238, 0 >> >> >> Any ideas what's going on? > > This is odd, as you're the first to report systematic errors of this kind. > In all the cases you're citing there is a datum transformation, which > in GeoServer is performed > by using the 7 params transformation driven by the towgs84 parameter set. > > It is a simple method that gives normally good results with some > meters error (4 to 10). > Maybe QGis is using under the hood a grid based datum transformation > that GeoServer, > as of now, does not have support for (there were talks about > implementing it but nothing > materialized). Grid based transformations normally give better > results, with accuracies > in the order of the centimeters (if properly setup). > > That said, there is something odd with the data you're providing. This > EPSG:2019 > is a projected coordinate system with ordinates expressed in meters > that do range > in the orders of millions of meters, a bbox like: > Original (EPSG:2019): -79.64, 43.578, -79.115, 43.854 > simply makes no sense in EPSG:2019, as you're still expressing the ordinates > in > degrees. > (see http://spatialreferences.org/ref/epsg/2019/, look at projected bounds) > > If you have the actual original bounding box (expressed in epsg:2019) > I can compare > the transfromation results between GeoServer and libproj, the library that > QGis > uses under the hood, and probably figure out what's going on. > > Cheers > Andrea > > PS: when datum transformations are concerned there is no "exact" result, there > are just different transformation methods that provide different > levels of accuracy > > -- > Ing. Andrea Aime > Technical Lead > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584962313 > fax: +39 0584962313 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > -----------------------------------------------------
------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
