Context aware GeoJSON sources

Enormous flexibility in data presentation can be gained by allowing each dynamically-generated mapping source to be aware of the context within which the map is displayed. This would allow features on a map to be filtered in the same standard ways that other entities are filtered in Views - by passing contextual filters in the URL request.

The Views-GeoJSON module already responds to contextual filters as expected, filtering the results in its GeoJSON-encoded list when appropriate values are provided in the URL request. What remains is to develop a mechanism where the OL map being displayed can pick up contextual filter values when they are present and pass those values to Views_GeoJSON in the URL request that it makes to each GeoJSON data source.

When a map is displayed within a Views page display using Format: Openlayers map, any contextual filter values applied to the View are readily available using the replacement patterns (!1, !2, etc.) and this View will filter the results of the map source that it provides as expected, although those values are not currently passed to the source queries of other layers within the map. Views already has a well developed facility to read, interpret and validate contextual filters, so perhaps using the Openlayers map Views formatter would be a good place to start to acquire context.

Passing the filter values to Views_GeoJSON seems to be a matter of inserting the values into the Sources > Source type options > URL variable, which is set for the GeoJSON source in OL3_UI.

When I add a contextual filter to a Views GeoJSON Feed (Provide default value > Taxonomy term from URL and change the Views > Path to "/places-map/%/feed"), the Views preview shows that the GeoJSON-coded output has been filtered as expected, but the map display still shows all data points.

Hard-coding a tid in the Source type options > URL setting such as "/places-map/81/feed", results in the map display showing properly filtered data points as expected. With working popups, even! Perhaps using replacement patterns or tokens in the URL string could be helpful, allowing the OL3 map to write the contextual values into the URL request in the right places on the fly.