David, Thanks for the reply. I don't think the client is at issue here. The error seems to be in the layer definition process in Geoserver, namely the Lat/Lon Bounding box is different depending on the native SRS of the shapefile. Should this ever be the correct result? (QGIS seems to covert back and forth between different SRS with little or no loss of accuracy.)
Regarding the client, shouldn't the server reproject (correctly) according to the SRS requested by the client? Otherwise, there would some implicit assumption in the production of the shapefile about the nature of the client ultimately making the request, which doesn't seem right to me. I'm new to this whole GIS world, so maybe I'm not understanding the underlying architectural assumptions of WMS. Rick On Jan 8, 2011, at 9:53 PM, David Collins wrote: > Rick, > > I believe that Google Earth always expects the data to be EPSG:4326, and > assumes this, regardless of what the datum really is. It sounds like the > results you are getting line up with this. > > Regards, > David > > > On Sun, Jan 9, 2011 at 9:20 AM, Rick Workman <[email protected]> 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? > > > Rick > > > > ------------------------------------------------------------------------------ > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-users >
------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-users
