On Sat, Jan 8, 2011 at 11:20 PM, 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?

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Reply via email to