[OpenLayers-Users] Coordinates shifted after upgrade from 2.10 to 2.11 / 2.12

Tue Feb 26 13:41:17 PST 2013

Joel, thanks for the response.  Comparing the proj4s projection 
definitions for EPSG:2804 and EPSG:26985, they are identical except that 
26985 has an extra "+datum=NAD83" parameter.  In any case I have to use 
26985 - more on that below.

However I would think that any projection would perform the same 
function whether it is used in OpenLayers 2.10 and 2.11, so I don't 
think the projection could explain the difference of behavior before and 
after the OpenLayers upgrade.

Joel, I agree that the coordinates on your map are correct for that 
intersection.  We are using different base layers, however, so perhaps 
it is a tile origin or tile shift problem rather than a projection 
problem.  Maybe it's specific to the type of base layer.

Everyone:

Whatever the issue is, I believe the problem MUST be in OpenLayers code 
because I can make this work or not work correctly by simply 
substituting OpenLayers 2.10 or 2.11, with no changes to my code.

Here is a page with a pair of screenshots that shows the issue:

http://71.178.253.249:8080/OpenLayers_issue_demo/OpenLayers_shift_results.html

Our application is required to use the tileset that is documented here:

http://65.207.23.58/ArcGIS/rest/services/ChartBG_Cache/MapServer

These tiles are owned by Maryland State Highway Administration and I 
have no control over the parameters or how they are laid out. Our 
application is one of several that uses these tiles.  (This is also 
where it specifies the EPSG 26985 projection).

Given the parameters specified at the URL above, I reduced our code to a 
pair of pretty simple demo web pages.  (These are the pages from which I 
took the screenshots above).  These pages differ only by which version 
of OpenLayers they include:

http://71.178.253.249:8080/OpenLayers_issue_demo/MapTest_OpenLayers_2_10.html

http://71.178.253.249:8080/OpenLayers_issue_demo/MapTest_OpenLayers_2_11.html

Feel free to do a View->Source, it is not that long... under a couple 
hundred lines, some of which are comments or trivial code.

There is one custom subclass of the XYZ layer type with is located in a 
separate Javascript file, but it too is small and fairly 
straightforward.  We  had to subclass the XYZ layer because the tile 
origin was outside of the extents of the tiles, which the XYZ layer did 
not seem to support.

Thanks.

Jay

On 2/26/2013 2:46 PM, Joel Leininger wrote:
> 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.
>
> Here's our site which offers real-time coord updates in a number of
> systems as one pans around:
>
> www.martenet.com/archives <http://www.martenet.com/archives>
>
> You might want to compare what we have with yours.
>
> -J.
>
> On Tue, 2013-02-26 at 12:03 -0500, Jay Parsons wrote:
>> 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
>> (http://trac.osgeo.org/openlayers/ticket/3640) 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
>> Users at lists.osgeo.org  <mailto:Users at lists.osgeo.org>
>> http://lists.osgeo.org/mailman/listinfo/openlayers-users
>
> --
> Joel M. Leininger
> S.J. Martenet & Co., Inc.
> 1114 St Paul Street
> Baltimore, Maryland 21202
>
> www.martenet.com <http://www.martenet.com>
>
>

-- 
Jay Parsons
Turnkey Technology Corp.
240-720-4936