<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/4.6.0">
</HEAD>
<BODY>
We use 2.11 and also track Maryland State Plane values in our site, and everything works well. However, our Maryland NAD83(m) is EPSG:2804, and NAD83(f) is EPSG:2893. Could that be the source of your problem? Those coords put me at the insn of Peachtree and Comus Rds in Montgomery County, and they look fine.<BR>
<BR>
Here's our site which offers real-time coord updates in a number of systems as one pans around:<BR>
<BR>
<A HREF="http://www.martenet.com/archives">www.martenet.com/archives</A><BR>
<BR>
You might want to compare what we have with yours.<BR>
<BR>
-J.<BR>
<BR>
On Tue, 2013-02-26 at 12:03 -0500, Jay Parsons wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hello,

I am new to this list.  We have been using OpenLayers for several years, 
but recently discovered an issue with the coordinates being shifted by 
around 500 ft (150 m) after upgrading from 2.10 to 2.11, and the problem 
still seems to exist in 2.12.

We are using a subclassed XYZ layer (subclassed to allow the origin to 
be outside of the extents of the tiles, which our tile set requires) to 
hit ArcGIS but otherwise it's straightforward - the display projection 
is EPSG:4326 (plain lat/long) and the base layer projection is 
EPSG:26985 (Maryland State Plane, which is a Lambert projection that 
requires a custom definition for proj4js).

Positioning the mouse cursor over a particular intersection of roads on 
the map using first OpenLayers 2.10 and then again using 2.11 reveals:

39.24226, -77.32623  (OpenLayers 2.10)
39.24332, -77.32737  (OpenLayers 2.11)

Plugging the first numbers into Google Earth, they are correctly aligned 
with the roads.  The second numbers are shifted and incorrect. 
(Interestingly I usually see it shifted to the southeast, although in 
this case it seems to be shifted to the northwest by the same distance). 
  The offset is glaring at 1:16K, still quite visible at 1:32K, and 
minor but visible at the 1:64K scale.

All of our vector objects are offset by a similar amount, but the mouse 
position control vs. the base layer also illustrates it without 
introducing vector layers as a potential suspect.

I could be wrong but I doubt that the problem is with the app-level code 
because the difference is apparent by simply switching the OpenLayers 
library.

I'm not sure if this is the same issue as Ticket #3640 
(<A HREF="http://trac.osgeo.org/openlayers/ticket/3640">http://trac.osgeo.org/openlayers/ticket/3640</A>) as there is not a lot of 
information given in that ticket, but the order of magnitude of the 
error looks about the same.

Any info or insight would be appreciated.  Thanks.

Jay
_______________________________________________
Users mailing list
<A HREF="mailto:Users@lists.osgeo.org">Users@lists.osgeo.org</A>
<A HREF="http://lists.osgeo.org/mailman/listinfo/openlayers-users">http://lists.osgeo.org/mailman/listinfo/openlayers-users</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>