[OpenLayers-Dev] Mapstraction vs OpenLayers?
Christopher Schmidt
crschmidt at metacarta.com
Tue Apr 8 09:36:58 EDT 2008
On Tue, Apr 08, 2008 at 08:53:16AM -0400, John R. Frank wrote:
> If someone asked you "what's the difference between OpenLayers and
> Mapstraction?" What would you say?
Mapstraction is a very thin wrapper on top of a variety of mapping APIs.
Essentially, it implements a 'lowest common denominator' API: allowing
you to use the common features between the APIs *within* those APIs.
So, for example, all mapping APIs have some kind of 'popup' class:
Mapstraction allows you to use Google Maps, or Yahoo Maps, or what have
you, and use *their* popup class for displaying the data. This has great
benefits in some cases: for example, it allows you to quickly say "I
want to see the difference between how this code looks against Google
Maps Popups, Yahoo Maps popups, and Virtual Earth popups." MetaCarta has
used Mapstraction in various projects for this reason: it allowed for
the disconnection between Javascript code and mapping API, but *not* the
disconnect between mapping API and the features of that mapping API.
OpenLayers, on the other hand, doesn't use the 'higher level'
functionality of any of the data sources: instead, it uses data sources
*only* as a source of data, and implements the entire API *above* the
lower level mapping API. So, with OpenLayers, you can't use Google Maps
popups: you use only OpenLayers popups.
This has a benefit in the other direction: if you want your application
to be distinctly 'you', you can customize OpenLayers popups to your
heart's content, and use them over *all* the APIs. However, this comes
at a cost: For example, the popups in OpenLayers before OpenLayers 2.6
are obviously not quite the same level of 'polish' as Google popups, and
you *can't* fall back to the underlying data source.
An additional restriction of using Mapstraction is you are essentially
tied to using one API at a time, and can only use the methods that exist
within that API (as far as I'm aware). This means that, for example, you
can't have both Virtual Earth and Google Maps in the *same* map: you can
switch between them, but you can't switch the stuff out from under them.
(If you think about it, this makes some sense: you can't display Google
Maps popups on top of a Virtual Earth map, for example.)
This means that, if you're a county sheriff in Texas, where half your
county is covered by Virtual Earth data, and half your county is covered
by Google Maps data, you can't quickly 'flip the switch' back and forth
as you cross the border, to see the two different data types.
Another limitation is that it doesn't have the same 'layer' API that
OpenLayers does, because you're ependant on the underlying API: you
can't easily 'mix and match' datatypes, as far as I'm aware.
This means that there are use cases where using Mapstraction over
OpenLayers makes sense. If you just want 'markers on a map', and you're
planning to support switching between a few commercial APIs as a
preference, mapstraction works great. If you want something that's
simple to use and get started with, Mapstraction still has a leg up on
OpenLayers when using commercial data, because (similar to the
commercial data) it uses Lon/Lat to do its manipulation (whereas
OpenLayers prefers to work in sphericalMercator when working with
projected data). It's also mught lighter weight than even the lightest
OpenLayers build, which can be useful.
However, when you've got a desire to switch between multiple commercial
basemaps while using an application, or you want to have a consistent
'look and feel' to your application regardless of what underlying
mapping API you're using, I think that OpenLayers is probably the way to
go. This increases if you plan to use custom data loading, or you want
to use some of the more advanced features of OpenLayers, like vector
editing, over any base map: Mapstraction does not, as far as I know,
have support for these types of usage.
Hopefully this helps answer your question,
--
Christopher Schmidt
MetaCarta
More information about the Dev
mailing list