(I know AJAX is a stupid term and not entirely accurate for this, but you get my point) So, this has been discussed by phayes and I before, and have heard it mentioned by others.

We should create a AJAX system for loading features, probably based on display boundaries.

More in-depth features:
* I am not fully aware of what OpenLayers supports natively for something like this.
* This should be something that can be turned on and off.
* Maybe some way of designating a weight system for zoom levels.

Ideally, I don't see this as too difficult, though I think the challenges will be to do it efficiently and elegantly.

Thoughts? More details into how to actually implement?

Comments

tmcw’s picture

tmcw commented

OpenLayers supports a ton of this natively. Notably KML and Strategy.BBOX will let you do dynamic point loading based on bounding box - febp does it this way.

Next steps here are essentially:

The KML module needs views support, or we need a GeoJSON/etc module to step up to the task.

For offsite point loading, we'd need a proxy of some sort, whether a drupal module or a recommended non-drupal solution.

A KML layer type.

zzolo’s picture

zzolo commented

Awesome. With OpenLayers. Strategy.BBOX and maybe OpenLayers.AJAX we should be able to come up with a good solution.

About the KML module and Views integration? It looks like that issue is a little stuck which is unfortunate. But, if the KML module fully supports Views, does this make our Views integration a little pointless. It seems like in this 2.x branch we are pretty much just using to make data/feature layers, which is essentially what a KML view would be. Maybe I am missing or forgetting about a piece here. Also, if we made that sort of switch, it would require a big dependency.

Concerning a proxy. I would love to see this, but I am not entirely sure what the best way to go about this is. I also think that the proxy is a separate issue all together. It doesn't seem like there is an existing proxy module for Drupal. Is this the sort of solution that you are thinking about?

http://jquery-howto.blogspot.com/2009/04/cross-domain-ajax-querying-with...

That method seems like an easy module to implement in Drupal. Seems inefficient, but without native support of getting data from another domain in JS, I think inefficiency is unavoidable. Actually, a Drupal module could allow for caching other domain data for an arbitrary amount of time, which would help speed things up.

zzolo’s picture

zzolo commented

Also just noticed the Paging Strategy: http://dev.openlayers.org/releases/OpenLayers-2.8/examples/strategy-pagi...

zzolo’s picture

zzolo commented

Looked into things like PHP Proxy and I think I will try to implement a simple proxy module in Drupal tomorrow (as time allows).

tmcw’s picture

tmcw commented

But, if the KML module fully supports Views, does this make our Views integration a little pointless. It seems like in this 2.x branch we are pretty much just using to make data/feature layers, which is essentially what a KML view would be. Maybe I am missing or forgetting about a piece here. Also, if we made that sort of switch, it would require a big dependency.

Not quite. If you're handling small to moderate numbers of points, processing them into a JSON array (like we do now) is faster on the first pageload and beyond, and it's also a terrible hack to pass filters and other arguments into a KML view via a calling page. Essentially, we need both.

The main issue with implementing a proxy module in Drupal is the fact that we'd need to severely whitelist domains/URLs which could be accessed, or else it would be a totally open proxy / possible route for XSS attacks, etc. I'm just kind of surprised that some kind of module doesn't already exist for this purpose, really.

tmcw’s picture

tmcw commented
Status: Active » Fixed

zzolo wrote the Proxy module and the OpenLayers 2.x branch already has ProxyHost support, so the code portion of this ticket is finished. I don't think there's any reason to make it any more 'auto' than having to enter in a URL for the OpenLayers module. However, documentation needs to be written on both sides.

phayes’s picture

phayes commented
Status: Fixed » Active

I think there is a little misunderstanding about the requested functionality. I *think* zzolo means that we should have the ability to load features client-side whereby the client sends a zoom, and bounding box to the server, and the server passes back some JSON with the features corresponding to that bounding box. I'm running into an issue with loading massive layers where I could be served by being able to serve up only chunks of it. I personally think this would be best served by a new layer type, analogous to the vector type, but with this ajax loading functionality.

tmcw’s picture

tmcw commented

phayes: yes, you're looking for Strategy.BBOX and some improvements to the KML module. These aren't really OpenLayers things, they're blocked by the current state of the KML module. The OpenLayers module should definitely not be doing JSON output or anything like that on its own.

tmcw’s picture

tmcw commented
Status: Active » Closed (works as designed)

Continue discussion, but this doesn't primarily concern the OpenLayers module.

batje’s picture

batje commented

subscribe

R.J. Steinert’s picture

R.J. Steinert commented

subscribe

R.J. Steinert’s picture

R.J. Steinert commented

I just want to make sure I'm on the same page as y'all. What has been proposed is about interacting with OpenLayers.js's internal features and not about supporting AJAX mode from Views for changing exposed filers/pagers right?

Adam S’s picture

Adam S commented

@phayes cc: #7 We might want to ask Kerberos (http://drupal.org/user/348928) how he went about accomplishing this feature on his website (http://urbo.ro/harta#gh/sxu77w2ktupz/z/17/).

tmcw’s picture

tmcw commented

Adam S: that site doesn't use the OpenLayers module.

Dave-B’s picture

Dave-B commented

subscribe

tmcw’s picture

tmcw commented

Dave-B: issues marked as closed (works as designed) will not be updated, because the module works as designed and the relevant work will happen in other issues. You can subscribe if you insist, but there isn't going to be anything here.