Hi all,
Since the month of September of 2014, I started working on a new version of Openlayers, find the roadmap here and feel free to participate.
Last week, after 10 months of development, I made a summer cleanup of the code again, added the missing bits and finalized the API.
I feel that the module has never been so stable since.
Now that it has a rock solid API, we can now focus on adding features and functionnalities.
I also updated an old sandbox of Leaflet that I made a couple of month ago, based on the same basecode.
You can test both modules here:
Openlayers: http://dev.through-my-eyes.be/openlayers_examples
Leaflet: http://dev.through-my-eyes.be/leaflet_examples
There are only 3 examples for Leaflet.
I don't know if the Leaflet module is still developped, but my Leaflet sandbox might be a good base for starting something new.
Also, I think the Openlayers module could be a good candidate for the 'mapping' module that never has never seen the light.
Imagine, we could have a mapping module that would be the basecode of Openlayers AND Leaflet module, it would define how basic maps objects should behave and render in Javascript.
There are still a lot of work to be done, but feel free to join de discussion and help.
Developping this on my free time and for free, I'm looking for sponsors (flight, accomodation and entry fees) to help me to come to Drupalcon Barcelona.
Comments
For a base 'mapping' module,
For a base 'mapping' module, keeping the Rule of Three in mind, a good approach may be to have a third mapping module based on the same codebase (a Google Map one maybe). Then, refactor these three modules to move shared parts to a base module.
I think that I have this
I think that I have this notion more or less in mind. See my post below, a really basic Mapping data module that does nothing at all on it's own, just aiming to serve as an Entity based data structure for maps that a rendering engine such as the OL or Leaflet module might run on top of.
Hello Pierre, That's the idea
Hello Pierre,
That's the idea actually. Yesterday I committed a submodule for both of them: 'openlayers_field' and 'lealfet_field' and the code is exactly the same.
Commit for Openlayers: http://cgit.drupalcode.org/openlayers/commit/?h=7.x-3.x&id=ce3e73fe13182...
Commit for Leaflet: http://cgit.drupalcode.org/sandbox-Pol-2399051/commit/?id=f4f3b643cc3f8e...
-Pol-
Pol, the work that you have
Pol, the work that you have done on bringing OL up to speed is fantastic. Also, I agree that standardizing on something like the "Mapping" module. I have played around with the mapping module a bit, and I also noticed that the OL data structure that you are using resembles it in many ways.
I have a some questions though.
Are you thinking of a stand-alone module like Mapping to provide the backend data structure? The way that previous OL and Leaflet version were done they essentially duplicate a large amount of code - which seems like it provides difficulty for long term maintenance.
What are your thoughts on basing the data model on Entity (be it stand-alone or duplicative)? Entity CRUD provides some nice abilities.
I have been working a bit on a basic Entity-based mapping infrastructure. My goal is to provide display independent data storage to assemble basic map pieces, and then let the rendering be handled by an appropriate engine, be it OpenLayers, Leaflet, d3, Gmap or others. https://www.drupal.org/sandbox/robertwb/2535152
Hello Robert,I wanted to use
Hello Robert,
I wanted to use entities too but I also wanted to have the ability to export the configuration on files, this is why I used CTools exportable system and CTools Export UI. Both of these tools allowed me to build a quick and consistent CRUD UI for every OL objects.
I've checked emapping and the idea if very good but... how to manage the exportables ?
How to manage the CRUD UI ?
Maybe i'm missing something, please, let me know !
-Pol-
Hey Pol, thanks for the
Hey Pol, thanks for the reply, and sorry for taking this off topic, kind of hijacking your announcement which is awesome news! To your questions:
So, for exportability, I am not an expert since I don't really use that feature, but Entity API support export out of the box I believe (in hook_entity_info each type is marked 'exportable' => true and the objects are sub-classes of EntityAPIControllerExportable . (details on what is suported by exportable Entity at Community docs, "Make an entity type exportable" - https://www.drupal.org/node/1021526 )
The CRUD UI is something that I have a little more experience with, though still not an expert. In the demo module that I created, I do:
I will give you an account if you are interested in playing around. Also, I will begin testing the current Leaflet sandbox version you just posted up.
Entity Operations module
Entity Operations module seems to offer custom entity CRUD UI. Is this what you are looking for?
Milos - thanks, I had not
Milos - thanks, I had not seen this one before. I have done quite a bit of CRUD with entity API, but all through code, not through the Entity Operations UI -- seems like it could aid in development? Do you have experience with it?
Guys, I'm more than willing
Guys,
I'm more than willing to use Entity stuff insteaf of CTools, I just don't know where to begin right now.
I should make a small proof of concept first.
-Pol-
fatal error after any attempt to update from beta3 to the stable
Hi, I have experienced similar error any time I tried to update, since the module has a stable version:
Fatal error: Class 'Drupal\openlayers\Openlayers' not found in /sites/all/modules/openlayers/openlayers.module on line 322
The only way to resolve this is by returning back to the "not stable" beta3 version of the module.
Any idea how to resolve that?