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
us...@lists.osgeo.org <mailto:us...@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
_______________________________________________
Users mailing list
us...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-users
