After discussing with Ævar, we agreed that using the Maps extension [0] instead of SlippyMap to display OSM maps with OL is probably a good idea, assuming this is doable of course, which I think it is.

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

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 voice them, so we can discuss the advantages and disadvantages of using Maps.

These are as I see it the most important functionality to-do's: * Migrate code from SlippyMap to Maps, mainly the static map handling

* Add the ability to display maps without any markers on them. Currently maps has several parser functions, like display_point, which will display

error when you don't provide any coordinates instead of displaying an

map. (Should be easy to do though.)

* Optimize the code. Currenly Maps supports OpenLayers as mapping

and allows you to display maps from a variety of mapping services. On top

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 version) add

capabilities, allowing users to zoom and pan around high resolution

Anything mission critical I'm missing there?

wrote:

On Fri, Sep 4, 2009 at 4:56 PM, jeroen De Dauw<jeroen_dedauw(a)yahoo.com> wrote: idea, [see below] changes the be that well.) I run the code from SVN (although with this patch: https://bugzilla.wikimedia.org/show_bug.cgi?id=19961 but that shouldn't matter) and it works just fine. What file is missing / what errors do you get? voice 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 extractOptions in http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SlippyMap/Slippy… ). 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). 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. display an empty 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 rendering backend. service, top of simply Sounds good. image-as-layer images. That's probably better done as a seperate project for File: pages as OpenLayers gets wider use within MediaWiki. Not that I can see. _______________________________________________ Maps-l mailing list Maps-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l

The Maps extension appears to have a lot of excess code for supporting Google Maps, yahoo, etc.  I see there also is geocoding, but it using Google Maps so we wouldn't want to use it. Although, Google Maps and other non-free map services may be turned off with LocalSettings.php, I think it would be better not to have all that code in the extension.  I would prefer to keep the code base small and simple as possible, and strictly have only open source mapping services in the code.

What does the Maps extension do that we can't do with SlippyMaps that we would want for OpenStreetMap integration?  Let's do things the other way around, instead of using Maps extension, use SlippyMaps and incorporate what bits of Maps code that are useful into SlippyMaps?