Updated Use Cases (markdown)

tschaub
2013-03-23 11:24:41 -07:00
parent bd86dfee3c
commit 3757e121fd

@@ -1,8 +1,8 @@
# Vector Use Cases
## Vector Use Cases
These use cases describe common scenarios for loading, rendering, and editing vector data.
## Load data once from static file
### Load data once from static file
User has a static file (e.g. GeoJSON) hosted on the same origin as their application. User expects data to be loaded and rendered over a raster tile based layer (e.g. WMS). Data may be in a different coordinate reference system than map.
@@ -38,9 +38,9 @@ var map = new ol.Map({
});
```
This alternative can be implemented if the layer knows the map projection. The vector layer would be responsible for calling `source.protocol.read({success: callback})` where the callback would call `source.parser.parseFeatures(data, {projection: projection})` (`data` is supplied to the callback and `projection` comes from the map's view). The layer would maintain a cache of features in the map view's projection, and these would be provided on demand to layer's the renderer.
This alternative can be implemented if the layer knows the map projection. The vector layer is responsible for calling `source.protocol.read({success: callback})` where the callback calls `source.parser.parseFeatures(data, {projection: projection})` (`data` is supplied to the callback and `projection` comes from the map's view). The layer maintains a cache of features in the map view's projection, and these are on demand to layer's the renderer.
## Generate features in app and add to a layer
### Generate features in app and add to a layer
User writes an application that generates features at run time. These features are added to the layer for display and interaction (e.g. popup on selection).
@@ -78,4 +78,30 @@ vector.addFeatures(parser, {
});
```
In this alternative, the vector layer has no source set - meaning the user will be manually generating features. This alternative can be implemented if the layer knows about the map projection. In the `addFeatures` method, the layer would call `parser.readFeatures(data, {projection: projection})` where `data` is the first argument to `addFeatures` and `projection` is the map view's projection.
In this alternative, the vector layer has no source set - meaning the user will be manually generating features. This alternative can be implemented if the layer knows about the map projection. In the `addFeatures` method, the layer calls `parser.readFeatures(data, {projection: projection})` where `data` is the first argument to `addFeatures` and `projection` is the map view's projection.
### Load data based on map extent
User has a service that provides vector features for requests with an arbitrary BBOX (e.g. a WFS). Data source contains hundreds of millions of features with worldwide coverage (e.g. OSM) and the user only wants to display a small subset, updating rendered features as the user navigates around the map.
**Alternative 1**
```js
var vector = new ol.layer.WFS({
featureNS: 'http://opengeo.org/#osm'
featureType: 'roads'
});
var map = new ol.Map({
target: 'map',
layers: [vector]
view: new ol.View2D({
projection: 'EPSG:1234',
center: ol.projection.transform(
new ol.Coordinate(-111, 45), 'EPSG:4326', 'EPSG:1234'),
zoom: 3
})
});
```
This alternative can be implemented if the layer knows about the map. The WFS layer creates a WFS protocol, a GML parser, a BBOX strategy by default. The layer creates a vector source with the protocol and the parser (these are the two things associated with the data source). The bbox strategy listens for changes in map extent. When the previous data bounds become invalid, the bbox strategy notifies the layer that new data is needed, and the layer calls `source.protocol.read({success: callback})`. The provided callback would call `source.parser.readFeatures(data, {projection: projection})` with the provided data and the map view's projection. The resulting features would replace the existing features (or new ones would be added and features outside the data bounds would be removed).