Projection from view #233

Closed
wants to merge 10 commits into
from

Projects

None yet

3 participants

@ahocevar
Member

Depending on how a WMS is configured, it can serve multiple resolutions. If a WMS supports arbitrary projections, it makes sense to use the view's projection. This pull request moves the tile/image url function generation from the constructor to the rendering sequence, where the view's projection is already known. For the API this means that users no longer need to provide a projection configuration on WMS layers that support the view's projection.

With the introduction of a negotiateSourceProjection() method on the layer renderer, future layer types can leverage this convenience as well, and we will be able to find a projection on a source that does not require client side reprojection to match the renderer projection.

Because the projection also affects the WMS request (SRS or CRS param), this pull request also introduces an updateUrlFunction(opt_params) method on WMS sources. This method can later be modified to trigger an event, so it can be used to update WMS params like STYLES and re-render the layer.

ahocevar added some commits Feb 24, 2013
@ahocevar ahocevar Sensible default for number of resolutions e8eaee0
@ahocevar ahocevar Setter for tileGrid 10f5c2b
@ahocevar ahocevar Allow source configuration without projection c0dfb16
@ahocevar ahocevar Set defaults in setTileGrid, not in constructor
By doing so, we can fall back to the view's projection instead
of EPSG:3857. For the API, this means that WMS layers can be
configured without a projection if the WMS supports the view's
projection.
984549a
@ahocevar ahocevar Negotiate projection for image and tile layer sources
By renaming the setTileGrid method on the renderer to
negotiateSourceProjection, we can not only set the view's
projection on layer sources that do not require a specific
projection, but we also have a place for future efforts to
negotiate a suitable projection between the renderer and the
source.
366ffa9
@ahocevar ahocevar Comment about setting resolutions for image layers
To keep the example simple, no resolutions are configured by
default. But a comment shows how to configure a set of
resolutions to reduce the number of requests for single image
layers.
1749564
@ahocevar ahocevar Re-adding accidently removed tileCoordTransform 77d697f
@ahocevar ahocevar Improving example readability 7f0773a
@ahocevar ahocevar Factoring out common WMS code
This change also introduces a WMS source interface that both
TiledWMS and SingleImageWMS implement. It provides an
updateUrlFunction method which can be used to accomplish things
like mergeNewParams in OpenLayers 2.
a53df65
@ahocevar ahocevar Removing commented out line 64eac95
@elemoine
Member
elemoine commented Mar 1, 2013

I tend to think that the tileUrlFunction should receive the view resolution (in addition to the tile coordinate). This would make sense to me, and allow to not defer the creation of the function. What do you think?

Also, I don't have a good feeling with having the layer renderer set a projection in the source. For example, what if the view projection changes? I'd rather use a null value for projection when the source can work with any resolution. Maybe I'm missing something, and in that case I can probably be convinced that the way you do it is better.

@ahocevar
Member
ahocevar commented Mar 1, 2013

I may be missing something, but I don't see why passing the view resolution to the tileUrlFunction would help here. What would help, however, would be to pass the tile extent (like for the imageUrlFunction in image sources). Then we could work without a grid. Not sure what the implications on tile caching would be though.

I also had the thought that the renderer should not set the tile grid on the source. But then again, we know if a tile grid was user provided by checking options_.tileGrid. So I think we're good.

@elemoine
Member
elemoine commented Mar 1, 2013

Sorry Andreas, I meant "passing the view projection to the tile url function". I'll look again at your pull request, giving it more thinking.

@ahocevar
Member
ahocevar commented Mar 1, 2013

That could make things simpler, yes. We could then maybe create a tile grid in tileUrlFunction if none is available on the source, and persist it in the scope of the tileUrlFunction.

@elemoine
Member
elemoine commented Mar 2, 2013

Bruno and I just talked about it. Here is a summary of our discussions. We think that the renderer should not set a projection (and a tile grid) in the source. If a (WMS) source supports any projection then its projection property should be null, and it should remain null. Likewise, if a source supports any projection then its tileGrid property should be null. In addition to tileCoord the getTile function could receive a projection object (the view projection). Also, we've mentioned storing tileGrid objects created by the lib in a tile grid registry. getTile is called on the source, the source does not have a projection and a tile grid, so getOrCreateTileGrid is called on the registry. The whole idea is to not automagically set a projection and a tile grid in the source if the user did not provide any, with the goal of supporting changing the view projection, and sources configured with fixed sets of projections. Just sharing ideas...

@twpayne
Contributor
twpayne commented Mar 3, 2013

Note that a source can be shared between multiple layers, or maps, and so having a renderer modify the source might cause strange side-effects. I think it's a good idea to keep the sources as pure "read only" objects.

@ahocevar
Member
ahocevar commented Mar 4, 2013

#268 is a better way to resolve this. Closing.

@ahocevar ahocevar closed this Mar 4, 2013
@ahocevar ahocevar deleted the ahocevar:projection-from-view branch Jun 19, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment