Pass resolution when requesting features in an extent #1812

Closed
wants to merge 3 commits into
from

Conversation

Projects
None yet
2 participants
@twpayne
Contributor

twpayne commented Mar 6, 2014

This PR is opened for discussion. The goal is to explore options for supporting tiled and server-simplified vector data.

In a tiled vector scheme, it is likely that the tiles covering large areas will contain simplified versions of the features compared to tiles covering small areas. If tiles covering large areas contained fully detailed features they could become very large indeed. This means that a single feature will be present in multiple tiles, and at different resolutions. This means that when rendering the feature, we have to somehow decide which version to use.

Similarly, when requesting vector data it can be helpful to specify the desired resolution so that the server can perform simplification.

There are multiple possibilities:

  • As features are loaded with a tiling strategy, replace features with the same if the newly-loaded feature is more detailed, and then rely on ol3's existing client-side simplification.
  • Maintain multiple R-Trees, say one per discrete resolution, and preferably return features from the R-Tree with the resolution corresponding to the requested resolution. Features from other resolutions can be returned if none is found at the desired resolution. This would be the vector equivalent of interim tiles.

This PR suggests a new function (currently stubbed out) forEachFeatureInExtentAtResolution to allow renderers to communicate the desired resolution to the vector source.

Comments welcome. It's not obvious to me what the best approach is here.

@twpayne twpayne referenced this pull request Mar 18, 2014

Merged

ol.source.RemoteVector #1744

@twpayne

This comment has been minimized.

Show comment
Hide comment
@twpayne

twpayne Mar 25, 2014

Contributor

Does anyone have any comments on this? It's needed for supporting vector tiles in #1744.

Contributor

twpayne commented Mar 25, 2014

Does anyone have any comments on this? It's needed for supporting vector tiles in #1744.

@fredj

This comment has been minimized.

Show comment
Hide comment
@fredj

fredj Mar 26, 2014

Member

LGTM

Member

fredj commented Mar 26, 2014

LGTM

@twpayne

This comment has been minimized.

Show comment
Hide comment
@twpayne

twpayne Mar 26, 2014

Contributor

Thanks for the review @fredj, I've merged the code into #1744 where it was needed for the initial tile-vector implementation.

Contributor

twpayne commented Mar 26, 2014

Thanks for the review @fredj, I've merged the code into #1744 where it was needed for the initial tile-vector implementation.

@twpayne twpayne closed this Mar 26, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment