Demo: Leaflet/OpenLayers Translator
икониFor a long time, I’ve seen complaints that the OpenLayers API is ‘too complicated’ — that there are too many options, that it’s too difficult to configure, etc. I’ve said for a long time that although OpenLayers offers a lot of power, it’s also possible to make things simpler with a relatively thin layer on top of OpenLayers — that the power doesn’t necessary have to compete with simplicity, but that maintaining a simple wrapper at the OpenLayers level is probably not ideal, for a lot of reasons.
I’m obviously not a good target for making a simpler API — I don’t consider OpenLayers difficult to use, so it’s really hard for me to be the one to implement an ‘easier’ to use API! Thankfully, only 3.5 years after I started saying someone should write a simpler API, there appears to be a significant competitor to OpenLayers which is being praised for its ease of use: Leaflet, from Cloudmade.
So, after watching people continually praise the Leaflet API, I thought I’d see what it took to make OpenLayers as easy to use as Leaflet. I started with the Quick Start example, and worked my way down the features of the page until I got to the end.
The result is the ol-leaflet-wrapper quick-start — a substantially similar page, which looks the essentially the same as the Leaflet Quick Start guide (minus popups). Total code to implement: 99 lines.
Now, I’m not saying this is a full-fledged wrapper: in fact, anyone with half a brain would be able to observe that this particular example is missing one big feature, in the form of popups. (In fact, I think this kind of demonstration is one very easy way to make it clear where the OpenLayers *library* is deficient: things that are hard to wrap between one library and another are a clear target for API refactoring and cleanup.) Any deeper look would show that I’ve only minimally wrapped Leaflet, and that a more complete wrapper would still be a significant investment.
However, I do think that it’s possible to make the kinds of changes that people desire most from OpenLayers *without* completely reimplementing the library — and even without a refactoring of the (admittedly bulky) core library; instead, approaching a new API as something built on top of the existing is a way to rapidly prototype a new approach, and integration or improvements can move into the core library as needed.
And if people who like OpenLayers really want a simpler API like Leaflet — well, I’m happy to help develop the Leaflet API wrapper into something more real, to help direct what a suitably friendly API for working with OpenLayers might actually look like.
September 5th, 2011 at 11:54 am
Chris,
OL is wonderfully powerful, but LeafletJS just does the job. I’m always impressed by the sophistication of OL, but I always struggle to understand how much of that sophistication I need to ignore to make my app work. My biggest gripe with OL is the documentation. It seems to be written for people who know how OL works, not for people who want to use it occasionally or want to know where to start. My first OL slippy map took hours and I nearly gave up. My first LeafletJS slippy map took a few minutes, mostly because the documentation assumes you know very little.
I have urged the LeafletJS guys to resist the urge to add more complexity and sophistication. If I want that it is there in OL in spades.
Chris ( a user of OL and LeafletJS)
September 5th, 2011 at 6:23 pm
Chris: I agree that OL’s API is not designed for the same use case as Leaflet is currently; this post is a call-out less to *users* of the libraries, and more to developers of the libraries, as those are the people who are bearing the cost of reimplementing from scratch rather than building on what exists.
That said, I think that http://docs.openlayers.org/library/introduction.html starts at a very basic level and results in a map not altogether different from the first Leaflet example. Can you explain what in this example is unclear, so we can improve that documentation for initial/new users?
September 6th, 2011 at 1:49 am
Chris, that’s a great initiative and really shows how powerful OpenLayers can be (especially in the hands of its core contributor).
But I’d like to point out several problems with “building on what exists rather than bearing the cost of reimplementing from scratch” approach:
1) one point you brought up yourself – “things that are hard to wrap between one library and another are a clear target for API refactoring and cleanup” – when developer writing a wrapper stops before one of such obstacles, refactoring the HUGE core of the library when you don’t know the internals as perfectly as you is really painful compared to writing similar functionality from scratch.
2) even if we assume that we can implement the wrapper we need without refactoring OL core, wrapper always means additional performance overhead. And if you just need some common mapping functionality for map apps without the hardcore GIS stuff, wrapping around an enourmous “does-it-all” library doesn’t make much sense as it has a lot of performance overhead in the first place. Even you make a specialized build of OL with just the features you need, all the performance and size overhead in architecture to support tons of OL features adds up. So basically we take a big and slow library that’s suited to a much broader set of functionality than we actually need, and make it even slower.
3) maintaining a good wrapper is hell. Not only does it add an additional layer of complexity to an already complex code, it is also much more fragile because it’s dependent on a library with another team of developers, so fixing any issues is much harder and slower. And because the API assumes certain architecture under the hood, trying to solve architecture differences between the core we wrap around and our API means using ugly, hard-to-maintain and fragile hacks often.
So in other words, you can’t tune a truck into a sports car. It’s just meant for heavy lifting, even if we leave out its storage containers and work with the core. And vice versa – sports car isn’t meant to carry tons of cargo. They’re just for different things. It’s possible to tune them somehow but you won’t get good results.
September 6th, 2011 at 5:35 am
Vladimir:
First of all, I should clarify. Leaflet is doing a thing. It’s a good thing, and people appreciate the thing — but it’s not going to be for everybody, because for every user with a simple use case that Leaflet makes trivial, I think there’s probably other users out there for which they need the ‘complexity’ that OpenLayers provides, which Leaflet doesn’t appear to be targeting.
Instead, this commentary is directed more at the people who seem to think that OpenLayers can’t be made to be simple, and that it should be thrown into the trash heap as a result. I’ve dealt with complaints for 5 years now that OpenLayers isn’t simple enough, and to be frank, I’m tired of the assumption that making it simple is something that belongs solely in the hands of a core development team which is concentrating on making the difficult possible, rather than the simple trivial.
That said, I am not sure I agree with (or perhaps, understand) all of the points of your comment.
1) If you’re trying to say that Leaflet is trying to meet all the same API needs as OpenLayers, then I guess I’m confused, because that seems completely opposite of what I’ve seen; Leaflet seems to be targeting simplicity, which means that the ‘huge core’ isn’t something that a wrapper would *ever* need to touch: These are the pieces that you can just leave for advanced users, while concentrating on documenting the types of functionality that a target audience needs.
2) I think that this is just a misunderstanding of my target audience for these comments. Though I think there is a little bit of “with many eyes, all bugs are shallow” that you lose — which affects performance as much as anything else — certainly if all you needed to do is display a static image of a map on a webpage, you wouldn’t use a web mapping library. (Well, except for people who do, because it’s still the best solution… :)) But overall, yes, simpler use cases can get a performance boost by removing bloat.
In any case, it seems to me that you’re answering “Why does Leaflet exist?” — something I’ve said before is a completely reasonable thing to exist and develop.
Instead, I’m answering the question: “Why doesn’t OpenLayers look like Leaflet?” — and the answer is simple: It’s not because it couldn’t — with just 100 lines, OpenLayers starts to look very much like Leaflet for common use cases. It’s because making the simple cases trivial is not the core development goal: making difficult cases possible is. However, it doesn’t prevent people from using a simpler OpenLayers — they just need to commit to it.
September 9th, 2014 at 6:17 pm
So, I just at through the FOSS4G Laeflet/Mapbox workshop, and I really like the control over the markers that are included.
The workshop got me thinking about how to use the marker control from Leaflet with the OpenLayers interface. The first thought was that one of the other would need to have navigation control, and the other lib would need to be synced somehow. Maybe there is even a mode of operation that could be switched, anyway, the general idea was to use the marker stuff from Leaflet with the Underlying openlayers base and overlays.
I did a search on Leaflet and Openlayers, and ended up here. So, other thoughts?
bobb
February 11th, 2015 at 3:18 am
For experts in both Ol and leaflet could I get a few examples of something that’s possible in Ol that isn’t in leaflet? This is not a challenge, I am just curious what people are using the power of Ol for.
February 11th, 2015 at 3:19 am
For experts in both Ol and leaflet could I get a few examples of something that’s possible in Ol that isn’t in leaflet? This is not a challenge, I am just curious what people are using the power of Ol for.b