Hey,
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 changes to Maps. Before I can really start though, it would be helpful if I had the most up to date code of SlippyMap, since a lot of it's current code can be re-used. Is this the one committed to the SVN trunk? (I've downloaded that code, but it's missing at least one file and giving other errors as well.) 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 an error when you don't provide any coordinates instead of displaying an empty map. (Should be easy to do though.) * Optimize the code. Currenly Maps supports OpenLayers as mapping service, and allows you to display maps from a variety of mapping services. On top of that, the OL JS is far from optimal. Therefore I think it's best to simply 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 image-as-layer capabilities, allowing users to zoom and pan around high resolution images.
Anything mission critical I'm missing there?
[0]http://www.mediawiki.org/wiki/Extension:Maps
Cheers
--
Jeroen De Dauw
* Forum: code.bn2vs.com * Blog: blog.bn2vs.com
* Skype: rts.bn.vs --
Don't panic. Don't be evil.70 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65!
On Fri, Sep 4, 2009 at 4:56 PM, jeroen De Dauwjeroen_dedauw@yahoo.com wrote:
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.
[see below]
I am able and willing to put quite some time into making the needed changes to Maps. Before I can really start though, it would be helpful if I had the most up to date code of SlippyMap, since a lot of it's current code can be re-used. Is this the one committed to the SVN trunk? (I've downloaded that code, but it's missing at least one file and giving other errors as 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?
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.
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/SlippyM...). 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 functionality to-do's:
- 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 display an error when you don't provide any coordinates instead of displaying an empty 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 rendering backend.
- Optimize the code. Currenly Maps supports OpenLayers as mapping service,
and allows you to display maps from a variety of mapping services. On top of that, the OL JS is far from optimal. Therefore I think it's best to simply 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.
Sounds good.
- Optionally (probably not required in the first version) add image-as-layer
capabilities, allowing users to zoom and pan around high resolution images.
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.
Hi Ævar, 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 and responses:
- 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 performance).
- 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 set 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?
-Yaron
On Sun, Sep 6, 2009 at 11:33 AM, Ævar Arnfjörð Bjarmason avarab@gmail.comwrote:
On Fri, Sep 4, 2009 at 4:56 PM, jeroen De Dauwjeroen_dedauw@yahoo.com wrote:
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.
[see below]
I am able and willing to put quite some time into making the needed
changes
to Maps. Before I can really start though, it would be helpful if I had
the
most up to date code of SlippyMap, since a lot of it's current code can
be
re-used. Is this the one committed to the SVN trunk? (I've downloaded
that
code, but it's missing at least one file and giving other errors as
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?
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.
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/SlippyM... ). 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 functionality to-do's:
- 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 display
an
error when you don't provide any coordinates instead of displaying an
empty
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 rendering backend.
- Optimize the code. Currenly Maps supports OpenLayers as mapping
service,
and allows you to display maps from a variety of mapping services. On top
of
that, the OL JS is far from optimal. Therefore I think it's best to
simply
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.
Sounds good.
- Optionally (probably not required in the first version) add
image-as-layer
capabilities, allowing users to zoom and pan around high resolution
images.
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
On Sun, Sep 6, 2009 at 8:38 PM, Yaron Korenyaron57@gmail.com wrote:
Hi Ævar, 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 and responses:
- 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 performance).
- 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.
My questions reveal how little I know about Extension:Maps :)
It sounds like it will work just fine & is designed in a modular enough fashion to not bog us down in any way.
- 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)?
Yes to get a static map the extension just has to include a <img> tag pointing at the static map server(s). E.g.:
http://cassini.toolserver.org/cgi-bin/export?bbox=-0.2214,51.4746,0.0316,51....
Calculating the "bbox=-0.2214,51.4746,0.0316,51.5878&scale=110000" part is what all the complexity in SlippyMapExportCgiBin.class.php is about. But hopefully we'll be able to specify "lat/lon/zoom/width/height" instead soon which will save us all that complexity.
- I assume "marker=" sets the marker image? Maps doesn't allow users to set
the image for the marker, so that should be fine. (We'll know not to add it. :) )
The marker is set (currently) with marker=1 which will turn on an OpenLayers.Marker in the JavaScript: http://dev.openlayers.org/docs/files/OpenLayers/Marker-js.html
I'm going to remove that until we've figured out how do do this in an extensible and open-enden way. Like e.g.:
<maps lat=.. lon=.. zoom=..> some code that specifies lots of markers / layers / highlighting of OSM data here </maps>
AND if we're going to add marker support the static map service needs to support that too.
- 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?
The reason I suggested a separate project was because Jeroen ended his bullet point list of requirements with "Anything mission critical I'm missing there?". So I thought he might be under the impression that this functionality was needed for getting maps embedding to work.
But we're probably talking about separate things here.
It has been suggested to use OpenLayers for huge images on image description pages. There's a demo of how this might work here:
http://toolserver.org/~kolossos/zoom-image/zoom-ol.html
I thought he had looked at that demo and were talking about that. It would be an interesting project but to do it properly (for supporting huge images at commons) you'd have to split images into tiles on demand and embed OpenLayers into image pages. Which would be a different sort of embedding than embedding maps into articles (although using much of the same techniques).
Another way it might be done is with OpenLayers.Image (like for scrolling a panorama), e.g.:
http://openlayers.org/dev/examples/image-layer.html
In any case both of those are interesting problem to work on and if you're interested in either one by all means go for it.
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?
-Aude
On Sun, Sep 6, 2009 at 4:38 PM, Yaron Koren yaron57@gmail.com wrote:
Hi Ævar, 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 and responses:
- 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 performance).
- 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 set
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?
-Yaron
On Sun, Sep 6, 2009 at 11:33 AM, Ævar Arnfjörð Bjarmason <avarab@gmail.com
wrote:
On Fri, Sep 4, 2009 at 4:56 PM, jeroen De Dauwjeroen_dedauw@yahoo.com wrote:
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.
[see below]
I am able and willing to put quite some time into making the needed
changes
to Maps. Before I can really start though, it would be helpful if I had
the
most up to date code of SlippyMap, since a lot of it's current code can
be
re-used. Is this the one committed to the SVN trunk? (I've downloaded
that
code, but it's missing at least one file and giving other errors as
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?
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.
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/SlippyM... ). 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 functionality to-do's:
- 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
display an
error when you don't provide any coordinates instead of displaying an
empty
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 rendering backend.
- Optimize the code. Currenly Maps supports OpenLayers as mapping
service,
and allows you to display maps from a variety of mapping services. On
top of
that, the OL JS is far from optimal. Therefore I think it's best to
simply
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.
Sounds good.
- Optionally (probably not required in the first version) add
image-as-layer
capabilities, allowing users to zoom and pan around high resolution
images.
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
On Mon, Sep 7, 2009 at 11:44 AM, Audeaude.wiki@gmail.com wrote:
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.
It really doesn't matter as long as it can be configured. Other people can use Google Maps but we don't have to.
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?
I don't really care either way but as far as I can tell we have two new people interested in working on the MediaWiki aspect as opposed to the 0.1 people we have now. That counts for a lot.
On Mon, Sep 7, 2009 at 11:54 AM, Ævar Arnfjörð Bjarmasonavarab@gmail.com wrote:
On Mon, Sep 7, 2009 at 11:44 AM, Audeaude.wiki@gmail.com wrote:
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.
It really doesn't matter as long as it can be configured. Other people can use Google Maps but we don't have to.
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?
I don't really care either way but as far as I can tell we have two new people interested in working on the MediaWiki aspect as opposed to the 0.1 people we have now. That counts for a lot.
And to elaborate a bit: What we end up using for embedding maps in wiki pages doesn't need to be decided in advance / designed by committee. If Jeroen and Yaron are interested in adapting their extension to reach feature parity with SlippyMap then that's great.
And if it turns out that it works better than what we currently have we can just use their code instead. And if not: we don't :)