Grants:IEG/Wikimaps Atlas

This project is funded by an Individual Engagement Grant

status: selected

project:

Wikimaps Atlas

project contact:

hugo.lpzgmail.com, arun.planemadgmail.com

participants:

join this idea!

grantees: User:Yug,User:planemad,
volunteers: User:Keeby101, User:commons_sibi, User:Guerillero, User:Yuvipanda
advisors: user:Kolossos, User:Susannaanas, User:Ilario

summary:

Systematically generate a free atlas of the world with well coded SVG files

engagement target:

Wikipedia, Commons, Wikidata, (+Wikivoyage?)

strategic priority:

Improving Quality, Encourage Innovation

total amount requested:

$12,500

2013 round 2

Project idea

Maps are an invaluable visual aid to localize encyclopedic objects and events, understand spatial relationships and dynamics. As such, encyclopedias have always been accompanied by encyclopedic maps, either in-text, or in additional atlases. Today, maps are used in thousands of Wikipedia articles as embedded static images or through the WikiMiniAtlas plugin which provides an interactive slippy map. While the WikiMiniAtlas provide a view of OSM -a traffic oriented website-, static locator maps provide superior context as they have been individually designed to illustrate an encyclopedic topic in a standardized cartographic form. The current mapmaking workflow by volunteers is highly manual resulting in large pool of locator and other base maps in varying styles, accuracy and formats. This "hand made" approach is unable to satisfy the huge demand of updated and standardized maps in the Wikimedia environment.

Problem: Making maps for Wikipedia is currently a highly manual process resulting in a poor supply of maps that is unable to meet the demand of accurate and updated maps for various projects and languages.

Solution: Automate the creation of SVG base maps in a well researched cartographic style using the latest and most accurate open geographic data.

Project goals

Objectives : elegant encyclopedic maps
Building upon well established best practices (colorschemes) and handmade workflows from the Wikipedia Map Workshops, following the Wikipedia:Kartenwerkstatt/Positionskarten project, the Wiki Atlas (2013) project will be a centralized, automatized, systematic way to produce the most needed and most difficult to create base layers. It will provide volunteer cartographers and graphists a complete and consistent set of high quality base maps, so they may focus on designing semantics layers representing and explaining a given encyclopedic topic. Following clean and standard graphic guidelines, we want these maps to be elegant, consistent, readable, accessible to the reader, alltogether building a graphical identity and feel for Wikipedia and for maps on Wikipedia. We want these maps to be standalone maps, able to be directly embedded in any MediaWiki wiki page, but also to be easy to edit, print, and spread inside and outside Wikipedia. We also want these maps to be well coded SVG documents, with some hidden meta-data serving as anchors, so data and interaction may be bidden to them.

How: automatizing the cartographer's workflow for the basemaps creation
The central concept is to greatly simplify the mapmaking workflow by separating (1.) the map-data script-processing to generate accurate and elegant background, from (2.) the process of map design : selecting relevant encyclopedic items and events to display and explain upon a geographic area. The first part can be automatized. Single GIS files are between 50MB and 5GB and take minutes to loads in human friendly softwares. Each individual graphist has to process these heavy data files with a script or tedious handwork before being able to move to the graphic design step. The job of the project members is to provide a system which will crop, slice, simplify, filter, stylize these huge GIS files in order to provide a final SVG background of about 100~500KB each which will be fine for the end users, his/her web browser, and the WMF's servers.

System: sources and main requirements
The system will reuse existing and notable graphic guidelines (best practices), various available online open GIS data and layers from providers like Natural Earth, OpenStreetMap, NASA, GADM.org etc (public domain, CC-by-sa-3.0), as well as web oriented data visualization technologies (D3js, topojson). The system will keep metadata allowing to categorize maps and conserve traces of geolocalisation, so when on commons, it in effect create the first systematic, complete, and consistent atlas of free and open maps which can be constantly updated by the underlying data. Contrary to the handmade Wikipedia:Kartenwerkstatt/Positionskarten project who hardly move above the 200 countries maps after 3 years of work, the Wikimaps Atlas project will be able to generates all the set of target maps for countries, provinces, subunits, and custom areas under request. This set being about 5.000 basemaps.

Project plan

Scope:

Scope and activities

Wikipedia maps types & best practices

Abstract

While well established best maps making practices are a clear progress over the patchwork of diverging users provided maps, these styles need to be reviewed and strengthened to be in accordance with the rules and principles of academic literature on map design, color blindness, and print-friendliness. With a support from a grant, we expect to take up this review (10 days * 8h).

Details

Hide for summarization

Over 7 years, volunteer cartographers within the Graphic_labs' Map_Workshops designed or improved +6000 maps, gathering an extensive on-field experience on maps making for Wikipedia. Naturally, some toolkits were exchanged, discussed, most frequent wikimaps types have been identified and a hand of Wikipedia Maps best practices (aka Wikipedia map conventions, map guidelines, map templates, map toolkits) have been consolidated. The break down is as follows: a: Most of the times, Wikipedia maps define in a visual and user friendly way the geolocalisation and geographic context of a Wikipedia entry. For these, we use labels-less location_maps and relief_location_maps (for points), locator_maps (for areas), and orthographic_maps (for countries). b: At other times, Wikipedia maps build upon previous layers to define in a visual and user-friendly way some known phenomenons or dynamics. Gradient_maps (for statistics), area_maps (for multiple subjects), historical_maps (for historic events), and technical_maps (for urbanism and architecture). c. Lastly, the Exchange_maps are used to define the urban areas and roads networks of a region with few selected items (a simplification of OSM with a specific stylesheet). Experience shows that these types represent about 95% of all maps requested by editors on the Map workshops. Extreme examples are files such as file:France_location_map.svg, used in each of the 36,000 articles about French towns on the French Wikipedia alone. Because the most frequently used and requested wikimaps are based on the location_maps and relief_maps, we wish to focus our energies on these two types of base maps. (a) Base maps (best practices): location_maps and relief_location_maps are consistent base maps for online encyclopedic cartographic illustration. Their conception is aligned, and they are the foundation of Wikipedia's higher quality map making. They are also the most difficult types to create since large GIS files need to be processed. They also are the easiest types to automatize since no creative work is requested. location_map (2009 guidelines) relief_location_map locator_map: USA_location_map + focus and red on Hawaii (2009 guidelines) _location_map.svg (2009 guidelines) _relief_location_map _locator_map.svg : India_location_map + focus and red on Maharashtra (2009 scheme) _(orthographic_projection).svg location_map (2009 guidelines) _relief_location_map+color_ramp (2009 guidelines) location_map (2009 guidelines) _relief_location_map (2009 guidelines) (b) Advanced encyclopedic map : base maps are used as tools to create more advanced maps with encyclopedic layers. There, a graphic designer (not necessarily cartographer !) enlighten the base map with encyclopedic facts. relief_map : relief map + added semantic layers (areas, icons, labels, legend) areas_map : relief map + added semantic layers (areas, icons, labels, legend) areas_map : relief map + added semantic layers (areas, icons, labels, legend) areas_map : relief map + added semantic layers (areas, icons, labels, legend) areas_map : relief map + added semantic layers (areas, icons, labels, legend) location_map + added semantic layers (historic boundary, icons, labels) historical_map : relief_map + added semantic layers (areas, icons, labels, legend) exhange_map : relief_map + added semantic layers (roads, areas, icons, labels, legend) exhange_map : relief_map + added semantic layers (roads, icons, labels, legend) gradiant_map : location_map + added semantic layers (color for values + legend) historical_map:  : location_map + added semantic layers (areas, icons, labels, legend) (c) Outdated maps: Thousands in-articles maps are nor up to the quality and accessibility requested by new web usages, nor event consistent between them. We wish to provide a comprehensive, complete, consistent set of base maps to ease their replacement by high quality maps. relief map, NOT up to 2009 guidelines. locator_map, NOT up to 2009 guidelines. locator_map, NOT up to 2009 guidelines. Historical_maps NOT up to 2009 guidelines. gradiant_map with population data. relief_map, NOT up to 2009 guidelines. gradiant_map, NOT up to 2009 guidelines. areas_map, NOT up to 2009 guidelines.

Current issues in making hand made high quality maps

Abstract

We now have access to the needed map styles, GIS data, know-how, technologies (makefile, gdal, topojson, nodejs, D3js). With the support of a IEG grant, we wish to automatize the cartographers' workflow and centralize it.

Details

Hide for summarization

The current situation is not, however, this nice. Workflow: while a simple representation of available GIS data, the base layers are the most difficult to generate. The cartographer has to download heavy GIS satelite images of 50MB up to 5GB. He has to master complex GIS sofware --which needs days to weeks of practice to achieve--, and a lot of time to produce his first suitable base map. Despite available tutorials, only a dozen of users currently have this know-how, and most of them just do a handful of (great) maps a year. Quality & consistency: Likely because of these difficulties and the scarcity of suitable base maps, editors of Wikipedia use various other low quality base layers together with random graphics conventions, colors, icons sets, to generate poor quality, mismatching maps into encyclopedic articles. Such maps look amateur and may downgrade the article credibility. On the other hand, the Map worshops guidelines and workflow are a guaranty of elegance and quality. Features articles' editors love to request such custom made maps. Feature article Mauna_Loa is a such success story. Coverage & reach: world regions with high income and active Wikipedia communities such Europe, the USA, tend to have a correct map coverage with countries [L0], provinces [L1] and subdivisions [L2] levels provided. Other world regions such Eastern Europe, Latin Americas, Africa, Asia with lower incomes tend to have very poor coverage, with only the country [L0] level provided thanks to the help of German or western cartographers. Maintenance: Wikipedia volunteers have complained for years that hand made workflows and approach is suicidal. Cutting the connection between source GIS data and the end files is counter-productive. Various centered systems have been discussed without any implementation.

Project objectives

Produced stand alone maps should be all human friendly, color-blinds friendly, and machine readable, thus allowing later on binding with available data (Wikidata in mind). Both side are challenging. While there is a global agreement among Wikipedia cartographers over these location_map and relief_map stylesheets, they are still some sensible issues under negotiation between the communities (de, fr, es, en, mainly). The question of color blindness also need to be refreshed by inputs from academic knowledge. In coming months, we wish to increase awareness about these academic literature, synchronize the views of influencial Wikipedia cartographers : STyx, Sting, Séhmur, NordNordWest, TUBS, Thoroe, Bourrichon, Flappiefh, MapMaster, Ikonact,... wish to lead a new cleanup and upgrade for these styles all together. Kickstarted by the present grant, this upgraded set of wikimaps guidelines would create a solid basis for further consistency and later wikimaps projects.

• 
  (English)
• 
  (English)

Action	Effect for web actors (cartographers, editors, programmers)	Effect for the readers	Effect on Wikipedia	Tags
1. use map guidelines	smooth integration in current WP maps practices and identity	user-centered design, elegance, efficiency, color-blind friendly, consistency, readability	increase WP graphic identity	#quality #accessibility
2. work on all regions	high quality base maps available for all regions of the world, greatly ease cartographers' capability to create advanced encyclopedic maps	all world regions systematically covered	increase reach	#reach #quality #standardization
3. work programmatically	systematically well structured output files, machine friendly, programmers may build apps and interactions upon them	—on WP: none (wikidata?). —outside WP: interactive SVG maps bidden with data	increase graphic consistency	#sustainability #reusability
4. from one central script/system	could be rerun on request to upgrade all maps data/structure/styles at once, increase WP reactivity to events such the creation of a new state (i.e.: South Sudan)	consistency, accuracy	increase WP graphic identity, increase accuracy	#maintenance #sustainability #accuracy
5. generate the bases location_maps & relief_maps	high quality base maps available, cartographer can focus on designing the semantic layers	maps with sharper design and high quality backgrounds	increase graphic quality	#quality

Tools, technologies, and techniques

Mapmaking workflow

We propose the development of a system to assist Wikipedia cartographers in doing the hardest part : convert huge GIS data file into elegant base maps (①>➊➋➌➍➎➏), that users with simple graphic skills can reuse as background to create elegant encyclopedic maps (②>➐➑). The first map shows how a such relief background is used, upon which semantic layers were added using a vector editor and relatively basic graphic skills.

• 
  Each map is the the result of the piling up of separated layers. Each layer is one major step within the workflow of encyclopedic map making.
• 
  ①: Layers from GIS data: ➊. NASA topographic data ; ➋. Shaded relief (processed from ➊); ➌. NaturalEarth political divisions and watersways; ➍. OSM roads and urban areas ; ➎. Reprojection (if needed); ➏. Layers' pilling & styling in vector editor;
  ②: Additional layers to design : ➐. Semantics: legends, icons, scale, north arrow, localizator, topographic legend are drag&drop-added, then selected & edited to create the needed toolbox; ➑. Addition of shapes & icons upon the map to represent the selected encyclopedic informations.
• 
  ①: Layers from GIS data : Administrative basemap, ②: Semantics: as previous.

Input parameters & data mining

Designing base maps such location_map and relief_map of a given area needs :

The name of our subject, such "India"	"India_Tamil_Nadu"
WNES bounding box of the area of interest	W:67⁰0", N37⁰5", E99⁰0", S5⁰0" (in decimal degrees)
Satellite based GIS data to crop, simplify, process. style, such administratives shapes or relief elevation	files between 50MB and 10GB
A system & workflow treating these data depending on these parameters	makefile with various GIS libraries

GIS data for administrative areas are available from Gadm.org. High quality relief GIS data are available from various space agencies, mainly the NASA. The gadm.org GIS administrative data provide the English name of each item. The bounding boxes and name can be obtained by various ways: by hand, by a crawler over a existing location_map, or by the processing of available GIS data. This last approach is well advanced, more massive, and the most promising. It also needs, however, to be completed so historical areas of interest can also be covered.

The workflow and script

The core project will be to generate a smooth workflow and script. Both Ikonact as well as Yug already made proofs of concepts for such an approach on Wikipedia map making. Given access to the subjects' names and WNES bounding boxes through data mining or processing, we wish to develop further a script approach in order to automize the workflow of map making, this to design and generate both location_maps as well as relief_maps. Parameters would allow the generation of different maps. It will be run in console, something like :

$make -context: "India" -focus: "Tamil_Nadu" -boundingbox: "67.0 37.5 99.0 5.0" > India_Tamil_Nadu_location_map_(2013).svg > India_Tamil_Nadu_relief_location_map_(2013).svg

This will be looped over all target items for which we have a name and a WNES bounding box, producing as many maps. Ryan Kaldari (WMF usability team) suggested us to use the Wikimedia lab's environment to share this tool with the community. Indeed, with:

1. folders with about 10Go of space (admin)
2. a console to install libraries such curl, unzip, gdal, nodejs, topojson, and some others (admin)
3. a console to run the command (public)
4. an UI / web interface

the system could be shared with other netizens.

Output maps by the team

Processing the GIS data can provide us with the much wanted names and WNES bounding boxes. Runing this data with the system we wish to build, we can kickstart production, generating base maps for:

1. Countries (level L-0) : data available for all countries.
2. provinces (level L-1) : data available for all countries,
3. subdivisions (level L-2): data available for all countries but 10,

This make about 200 countries, near 3000 provinces, and ~8000 subdivisions maps. This output and upload to commons would de facto create a real, consistent Wiki Atlas up to 2013/2014's best practices. This massive set of base maps to reuse as background for more advanced encyclopedic maps will also help to set upward the quality expectancy for Wikipedia maps. Both administrative maps (location_map) and relief maps (relief_location_map) will be generated for each area.

• 
  World countries level (L0) GIS data are available; bounding boxes have been calculated for each country, see here.
• 
  Worldwide provinces level (L1) GIS data are available; bounding boxes can be calculated for each item.
• 
  Worldwide subdivisions level (L2) GIS data are available; bounding boxes can be calculated for each item.

Output maps on demand

Doing so, the project also wish to publish a human-friendly version of its scripts to allow netizens and wikipedia editors to generate location_map and relief_map with wikimaps' styles on demand. The input needed will be a given geo-area, defined by its West, North, East, South borders in decimal degrees, and then name of the area of interest. The makefile script would run locally in a console, and may be the backend of a web apps for wikimaps on demand. This script is a core element to ease map making for historic areas, or international dynamics which are a notable part of an encyclopedia.

Budget:

$12,500 (per the table below).

Overview

The core team will consist of User:Yug and User:Planemad (see Grants:IEG/Wikimaps_Atlas#Participant.28s.29 for details) who will undertake the main research, design and development work over a period of 3 months.

Budget includes provision for Yug to travel to India, so the reunited team may serious work for 2~3 months together while taking advantage of the lower cost of living.

Planemad & Yug have been key members in the history of wikipedia's maps and map styles, both have experience with interactive SVG maps & wikidata, The team already collaborated positively on interactive map design.

Budget breakdown

Item	Description	Units	Total (USD)
Team expenses:
Research and Design	480 hours	480 * $10/hr	4800
Development	240 hours	240 * $10/hr	2400
Travel expenses	Roundtrip airfare+train from Paris - Dharamsala, India[1]	1	1000
Supporting expenses:
Books	Synchronize the basic concepts and metalanguage within the community of wiki cartographers	~12	300
Postal fees	Mainly for books	12	200
External freelancers	90 hours. External consultants to kickstart through some peripheral technologies and difficulties. Consulting experts from the Open cartography community.	60 * $30/hr	1800
Additions following's WMF's IEG representative's comments on the project.
Wikip/median's freelancers	Modules we must provide (We currently don't have these competences ourselves, we are looking for WM volunteers/freelancers) : 1. Sysadmin deployment of our system on Wikimedia Lab ; 2. Add automatic upload of generated maps to commons (Upload_Wizard integration?).	$1000	1000
Acceptance	Technology acceptance & Community management through 3 more months (summer 2014)	2 * 50h * $10/hr	1000
Total: 12.500 (updated on 2013/12/10)

External experts we may want to consult

• Mike Bostock : creator of D3js & Topojson, data visualization scientist from Standford university, now working for the New York Times, expert in web cartography. Need for topojson optimisation. See also http://bl.ocks.org/mbostock
• Michal Migurski : open source GIS expert, creator of "Vector_tiles". For OSM compatibility. See also http://stamen.com/maps
• Ikonact : created a Matlab script to generate topographic maps for Wikipedia. For general advices. See https://fr.wikipedia.org/wiki/Utilisateur:Ikonact/Cartographie
• Arthur Gunn : made a D3js gradient map generator based on data submitions. For gradient maps. See http://gunnmap.herokuapp.com
• <Wikipedian_name_to_clarify> : wikimedia lab's server, installation of our system (data, scripts, UI). Fixes (?)
• <Wikipedian_name_to_clarify> : wikimedia lab's server, automatic upload of generated files to Wikimedia commons, with relevant categorization, template, metadata.

Timeline:

• Duration: 3 months
• Start: 1 March 2014
• End (soft): 31 May 2014
• End (hard): 31 August 2014(?)

March - Planning and Research

• Guidelines step 1: checking
  • Identify and categorize the different type of basemap requirements for use in wikimedia projects
  • Fix file naming scheme conventions
  • Comparative analysis of existing map styles from various sources
  • Research of cartographic guidelines from academic literature (Brewer & co)
  • Identify relevant GIS data sources used by wikicartographers
• Pre-developement
  • Github synchronisation between members for scripts (GIS sources synchronisation done offline)
  • Synchronisation of developement compentences between members
  • Monitoring of available technologies
  • Exploring needs for wikidata-compatible data-binding
  • Exploring structures, meta-data, and quality of selected GIS data sources
  • WNESdatabase: Prepare total list of maps to be generated, WNES bounding boxes + name
  • WNESdatabase hand-correction : cases such France, USA with fragmented territories

April - Cartographic conventions and community consensus

• Guidelines step 2: push (agile developement)
  • Improve style guide considering accessiblity for people with visual deficiencies
  • Define new Wikimaps Atlas cartographic conventions
  • Create prototype maps illustrating new guidelines
  • Publish the cartographic conventions for community feedback
  • Build community consensus and improve the conventions at the Graphic Lab
• Back-end scripts: Local development, demos & community feedback
  • Build a repository of open GIS data sources for map generation (locally)
  • Create & optimize makefiles to generate maps with new convention
  • Create & optimize D3js script to generate maps with new convention
  • Optimize Topojson command for better quality/weight rate (consultant: M. Bostock)
  • Output of satisfying standalone SVG (locally)

May -- Scaling up to the cloud (Wikilab) & community feedback

• Back-end server : Move to Wikilab:
  • Install dependencies : NPM, Make, Topojson, gdal, ...
  • Upload relevant GIS data files
  • Set up a NodeJS server and others needs
  • Prepare batch files to automatically generate required maps from data sources using the new conventions
• Documentation on:
  • The system structure / workflow
  • How to download & run the system locally
  • How to increment the system with new code / plugins for futur needs.
• Front-end: Design and build a basic Wikimaps Atlas frontend tool for users:
  • to search and browse the generated map collection
  • to request a custom map with a set of parameters :
    • UI > Input: name, WNES geoocoordinates, layers, topographic thresolds.
    • UI + Back-end: generate suitable makefile
    • Back-end : processing data on server (as usual)
    • Back-end + UI : propose file to download (or to send to commons?)
  • to download the script to run locally

Out: -- actions which would be better to let other wikipedians to do them

• Upload to commons: all the files which have to be upload to Commons, with relevant template and using meta-data to put them into relevant categories.

Deliverables:

• Research documentation of Wikimaps Cartographic conventions on wiki
• Publication of makefiles, datasource locations and automation scripts for map generation on github
• Comprehensive collection of standardised basemaps upto administrative level 3 for the world in SVG format

Intended impact:

Target audience

1. Wikipedia readers, who daily view wikipedia maps, will have a more consistent experience due to higher quality maps, for all regions of the world without geographic segregation.
   
2. Wikipedia cartographers, who will reuse and edit these base maps to add encyclopedic layers to them. The project will greatly ease their work, increase their ability to satisfy map requests, and set upward the quality of maps generated by the map workshops.
3. Wikipedia editors, aware that the speed and quality of map creations on the map workshops has increased, will request more of these maps for the articles they are editing,
4. Smartphone apps and websites developers within and outside Wikipedia/Wikidata, who will be able to bind data to such well structured stand alone maps, in order to generate interactive data visualizations.

Fit with strategy

1. Improving Quality, by tapping in the lagging graphic side of Wikipedia. Each item produced should be of high quality. Quantitatively, the sum of these files for all regions of the world with the initial dump of all L0, L1, L2 administrative areas maps will be an helpful tool to illustrate articles of remote areas.
2. Encouraging Innovation, having free base maps available for all major administrative regions in a machine readable vector format opens up new possibilities for data driven documents (See Wiki-Atlas hack[2])
3. Increasing reach: for the first time, maps will be generated for all areas of the world, without regards for the demographic size and activity of their wiki community within Wikimedia .

Sustainability

The value of the project is actually not in "doing 5000 maps" or more, the value is in "doing all of them exactly the same way", so that they first share a same high quality and human friendly look and feel, but also the same machine readable code, so data and Wikidata's data can be plugged in on all of them. Doing them programmatically from a centered point is also critical, so we could roll out the whole again when the underlying data change, and it will! The creation of South Sudan generated the need to redraw about 600 maps of Commons. Same when our graphic guideline needs to be upgraded to satisfy new needs such as accessibility. An update of all of these base maps (or even derivative maps if we are smart !) could be done quickly in a systematic way.

Measures of success

By mid project (+3months)

• Smooth workflow: The project should publish a system allowing a radically smoother workflow to generate these base maps. Anyone should be able to generate a relief_map or location_map within one hour the first time he/she tries, and within 10 minutes thereafter.
• Bounding boxes dataset (BBD): a dataset of item names and their WNES bounding boxes should be published so other projects such as Grants:IEG/ShareMap could reuse them as well.
• Project initial map dump: Using the BBD, the project should generate suitable maps for all L0 (countries), L1 (provinces), and hopefully L2 (subdivisions) levels. We expect this to make about 3 to 10 thousands areas, and 6 to 20 thousands files of location & relief_location maps pairs.
• Centralized: As much as possible, the system should be able to rerun on these thousands of items from the BBD to (re)generate as many maps, which allow us to easily upgrade/update the whole set of thousands of maps.
• End users: Eventually, with time, the main measure of success is to see end users such as wikipedia's and external cartographers, as well as developers and articles editors reuse these standalone base maps to generate more advanced maps with other encyclopedic layers.

By end of project (+6months)

(Added following early December's comments)

• Wikis: Have our maps used in 12 wikis
• Data-binding: having 3 different approaches of data-binded maps working (ex1: multilangual maps thanks to wikidata).

Participant(s)

• Arun Ganesh (en:User:Planemad, India) is an open source information artist with a large number of contributions to Wikimedia Commons and the OpenStreetMap Project. Arun created the Wiki-atlas hack at the Amsterdam Hackathon 2013 to explore client side rendering of vector maps. He is an active member of the India OSM community and conducts cartography workshops at academic institutions in India.
• Hugo Lopez (en:User:Yug, France) is a PhD candidate in language teaching & e-learning, part-time professional cartographer. Hugo started the Graphic Lab (fr, en) and several Map Workshops (fr:2006, en:2009), maintains the WikiProject_Maps/Conventions, and recently used new web oriented technologies to created makefile/D3js a demo workflow with which one can generate Wikidata-compatible location_maps and relief_location_maps for Wikipedia & others. An other of his D3js demos show how to import classes of OSM items into a SVG.

Arun Ganesh & Hugo Lopez are hunger to have a grant allowing them to take the 3 months off regular work needed to kickstart this project.

Discussion

Community Notification:

Please paste a link to where the relevant communities have been notified of this proposal, and to any other relevant community discussions, here:

• Yug & EdwardLane, The Cartographers of WikiProject Maps (2012-04-30), Wikipedia Signpost -- interview about maps on Wikipedia, the Maps_Workshop.
• Notified the Indian Community on wikimediaIndia-l Oct 18
• Notified Maps-l Oct 18 (IST)
• Notified German Map workshop Oct 19
  • Discussion: German map workshop blog (in German)
• Notified French Map workshop Oct 19
• Notified: English Map workshop Oct 19
  • Notified: WikiProject_Maps, redirect toward EMW. Oct 19
  • Notified: Wikipedia_talk:Graphics_Lab, redirect toward EMW. Oct 19
• Notified wikitech-l Oct 19
• Notified Wikidata:Project_chat

Endorsements

Do you think this project should be selected for an Individual Engagement Grant? Please add your name and rationale for endorsing this project in the list below. Other feedback, questions or concerns from community members are also highly valued, but please post them on the talk page of this proposal.

• Awesome. This is a great project. It is exactly as you say: Wikipedians need base maps so that they create their own. You guys have my endorsement. Wereldburger758 (talk) 09:35, 14 October 2013 (UTC) (on Wikimedia commons my name is: citypeek).
• Highly useful and high time to have worked upon. Arun, this confers very well with the idea we were discussing during last October. Upon this fundamental framework, we could build up 'intelligent' and dynamic thematic/semantic maps too by incorporating data elements managed by the wikidata repository in due course. That will yield (almost) real time or dynamic map illustrations on Wikipedia pages and elsewhere. ViswaPrabha (വിശ്വപ്രഭ) (talk) 14:40, 18 October 2013 (UTC)
• As a Wikipedia cartographer I can vouch that this is a much needed project. Currently we have to make each individual map essentially "from scratch" which consumes a lot of labor from our very small pool of cartographers. Existing basemaps that are readily available (notably Google maps and those from ESRI) do not meet Wikimedia's licensing requirements, but the ingredients are out there to make a compatible basemap - as the project outlines. Doing so would free us from having to recreate a basemap for every map and result in maps with a more unified and professional look. -- Wiki-en cartographer Kmusser (talk) 13:54, 19 October 2013 (UTC)
• Awesome and absolutly essential. It would greatly simplify the work! -- Wiki-fr wikicartographer --M0tty (talk) 17:16, 19 October 2013 (UTC)
• This would definitely make it easier to, say, add maps to infoboxes. --Jakob (Scream about the things I've broken) 23:43, 19 October 2013 (UTC)
• Improvement of an important aspect on Wikimedia projects. --Danrok (talk) 01:08, 20 October 2013 (UTC)
• Awesome. Map integration of wikipedia is getting better but this sounds like the step needed to kick it to the next level. I hope this will be open to integration with other projects, especially OSM and wikidata - reusing their tools. data and infrastructure where it's helpful, making your stuff reusable by them too. Good Luck! Filceolaire (talk) 13:29, 20 October 2013 (UTC)
• Visualization of Geographic data needs a good base.--Saehrimnir (talk) 21:00, 20 October 2013 (UTC)
• Very useful as it give a lot of possibilities with direct improvements to articles. Like tears in rain (talk) 07:38, 21 October 2013 (UTC)
• per Kmusser basically. Great feature - much needed. I know for a fact that a lot of work has already gone into this, and I've seen some of the impressive results already. Could cut out a time-consuming stage and introduce some standardisation of look and feel - which is a good thing. Endorse wholeheartedly - and happy to help, too, where possible. There are not many editors contributing to the Map workshop at en (although a few more recently). Time would be far better spent on accuracy and presentation of the relevant data in the informational layers, and enhancing that, than repeated "grunt-work" on backgrounds, and the consequent inconsistencies in approach and result. -- Wiki-en cartographer -- Begoon (talk) 06:30, 22 October 2013 (UTC)
• As some one who tried to improve the district level maps with location text overlays and faced problems due to lack of rectangular projection maps for Andhra Pradesh, India and inadequate support from the Map resources at Wikipedia, I feel this project will be very valuable in improving the maps for Indian states in local languages with potential for dynamic updates. --India cartographer --Arjunaraoc (talk) 10:50, 22 October 2013 (UTC)
• Great project. Finally! a centralized tool to save hours and hours of work in mapping workshop, and to allow everyone to make maps. This will greatly increase our efficiency. ENFIN!... -- Wiki-fr cartographer Bourrichon (talk) 10:54, 22 October 2013 (UTC)
• Excellent plan. Will provide a much needed uniform foundation for many maps, while allowing for future improvements. --Avenue (talk) 11:23, 22 October 2013 (UTC)
• Very nice plan - complete script set based on open sources libraries will be very useful for all Wikipedia Cartographers, also I see outcome of this project useful in conjuction with ShareMap project. -- Sharemap developer Jkan997 (talk) 11:27, 22 October 2013 (UTC)

Note: Being coordinated, Wikimaps Atlas SVGs will contain metadata (Title, WNES geographic bounding boxes) allowing their reuse by Sharemap.org. Yug (talk) 20:06, 22 October 2013 (UTC)

• It's a very useful project. It will result in saving us a lot of time when making or even updating maps! We, map makers, will have much more time to spend on all the Wiki projects. A must-have. --Flappiefh (talk) 16:32, 22 October 2013 (UTC)
• I fully support this project. It is a thoughtful initiative to advance the utilization of available geographic data in the creation of core Wikimedia tasks. Also, it is coordinated well with the Wikimaps project. I am really looking forward to what possibilities are opened through the initiatives! -- Wikimaps project coordinator --Susannaanas (talk) 18:15, 22 October 2013 (UTC)

Note: Being coordinated, Wikimaps Atlas SVGs will contain metadata (Title, WNES geographic bounding boxes) allowing their reuse by the wider Wikimaps project. Yug (talk) 20:06, 22 October 2013 (UTC)

• Being one of the creators of the currently widely used Wiki-standard color scheme for bathymetric, topographic and political maps (the one proposed here), having myself created over 300 new maps, I can testify here how painful and time-consuming map creation is. The local WP cartographic workshops aren't able by far to satisfy all the demands made to them by lack of time while there is a great need of this kind of media to illustrate and ease the understanding of the WP articles. That is why I highly support this initiative of trustful contributors, working on maps for WP for years, which would at last bring to the project the possibility of semi-automated map creation with unified colors as well as even and good quality. Sting (talk) 17:59, 23 October 2013 (UTC)
• As endorsed above by some cartographers unified look on the wikipedia pages is something which is very much needed , at the same time OSM project releases its data in Open Database License (ODBL) , I always wondered why these two projects havent come close .This effort by Yug and Planemad is commendable and I whole heartedly endorse it ,looking forward to see those awesome maps which Planemad had previously done for Indian maps on a large scale :) --Pavithrans (talk) 10:52, 24 October 2013 (UTC)

Note @user:Pavithrans: I made this OSM-D3js experiement which show how to import OSM data into a online SVG. The wider Wikimaps project is all about getting Wikipedia and OSM closer, and upgrading Wikimaps workflow to professional level. Yug (talk) 12:43, 24 October 2013 (UTC)

• I've known Planemad for three years, and I have seen him do some amazing stuff with maps and GPS systems. I think this would be amazing! ----Rsrikanth05 (talk) 14:01, 24 October 2013 (UTC)
• I support this technical initiative. I had the same idea of creation of central layered map when I see those locator maps. Even I support creation of layers for history like depicting empires and growth of cities. Planemad have good experience in cartography, so I trust. -Nizil Shah (talk) 19:14, 24 October 2013 (UTC)
• Thank you for initiated this project.Jayantanth (talk) 21:10, 24 October 2013 (UTC)
• This appears to be an inspired and much needed project in order to improve Wikipedia's strength in the department of allowing editor's to produce quality maps for articles, especially given that many third-party maps are often copyrighted. Any tool that will allow editors to create highly detailed maps, of SVG standards, sounds worthy of consideration. MarcusBritish (talk) 04:15, 25 October 2013 (UTC)
• All the best! a needed project currently. This will definitely improve, the region based Wiki pages. Mokshjuneja (talk) 07:28, 25 October 2013 (UTC)
• The prototype of the multilingual map based on Wikidata data by these guys is one of the greatest showcases of what Wikidata is making possible. The possibility of taking this from prototype to something that is used all over Wikipedia and elsewhere is really exciting for me. The Wikidata development team endorses this proposal. --Lydia Pintscher (WMDE) (talk) 14:26, 25 October 2013 (UTC)
• Looks very promising + trusted contributors. Ayack (talk) 18:24, 25 October 2013 (UTC)
• Looks amazing, hopefully it is approved MADe (talk) 14:12, 30 October 2013 (UTC)
• Hopefully this will be approved. It will increase the mapping competency of Wikipedia manifold. --Tobias1984 (talk) 10:55, 31 October 2013 (UTC)
• Amazing idea. Hopefully it can help improve the reliability of various maps on Wiki projects. Especially Asia & Pacific.--Yhz1221 (talk) 05:29, 28 December 2013 (UTC)

References

• Bostock M., Davies J. (2013). Code as Cartography, The Cartographic Journal, Volume 50, Number 2, May 2013 , pp. 129-135(7)
• Raposo Paulo, Brewer Cynthia A., Stanislawski Lawrence V. (2013). Label and Attribute-Based Topographic Point Thinning, Label and Attribute-Based Topographic Point Thinning
• http://techslides.com/tag/d3/
• The World's Fresh Waters, National Geographic, 2010.
• Young Julia (201?), Accessible Color: The Work of Cynthia Brewer