Bounding Box filtering

Are we talking about a bounding box to filter all data that's passed to OL, or that OL is using for the current viewport? (Should I actually be distinguishing these?)

For the former, it seems like Views GeoJSON could offer a views argument for bounding box params, and filter the output features accordingly.

The latter would be more dynamic and has View GeoJSON and OL talking more. Do we ever want changes to the OL map (like dragging and zooming) to trigger re-request of new GeoJSON data?

Are we talking about a bounding box to filter all data that's passed to OL, or that OL is using for the current viewport?

My map will probably end up having more than 100.000 markers, which would make the loading time Very Slow. See also this discussion about the same issue: Solutions for dealing with large numbers of features on a map

So I would prefer it if Openlayers could grab the lat+long of the bounding box and use it to filter the view, so that only the markers in visible area of the map is returned and displayed. If I understand it correctly :-)

Spent a little time on this.

Still a lot to do, and a lot wrong with this (like that it's a filter instead of a contextual filter, :-p,) but it's a start.

Inching forward a bit further. This one actually pulls the bbox coordinates from the arg string instead of using sample numbers. Works if your GeoJSON view uses lat & lon fields.

Added Geofield support. Next will be to change this into a contextual filter.

OK. This is in a working state where I could use a few more eyes.

I've turned it from a Views filter to a contextual filter (argument.) You can add a contextual argument for bounding box, which accepts an arg in form "x,x,x,x" and edits the query accordingly. If the string starts with "?BBOX=" it'll strip that. Well, kind of, (see inline comments.)

I've also added a "default argument" plugin to allow pulling the query string from the URL (via GET params.) I'm not sure whether this is actually necessary. I'm not totally clear how the query string from OpenLayers will come through Views: whether Views will interpret it as an argument, (and we can just do some substring stripping,) or we need to special case this and pull it from GET like I'm doing.

Another issue is that, when using the default argument, if the string is not in the query, no results are returned...

Would love some feedback on whether this is a good route.

Committed this. Let's pick it apart and improve it.

@zzolo I noticed this sandbox project doing the same thing - at least by the description. no code commits yet.

http://drupal.org/sandbox/katbailey/1445310

Just committed a small fix to return all results when arg is not in the query string, (when using the Provide default value: Bounding box from query string context filter option:

index a084610..fb8e384 100644
--- a/views/views_plugin_argument_default_bboxquery.inc
+++ b/views/views_plugin_argument_default_bboxquery.inc
@@ -34,6 +34,8 @@ class views_plugin_argument_default_bboxquery extends views_plugin_argument_defa
   function get_argument() {
     if (isset($_GET[$this->options['arg_id']])) {
       return $_GET[$this->options['arg_id']];
+    } else {
+      return TRUE; // Return all values if arg not present
     }
   }
 }

Thanks @zzolo, I've made most of those changes.

I changed the logic for "unwrapping" out-of-bounds bbox coords. It's working for me, but there's faulty logic that should be fixed to make things more efficient.

When the displayed map wraps over the 180° or -180° line, OpenLayers extends those numbers further out, making the next map, for example, from 180 to 540. If you zoom out more and keep dragging the map further in that direction, the numbers keep getting bigger.

My current logic is incorrect in assuming that points are displayed across one of these [180°/-180°] lines. I'm taking the negated modulus and turning the query into an OR, to get the points on either side of the line that are inside the map view. What I see OL doing, though, is only displaying points on a single full-width map (-180° to 180) part of the display at any given time. If there are two full-width maps in view, the points get shown on the one that takes up the majority of the viewport... Since my logic is asking for points on both sides of the dividing line, the ones on the side whose points aren't being shown are being loaded but not viewed.

The patch...

Committed this to get us closer to good.
Let's make new tickets for new issues.