Firstly it's great to see so much interest in this project, we now have approx. 60 subscribers to this mailing list just a few days after it poofed into existence.
What's the current status of the new boxes Wikimedia-DE is donating, and more importantly, do we have people interested in setting up the required infrastructure there? I.e. the Planet.osm -> DB -> Mapnik tile generation process? Someone at the hacking days volunteered to do mapnik stuff but I forget whether we had a DB admin yet.
Anyway, what I've been working on is the MediaWiki related stuff mentioned in the techblog:
http://techblog.wikimedia.org/2009/04/openstreetmap-maps-will-be-added-to-wi...
I started by hacking the SlippyMap so that it supports multiple maps per page:
http://u.nix.is/phase3/index.php?title=Slippy_Test
It's still somewhat hacky, e.g. it duplicates the whole OpenLayers template for each map.
Could someone more familiar with OpenLayers please refactor it so that it's possible to just call a function to include the map, something like:
<script type="text/javascript">include_slippymap( lat, lon, zoom, ....)</script><noscript><img src="http://static.map/lat/lon/zoom</noscript>
I'm not asking for the *extension* to be edited (although that would be great), just fore a HTML/JS example.
Note that this is probably easier in OpenLayers trunk due to OpenLayers.Layer.OSM being included now:
http://trac.openlayers.org/ticket/1950
(But I don't know if we want to run OpenLayers trunk)
There are also some more OpenLayers-related issues on the wiki page for the extension: http://wiki.openstreetmap.org/index.php/Slippy_Map_MediaWiki_Extension#Known...
In particular the Attribution issue & snapping to lat/lon 0/0.
And it it enough to have the alternate static map inside <noscript>? Does this work on all the odd browsers out there that we want to support? If so that'll make everything else much easier.
As for the static map this is how the Export tab on the OSM site does it:
http://trac.openstreetmap.org/browser/sites/rails_port_branches/api06/app/co...
I.e. it redirects to the cgi-bin/export script on the tileserver, which is a python program which renders directly from the database:
http://svn.openstreetmap.org/sites/tile.openstreetmap.org/cgi-bin/export
For example:
http://tile.openstreetmap.org/cgi-bin/export?bbox=-18.1343,65.676,-18.0711,6...
Except on Wednesday you'll see an empty map (only coastline) if you look at that, since the osm2pgsql import is running on the tileserver. I don't know whether that's something that's a problem we could hack around in our own setup while updating the Planet mirror, maybe by keeping two database copies. Or maybe by just creating static maps from the tiles themselves instead, although they'll still have this problem if an area that hasn't been pre-rendered is requested, OSM itself is serving 404.png for tiles where that's the case since it's a Wednesday.
In any case we need lat/lon/zoom to bbox/scale to use that script as-is.
What else needs be done/hacked up and who's interested in doing it?
Hi, I will have a go at the SlippyMap; expect some results early next week. I wanted to pass around the link to the DBpedia downloads where you can find the Wikipedia geodata [1]. The related extractor code is at [2]. We'll also have our live extraction back up soon where we could provide an update stream.
Cheers,
Christian
[1] http://wiki.dbpedia.org/Downloads32 [2] http://dbpedia.svn.sourceforge.net/viewvc/dbpedia/extraction/extractors/GeoE...
On Apr 8, 2009, at 1:34 PM, Ævar Arnfjörð Bjarmason wrote:
Firstly it's great to see so much interest in this project, we now have approx. 60 subscribers to this mailing list just a few days after it poofed into existence.
What's the current status of the new boxes Wikimedia-DE is donating, and more importantly, do we have people interested in setting up the required infrastructure there? I.e. the Planet.osm -> DB -> Mapnik tile generation process? Someone at the hacking days volunteered to do mapnik stuff but I forget whether we had a DB admin yet.
Anyway, what I've been working on is the MediaWiki related stuff mentioned in the techblog:
http://techblog.wikimedia.org/2009/04/openstreetmap-maps-will-be-added-to-wi...
I started by hacking the SlippyMap so that it supports multiple maps per page:
http://u.nix.is/phase3/index.php?title=Slippy_Test
It's still somewhat hacky, e.g. it duplicates the whole OpenLayers template for each map.
Could someone more familiar with OpenLayers please refactor it so that it's possible to just call a function to include the map, something like:
<script type="text/javascript">include_slippymap( lat, lon, zoom, ....)</script><noscript><img
src="http://static.map/lat/lon/zoom</noscript>
I'm not asking for the *extension* to be edited (although that would be great), just fore a HTML/JS example.
Note that this is probably easier in OpenLayers trunk due to OpenLayers.Layer.OSM being included now:
http://trac.openlayers.org/ticket/1950
(But I don't know if we want to run OpenLayers trunk)
There are also some more OpenLayers-related issues on the wiki page for the extension: http://wiki.openstreetmap.org/index.php/Slippy_Map_MediaWiki_Extension#Known...
In particular the Attribution issue & snapping to lat/lon 0/0.
And it it enough to have the alternate static map inside <noscript>? Does this work on all the odd browsers out there that we want to support? If so that'll make everything else much easier.
As for the static map this is how the Export tab on the OSM site does it:
http://trac.openstreetmap.org/browser/sites/rails_port_branches/api06/app/co...
I.e. it redirects to the cgi-bin/export script on the tileserver, which is a python program which renders directly from the database:
http://svn.openstreetmap.org/sites/tile.openstreetmap.org/cgi-bin/export
For example:
http://tile.openstreetmap.org/cgi-bin/export?bbox=-18.1343,65.676,-18.0711,6...
Except on Wednesday you'll see an empty map (only coastline) if you look at that, since the osm2pgsql import is running on the tileserver. I don't know whether that's something that's a problem we could hack around in our own setup while updating the Planet mirror, maybe by keeping two database copies. Or maybe by just creating static maps from the tiles themselves instead, although they'll still have this problem if an area that hasn't been pre-rendered is requested, OSM itself is serving 404.png for tiles where that's the case since it's a Wednesday.
In any case we need lat/lon/zoom to bbox/scale to use that script as- is.
What else needs be done/hacked up and who's interested in doing it?
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
2009/4/8 Ævar Arnfjörð Bjarmason avarab@gmail.com
And it it enough to have the alternate static map inside <noscript>? Does this work on all the odd browsers out there that we want to support? If so that'll make everything else much easier.
There are some concerns about a) printing and b) the amount of JavaScript that needs to be loaded for the slippy map, and c) possibly missing <noscript> support. Would it perhaps be better to have the static map image that's currently in <noscript> as default, add a JavaScript "onclick" handler to it, that shows some animated sandclock, loads OpenLayers and displays a map instead of the former static image?
Except on Wednesday you'll see an empty map (only coastline) if you look at that, since the osm2pgsql import is running on the tileserver. I don't know whether that's something that's a problem we could hack around in our own setup while updating the Planet mirror, maybe by keeping two database copies.
The original plan was to permanently import the diffs, just like others are doing it already (e.g. MetaCarta for the up-to-date service).
Regards,
jens
On Wed, Apr 8, 2009 at 1:15 PM, Jens Frank jens.l.frank@googlemail.com wrote:
2009/4/8 Ævar Arnfjörð Bjarmason avarab@gmail.com
And it it enough to have the alternate static map inside <noscript>? Does this work on all the odd browsers out there that we want to support? If so that'll make everything else much easier.
There are some concerns about a) printing and b) the amount of JavaScript that needs to be loaded for the slippy map, and c) possibly missing <noscript> support. Would it perhaps be better to have the static map image that's currently in <noscript> as default, add a JavaScript "onclick" handler to it, that shows some animated sandclock, loads OpenLayers and displays a map instead of the former static image?
Sounds good, even on Firefox I'd prefer to have a static image when printing as I don't need the OpenLayers UI elements on paper. But even then quicker loading time wins over the maps being dynamic in most cases, and you get other niceties like right click -> save image.
Which is the default could be made optional, either with a parameter or site-wide (depending on a config setting. Requesting someone with JavaScript-fu to implement the user visible parts :)
Except on Wednesday you'll see an empty map (only coastline) if you look at that, since the osm2pgsql import is running on the tileserver. I don't know whether that's something that's a problem we could hack around in our own setup while updating the Planet mirror, maybe by keeping two database copies.
The original plan was to permanently import the diffs, just like others are doing it already (e.g. MetaCarta for the up-to-date service).
Ah, but the problem outlined above is encountered by OSM due to the way they're swapping out the planet weekly.
But in any case it's a solvable server administration problem, so let's just worry about it when we have something installed to worry about. I shouldn't have brought it up.
Jens Frank wrote:
There are some concerns about a) printing
For good printing, SVG or PDF would be nice. But hey, isn't SVG an intermediary format in Mapnik, before PNG tiles are generated? Could we tap that for the print version?
2009/4/8 Lars Aronsson lars@aronsson.se
Jens Frank wrote:
There are some concerns about a) printing
For good printing, SVG or PDF would be nice.
SVG is not yet widely supported, and I'm not aware of any common way to include a PDF as an image in a web page.
Regards,
jens
Jens Frank schrieb:
2009/4/8 Lars Aronsson <lars@aronsson.se mailto:lars@aronsson.se>
Jens Frank wrote: > There are some concerns about a) printing For good printing, SVG or PDF would be nice.SVG is not yet widely supported, and I'm not aware of any common way to include a PDF as an image in a web page.
Well, if people are printing the *page*, png is probably the best bet, until native support for embedded svg is available in most browsers.
However, perhaps people wopuld like to print full size maps in high detail. for that, a PDF and/or SVG option would be good.
-- daniel
On Wed, Apr 08, 2009 at 10:29:07PM +0200, Daniel Kinzler wrote:
SVG is not yet widely supported, and I'm not aware of any common way to include a PDF as an image in a web page.
Well, if people are printing the *page*, png is probably the best bet, until native support for embedded svg is available in most browsers.
However, perhaps people wopuld like to print full size maps in high detail. for that, a PDF and/or SVG option would be good.
Experience shows that even for printing it makes more sense to go with the PNG maps. The SVG created for any sizeable map is so huge and complex that renderers have problems rendering it and need huge amounts of RAM doing that. A vector format might in theory be better for printing, but in practice its too cumbersome. So just doing PNGs is fine for now. We can always add more options later.
Jochen
On Wed, Apr 8, 2009 at 3:47 PM, Lars Aronsson lars@aronsson.se wrote:
Jens Frank wrote:
There are some concerns about a) printing
For good printing, SVG or PDF would be nice. But hey, isn't SVG an intermediary format in Mapnik, before PNG tiles are generated? Could we tap that for the print version?
The export script I linked to earlier in this thread has JPEG, PNG, SVG and PDF export options. So yes, we could offer that option if someone hacks up a UI for it.
On Wed, Apr 8, 2009 at 4:47 PM, Lars Aronsson lars@aronsson.se wrote:
Jens Frank wrote:
There are some concerns about a) printing
For good printing, SVG or PDF would be nice. But hey, isn't SVG an intermediary format in Mapnik, before PNG tiles are generated? Could we tap that for the print version?
Technically it's an alternative output format to png, but yes, mapnik does support SVG output.
Cheers, Andy
I have my own OpenLayers extension in development and would like to merge some of the code. What it does is parse a tag: <map lat="38.90962" long="-77.04341" zoom="15" mode="osm">
The "mode" parameter allows specifying osm - OpenStreetMap as the map source, or WorldWind and can allow other sources such as a custom WMS server. There is a variable in LocalSettings.php to specify what modes are enabled on the wiki. For what we are doing (just OSM to start with), we can enable just the OSM mode. The "mode" parameter could be optional, but the others required. If the "mode" parameter is not provided, then the default mode (e.g. OSM) is used.
The JavaScript is included as a separate js file.
Here are code snippets from my Map.php (main extension file), which makes calls to a Map.class.php file:
$wgHooks['ParserFirstCallInit'][] = 'wfMapParserInit';
function wfMapParserInit() { global $wgParser; $wgParser->setHook( 'map', 'wfMapRender' ); return true; }
function wfMapRender( $input, $args, $parser ) { /* $wgMap is as a public object, with the setupMap function available, while other parts of the code are protected */ global $wgOut, $wgScriptPath, $wgMap;
/* pass variables to JavaScript. right now, there can only be one map per page, but I would like to put the variables into a multidimensional array, and handle multiple maps that way. I'm working on this. */ $wgOut->addScript( "<script type='text/javascript'>var mode='" . $args[mode] . "'; var lat=" . $args[lat] . ";var long=" . $args[long] . ";var zoom =" . $args[zoom] . ";</script>");
/* it might be better to have the map.js script call and include the OpenLayers.js script, rather than do it from php. That way, if a user does not have JavaScript enabled, then the JavaScript won't load and things will be faster */ $wgOut->addScript( "<script type='text/javascript' src='" . $wgScriptPath . "/extensions/Map/OpenLayers/lib/OpenLayers.js'></script>" );
// add our custom js that implements and adds OpenLayers maps $wgOut->addScript( "<script type='text/javascript' src='" . $wgScriptPath . "/extensions/Map/map.js'></script>" );
// code making calls to the OpenLayers.class.php file to setup the map $text = $wgMap->setupMap($args[mode]);
// insert map where the <map> tag was in the wikicode $wgOut->addHTML($text);
return htmlspecialchars( $input );
}
I would like to test if a user has JavaScript enabled, which can be done with an Ajax call or other way. If they don't, then don't load all the external JavaScript, so as to keep the code lightweight and fast. If the user does have JavaScript enabled, then load the map.js script. Depending on the mode selected, the OSM portion of the js can be loaded, or the WorldWind portion, or other portion.
As for where to have the OpenLayers code, I would like to have our own copy which we can keep up-to-date as possible. It would not be good to reference the OpenLayers.js directly from OpenLayers or OSM, since those will get changed as others see fit. It could be that some change will break our extension. When we do update our copy of OpenLayers.js, we can test it with our extension and make sure everything is okay.
Anyway, in the next few days and over this upcoming weekend, I can hack more at the code where we integrate OpenLayers and MediaWiki. I can provide them as patches or if I can get svn access to the extensions part of the MediaWiki svn, then I can integrate code myself.
-Kate
On Wed, Apr 8, 2009 at 7:34 AM, Ævar Arnfjörð Bjarmason avarab@gmail.comwrote:
Firstly it's great to see so much interest in this project, we now have approx. 60 subscribers to this mailing list just a few days after it poofed into existence.
What's the current status of the new boxes Wikimedia-DE is donating, and more importantly, do we have people interested in setting up the required infrastructure there? I.e. the Planet.osm -> DB -> Mapnik tile generation process? Someone at the hacking days volunteered to do mapnik stuff but I forget whether we had a DB admin yet.
Anyway, what I've been working on is the MediaWiki related stuff mentioned in the techblog:
http://techblog.wikimedia.org/2009/04/openstreetmap-maps-will-be-added-to-wi...
I started by hacking the SlippyMap so that it supports multiple maps per page:
http://u.nix.is/phase3/index.php?title=Slippy_Test
It's still somewhat hacky, e.g. it duplicates the whole OpenLayers template for each map.
Could someone more familiar with OpenLayers please refactor it so that it's possible to just call a function to include the map, something like:
<script type="text/javascript">include_slippymap( lat, lon, zoom, ....)</script><noscript><img
src="http://static.map/lat/lon/zoom</noscript>
I'm not asking for the *extension* to be edited (although that would be great), just fore a HTML/JS example.
Note that this is probably easier in OpenLayers trunk due to OpenLayers.Layer.OSM being included now:
http://trac.openlayers.org/ticket/1950
(But I don't know if we want to run OpenLayers trunk)
There are also some more OpenLayers-related issues on the wiki page for the extension:
http://wiki.openstreetmap.org/index.php/Slippy_Map_MediaWiki_Extension#Known...
In particular the Attribution issue & snapping to lat/lon 0/0.
And it it enough to have the alternate static map inside <noscript>? Does this work on all the odd browsers out there that we want to support? If so that'll make everything else much easier.
As for the static map this is how the Export tab on the OSM site does it:
http://trac.openstreetmap.org/browser/sites/rails_port_branches/api06/app/co...
I.e. it redirects to the cgi-bin/export script on the tileserver, which is a python program which renders directly from the database:
http://svn.openstreetmap.org/sites/tile.openstreetmap.org/cgi-bin/export
For example:
http://tile.openstreetmap.org/cgi-bin/export?bbox=-18.1343,65.676,-18.0711,6...
Except on Wednesday you'll see an empty map (only coastline) if you look at that, since the osm2pgsql import is running on the tileserver. I don't know whether that's something that's a problem we could hack around in our own setup while updating the Planet mirror, maybe by keeping two database copies. Or maybe by just creating static maps from the tiles themselves instead, although they'll still have this problem if an area that hasn't been pre-rendered is requested, OSM itself is serving 404.png for tiles where that's the case since it's a Wednesday.
In any case we need lat/lon/zoom to bbox/scale to use that script as-is.
What else needs be done/hacked up and who's interested in doing it?
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
2009/4/8 Aude aude.wiki@gmail.com
I would like to test if a user has JavaScript enabled, which can be done with an Ajax call or other way. If they don't, then don't load all the external JavaScript, so as to keep the code lightweight and fast. If the user does have JavaScript enabled, then load the map.js script.
If JavaScript is not enabled, the browser won't load scripts, no need to test for it.
As for where to have the OpenLayers code, I would like to have our own copy which we can keep up-to-date as possible. It would not be good to reference the OpenLayers.js directly from OpenLayers or OSM, since those will get changed as others see fit. It could be that some change will break our extension. When we do update our copy of OpenLayers.js, we can test it with our extension and make sure everything is okay.
The SlippyMap extension requires a small change to the original OpenLayers code. At the very end of the file, it sets a variable to "true", so that the JavaScript can be loaded asynchronously. The part of the JavaScript that creates the map polls for these variables. If they are not yet set, the function calls itself using alarm() and a ~0.5s delay. Without this hack, the loading of the page would stall at the map in many browsers when using slow links or slow CPUs
Regards,
jens
On Wed, Apr 8, 2009 at 2:17 PM, Jens Frank jens.l.frank@googlemail.com wrote:
As for where to have the OpenLayers code, I would like to have our own copy which we can keep up-to-date as possible. It would not be good to reference the OpenLayers.js directly from OpenLayers or OSM, since those will get changed as others see fit. It could be that some change will break our extension. When we do update our copy of OpenLayers.js, we can test it with our extension and make sure everything is okay.
The SlippyMap extension requires a small change to the original OpenLayers code. At the very end of the file, it sets a variable to "true", so that the JavaScript can be loaded asynchronously. The part of the JavaScript that creates the map polls for these variables. If they are not yet set, the function calls itself using alarm() and a ~0.5s delay. Without this hack, the loading of the page would stall at the map in many browsers when using slow links or slow CPUs
Is this a bug the OpenLayers developers know about and might be fixed in a future version of OpenLayers itself?
On Wed, Apr 8, 2009 at 10:19 AM, Ævar Arnfjörð Bjarmason avarab@gmail.comwrote:
On Wed, Apr 8, 2009 at 2:17 PM, Jens Frank jens.l.frank@googlemail.com wrote:
As for where to have the OpenLayers code, I would like to have our own copy which we can keep up-to-date as possible. It would not be good to reference the OpenLayers.js directly from OpenLayers or OSM, since those will get changed as others see fit. It could be that some change will
break
our extension. When we do update our copy of OpenLayers.js, we can test
it
with our extension and make sure everything is okay.
The SlippyMap extension requires a small change to the original
OpenLayers
code. At the very end of the file, it sets a variable to "true", so that
the
JavaScript can be loaded asynchronously. The part of the JavaScript that creates the map polls for these variables. If they are not yet set, the function calls itself using alarm() and a ~0.5s delay. Without this hack, the loading of the page would stall at the map in many browsers when
using
slow links or slow CPUs
Is this a bug the OpenLayers developers know about and might be fixed in a future version of OpenLayers itself?
I can take a look at this, when I work on integrating changes. I'm also interested in submitting any changes to OpenLayers to make it work better and accommodate things we want to do, while making our improvements available to others.
-Kate
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
2009/4/8 Ævar Arnfjörð Bjarmason avarab@gmail.com
The SlippyMap extension requires a small change to the original
OpenLayers
code. At the very end of the file, it sets a variable to "true", so that
the
JavaScript can be loaded asynchronously. The part of the JavaScript that creates the map polls for these variables. If they are not yet set, the function calls itself using alarm() and a ~0.5s delay. Without this hack, the loading of the page would stall at the map in many browsers when
using
slow links or slow CPUs
Is this a bug the OpenLayers developers know about and might be fixed in a future version of OpenLayers itself?
This is no OpenLayers specific issue, it's just how most web browsers work, and a well known workaround for it.
Regards,
jens
2009/4/8 Jens Frank jens.l.frank@googlemail.com
The SlippyMap extension requires a small change to the original OpenLayers code. At the very end of the file, it sets a variable to "true", so that the JavaScript can be loaded asynchronously. The part of the JavaScript that creates the map polls for these variables. If they are not yet set, the function calls itself using alarm() and a ~0.5s delay. Without this hack, the loading of the page would stall at the map in many browsers when using slow links or slow CPUs
I have to correct myself. The current version of the extension does no longer include this code. The code was removed in this change:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SlippyMap/SlippyM...
Regards,
jens
On Wed, Apr 8, 2009 at 2:06 PM, Aude aude.wiki@gmail.com wrote:
I have my own OpenLayers extension in development and would like to merge some of the code. What it does is parse a tag: <map lat="38.90962" long="-77.04341" zoom="15" mode="osm">
The "mode" parameter allows specifying osm - OpenStreetMap as the map source, or WorldWind and can allow other sources such as a custom WMS server. There is a variable in LocalSettings.php to specify what modes are enabled on the wiki. For what we are doing (just OSM to start with), we can enable just the OSM mode. The "mode" parameter could be optional, but the others required. If the "mode" parameter is not provided, then the default mode (e.g. OSM) is used.
I was already going to hack SlippyMap*.php around to support this, but it might be easier to use your extension as a starting point.
The JavaScript is included as a separate js file.
Here are code snippets from my Map.php (main extension file), which makes calls to a Map.class.php file:
$wgHooks['ParserFirstCallInit'][] = 'wfMapParserInit';
function wfMapParserInit() { global $wgParser; $wgParser->setHook( 'map', 'wfMapRender' ); return true; }
function wfMapRender( $input, $args, $parser ) { /* $wgMap is as a public object, with the setupMap function available, while other parts of the code are protected */ global $wgOut, $wgScriptPath, $wgMap;
/* pass variables to JavaScript. right now, there can only be one map per page, but I would like to put the variables into a multidimensional array, and handle multiple maps that way. I'm working on this. */ $wgOut->addScript( "<script type='text/javascript'>var mode='" . $args[mode] . "'; var lat=" . $args[lat] . ";var long=" . $args[long] . ";var zoom =" . $args[zoom] . ";</script>");
/* it might be better to have the map.js script call and include the OpenLayers.js script, rather than do it from php. That way, if a user does not have JavaScript enabled, then the JavaScript won't load and things will be faster */ $wgOut->addScript( "<script type='text/javascript' src='" . $wgScriptPath . "/extensions/Map/OpenLayers/lib/OpenLayers.js'></script>" );
// add our custom js that implements and adds OpenLayers maps $wgOut->addScript( "<script type='text/javascript' src='" . $wgScriptPath . "/extensions/Map/map.js'></script>" );
// code making calls to the OpenLayers.class.php file to setup the map $text = $wgMap->setupMap($args[mode]);
// insert map where the <map> tag was in the wikicode $wgOut->addHTML($text);
return htmlspecialchars( $input );
}
I would like to test if a user has JavaScript enabled, which can be done with an Ajax call or other way. If they don't, then don't load all the external JavaScript, so as to keep the code lightweight and fast. If the user does have JavaScript enabled, then load the map.js script. Depending on the mode selected, the OSM portion of the js can be loaded, or the WorldWind portion, or other portion.
Or, if we provide a static map by default / slippy map on onclick() the onclick() routine could take care of pulling in OpenLayers / other required JS.
As for where to have the OpenLayers code, I would like to have our own copy which we can keep up-to-date as possible. It would not be good to reference the OpenLayers.js directly from OpenLayers or OSM, since those will get changed as others see fit. It could be that some change will break our extension. When we do update our copy of OpenLayers.js, we can test it with our extension and make sure everything is okay.
Yes, this goes without saying. Nothing deployed on Wikimedia will be referencing 3rd party JavaScript as the current slippyMap extension is doing both for JS and for .png images.
Anyway, in the next few days and over this upcoming weekend, I can hack more at the code where we integrate OpenLayers and MediaWiki. I can provide them as patches or if I can get svn access to the extensions part of the MediaWiki svn, then I can integrate code myself.
Please get a SVN account, send an e-mail to wikitech-l@lists.wikimedia.org / brion@wikimedia.org with your ssh public key, desired username and a note that you'll be working on this.
This also goes for other interested parties, 2 of which I've given these instructions already, and anyone else on this list who wants to hack this too.
Aude wrote:
I would like to test if a user has JavaScript enabled, which can be done with an Ajax call or other way. If they don't, then don't load all the external JavaScript, so as to keep the code lightweight and fast. If the user does have JavaScript enabled, then load the map.js script. Depending on the mode selected, the OSM portion of the js can be loaded, or the WorldWind portion, or other portion.
Just add it as <script src="whatever/map.js"></script> If they don't have javascript enabled, they won't load it.
You can load the secondary ones from map.js by using importScriptURI() or simply add more <script src="">, as the cost is negligible, just one line.
On Wed, Apr 8, 2009 at 10:37 AM, Platonides platonides@gmail.com wrote:
Aude wrote:
I would like to test if a user has JavaScript enabled, which can be done with an Ajax call or other way. If they don't, then don't load all the external JavaScript, so as to keep the code lightweight and fast. If the user does have JavaScript enabled, then load the map.js script. Depending on the mode selected, the OSM portion of the js can be loaded, or the WorldWind portion, or other portion.
Just add it as <script src="whatever/map.js"></script> If they don't have javascript enabled, they won't load it.
You can load the secondary ones from map.js by using importScriptURI() or simply add more <script src="">, as the cost is negligible, just one line.
I wasn't 100% sure, but know that the amount of JS being loaded needs to be minimized and optimized -- even for users that do have JavaScript. Linking to external JS files is the best way to go, with minimal amounts of JS placed inline by the parser.
-Kate
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
2009/4/8 Aude aude.wiki@gmail.com
On Wed, Apr 8, 2009 at 10:37 AM, Platonides platonides@gmail.com wrote:
Aude wrote:
I would like to test if a user has JavaScript enabled, which can be done with an Ajax call or other way. If they don't, then don't load all the external JavaScript, so as to keep the code lightweight and fast. If the user does have JavaScript enabled, then load the map.js script. Depending on the mode selected, the OSM portion of the js can be loaded, or the WorldWind portion, or other portion.
Just add it as <script src="whatever/map.js"></script> If they don't have javascript enabled, they won't load it.
You can load the secondary ones from map.js by using importScriptURI() or simply add more <script src="">, as the cost is negligible, just one line.
I wasn't 100% sure, but know that the amount of JS being loaded needs to be minimized and optimized -- even for users that do have JavaScript. Linking to external JS files is the best way to go, with minimal amounts of JS placed inline by the parser.
We might want to build our own OpenLayers, by not including some of the exotic modules (like support for commercial maps, WFS, etc) to reduce its size. And we should host it on a server that supports dynamic compression of static files (which the normal WMF servers do not, since its done in PHP).
I'm not sure whether it's already possible to load parts of OpenLayers on demand, e.g. in the case where we decide to load Google maps instead of OSM maps.
Regards,
jens
On Wed, Apr 8, 2009 at 11:32 AM, Jens Frank jens.l.frank@googlemail.comwrote:
We might want to build our own OpenLayers, by not including some of the exotic modules (like support for commercial maps, WFS, etc) to reduce its size. And we should host it on a server that supports dynamic compression of static files (which the normal WMF servers do not, since its done in PHP).
I'm not sure whether it's already possible to load parts of OpenLayers on demand, e.g. in the case where we decide to load Google maps instead of OSM maps.
A patch can be submitted to OpenLayers to support different mode options, to load only some JS if only some map modes are supported on a particular website.
-Kate
Regards,
jens
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
On Wed, Apr 8, 2009 at 12:01 PM, Aude aude.wiki@gmail.com wrote:
On Wed, Apr 8, 2009 at 11:32 AM, Jens Frank jens.l.frank@googlemail.comwrote:
We might want to build our own OpenLayers, by not including some of the exotic modules (like support for commercial maps, WFS, etc) to reduce its size. And we should host it on a server that supports dynamic compression of static files (which the normal WMF servers do not, since its done in PHP).
I'm not sure whether it's already possible to load parts of OpenLayers on demand, e.g. in the case where we decide to load Google maps instead of OSM maps.
A patch can be submitted to OpenLayers to support different mode options, to load only some JS if only some map modes are supported on a particular website.
We can use OpenLayers Build Profiles to generate a single js file that includes just the portions we need. I can take a more detailed look at this, see if it works as-is to meet our needs. Or we can submit improvements to that portion of the main OpenLayers code, if needed.
http://trac.openlayers.org/wiki/Profiles
-Kate
-Kate
Regards,
jens
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
I sent out a message to the OpenLayers people. If there are some parts of the OpenLayers code that don't quite meet our needs, I think they can help and/or we can submit changes to the code.
http://openlayers.org/pipermail/dev/2009-April/004723.html
-Kate
So we're working with SlippyMaps and OpenLayers. Anyone opposed to Google Maps? ________________________________________ From: maps-l-bounces@lists.wikimedia.org [maps-l-bounces@lists.wikimedia.org] On Behalf Of Aude [aude.wiki@gmail.com] Sent: Wednesday, April 08, 2009 12:13 PM To: Map integration Subject: Re: [Maps-l] What's being done and what needs doing?
On Wed, Apr 8, 2009 at 12:01 PM, Aude <aude.wiki@gmail.commailto:aude.wiki@gmail.com> wrote:
On Wed, Apr 8, 2009 at 11:32 AM, Jens Frank <jens.l.frank@googlemail.commailto:jens.l.frank@googlemail.com> wrote:
We might want to build our own OpenLayers, by not including some of the exotic modules (like support for commercial maps, WFS, etc) to reduce its size. And we should host it on a server that supports dynamic compression of static files (which the normal WMF servers do not, since its done in PHP).
I'm not sure whether it's already possible to load parts of OpenLayers on demand, e.g. in the case where we decide to load Google maps instead of OSM maps.
A patch can be submitted to OpenLayers to support different mode options, to load only some JS if only some map modes are supported on a particular website.
We can use OpenLayers Build Profiles to generate a single js file that includes just the portions we need. I can take a more detailed look at this, see if it works as-is to meet our needs. Or we can submit improvements to that portion of the main OpenLayers code, if needed.
http://trac.openlayers.org/wiki/Profiles
-Kate
-Kate
Regards,
jens
_______________________________________________ Maps-l mailing list Maps-l@lists.wikimedia.orgmailto:Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
2009/4/8 Ryan, Christopher M RyanCM@battelle.org
So we're working with SlippyMaps and OpenLayers. Anyone opposed to Google Maps?
Yes. Google isn't free.
Jens
On Wed, Apr 8, 2009 at 12:47 PM, Ryan, Christopher M RyanCM@battelle.orgwrote:
So we're working with SlippyMaps and OpenLayers. Anyone opposed to Google Maps?
Due to copyright issues, it's not possible to embed Google Maps on anywhere on Wikipedia or other Wikimedia projects.
http://www.google.com/permissions/geoguidelines.html
There are some existing MediaWiki extensions that work with Google Maps.
-Kate
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l