From bbtt0 at verizon.net  Fri Mar  1 09:10:52 2013
From: bbtt0 at verizon.net (Jay Parsons)
Date: Fri, 01 Mar 2013 12:10:52 -0500
Subject: [OpenLayers-Dev] Coordinate shift of ~150m after OpenLayers 2.10
	upgrade to 2.11/2.12
Message-ID: <5130E11C.7040509@verizon.net>

Hello,

We recently discovered an issue with coordinates being shifted by around 
150 m (500 ft) after upgrading from 2.10 to 2.11, and the problem still 
exists in 2.12.  The problem occurs in at least the latest Firefox and 
IE8/9.

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 vs. 
2.11/2.12, with no changes to my application code.

This may or may not be 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 magnitude of the error and the 
direction of the offset look about the same.  That ticket may seem to 
suggest that the problem is specific to that type of map/application, so 
if it is the same problem perhaps this report will at least give you 
more information.

Positioning the mouse cursor over a particular intersection of roads on 
my 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.

Here is a page with a pair of screenshots that shows the issue for the 
intersection listed above:

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

Here are the demo web pages from which I took the screenshots above. 
These pages differ only by which version of OpenLayers they use:

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, as it is less than a couple hundred 
lines (some of which are comments or trivial code).

The code uses parameters from the tileset documented here (over which I 
have no control):

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

There is one custom subclass of the XYZ layer type which is located in a 
separate Javascript file, but it too is small and fairly 
straightforward.  (You can do a View->Source of that too).  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. 
Again this subclass has been working for a couple of years with 2.10.

I did a diff of the 2.10 and 2.11 source tree and spent a few hours 
trying to figure it out.  I suspect the issue may be related to the 
changes in Layer.getLonLatFromViewPortPx() but I tried reverting this 
function back to 2.10 and got a stack overflow error and at that point 
realized that I am not familiar enough with this code to know what I'm 
doing, and this would be hard for me to debug also since it is probably 
called a lot.

Any info or insight would be appreciated.  Thanks.

Jay

From Robert.Sanson at asurequality.com  Sun Mar  3 11:39:46 2013
From: Robert.Sanson at asurequality.com (Robert Sanson)
Date: Mon, 04 Mar 2013 08:39:46 +1300
Subject: [OpenLayers-Dev] Coordinate shift of ~150m after OpenLayers
 2.10 upgrade to 2.11/2.12
In-Reply-To: <5130E11C.7040509@verizon.net>
References: <5130E11C.7040509@verizon.net>
Message-ID: <51345DD2020000370000F094@lx-gwgate1.asurequality.com>

Sounds like a projection issue, perhaps related to a datum shift? If so, I would be looking at Proj definition files.

This is how I refer to proj files at the top of my Javascript code:

<script src="lib/proj4js-combined.js"></script>
<script src="lib/EPSG2193.js"></script>
<script src="lib/EPSG27200.js"></script>
<script src="lib/EPSG4326.js"></script>

Regards,

Robert

>>> Jay Parsons <bbtt0 at verizon.net> 2/03/2013 6:10 a.m. >>>
Hello,

We recently discovered an issue with coordinates being shifted by around 
150 m (500 ft) after upgrading from 2.10 to 2.11, and the problem still 
exists in 2.12.  The problem occurs in at least the latest Firefox and 
IE8/9.

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 vs. 
2.11/2.12, with no changes to my application code.

This may or may not be 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 magnitude of the error and the 
direction of the offset look about the same.  That ticket may seem to 
suggest that the problem is specific to that type of map/application, so 
if it is the same problem perhaps this report will at least give you 
more information.

Positioning the mouse cursor over a particular intersection of roads on 
my 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.

Here is a page with a pair of screenshots that shows the issue for the 
intersection listed above:

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

Here are the demo web pages from which I took the screenshots above. 
These pages differ only by which version of OpenLayers they use:

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, as it is less than a couple hundred 
lines (some of which are comments or trivial code).

The code uses parameters from the tileset documented here (over which I 
have no control):

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

There is one custom subclass of the XYZ layer type which is located in a 
separate Javascript file, but it too is small and fairly 
straightforward.  (You can do a View->Source of that too).  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. 
Again this subclass has been working for a couple of years with 2.10.

I did a diff of the 2.10 and 2.11 source tree and spent a few hours 
trying to figure it out.  I suspect the issue may be related to the 
changes in Layer.getLonLatFromViewPortPx() but I tried reverting this 
function back to 2.10 and got a stack overflow error and at that point 
realized that I am not familiar enough with this code to know what I'm 
doing, and this would be hard for me to debug also since it is probably 
called a lot.

Any info or insight would be appreciated.  Thanks.

Jay
_______________________________________________
Dev mailing list
Dev at lists.osgeo.org 
http://lists.osgeo.org/mailman/listinfo/openlayers-dev



This email and any attachments are confidential and intended solely for the addressee(s). If you are not the intended recipient, please notify us immediately and then delete this email from your system.

This message has been scanned for Malware and Viruses by Websense Hosted Security.
www.websense.com

From p.scadden at gns.cri.nz  Sun Mar  3 12:19:48 2013
From: p.scadden at gns.cri.nz (Phil Scadden)
Date: Mon, 04 Mar 2013 09:19:48 +1300
Subject: [OpenLayers-Dev] Coordinate shift of ~150m after OpenLayers
 2.10 upgrade to 2.11/2.12
In-Reply-To: <51345DD2020000370000F094@lx-gwgate1.asurequality.com>
References: <5130E11C.7040509@verizon.net>
	<51345DD2020000370000F094@lx-gwgate1.asurequality.com>
Message-ID: <5133B064.4000704@gns.cri.nz>

Except it seems strange thing to change between 2.10 and 2.11. My money 
is on the tileorigin /offset calculation. You might want to check if 
anything is changed between 2.10 and 2.11 on that.

Notice: This email and any attachments are confidential.
If received in error please destroy and immediately notify us.
Do not copy or disclose the contents.


From p.scadden at gns.cri.nz  Tue Mar  5 12:55:45 2013
From: p.scadden at gns.cri.nz (Phil Scadden)
Date: Wed, 06 Mar 2013 09:55:45 +1300
Subject: [OpenLayers-Dev] Coordinate shift of ~150m after OpenLayers
 2.10 upgrade to 2.11/2.12
In-Reply-To: <CAOiJ94jFmiPY+ShwA4jkeWzFmZOS-6dX4QrxyNinjbykPp=qTQ@mail.gmail.com>
References: <5130E11C.7040509@verizon.net>
	<51345DD2020000370000F094@lx-gwgate1.asurequality.com>
	<5133B064.4000704@gns.cri.nz>
	<CAOiJ94jFmiPY+ShwA4jkeWzFmZOS-6dX4QrxyNinjbykPp=qTQ@mail.gmail.com>
Message-ID: <51365BD1.4070304@gns.cri.nz>

Copying to list.
On 5/03/2013 11:59 p.m., Andreas Hocevar wrote:
> I think Phil is absolutely right. This was fixed with
> https://github.com/openlayers/openlayers/commit/893966dfae6e9f2e376e08eccbf6b4474de56cd7.
>
> Andreas.
>
> On Sun, Mar 3, 2013 at 9:19 PM, Phil Scadden <p.scadden at gns.cri.nz> wrote:
>> Except it seems strange thing to change between 2.10 and 2.11. My money is
>> on the tileorigin /offset calculation. You might want to check if anything
>> is changed between 2.10 and 2.11 on that.
>>
>> Notice: This email and any attachments are confidential.
>> If received in error please destroy and immediately notify us.
>> Do not copy or disclose the contents.
>>
>> _______________________________________________
>> Dev mailing list
>> Dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
>
>
> --
> Andreas Hocevar
> OpenGeo - http://opengeo.org/
> Expert service straight from the developers.


-- 
Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St, 
Private Bag 1930, Dunedin, New Zealand Ph +64 3 4799663, fax +64 3 477 5232

Notice: This email and any attachments are confidential.
If received in error please destroy and immediately notify us.
Do not copy or disclose the contents.


From bbtt0 at verizon.net  Tue Mar  5 13:41:40 2013
From: bbtt0 at verizon.net (Jay Parsons)
Date: Tue, 05 Mar 2013 16:41:40 -0500
Subject: [OpenLayers-Dev] Coordinate shift of ~150m after OpenLayers
 2.10 upgrade to 2.11/2.12
In-Reply-To: <51365BD1.4070304@gns.cri.nz>
References: <5130E11C.7040509@verizon.net>
	<51345DD2020000370000F094@lx-gwgate1.asurequality.com>
	<5133B064.4000704@gns.cri.nz>
	<CAOiJ94jFmiPY+ShwA4jkeWzFmZOS-6dX4QrxyNinjbykPp=qTQ@mail.gmail.com>
	<51365BD1.4070304@gns.cri.nz>
Message-ID: <51366694.2090903@verizon.net>

Andreas and Phil:

Wow.  You are correct, it does fix it!

I thought a tile origin issue sounded like a promising lead, but even 
with that hint I would have NEVER figured this out without out your help.

Thank you very much!

Jay


On 3/5/2013 3:55 PM, Phil Scadden wrote:
> Copying to list.
> On 5/03/2013 11:59 p.m., Andreas Hocevar wrote:
>> I think Phil is absolutely right. This was fixed with
>> https://github.com/openlayers/openlayers/commit/893966dfae6e9f2e376e08eccbf6b4474de56cd7.
>>
>>
>> Andreas.
>>
>> On Sun, Mar 3, 2013 at 9:19 PM, Phil Scadden <p.scadden at gns.cri.nz>
>> wrote:
>>> Except it seems strange thing to change between 2.10 and 2.11. My
>>> money is
>>> on the tileorigin /offset calculation. You might want to check if
>>> anything
>>> is changed between 2.10 and 2.11 on that.
>>>
>>> Notice: This email and any attachments are confidential.
>>> If received in error please destroy and immediately notify us.
>>> Do not copy or disclose the contents.
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> Dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
>>
>>
>> --
>> Andreas Hocevar
>> OpenGeo - http://opengeo.org/
>> Expert service straight from the developers.
>
>

From carolbhansen at gmail.com  Fri Mar  8 04:49:11 2013
From: carolbhansen at gmail.com (Carol Hansen)
Date: Fri, 8 Mar 2013 07:49:11 -0500
Subject: [OpenLayers-Dev] OL and Bing Traffic API
Message-ID: <CAGsgxnADSbcBTFZ=PRXC4ibZ7x0w_sixP0nNPAU3XV0BHB87Ng@mail.gmail.com>

Hello,

I am working on a traffic gadget. I've been tooling around with OpenLayers
and the Bing Traffic API, but I can't figure out how to integrate a
XML/JSON api feed. The OSGeo tutorial showed how to integrate a straight up
.xml file as a Vector layer using the url parameter...but that doesn't
work. I also played around with OpenLayers.Format.XML, but I couldnt figure
that out either.

Any suggestions on how to integrate API feed using OL? Is OL picky  about
this?

Side question: Is it possible to integrate multiple feeds from different
sources?

(Just joined OpenLayers DevList, and excited to meet you all!)

Thank you for any suggestions,
Carol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20130308/03bbf0ec/attachment.html>

From mehmetakifalp at gmail.com  Tue Mar 19 04:47:54 2013
From: mehmetakifalp at gmail.com (Mehmet ALP)
Date: Tue, 19 Mar 2013 13:47:54 +0200
Subject: [OpenLayers-Dev] Openlayers & Lightbox - Fancybox
Message-ID: <CAE_6yUAQGBOnUtfOm3mQk8Q_bMhR52DxSt-hKLrE=G2+5HvrqQ@mail.gmail.com>

Hello,

I want to Openlayers Popup convert Fancybox or Lightbox..

my problem;

I create map with Openlayers(OpenStreetMap). This code added Marker and
Popup content with Map.

> var pois = new OpenLayers.Layer.Text( "My Points",
>
> { location:"textfile.txt",
>
> projection: map.displayProjection
>
> });
>
I want edit Popup style. I want use Fancybox & Lightbox Or some jQuery.

I looked Openlayers Manual Page, But I can't run my code.

Openlayers Manual Page :
http://dev.openlayers.org/docs/files/OpenLayers/Layer/Text-js.html

Thank you....


-- 

*Te?ekk?rler*
*Mehmet ALP
**twitter.com/mehmetalp*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20130319/9ddd48e3/attachment.html>

From chrisberkhout at gmail.com  Tue Mar 19 17:24:48 2013
From: chrisberkhout at gmail.com (Chris Berkhout)
Date: Wed, 20 Mar 2013 11:24:48 +1100
Subject: [OpenLayers-Dev] offline caching issues
Message-ID: <CAPekLyFD-qt1YzQwMn1=EEu6U0aZ=Gx9N_1Km7Js9bRYAtNyPQ@mail.gmail.com>

Hi All,

I've been trying to get offline (localStorage) tile caching to work
like the example
    http://openlayers.org/dev/examples/offline-storage.html
and I've run into a couple of problems.

I'm restricting myself to a single layer, same origin via proxy and I
always set read from cache first (fall back to network).

The first problem is that after populating the cache and going
offline, failed tile fetches continue to populate the cache. These
appear as black squares in the example (non-cached failures are pink).
Manually turning off "Write to cache" in the example resolves this.
I've been able to avoid this by patching OpenLayers.Control.CacheWrite
to not write failed tiles to the cache, by checking the condition:
    !evt.tile.imgDiv.classList.contains("olImageLoadError")
I guess there's probably a better way to do that.

The other problem I found is that after populating the cache and going
offline, then panning away to non-cached areas and back to the cached
area, things around the edges of the cached areas are disappearing.
This was more obvious when working with my own layer (at detailed
zoom), but could also be replicated using the openlayers example. The
problem seems to be variation (rounding errors?) in the bbox
parameters of the WMS tile request.

For example, this URL was a cache miss:
http://m1.pozi.com/geoserver/gwc/service/wms?LAYERS=VicmapClassic&FORMAT=image%2Fpng8&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&SRS=EPSG%3A900913&BBOX=16133716.431963,-4554423.89271,16136162.416867,-4551977.9078052&WIDTH=256&HEIGHT=256

Even though the tile it refers to was cached with a URL of:
http://m1.pozi.com/geoserver/gwc/service/wms?LAYERS=VicmapClassic&FORMAT=image%2Fpng8&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&SRS=EPSG%3A900913&BBOX=16133716.431963,-4554423.89271,16136162.416868,-4551977.9078052&WIDTH=256&HEIGHT=256

That's a maxx (3rd bbox value) with last digit 7 instead 8.

I could avoid this by patching the cache read/write code to use an
optional URL normalization function, which the user could set to trim
off the last digits of the bbox parameters.

So, I think I've straightened out what's going on, but the only
solutions I can see involve various hacks in the openlayers code.

Has anyone else run into these issues or got some advice?

Cheers,
Chris

From ahocevar at opengeo.org  Tue Mar 19 22:52:00 2013
From: ahocevar at opengeo.org (Andreas Hocevar)
Date: Wed, 20 Mar 2013 06:52:00 +0100
Subject: [OpenLayers-Dev] offline caching issues
In-Reply-To: <CAPekLyFD-qt1YzQwMn1=EEu6U0aZ=Gx9N_1Km7Js9bRYAtNyPQ@mail.gmail.com>
References: <CAPekLyFD-qt1YzQwMn1=EEu6U0aZ=Gx9N_1Km7Js9bRYAtNyPQ@mail.gmail.com>
Message-ID: <CAOiJ94jv4tVK1OzwceFjSwqJHGKAoq93GkEMjfzP5ixRCAE2RA@mail.gmail.com>

Which version of OpenLayers are you using? Both issues you describe here
should be fixed in master.

Andreas.
On Mar 20, 2013 1:24 AM, "Chris Berkhout" <chrisberkhout at gmail.com> wrote:

> Hi All,
>
> I've been trying to get offline (localStorage) tile caching to work
> like the example
>     http://openlayers.org/dev/examples/offline-storage.html
> and I've run into a couple of problems.
>
> I'm restricting myself to a single layer, same origin via proxy and I
> always set read from cache first (fall back to network).
>
> The first problem is that after populating the cache and going
> offline, failed tile fetches continue to populate the cache. These
> appear as black squares in the example (non-cached failures are pink).
> Manually turning off "Write to cache" in the example resolves this.
> I've been able to avoid this by patching OpenLayers.Control.CacheWrite
> to not write failed tiles to the cache, by checking the condition:
>     !evt.tile.imgDiv.classList.contains("olImageLoadError")
> I guess there's probably a better way to do that.
>
> The other problem I found is that after populating the cache and going
> offline, then panning away to non-cached areas and back to the cached
> area, things around the edges of the cached areas are disappearing.
> This was more obvious when working with my own layer (at detailed
> zoom), but could also be replicated using the openlayers example. The
> problem seems to be variation (rounding errors?) in the bbox
> parameters of the WMS tile request.
>
> For example, this URL was a cache miss:
>
> http://m1.pozi.com/geoserver/gwc/service/wms?LAYERS=VicmapClassic&FORMAT=image%2Fpng8&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&SRS=EPSG%3A900913&BBOX=16133716.431963,-4554423.89271,16136162.416867,-4551977.9078052&WIDTH=256&HEIGHT=256
>
> Even though the tile it refers to was cached with a URL of:
>
> http://m1.pozi.com/geoserver/gwc/service/wms?LAYERS=VicmapClassic&FORMAT=image%2Fpng8&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&SRS=EPSG%3A900913&BBOX=16133716.431963,-4554423.89271,16136162.416868,-4551977.9078052&WIDTH=256&HEIGHT=256
>
> That's a maxx (3rd bbox value) with last digit 7 instead 8.
>
> I could avoid this by patching the cache read/write code to use an
> optional URL normalization function, which the user could set to trim
> off the last digits of the bbox parameters.
>
> So, I think I've straightened out what's going on, but the only
> solutions I can see involve various hacks in the openlayers code.
>
> Has anyone else run into these issues or got some advice?
>
> Cheers,
> Chris
> _______________________________________________
> Dev mailing list
> Dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20130320/07516f8a/attachment.html>

From bmahf at hotmail.com  Fri Mar 22 06:37:59 2013
From: bmahf at hotmail.com (Bruce Mahfood)
Date: Fri, 22 Mar 2013 09:37:59 -0400
Subject: [OpenLayers-Dev] OpenLayer Map restrict panning and zooming
Message-ID: <COL124-W16D44320D66B72BA8FB233AFD40@phx.gbl>

I am new to OpenLayers, and am trying to figure out how to restrict the amount that a user can pan around and zoom outward. For this application, the user chooses a local area in the map and clicks a button saying to use that area, and we want them not to be able to pan outside of or zoom out greater than that extent. When the button is clicked, I am setting both the maxRestrictedExtent and the maxExtent to the current extent using map.GetExtent(). I am also setting the maxResolution to the current resolution by calling map.getResolution(). Panning works perfectly, but zooming doesn't. The user is still able to zoom out passed the given resolution.
I have added code which, every time the extent changes, prints out the current extent and resolution. On the 6th extent change I set the three map properties listed above and print out the settings. This allows me to zoom in from full world view to a localized enough area for testing. On the 6th extent change, I zoom out with my mouse wheel and see the extent and resolution that were chosen. On zooming out with one click of my mouse wheel, the next printout shows clearly that the resolution is indeed larger than the setting for map.maxResolution, and I can see that the viewable area is larger than the one chosen. I have tried a number of things, including setting maxExtent, but nothing seems to cause the max zoomable extent to be restricted. I can zoom all the way out to full world view again if I like.
Below you can see the test code that I have written which instantiates a map with a Navigation control and an OSM layer, and then registers for the map's moveend event, creating a callback function that does what I have described, and finally zooms to max extent.
Does anyone have an idea as to what I should be doing differently in order to limit the ability to zoom out to the max extent chosen? I am hoping that I will not have to manually adjust the extent back to within the max extent, but if that's the case, at least knowing that would help.
P.S. - Unfortunately the whole html doesn't show, since from to just before style, and from after the final are being processed as html. The only thing that is really missing is that I call init() in the onload event of the body.
<style type="text/css">        html, body {        width: 100%;        height: 100%;        margin: 0;             }    #map {        width: 100%;        height: 100%;        margin: 0;             } </style>
<script src="http://www.openlayers.org/api/OpenLayers.js"></script><script type="text/javascript">
var map;var num;
function init(){    map = new OpenLayers.Map('map', { controls: [] });           map.addControl(new OpenLayers.Control.Navigation());           map.addLayer(new OpenLayers.Layer.OSM());
    map.events.register("moveend", this, function (e) {        if (num == 5)        {            map.maxExtent = map.getExtent();            map.restrictedExtent = map.maxExtent;            map.maxResolution = map.getResolution();            console.log(num++ + ": Setting maxExtent/restrictedExtent: " + map.maxExtent + "; resolution: " + map.maxResolution);        }        else        {            console.log(num++ + ": Changed to extent: " + map.getExtent() + "; resolution: " + map.getResolution());        }    });
    num = 0;    map.zoomToMaxExtent();}</script> 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20130322/d3911a4b/attachment.html>

From p.scadden at gns.cri.nz  Sun Mar 24 13:50:57 2013
From: p.scadden at gns.cri.nz (Phil Scadden)
Date: Mon, 25 Mar 2013 09:50:57 +1300
Subject: [OpenLayers-Dev] OpenLayer Map restrict panning and zooming
In-Reply-To: <COL124-W16D44320D66B72BA8FB233AFD40@phx.gbl>
References: <COL124-W16D44320D66B72BA8FB233AFD40@phx.gbl>
Message-ID: <514F6731.3040202@gns.cri.nz>

Firstly, please put requests like this on the users list. dev list is 
for discussions about changes to OL code.

Turning to your problem though. maxExtent should relate to the maximum 
range of the map coordinate system you use. You should not be using it 
to restrict zoom/pan and certainly should not be changing it in an 
event. Recipe for all kinds of problems. You should set restrictedExtent 
and maxExtent (if needed) in the map constructor. It should work. 
minScale, maxScale and resolutions properties provide addition control 
over zoom but shouldnt be needed.
eg
    * var map = new OpenLayers.Map({
      *     projection: "EPSG:3857",
      *     maxExtent: [-18924313.432222, -15538711.094146, 
18924313.432222, 15538711.094146],
      *     restrictedExtent: [-13358338.893333, -9608371.5085962, 
13358338.893333, 9608371.5085962],
      *     center: [-12356463.476333, 5621521.4854095]
      * });

Notice: This email and any attachments are confidential.
If received in error please destroy and immediately notify us.
Do not copy or disclose the contents.


From eric.blasenheim at pb.com  Mon Mar 25 08:11:13 2013
From: eric.blasenheim at pb.com (Eric Blasenheim)
Date: Mon, 25 Mar 2013 15:11:13 +0000
Subject: [OpenLayers-Dev] case restrictions for use of EPSG codes
Message-ID: <AC2B34A74F0F754188C27F590C583F49063A81AA@013-BR1MPN1-012.MGDPBI.global.pvt>

I have seen a number of examples where unknowledgeable coders have created their map projection or assigned layer projections using something like "epsg:3857" and thought this was working.
>From what I have seen, this is not supported by Open Layers and seems to do nothing.   A transform, for example, between EPSG:4326 and epsg:3857 returns the identical input coordinates.

Is there a reason for this being case sensitive?

Eric Blasenheim


________________________________