The tileQueue might have entries again after zooming when the previous zoom level hasn't finished loading yet. Removing the check for the tileQueue's length makes layers report loadend correctly again.
layer.maxExtent is always set as soon as the layer is added to a map. Instead, making behavior consistent with tiled layers: don't display outside maxExtent except when displayOutsideMaxExtent is set to true or the layer's extent equals the world bounds for maps with a baseLayer that has wrapDateLine set to true.
The UTFGrid layer's `getTileInfo` method was not correctly handling dateline wrapping (and was a bit more complicated than it needed to be). Since it would be useful to all grid layers to be able to retrieve a tile and pixel offset for any map location, this functionality deserves to be on the Grid layer.
The WMTS layer currently exposes a `getTileInfo` method that is used within the layer and by the WMTSGetFeatureInfo control. This method could be renamed to `getRemoteTileInfo` or something to differentiate it from a method that gets locally cached tile info. Until that change is made, the method on the Grid layer will be called `getGridData`.
For this to be useful (i.e. so listeners can see/modify the tile url), a change in Tile.Image is required so we do not fire the loadstart event before we have the url to load.
Having to call two methods to get complete feature information (id and data) is cumbersome. The `getFeatureInfo` method returns an object with both feature id and data.
The tile now has responsibility for resolving feature ids and fetching feature data given x, y pixel offsets with getFeatureId and getFeatureData methods. The layer has corresponding getFeatureId and getFeatureData methods that take a map location, lookup the appropriate tile, and delegate to the tile for the rest of the work.
I think it should be the job of the layer to retrieve data for a given location (instead of the control). The first part of this change creates a `getData` method on the layer and updates the control to use this method.
The second part of this change removes the assumption that the data returned will be an simple object representing feature attributes. The UTFGrid specification doesn't say anything about the structure of property values in the optional data member. The examples given in the spec use string values. The default callback previously assumed that the data could be rendered in a two column table. I think it would make more sense not to make this assumption. With this change, the user must always provide a callback to do anything with returned data.
When the list of event types became unconstrained in 501b42228a, we lost the documentation for events that are triggered. This change adds the list of events triggered to the API docs for events properties.
In setMap, the layer gets the map's projection if it doesn't have its own. And since a layer can have a different SRS code than the map (but a compatible one, i.e. with OpenLayers.Projection.transforms[mapProj][layerProj] being OpenLayer.Projection.nullTransform), the axis order can be different.
This allows us to simplify the map and layer configuration, because now the projection also defines defaults for maxExtent, maxResolution and units.
This change also adds transforms for SRS aliases for EPSG:4326 and centralizes axis order information in OpenLayers.Projection.defaults.
