Extension:Maps/Future

Future work on Maps

Feel free to add new feature requests to the new proposals section. Please review the turned down proposals first. Adding your vote or objection to proposals will help determining which ones will get the priority. If you have any comments on the already accepted or turned down proposals, please add them to the talk page, but refer from adding them to the lists themselves.

Accepted to-do's
Items that have strikethrough have been completed/fixed.

New features

 * Backwards compatibility by using the $wgGoogleMapsKey when this one is set and $egGoogleMapsKey isn't.


 * Hook for Admin Links


 * A true aliasing system for service names


 * Centre parameter, that will allow you to set a custom map centre (different from the place where the marker will be put)


 * Popups for the markers: title and label parameters to determine the pop-up contents


 * Change the OpenLayers control handling. Make it accept all (36) OL controls by using eval instead of a switch statement in the JS.


 * 'physical' in the map type control of Google Maps maps when this map type is set


 * Multi geocoder support: creation of a system that allows to easilly add new geocoders to the extension, and allows the user to set a default one in the settings file, and also add a parameter for this selection to the geocoding functions


 * Yahoo! geocoder


 * Open Street Maps support for OpenLayers

Refactoring

 * Refactor MapsBaseMap and all it's child classes. This will vastly increase code centralization and decrease redundant logic and definitions.


 * Major rewrite of the Google Maps and Yahoo! Maps code. The parser function classes should only print a call to a JS function with all needed parameters, which then does all the logic and creates the map.

Bug fixes

 * Issue causing aliases for service names getting turned into the default service since they are not in the allowed services list

New features

 * Making the map type controls configurable for Google Maps and Yahoo! Maps


 * Aliasing system for map property parameters (like currently the hard-coded center which changes into centre)


 * display_points (and display_addresses) parser function(s). This will enable you to display multiple markers on one map, and will be particularly useful together with custom base layers in OpenLayers.

New features

 * Ability to define custom base layers (with images) for OpenLayers. example, example


 * Bing Maps (formerly called Virtual Earth) support


 * Display_route parser function, to auto generate routes


 * KML support for Google Earth


 * KML support for Open Layers


 * Google Maps moon/mars/skye support (2D)


 * Google Earth moon/mars/skye support (3D)


 * Street view support for Google Maps

New proposals

 * Add some kind of custom route tool, like done by the Google Maps extension? vid - Jeroen De Dauw 01:30, 22 July 2009 (UTC)


 * Add based syntaxis for the parser functions - Jeroen De Dauw 22:48, 23 July 2009 (UTC)


 * General zoom level system: one zoom level scale for all services. This would make it easier for users to get the hang of the zoom levels, and would not affect the zoom when changing the service parameter. However, this would not allow backward compatibility, by affecting the zoom of all maps using one of the current zoom scales. Even if this is a good idea, there needs to be voted for the scale system to use. - Jeroen De Dauw 01:43, 24 July 2009 (UTC)