Grants talk:IEG/Wikimedia Maps Rendering Improvements

Eligibility confirmed, round 2 2015

This Individual Engagement Grant proposal is under review!

We've confirmed your proposal is eligible for round 2 2015 review. Please feel free to ask questions and make changes to this proposal as discussions continue during this community comments period.

The committee's formal review for round 2 2015 begins on 20 October 2015, and grants will be announced in December. See the schedule for more details.

Questions? Contact us.

Pnorman, please add your budget information as soon as possible. Community review has already begun and should include an opportunity to comment on budget request. You will have opportunity to revise your budget as needed, but do get an initial draft in place.

Marti (WMF) (talk) 05:19, 4 October 2015 (UTC)

Community norifications

Hey Pnorman. Thanks for getting in touch with the MediaWiki community regarding maps. I'd encourage you to consider notifying other communities you are hoping to impact with or could benefit from your proposal, like WikiVoyage. It looks like there a similar discussion page regarding map usage on WikiVoyage you can find here. You can also consider looking for communities of editors specializing in map-related work, such as WikiProject Maps on English Wikipedia or Kartenwerkstatt on the German Wikipedia. Let me know if I can help you out with additional notifications. I JethroBT (WMF) (talk) 20:47, 7 October 2015 (UTC)

Disputed borders

I noticed that one of the goals of this proposed project is to better present disputed borders/boundaries with the subtask of noting how such features are tagged in OSM. AFAIK, there is no standard way and certainly not with any level of nuance of disputes that manual maps created for Wikipedia currently show. (See for example: File:India-locator-map-blank.svg)

Pnorman, you may recall the most recent discussion on the OSM Tagging mailing list for reference: [1] —seav (talk) 01:22, 12 October 2015 (UTC)

There is sufficient information in OSM to indicate disputed borders. As an example, you can see that Mapbox Streets gets most disputed areas right, using dashed lines. A country-specific basemap has certain advantages in displaying information relating to that country in that it can concentrate exclusively on the situation as it applies to that country. A worldwide basemap can't do this. Pnorman (talk) 23:11, 23 October 2015 (UTC)

Dear Pnorman, I do not want to see the road names abbreviated. Geraldshields11 (talk) 20:34, 16 October 2015 (UTC)

Unfortunately, there's no cartographic vision for the style yet (phab:T113912). Abbreviating road names is a common tool to reduce space used and something I would consider generally desirable. Pnorman (talk) 23:11, 23 October 2015 (UTC)

More technical details about integration into the Wikimedia Maps setup?

Hello! I'm wondering if you can provide more technical details about where exactly this will live - in the code that powers maps.wikimedia.org? If so, where exactly? Is there explicit support from the Maps team for this? YuviPanda (talk) 23:50, 20 October 2015 (UTC)

It will be part of the stylesheet, which the maps team have not yet given a name. This makes it awkward to refer to it, but it will live in https://github.com/kartotherian/osm-bright.tm2source (or somewhere else if the maps team renames the repo). maps.wikimedia.org consists of a tile server and a style. The tile server is Kartotherian. This work is all part of the style. Yurik (WMF) from the maps team has indicated his support of the proposal. Pnorman (talk) 23:24, 23 October 2015 (UTC)

road names

I am missing an explanation how the road names will be captured. Though I don't think we want all roads in the world to be translated, with the idea of fallback languages I think it is reasonable to have one fallback language for the language of the region of origin and then have all roads in Wikidata. We already have all the roads of citiies of the Netherlands on Wikidata. I would be very disappointed if this solution does not use Wikidata for the names. --Jane023 (talk) 15:30, 25 October 2015 (UTC)

I'm not proposing to do anything with road names except abbreviations. Using different road data sources is beyond the scope of what I think can be tackled reasonably in an IEG, unless the IEG were focused on experimental changes which might not work. 205.250.42.238 06:02, 28 October 2015 (UTC)

Can you please make some documentation promises?

I am not asking for much - but Wikimedia needs more documentation about the state of activities, what has been done, what is not done, and what you are doing.

I would like to request that if this is funded, there is a little casual review of whatever has already been written, and a confirmation that this project tried to review what already existed, and comments from the grant recipient that would be useful for anyone following. There is so much interest in maps that having any outline of things would be useful. Blue Rasberry (talk) 14:25, 6 November 2015 (UTC)

Hello, I thought that if I made a request then I should contribute something also. Please see en:Wikipedia:Outline of maps for Wikipedia. I do not know what should go on a page like this but I want for there to be some listing which is accessible to layman audiences but which help anyone think about development of maps in Wikimedia projects. I started this page. If you find it useful, and you look over it yourself, then feel free to claim it as a grant outcome and evidence of community participation in your project. Blue Rasberry (talk) 15:00, 6 November 2015 (UTC)

I'd agree that the overall documentation for the future of maps at WM is poor, as I haven't found any great either. The component I'm working on, the maps tile rendering service is at mw:Maps. User:Yurik is probably the best person to answer questions on where the maps tile rendering service fits within the overall picture. Pnorman (talk) 22:27, 6 November 2015 (UTC)

Existing name abbreviation code

In case this grant request succeeds and also if other efforts exists I want to ask you to consider basing on and/or improving a small github project I used for the osmapa.pl tiles that provides the name abbreviation mechanism. In its current state it does have has a bunch of problems that need work on, it's the least-effort code to get the job done. It contains a comprehensive (and AFAIK unavailable from anywhere else) input data for the Polish language and a relatively standard set for English and Spanish abbreviations plus minimal sets for 2-3 other languages.

The actual source is C code in a form that can be called by osm2pgsql during import (this predates the lua tagtransform support but is also bound to be faster) which has the limitation that reimports are needed on changes to the abbreviation mechanism. The same code could potentially be called from a PL/PGSQL function. Optimally the input data should be extracted to separate files and code provided to execute the mechanism for more programming languages than just C. Mechanism for language + locale selection based on geography needs to be added, wikimedia's rendering toolchain probably already has that information while osmapa.pl didn't.

Also note that German is going to be tricky because sub-words within compound nouns can be abbreviated.Balrog (talk) 08:44, 13 November 2015 (UTC)

Aggregated feedback from the committee for Wikimedia Maps Rendering Improvements

Scoring criteria (see the rubric for background)	Score 1=weak alignment 10=strong alignment
(A) Impact potential Does it fit with Wikimedia's strategic priorities? Does it have potential for online impact? Can it be sustained, scaled, or adapted elsewhere after the grant ends?	7.4
(B) Innovation and learning Does it take an Innovative approach to solving a key problem? Is the potential impact greater than the risks? Can we measure success?	6.2
(C) Ability to execute Can the scope be accomplished in 6 months? How realistic/efficient is the budget? Do the participants have the necessary skills/experience?	7.6
(D) Community engagement Does it have a specific target community and plan to engage it often? Does it have community support? Does it support diversity?	6.4
Comments from the committee: As a map lover, I must admit that the Wikimedian group of map lovers is rather small. Wikimedia’s map technology trails behind so map lovers tend to prefer other projects. However, our readers have never seemed to mind--I can't recall ever hearing about how horribly people want better maps on Wikipedia, except for the WIkiVoyage team. Though I personally find this strategically important, I’m not sure whether it is a high enough priority for the readers or contributors to warrant funding. This project fits with the priority to improve quality (in this case, of Wikimedia maps). I think there is potential for online impact if this project improves the usability of Wikimedia maps. A high-quality map infrastructure is critical for Wikivoyage, where the "lack of public transport information is a critical issue for acceptance" (though no evidence is presented to support this claim). It has potential applications for Wikipedia and other projects as well. This developer has worked with these tools and these developers (both in and out of the WMF) before and has the support of the community. Though I am unsure whether the approach is innovative, I do think the potential impact is much greater than the risk, and measures of success are easy (i.e. are these newly abbreviated maps used or not?) There are no explicitly defined measures of success. However, as the purpose of the project is to fix deficiencies in the existing tool, it can be assumed that success will be determined by the implementation of the needed fixes. At this point in time, I think both the potential impact and the potential risks are low. He has a clear plan with milestones for making this happen... and relevant experience. Explicit success measures are missing. PNorman, and all endorsers/supporters look like they have the proper experience to get this done. The proposed budget seems commensurate with the scope of work to be performed. The applicant is an experienced developer, and has the necessary skillset to implement the proposed tools. The lead seems very experienced in this area, and I have no concerns that the work would be accomplished in 6 months. However, I think the requested weekly salary is way too high and should be cut. $20-25 an hour is the regular rate for most IEG grantees in the US. There is support from the maps community (it's tiny, though). There is a reasonable degree of community engagement and support. They have buy-in from the WMF maps team which seems required for this project to go anywhere. Given that Wikimedia maps is a fairly new initiative, maybe it's worth experimenting in this area and bringing another skilled individual into the work. Needs 100% support from the WMF Maps team to succeed.

Round 2 2015 decision

This project has not been selected for an Individual Engagement Grant at this time.

We love that you took the chance to creatively improve the Wikimedia movement. The committee has reviewed this proposal and not recommended it for funding, but we hope you'll continue to engage in the program. Please drop by the IdeaLab to share and refine future ideas!

Comments regarding this decision:
Though the committee finds this project strategically important, we would have liked to have seen clearly defined measures for success and more engagement with your target user community in your proposal. The expertise in this idea should be lauded, and we look forward to your future submissions in IEG.

Next steps:

1. Review the feedback provided on your proposal and to ask for any clarifications you need using this talk page.
2. Visit the IdeaLab to continue developing this idea and share any new ideas you may have.
3. To reapply with this project in the future, please make updates based on the feedback provided in this round before resubmitting it for review in a new round.
4. Check the schedule for the next open call to submit proposals - we look forward to helping you apply for a grant in a future round.

Questions? Contact us.