some functions, and has tests available, so when I break it at some point,
hopefully I'll know :)
git-svn-id: http://svn.openlayers.org/trunk/openlayers@1389 dc9f47b5-9b13-0410-9fdd-eb0c1a62fdaf
- Added Layer/FixedZoomLevels.js, which is a new pseudo-layer that all layers
which have fixed zoom levels will need to extend. It provides alternative
methods to initResolutions(), getResolution(), and getExtent() which depend
on the fixed zoomlevel layer implementing getLonLatFromViewPortPx(),
getViewPortPxFromLonLat() and getZoomForExtent(). For documentation of how
this works, see the comments in the class header.
git-svn-id: http://svn.openlayers.org/trunk/openlayers@1380 dc9f47b5-9b13-0410-9fdd-eb0c1a62fdaf
getMaxExtent(), getMaxResolution(), and getNumZoomLevels(). They were just
wrapping around the properties. better to just access the property directly.
Needed to update for these removals in many different files.
- Improved initResolutions() functionality. It is now I believe both thorough
and complete. The only exception is that we should maybe allow a way for
the user to set up resolutions[] array using only minResolution and
numZoomLevels instead of only maxResolution and numZoomLevels... but I'm not
really sure anyone would ever really want to use that. And at any rate, I
don't know the math for how to do it. I'm sure schuyler or Dr. 5 would.
Oh. for a summary of how initResolutions works, see:
http://trac.openlayers.org/wiki/SettingZoomLevels
- Move getResolution(), initResolutions() out of HTTPRequest and into Layer. On
thinking this through (and trying to write documentation), I realized that
the real, true, GENERIC case for a layer will be using this awesome
resolutions[] array that allows for setting number of zoom levels, default
max resolutions, special scale arrays, etc.
- Updated code for getZoomForExtent() to work with resolutions[] array, instead
of using the the log 2 equation.
- Move standard getZoomForExtent() and getExtent() out of Grid and into
Layer. Like above, there is no reason for these methods to be found so far
down in the food chain. They are part of the generic calculations for
generic layers, so they belong in Layer.
git-svn-id: http://svn.openlayers.org/trunk/openlayers@1379 dc9f47b5-9b13-0410-9fdd-eb0c1a62fdaf
ready* -- it is a memory hog, and slow as heck when dragging. However,
including it doesn't harm OpenLayers.
git-svn-id: http://svn.openlayers.org/trunk/openlayers@1371 dc9f47b5-9b13-0410-9fdd-eb0c1a62fdaf
can cause problems in multiple different layers -- instead, just return
null, which is handled more gracefully.
git-svn-id: http://svn.openlayers.org/trunk/openlayers@1219 dc9f47b5-9b13-0410-9fdd-eb0c1a62fdaf
requests will 'just work' if the file is loaded locally (which was only the
case before when using relative URLs). It also means that the examples better
document how to set ProxyHost, since they no longer depend on an undocumented
setting.
git-svn-id: http://svn.openlayers.org/trunk/openlayers@1216 dc9f47b5-9b13-0410-9fdd-eb0c1a62fdaf
This is not an ideal situation, becauuse it's not really 100% correct for a
mercator projection, but it does cause things to work.
It seems that for some reason, the EventPane isn't actually catching all the
move events -- this seems to be what is causing the slow dragging. I'm not
sure of the reason for this, but maybe Erik or someone else will be able to
offer hints. I could also just be wrong ;) I just know it's slow, really.
git-svn-id: http://svn.openlayers.org/trunk/openlayers@1208 dc9f47b5-9b13-0410-9fdd-eb0c1a62fdaf
