ashatora/openlayers
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Use-Cases update

Éric Lemoine
2013-03-27 15:08:45 +01:00
parent 8fbaaa540e
commit e2fde088d6
1 changed files with 5 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Use-Cases.md
+5 -29
@@ -38,37 +38,13 @@ _Questions/comments from Eric:_
How do we know that the transform's source projection is EPSG:4326? It's not specified anywhere in the application code. Maybe you assume that the user/external projection is EPSG:4326 by default?
You say that "This alternative can be implemented if the layer knows the map projection". Why? The layer renderer knows about the map/view projection, so I think it could be the one providing the projection (the transform's target projection). As I see it the transform operation would occur during the first `render` pass, that is the one occurring when the layer is added to the map.
You say that "This alternative can be implemented if the layer knows the map projection". Why? The layer renderer knows about the map/view projection, so I think it could be the one providing the projection (the transform's target projection). As I see it the transform operation would occur during the first `render` pass, the one occurring when the layer is added to the map.
I've also been thinking about where to store the transformed data. But before that: in most cases, does it really make sense to store both the original data and the transformed data? In ol2 if the layer projection isn't the same as the map projection the strategy does an **in-place** transform of the data, and no copy of the original data is kept. Do we really want to do differently in ol3? I know that stores can be shared between maps, etc. We could think about a `copyOnTransform` boolean option on stores. By default `copyOnTransform` would be `false`, as we don't need the original data for the common cases.
I've also been thinking about where to store the transformed data. But before that: in most cases, do we really want/need to store both the original data and the transformed data? I'd say no.
Based on these comments, I'd add an Alternative 2 that just sets a projection in the source.
In ol2 if the layer projection isn't the same as the map projection the layer's strategy does an **in-place** transformation of the data - no copy of the original data is kept. Do we really want to do differently in ol3? I know that stores can be shared between maps, etc. We could think about a `copyOnTransform` option on stores, which would be `false` by default, as we don't need the original data in the common cases.
**Alternative 2**
```js
var vector = new ol.layer.Vector({
source: new ol.source.Vector({
protocol: new ol.protocol.HTTP({
url: './data/features.json'
}),
parser: new ol.parser.GeoJSON(),
projection: 'EPSG:4326'
})
});
var map = new ol.Map({
target: 'map',
layers: [vector],
view: new ol.View2D({
projection: 'EPSG:1234',
center: ol.projection.transform(
new ol.Coordinate(139.7, 35.7), 'EPSG:4326', 'EPSG:1234'),
zoom: 9
})
});
```
Really the store could (a) transform in place, (b) copy on transform, or (c) refuse to transform and return `null` to the renderer. The store would decide based on user options/hints (e.g. `copyOnTransform`). I think the default behavior should (a), i.e. transform in place if the view projection is not the same as the data projection.
### Generate features in app and add to a layer
@@ -162,4 +138,4 @@ The user has vector features with a high number of points. To render the feature
### Dense vector data
The user has [thousands](https://groups.google.com/forum/?fromgroups=#!searchin/leaflet-js/1500/leaflet-js/0SloJWSNbrg/XCtut0jhWqUJ) or [hundreds of thousands](https://groups.google.com/forum/?fromgroups=#!topic/leaflet-js/ytp2n-QLIH8) of vector features.
The user has [thousands](https://groups.google.com/forum/?fromgroups=#!searchin/leaflet-js/1500/leaflet-js/0SloJWSNbrg/XCtut0jhWqUJ) or [hundreds of thousands](https://groups.google.com/forum/?fromgroups=#!topic/leaflet-js/ytp2n-QLIH8) of vector features.