Integrating OpenLayers

The best option would be to write a layer_type plugin for the 2.x branch, because it will be able to handle per-layer configuration. You can see a good example in the MapBox module, which adds a new layer type just like OpenSpace.

We're about to start working on this and it appears that it's not possible to just add a new layer_type plugin since we can't directly access the tiles from openspace.

Openspace is build with openlayers but has modified some functions and it's looking like it will not be possible to cleanly extend the current openlayers drupal module.

If anyone wants to collaborate on this please let me know!

I'm not sure I understand, your layer_type plugin will be able to include the OpenSpace.js file that you point to. See the MapBox module for comparison, you'll include the OpenSpace.js file as well as a 'connector file' that lets the OpenLayers module create layers easily.

Hi Dubs, that's great news! It's actually another developer here who will be working on this, I'm just sticking my nose in :) Since I don't know the details I hope that tmcw is right too, give me your contact details and perhaps we can all hook up on Skype and discuss?

Ronald, the other developer working on this has already done a fair bit of investigation.

Hi - this the Ronald John was talking about :-)

I've been trying to work out how to best integrate OpenLayers with OpenSpace and having a good look at the MapBox module as well for pointers.

The way I see it the main problem (and difference) between what they did with MapBox and what we need to do with OpenSpace is that we cannot simply define an OpenSpace.Layer object.

The OpenSpace.js library that we are forced to use is actually an extension of OpenLayers - the UK Ordnance Survey has taken OpenLayers 2.7 and extended a series of classes (plus added some functionality) to enable people to easily work with UK maps. The maps have a different projection (27700), tile sizes change based on zoom level and the co-ordinate system is UK-specific so they've added helper functions to go from long, lat to the UK point system and vice-versa.

Unfortunately we also cannot go straight to a title service and just write an OpenLayers layer that interacts with that. To create a map we need to call: OpenSpace.Map which is an extension of the OpenLayers.Map functionality.

Now, the question is. Would it be possible to create a module that plugs into the preset system of OpenLayers 2.x so that users can define when they want to view an OpenSpace map but completely bypasses the OpenLayer way of doing things in openlayer.js when it comes to showing the map.

What we imagine is intercepting OpenLayer data views and layering them on an OpenSpace map instead (which is not that hard since we have all the OpenLayer 2.7 library available to do so). However, it is really messy trying to do this via the normal process of the OpenLayer module where (rightly so) it is assumed that Layers objects switch not Map objects and the library which constructs them!

Hope this was clear - Dubs - have you got any other ideas about how to move forward via the OpenLayers module?

Hmm, that's interesting. Have you tried simply doing a checkout of the OpenSpace source tree, putting that on your site, and updating the OpenLayers source to point to that? From the place you pointed to for the OpenSpace source, it looks like the namespace has stayed the same, so you can still call OpenLayers.Map and get a Map object.

I must be missing something - how is the OpenSpace code incompatible with the existing structure? One would have to change the source of the OpenLayers library in the settings panel, and have a SVN checkout of OpenSpace, but it would be much less work than the alternative. You can easily add a layer with a custom projection as a layer type, as well.

@tmcw re 11 - yes you are right! Turns out it is possible to handle the projections. What I was missing was a) exactly how to do that :-) (the openspace library meant I needn't worry) b) how to talk to an openspace tilemap server (a look at the url used to fetch the tiles solved that one)

So, I've now implemented a module (much in the vein of MapBox) that just hooks into the OpenLayers library and module, allows you to set things up in the interface and offers a new layer that inherits from OpenLayers.Layer.WMS.

Only issue is that I needed to add the 27700 projection straight into the OpenLayers code

Will post here later today (a few things I need to clean up first) and I guess I also need to apply for a CVS account to host it as a Drupal module as well

Only issue is that I needed to add the 27700 projection straight into the OpenLayers code

Could you clarify this? You should be able to pull this off without modifying the core of the OpenLayers module, but defining the projection in the layer_type. If there's a type of expandibility that needs to be expanded here, let me know.

@tmcw you are absolutely right :-) no changes needed to openlayers code. I had done something strange at the start while I was learning about how everything interacted and was setup and never questioned it! Went back and looked at the code and actually there is no need to change anything in the OpenLayers module since you can setup everything (as you say) in layer_type. apologies for the confusion...

One dependency my module does have is the proj4js library - not sure if that can be avoided or done differently.

While John sets it up as a module on drupal.org I am attaching it here as a zip as well. Usual warnings... don't use on production sites, this is still very much a first go at the issue, apply.

Has anyone looked at adding an Openspace boundaryLayer as a feature of this module?

Looks like the openspace module name is taken; maybe this can be something else?

You're right, the openspace module name is taken! What do people think the openspace for openlayers module should be called?

openspace_openlayers?

openspace_layer?

layer_openspace?

openlayers_os?

I assume there is no current naming convention for layer plugin modules?

Why not talk to the OpenSpace maintainer and collaborate instead of creating a new project? The goal of the project is to add general integration with Drupal, so I think this is within the scope.

I've contacted Jeremy, maintainer of the "openspace" module to ask his opinion on integrating our code. My feeling at the moment though is that the modules have different enough aims to warrant having their own projects.

The current openspace module "...allows for one block to be placed on the site with a basic OpenSpace map in it with a specified size location and zoom level."

Our module is more of a plugin to openlayers module, adding openspace as a layer type to openlayers.

It would make sense if there were a standard nomenclature for openlayers plugin modules, looking in the current openlayers project, there are already modules called "openlayers_views", "openlayers_cck" etc. which provide integration with their respective modules.

I guess it would be useful to ask whether the maintainers of openlayers module expect to integrate any additional layers into the openlayers module in future, or whether they see our openspace layer as always living in another module? Personally, I think that it should probably live in another module at least until it is stable.

I still think you should include this in the OpenSpace project. It clearly states: "The mission of the OpenSpace module is to provide integration between Drupal and OpenSpace." on the project page. Its totally up to you, but I just think there is already a good project for this and there is already so many modules in contrib.

I don't think its actually worth starting a project for a single openalyers layer implementation. MapBox, for instance provides layer implementation as well as a set of icons and probably will include other things.

As far as a namespace for openlayers related projects, there has been no conversation about this. My suggestion is that you use openlayers_whatever, but ensure that it depends on openlayers, otherwise all your variables will be deleted when openlayers is uninstalled :).

As far as what will go into the core openlayers module, in my opinion, we will probably only support what is currently in there. The main goals with what we choose are:

* Enough layers so users can get started mapping without other modules
* Widely-used, supported APIs and data
* And world level layers

If we go out of this realm, we end up trying to support too much, IMO.

Also, a couple more things to note:

* We only support one layer type that is not built into the OpenLayers library (Cloudmade), but this is world-level data layers as well as a well-supported add-on.
* Even if we agree on any naming convention for openlayers projects, there is no mechanism to enforce it. And there are already a number of projects that offer openlayers integration as well as other functionality.

These are just my thoughts. I think I can speak for the openlayers developers that we will not support this in the core module. But I don't want to discourage you from releasing your code in the way you feel best.

Hi Jeremy here, co maintainer of the openspace module.

It is very basic at the moment and probably won't be updated be me soon as my attention has been diverted elsewhere. Because there is the need for an API key it may make sense to create a sub module openspace_openlayers which is part of the openspace project. So there can be one place that an admin has to set up an API key which is used by all openspace modules.

Tomdeb is the owner of the module, so you can ask him to become a co maintainer and do more or less what you want with it. Alternatively if you set up an issue and submit a patch I can commit the change for you.

I think it is worth spending the time to integrate the two projects and keep everything under the single openspace namespace. This would make it much simpler for people looking for the solution to work out what they need to do. The openlayers integration can simply be a sub-module and there are other things that it would be nice to add to the module that don't really always need the whole openlayers infrastructure.

Would be happy to become co-maintainer and works towards getting things aligned.

Let me known

ronald

So there can be one place that an admin has to set up an API key which is used by all openspace modules.

Note that the OpenLayers module provides a facility for defining and saving API keys. I suppose you can refer to the same Drupal variable, but make sure not to duplicate functionality.

Hi guys,

It sounds like people would rather that we integrated our openlayers support for openspace with the existing openspace module. I'm happy to do this but will not be able to work on it until after Drupalcon, perhaps until a week or so after.

I sent a message to Tomdeb a couple of days ago but haven't heard anything back, the integration will depend on whether he wants Ronald and I to integrate our code and co-maintain the module.

Good to hear. Also, just a reminder that if people are interested in your code and you want it out there while waiting for responses on drupal.org, you can always use GitHub or just post the zip file in this thread. Not sure what you are comfortable with, but no reason not to put code somewhere in the interim.

Hi zzolo, yes you are right about github - code was there for some time now if anyone wants to grab it head to http://github.com/istos/openspace_for_drupal - rembemer to rename the module openspace before installing...

Still no word from Tomdeb - the maintainer of the existing openspace module.

Jeremy - can you please give him a poke!

This is probably better placed in the openspace issue queue.

I have seen what you have done on github. Looks good. I may see if I can turn it into a patch.

I've received an email from tomdeb and he is happy for us to integrate our code with openspace module. He's given us CVS access so we're currently working on integrating the code.

Changed title to make sense now this is in the openspace project.

Our code has now been merged into the module and I've released a new version - 6-2-beta1

Please open new issues for any bugs found.