It's great, once again, to hear that Maps can be used as part of the OSM
initiative - I think it makes a lot of sense as a solution. A few thoughts
- yes, Maps is modular - the code for services like Google Maps and Yahoo!
Maps sits in standalone directories that can either be included or not,
depending on the LocalSettings.php settings. For this project, only
OpenLayers support would be included (and possibly support for a separate
"OpenStreetMap" service, if such a thing were created to try to improve
- similarly, Maps has no Semantic MediaWiki component - all of that code is
contained, not surprisingly, in the separate extension "Semantic Maps". Maps
was created with Semantic Maps in mind, but the two are independent.
- for retrieving the static image, am I correct in thinking that there is,
or will be, an API that returns such an image, based on one or a set of
coordinates? And that thus, the MediaWiki extension, whether it's Maps or
anything else, doesn't have to worry about it much (besides knowing how to
call the API)?
- I assume "marker=" sets the marker image? Maps doesn't allow users to
the image for the marker, so that should be fine. (We'll know not to add it.
- The one possibly bigger issue is the use of OpenLayers to let users
browse through high-resolution images. You suggest turning that into a
separate project; presumably so that that functionality won't slow down the
regular OpenStreetMap stuff. I don't think that's necessary, though: in
terms of PHP performance, having code that can handle all the OpenLayers
stuff should affect performance only minimally, since it's just not much
code... or was there another reason you wanted it to be separate?
On Sun, Sep 6, 2009 at 11:33 AM, Ævar Arnfjörð Bjarmason <avarab(a)gmail.com
On Fri, Sep 4, 2009 at 4:56 PM, jeroen De
After discussing with Ævar, we agreed that using
the Maps extension 
instead of SlippyMap to display OSM maps with OL is probably a good
assuming this is doable of course, which I think
I am able and willing to put quite some time into
making the needed
to Maps. Before I can really start though, it
would be helpful if I had
most up to date code of SlippyMap, since a lot of
it's current code can
re-used. Is this the one committed to the SVN
trunk? (I've downloaded
code, but it's missing at least one file and
giving other errors as
I run the code from SVN (although with this patch:
shouldn't matter) and it works just fine. What file is missing / what
errors do you get?
It would also be nice if the people who are
working on this end of the
mapping effort give me a poke, so efforts can be coordinated, and no one
goes off to create duplicate or redundant functionality.
If anyone has objections to using Maps instead of SlippyMap, please
them, so we can discuss the advantages and
disadvantages of using Maps.
To provide a bit of context Jeroen contacted me on IRC recently about
this and I talked to Yaron (the other main author of Extension:Maps)
about this as well.
I don't care what piece of software we use for embedding maps into MW
pages as long as it works. So if you're willing to modify the Maps
extension so that it works for our purposes that's just great. One
less thing for me to worry about.
While I don't care /what/ software we use whatever we end up using has
to be suitable for production deployment on Wikimedia sites for our
purposes. Which means, among other things:
* Making it fast
I'm vaguely worried about the size of the Extension:Maps codebase
compared to what we actually have to use. But then again I'm not that
familiar with it and you said on IRC that it was all pluggable so you
could just enable the parts you need.
* Making it secure
I fixed up a bunch of potential XSS injections in the SlippyMap
codebase by being really paranoid about what input it accepts (see
I also added parser tests (which Extension:Maps lacks) to make sure
this all works.
Perhaps you can reuse some of the parsertests work for Maps?
* Making sure it doesn't bite us later
The SlippyMap extension has a really limited featureset currently.
Anything we enable we're going to have to support in the future (& has
to be scalable). So Maps will have to be configured to expose a really
limited featureset (e.g. no semantic stuff, or API queries to Yahoo).
These are as I see it the most important
* Migrate code from SlippyMap to Maps, mainly the static map handling
Rather than copying the huge pile of PHP code that calculates a
bbox/scale from lat/lon/zoom it would probably be more worthwhile to
work on this: https://bugzilla.wikimedia.org/show_bug.cgi?id=19861
But in any case I made the lat/lon/zoom -> bbox/scale code isolated
from the rest so feel free to copy/paste until we have something
better on the backend.
* Add the ability to display maps without any
markers on them. Currently
maps has several parser functions, like display_point, which will
error when you don't provide any coordinates
instead of displaying an
map. (Should be easy to do though.)
Regarding markers I was going to remove the marker= support in the
SlippyMap extension, because:
* It's limited. We want some sort of syntax to support multiple markers
* In order to support anything like markers/kml layers/whatever we're
going to have to support that in OpenLayers *and* on the static
* Optimize the code. Currenly Maps supports
OpenLayers as mapping
and allows you to display maps from a variety of
mapping services. On
that, the OL JS is far from optimal. Therefore I
think it's best to
add a new service to Maps (this is done via a
hook-like system build in
Maps), and create optimized handling for only OL+ OSM there, based on
current SlippyMap JS.
* Optionally (probably not required in the first
capabilities, allowing users to zoom and pan
around high resolution
That's probably better done as a seperate project for File: pages as
OpenLayers gets wider use within MediaWiki.
Anything mission critical I'm missing there?
Not that I can see.
Maps-l mailing list
Maps-l mailing list