Now that we have the rudimentary maps tile service in place, we should start looking at more complex use cases, such as showing overlay data on top of the map, e.g. WIWOSM sample which shows a red overlay on top of the tile map. Another use case is to show points of interest (POIs) as an extra layer, or even adding custom controls using code from common.js.

See implementation ideas at extension

Data Layers

We can add GeoJSON/KML/... data to wikipedia articles inside the <map> tag, and have a MW extension convert that tag into the HTML map call.

There are two types of maps - tiles (downloaded by a client-side lib such as Leaflet), and static (e.g. 800x600 South France).

• For tiles, the lib can add layers from URLs - so layer data should be available for direct download as a json blob.
• For the static images, overlay data will be applied to the static image on the server

Open Questions

• How should MW store layer data
• What data structure should the <map> tag use so that it can
  • have more than one layer
  • store different types of data (geojson, topojson, kml) / outlines / points of interest /...
  • be able to reference external resources (e.g. data stored on commons, wikidata)

User Interface Customizations

Leaflet library provides a very flexible interface, and it should be exposed via some hook mechanism to the community to modify maps functionality in a way that feats community's specifics. This is a much more open-ended question - please add what customization use cases the communities might want.

• Ability to select non-WMF base layers - this has some legal (privacy) and stability implications, but as long as the default comes from WMF-controlled servers, it should be OK(?)
• extra tools such as rulers
• customized interactions - custom on click actions, etc

Open Questions

• What is our current client-side hooks mechanism
• The delicate balance between cross-wiki consistency vs per-language/project ability to customize