Thanks to SharpGIS. Morten’s input got me looking in the right direction!

My orginal hunch was correct it was the ellipsoid datum vs spherical.

However, I finally realized I had made a big error on the eccentricity. Don’t know what I was thinking at the time but e should be:
double f = 1 / 298.257223563;
e = Math.Sqrt(2*f – Math.Pow(f,2));
or
e = 0.081819190842621486;

Use that in MercatorEllipsoid for com.esri.wms.Esrimap services and it all comes together correctly.

So GeoServer must ignore the flattening 298.257223563 or else assume it is like the 900913 where flattening is overridden by making semi_minor axis = major.
PARAMETER["semi_minor",6378137.0]

At any rate I now must check to see if ESRI is providing the WMS or some other service and take into account datum difference between EPSG:3857 and ESRI:54004

thanks
randy

Thanks for the input.

Yes there is no such thing as EPSG:900913 or 54004, or 41001, only EPSG:3857. Unfortunately the EPSG prefix seems to get used in various tools out there. Probably shouldn’t reference them that way, but I think it can’t be helped by this time.

Interesting, I thought that 900913 was around before Virtual Earth showed up. It does seem to be fairly commonly referenced as “900913=PROJCS[”WGS84 / Google Mercator, …”
I thought EPSG:3785 was sponsored by Microsoft and then it was deprecated in favor of EPSG:3857. I could be wrong on that.

I’m not sure what formula you are refering to above. The Mercator() uses spherical with no eccentricity, MercatorEllipsoid does/should use e since it was an attempt to see whether the datum diff noted would account for the shift. It didn’t seem to? It is used to calculate the BBOX coordinates for the GetMap requests.

Apparently GeoServers 54004 def is different from the ESRI def in some way since they give different results? GeoServers’s matches OSM, Yahoo etc, ESRI’s doesn’t.

When I get a chance I’ll look into it more. I want to change things a bit in my client so I can choose EPSG for each of the services independently and look at match ups.

thanks
randy

Second, 54004 was never meant to be the same as 3857. The reason is that they are using different datums. You need to define a datum transform to go from one to the other to get your transformations to look right. The error you are seeing is exactly the expected error for a datum transform error.
Here’s the main difference between the two spatial references:
54004: DATUM["WGS_1984", SPHEROID["WGS_1984",6378137,298.257223563]]
3857: DATUM["WGS_1984_SPHERE", SPHEROID["WGS_1984",6378137,0]]
The ‘e’ value in your formula above is therefore also wrong, since a sphere has no flattening. It does work for 54004 since this one defines a flattening. The conversion is actually a lot simpler because of the lack of flattening as described here: http://cfis.savagexi.com/2006/05/03/google-maps-deconstructed

Here’s a couple of others links that might also help you:
http://www.sharpgis.net/post/2007/07/27/The-Microsoft-Live-Maps-and-Google-Maps-projection.aspx
http://www.sharpgis.net/post/2008/05/15/SphericalWeb-Mercator-EPSG-code-3785.aspx
http://www.sharpgis.net/post/2007/05/05/Spatial-references2c-coordinate-systems2c-projections2c-datums2c-ellipsoids-e28093-confusing.aspx

If you are using ESRI software, use WKID 102113, since this was the ID ESRI chose before EPSG finally defined one.

Brian Timoney passed on your suggestion as well. I tried it but no change.

Hi dnewcomb,

I looked at this in uDig but it’s hard for me to see what the actual WMS url call is, so I can’t tell whether uDig is warping after the image request (as 4326) or not. I also noted uDig doesn’t seem to have 54004 in their list as of 1.1.1. Also missing are 900913 and 3857(does substitute AGD66(EPSG:4202)). The only spherical mercator I could try was 41001, which isn’t published in the GetCapabilities and resulted in similar discrepancy.
Of course 4326 does align as you zoom in to closer levels.

Also tried Glbal Mapper but I couldn’t make it use 54004?

Still baffled. I guess the problem is really that EPSG:3857 is so rare and these other partly supported spherical mercators 41001, 900913, 54004 are not consistently published by WMS servers or consumed by WMS clients. The best solution would be for EPSG:3857 to be universally adopted.

cheers
brian