Community Wishlist Survey 2019/Maps

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Community Wishlist Survey 2019

Maps
13 proposals, 199 contributors

Go-previous.svg Editing  •  Miscellaneous Go-next.svg

The survey has closed. Thanks for your participation :)
Here are the Community Wishlist Survey 2019 results!


Show nearby or related articles in maps

Edit proposal/discussion

  • Problem: Mapframe is now used in over 800,000 categories on Commons to display the area that the category covers through the coordinate on Wikidata and the layout of the corresponding item on OpenStreetMap (via commons:Template:Wikidata Infobox) - as well as being used on many other Wikimedia projects. However, it is not currently possible to automatically display related items in the map. Ideally, it should be possible to show items linked to through has part/P527 in the map - or, if there aren't any such values, then the nearby items (using the example of commons:Category:Teide Observatory)
  • Who would benefit: Readers and editors that see a map on Commons and other wikis who then want to explore nearby items.
  • Proposed solution: Have an option that shows the nearby/"part of" items in the maps.
  • More comments: Ideally this functionality could also be used in w:Special:Nearby to show a map of nearby objects rather than a list (As community-requested in 2017. Wikishootme is a current example where nearby Wikipedia articles and Wikidata items are shown on a map (along with Commons photos), but that is on the toolserver rather than built in to Mediawiki.
  • Phabricator tickets:
  • Proposer: Mike Peel (talk) 23:31, 2 November 2018 (UTC)

Discussion

mw:Beta Features/Nearby Pages sounds related (and talks about maps in some far away future). --AKlapper (WMF) (talk) 00:33, 5 November 2018 (UTC)

What you want here are KML and/or GeoJSON layers of Special:Nearby basically. Special:Nearby is powered by Geosearch api in turn part of mw:Extension:GeoData. So fixing that extensions to provide standard GeoJSON and KML layers, as well as updating GeoData to improve some of that information with wikidata richness sounds like a plan. Related are: phab:T180909, phab:T35704, phab: T142431, phab:T149280, phab: T158922 and wikivoyages' ext.kartographer.wv module. I think this would actually be a very much more suitable item than Community_Wishlist_Survey_2019/Miscellaneous#Wikimedia_Maps_Improvements and worth pursuing. —TheDJ (talkcontribs) 10:25, 5 November 2018 (UTC)
  • It could be nice to browse Wikipedia articles through a map interface, especially if you are in a new place. HLHJ (talk) 08:22, 14 November 2018 (UTC)

Voting

Geographic coordinates check

Edit proposal/discussion

  • Problem: Aus Prinzip auf Deutsch: Wir haben wikimediaweit, so weit mir bekannt ist, kein Werkzeug, um falsch gesetzte Geokoordinaten zu finden, bzw. sind es nur augenscheinliche statistische Ausreißer, die eventuell jemandem auffallen. Mein Eindruck ist auch, dass es viele falsche Koordinaten gibt, die von irgendwo aus per Bot zuerst in alle möglichen Sprachversionen, dann von dort nach Wikidata, und von dort wieder in alle möglichen Sprachversionen transferiert werden, ohne dass sich je jemand mit der Frage auseinandergesetzt hätte, ob die Koordinate denn überhaupt stimmt. Es sollte ein Werkzeug ermittelt werden, das Koordinaten mithilfe vorhandener Geotools überprüft, und in plausible, unklare und unplausible sortiert und Wartungslisten erstellt.
    • Translation: AFAIK we have no tool to find incorrect geo coordinates; there are only some obvious statistical outliers which eventually someone will recognize. Furthermore my impression is that there are many wrong coordinates which get taken from somewhere via a bot into some language versions, then transferred into Wikidata, then back to some language versions, without anyone who would have worked on the question whether the coorindates are correct at all. There should be a tool that checks coordinates via existing geotools and puts them into plausible, unclear, and non-plausible maintenance lists.
  • Who would benefit: Leser von Artikeln mit Geokoordinaten (kriegen verlässlichere Informationen), Autoren im Geo-Bereich (erhalten u.U. ein Werkzeug um den Artikelbestand in ihrem Bereich besser im Blick zu behalten), Wikidata (weniger Fehler, besserer Ruf)
  • Proposed solution: Bin kein Programmierer, kenne wohl nicht alle Möglichkeiten, wo man ansetzen könnte, aber vorstellen tu ich mir das Ganze ungefähr so:
  • Nehmen wir d:Q16572965 als Beispiel.
  • Wir haben dort die Properties P625 (geographische Koordinaten) und P131 (liegt in der Verwaltungseinheit). Hier soll angesetzt werden.
  • Rufen wir mal die Koordinate in Openstreetmap auf ([1]). Hier gehen wir zur "Objektabfrage" (Cursor-mit-Fragezeichen-Symbol ganz rechts), klicken auf diesen Button und dann auf den Punkt mit unserer Koordinate. Links öffnet sich was, wo diverse in der Nähe gelegene und verschiedene umschließende Objekte aufgelistet sind.
  • Uns interessieren mal die umschließenden: In der Liste taucht "Gemeinde-/Stadtgrenze San Antonio" auf. Diese so genannte Relation öffnen wir mal und gelangen zu dieser Seite.
  • Wir erkennen, dass diese Seite mit d:Q56135 verknüpft ist. Dies ist auch das Item, das bei P131 unseres Versuchsobjekts eingetragen ist. Geprüft wurde die tiefste vorhandene administrative Ebene (admin_level 8 auf Wikidata im Vergleich zu beispielsweise admin_level 4 auf Regionsebene). Ergebnis der Prüfung: Koordinate ist plausibel (das heißt nicht, dass sie richtig ist, aber plausibel ist sie).
  • Anm: Das zu schreibende Tool sollte natürlich nicht eine Prüfung auf gut Glück machen, sondern alle Einträge bei den umschließenden Objekten durchtesten.
Es gibt auch sehr viele OSM-Relationen, die nicht mit einem Wikidata-Item verknüpft sind. Die Prüfung ließe sich durch die Verschachtelung der P131-Beziehungen auf höheren Ebenen fortsetzen, was aber nur bis zu einem gewissen Punkt Sinn macht. Jedenfalls ist eine Koordinate, bei der die Prüfung nach dem Wikidata-Item bei P131 im zu prüfenden Fall erfolglos ist, nicht zwangsläufig falsch.
Als unplausible Koordinaten ließen sich solche erkennen und in Wartungslisten eintragen, bei denen die Relation auf der tiefsten auf Openstreetmap vorhandenen Ebene in keinem (verschachtelten) eindimensionalen P131-Bezug zum zu prüfenden Wikidata-Item steht. Beispielsweise stimmt irgendwas nicht, wenn ein Item gemäß P131-Angabe in der Gemeinde A in Kreis B liegt, die tiefste umschließende Relation mit Wikidata-Verknüpfung auf OSM aber entweder Gemeinde C oder Kreis D entspricht.
Ich sag gleich dazu, dass ich nicht weiß, wie leicht das für einen Bot zu prüfen ist (Stichwort API), und ob es nicht noch viel bessere Kartendienste gibt, mit denen man solche Prüfungen machen könnte.
Translation: I'm not a programmer, do not know all the possibilities, where to start, but imagine I do the whole thing something like this:
  • Take d: Q16572965 as an example.
  • There we have the properties P625 (geographical coordinates) and P131 (located in the administrative unit). Here should be set.
  • Let's call the coordinate in Openstreetmap ([1]). Here we go to the "object query" (cursor with question mark icon on the right), click on this button and then on the point with our coordinate. On the left, something opens where various nearby and various surrounding objects are listed.
  • We are interested in the enclosing: In the list appears "municipality / city boundary San Antonio". We open this so-called relation and go to this page.
  • We recognize that this page is linked to d: Q56135. This is also the item entered at P131 of our test object. The lowest available administrative level was checked (admin_level 8 on wikidata compared to eg admin_level 4 at region level). Result of the check: Coordinate is plausible (that does not mean that it is correct, but it is plausible).
  • Note: The tool to be written of course should not make a test to good luck, but to test all entries in the enclosing objects.
There are also many OSM relations that are not linked to a Wikidata item. The examination could be continued by nesting the P131 relationships at higher levels, but this makes sense only to a certain extent. In any case, a coordinate in which the check for the Wikidata item at P131 in the case under test is unsuccessful is not necessarily wrong.
As implausible coordinates could be identified and entered into maintenance lists, in which the relation at the deepest on Openstreetmap existing level in any (nested) one-dimensional P131 relation to the examined Wikidata item stands. For example, something is wrong if an item in P131's community A is in circle B, but the lowest enclosing relation with Wikidata's link to OSM is either community C or circle D.
I'll say straight away that I do not know how easy it is to check for a bot (keyword API), and whether there are not much better map services available to do such tests.
  • More comments:
  • Phabricator tickets:
  • Proposer: → «« Man77 »» [de] 18:40, 5 November 2018 (UTC)

Discussion

  • Niemand werden ihre vorschlag verstehen, wenn es ist nicht in Englisch. --Tohaomg (talk) 15:57, 8 November 2018 (UTC)
    I häd aa nu a vü a ausgfåinare Språch nemma kina. Åwa i wü d'WMF ned üwastrapazian. A bissi strapazian åwa do. → «« Man77 »» [de] 20:49, 9 November 2018 (UTC)
    Doch. Ist keine schlechte Idee. Soll ich den Uebersetzung verbessern? Es gibt auch viele Koordinaten, die in die Quellen falsch angegeben sind. Sehe en:Salton Buttes; steht sogar auf's Karte.
    Not so [that no-one will understand if it's not in English]! It's not a bad idea. Shall I polish the translation? There are also lots of co-ords that are given incorrectly in the sources. See en:Salton Buttes, for instance; it's even on the map. HLHJ (talk) 07:25, 14 November 2018 (UTC)

Voting

Maps Improvements: Vector Structure, Disputed Borders, Cleaner Style

Edit proposal/discussion

  • Problem: The development of the Wikimedia Maps should be continued. Main wishes are migration to vector tile structure and fix the international borders.
  • Who would benefit: All wikis including Wikipedia, Commons, Wikidata, Wikivoyage, etc.
  • Proposed solution:
  • More comments: Two issues very important for wikipedia maps

Discussion

Hi Naveenpf and all, it's been about a week since I posted that someone needs to cut this proposal down, or split it up into separate proposals. Ideally, the proposal would have the top two or three problems that are most important to solve. There is a ticking clock here -- the proposal phase ends on November 11th, and if this proposal stays the way it is, we'll have to archive the proposal, and it won't move on to the voting phase. The note about the "minimum a year/two years" needs to be taken out, and the proposal needs to be clear about what you're asking for. With the bullet list of 17 tickets in the Discussion section, we'll have to make it clear that that's part of the discussion and not the actual proposal. I'm happy to talk more about how to edit the proposal; please ping me here if you have questions that I can help with. -- DannyH (WMF) (talk) 00:59, 8 November 2018 (UTC)

Can we have just two ? vector tile structure and fix the international borders. first one as far as I know development is over. Only testing and deployment is required. Can we have both of them ? --naveenpf (talk) 13:07, 8 November 2018 (UTC)
Naveenpf: Yes! Vector tile structure and fix the international borders would make a great proposal. -- DannyH (WMF) (talk) 20:47, 8 November 2018 (UTC)
@DannyH (WMF): And will this proposal be renamed to better reflect its hobbled status? Gareth (talk) 08:01, 14 November 2018 (UTC)
I created one with the OSM issues [2] --Sabas88 (talk) 15:33, 9 November 2018 (UTC)
I created another one about OSM external data issues (above one being about styles/i18n). Pikne 17:07, 9 November 2018 (UTC)
  • I wanted to mention something for people who may not know the history behind the two main Phabricator wishes mentioned above, T153282 and  T113008. You wouldn't guess it from the titles, but one of the very cool results of doing those two tickets is that the styling of our maps will become much more sophisticated. The art of digital maps lies in knowing what to hide or show, abstract or provide in detail, at what level of magnification. If we put those tickets in place, dynamic wiki maps will look a lot cleaner and generally nicer. Plus the issue of clarifying disputed borders is quite important. —JMatazzoni (WMF) (talk) 21:38, 9 November 2018 (UTC)

I've created some proposals; please adopt these if you're interested, otherwise they'll be moved to the archive:

p.s. I think the revised "main wishes" proposal should be resubmitted with a more descriptive name and this proposal should be moved to the archive. Gareth (talk) 08:38, 10 November 2018 (UTC)

Is it in the cards to use background images that are actually useful as opposed to simply blank space? Google and Bing have contour levels and satellite images. Jo-Jo Eumerus (talk, contributions) 08:31, 14 November 2018 (UTC)
  • Hi naveenpf. Voting starts this week so I took a stab at giving this wish a name that more accurately reflects its new focus. I hope that's OK. If you have a better name feel free. —JMatazzoni (WMF) (talk) 16:16, 14 November 2018 (UTC)
  • Fine !!! -- naveenpf (talk) 23:53, 14 November 2018 (UTC)

Proposal does not state a problem. --Traveler100 (talk) 14:41, 17 November 2018 (UTC)

Voting

  • Support Support EneaSuper (talk) 13:46, 27 November 2018 (UTC)
  • Support Support Galobtter (talk) 19:08, 16 November 2018 (UTC)
  • Support Support SEMMENDINGER (talk) 19:24, 16 November 2018 (UTC)
  • Support Support This, that and the other (talk) 01:09, 17 November 2018 (UTC)
  • Support Support The Grid (talk) 01:57, 17 November 2018 (UTC)
  • Support Support --Ranjithsiji (talk) 08:21, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 08:26, 17 November 2018 (UTC)
  • Support Support Afernand74 (talk) 08:49, 17 November 2018 (UTC)
  • Support Support Mujeebcpy (talk) 09:01, 17 November 2018 (UTC)
  • Support Support Maps are used extensively since their development and it’s a shame that we have to do these repeated proposals to continue to improve them. stjn[ru] 09:15, 17 November 2018 (UTC)
  • Support Support Jo-Jo Eumerus (talk, contributions) 10:14, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 10:59, 17 November 2018 (UTC)
  • Support Support Like tears in rain (talk) 12:35, 17 November 2018 (UTC)
  • Support Support DerFussi 14:10, 17 November 2018 (UTC)
  • Support Support Naseweis520 (talk) 15:25, 17 November 2018 (UTC)
  • Support Support Sabas88 (talk) 08:54, 19 November 2018 (UTC)
  • Support SupportTheDJ (talkcontribs) 13:48, 19 November 2018 (UTC)
  • Support Support problem with disputed borders should be resolved as soon as possible. Tohaomg (talk) 20:40, 19 November 2018 (UTC)
  • Support Support Jmmuguerza (talk) 23:52, 19 November 2018 (UTC)
  • Support Support Rmikke (talk) 03:23, 20 November 2018 (UTC)
  • Support Support --Abhinav619 (talk) 09:18, 20 November 2018 (UTC)
  • Symbol strong support vote.svg Strong support The disputed border issue should be taken up as a top priority. Sankoswal (talk) 13:50, 20 November 2018 (UTC)
  • Support Support A very great proposal for improving maps on all Wikimedia projects. SshibumXZ (talk) 14:57, 20 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 01:27, 21 November 2018 (UTC)
  • Support Support Sturm (talk) 04:50, 21 November 2018 (UTC)
  • Support Support kocio 21:26, 21 November 2018 (UTC)
  • Support Support Zorzo Mirco (talk) 09:30, 22 November 2018 (UTC)
  • Support Support Bubici (talk) 14:02, 22 November 2018 (UTC)
  • Support Support MarcoMinghini (talk) 14:30, 22 November 2018 (UTC)
  • Support Support Jack who built the house (talk) 18:27, 22 November 2018 (UTC)
  • Support Support Spacearcangel (talk) 18:51, 22 November 2018 (UTC)
  • Support Support Serhio Magpie (talk) 03:31, 23 November 2018 (UTC)
  • Support Support Eluinie (talk) 08:59, 23 November 2018 (UTC)
  • Support Support IM3847 (talk) 10:19, 23 November 2018 (UTC)
  • Support Support Subhashish Panigrahi (talk) 10:30, 23 November 2018 (UTC)
  • Support Support Manojk (talk) 11:32, 23 November 2018 (UTC)
  • Support Support Sannita - not just another it.wiki sysop 00:33, 24 November 2018 (UTC)
  • Support Support Ultimograph5 (talk) 02:17, 24 November 2018 (UTC)
  • Support Support Old maps are a shame. Mecki.DtH (talk) 12:22, 24 November 2018 (UTC)
  • Support Support Sorcrosc (talk) 03:16, 25 November 2018 (UTC)
  • Support Support Disputed boundaries are a reality that affect numerous countries worldwide (China, India, Pakistan, Russia, Ukraine, Palestine, Israel, Cyprus..) and impact how maps can be legally used there. There is no single worldview that the whole world accepts and to maintain the NPOV in Wikimedia Maps and have it usable in these countries it is necessary to support all worldviews simultaneously which is only possible with vector map tiles --Planemad (talk) 09:11, 25 November 2018 (UTC)
  • Support Support WhatamIdoing (talk) 02:17, 26 November 2018 (UTC)
  • Support Support — AfroThundr (u · t · c) 02:22, 26 November 2018 (UTC)
  • Support Support ARR8 (talk) 02:53, 26 November 2018 (UTC)
  • Support Support Kannan Talk 07:23, 26 November 2018 (UTC)
  • Support Support Ckoerner (talk) 16:34, 26 November 2018 (UTC)
  • Support Support Izno (talk) 01:05, 27 November 2018 (UTC)
  • Support Support Amir E. Aharoni (talk) 11:14, 27 November 2018 (UTC)
  • Support Support Zache (talk) 14:07, 27 November 2018 (UTC)
  • Support Support Thgoiter (talk) 18:22, 27 November 2018 (UTC)
  • Support Support APh (talk) 11:33, 28 November 2018 (UTC)
  • Support Support Abijithka (talk) 15:25, 29 November 2018 (UTC)
  • Support Support Nandukrishna_t_ajith (talk) 21:17, 29 November 2018 (UTC)
  • Support Support -- Akhiljaxxn (talk) 17:07, 29 November 2018 (UTC)
  • Support Support Disputed borders are a huge problem as we are very likely not to match NPOV. Situations when maps depict borders different from described in articles are very frustrating — NickK (talk) 15:48, 30 November 2018 (UTC)
  • Support Support RolandUnger (talk) 16:34, 30 November 2018 (UTC)

Fix bugs relating to map data stored at Commons

Edit proposal/discussion

  • Problem: There are several bugs that mar the experience of creating maps at Commons.
  • Who would benefit: Editors storing maps on Commons. There are several possibilities that would open up if these bugs were fixed, allowing more data to be shared across projects.
  • Proposed solution: Fix the bugs listed below.
  • More comments:
  • Phabricator tickets:
    • Maps fast preview is broken on 2nd attempt (T151524) - needing to open a new tab and copy/paste GeoJSON code every second time you wish to check your work is no fun!
    • Maps that contain Wikidata ids and are stored on Commons fail to display when called via <maplink> or <mapframe> (T155927)
    • When called via <maplink> or <mapframe>, markers stored in a Commons .map page will display a broken image icon when the marker uses the "marker-symbol": "-letter" or "marker-symbol": "-number" properties (T207202)
    The following issues also affect tabular data stored at Commons:
    • Support appropriate documentation of CC BY SA data on Commons (T200968)
    • Add a data-page-only wiki markup header to datasets (T155290)
    • Track Commons Dataset usage across wikis (what links here) (T153966)
    • Support Data namespace redirects (T153598)
    The lack of support for redirects and what links here means that moving (or splitting) pages in the data namespace is liable to break stuff, with no way to know whether this has occurred – a really unacceptable situation for a repository that is supposed to be available across projects and languages.
  • Proposer: Gareth (talk) 06:18, 10 November 2018 (UTC)

Discussion

  • Thanks for contributing to the survey Gareth. The CommTech team has judged this ticket out of scope due to its being a list of loosely related issues. You can save this proposal by reducing your wish to one or two tickets that are your highest priority. I'm sorry to give you such short notice, but Wishlist voting begins November 16 at 18:00 UTC, so please don't delay or this proposal will be withdrawn. Thanks —JMatazzoni (WMF) (talk) 17:58, 15 November 2018 (UTC)
This proposal is entirely consistent with Community Wishlist Survey 2019/Search/Linksearch overhaul, Community Wishlist Survey 2019/Admins and patrollers/Page Curation and New Pages Feed improvements and Community Wishlist Survey 2019/Admins and patrollers/Feature parity for tools dealing with deleted revisions as proposals that request fixes for various problems that share a common theme or technology. This proposal was already spun off from the united maps proposal; meanwhile, the "Page Curation and New Pages Feed improvements" proposal (which is arguably the one most similar to this proposal) includes eighteen tickets. And this one is supposed to be cut to one or two tickets. (And how is a proposal with two "loosely related" tickets any less "out of scope" than one with seven tickets - less than half the number in the page curation proposal?) Some problems resist being packaged into "neat" proposals. So I'm sorry if the this proposal doesn't meet CT's aesthetic sensibilities or inconsistently applied sense of scope, but I won't be modifing it. Gareth (talk) 10:26, 16 November 2018 (UTC)
  • This can go forward to voting Gareth. Just know that if it wins, we can promise only to investigate these tickets and do as much here as is feasible, with community advice about which are the most valuable. I.e., there is not implied agreement to do this whole list. The value of reducing these or at least prioritizing them now is that people would have a better idea of what they might actually get if they vote for this. (The same is true for the other proposals you mention, which are also problematic. Some are the results of previous negotiations to reduce scope, however successful.) Good luck. —JMatazzoni (WMF) (talk) 17:03, 16 November 2018 (UTC)

Voting

Improve OSM external data usability in Kartographer

Edit proposal/discussion

  • Problem: It's possible to highlight boundaries, routes etc. in Kartographer using external data from OSM. However current external data support has a couple considerable deficiencies. External data reference (Wikidata id) in mapframe syntax may return nothing, resulting in a blank map instead of auto-positioned object when there's no Wikidata tag on OSM or no OSM object available or when reference becomes outdated (OSM generally stores only current objects). So it's hard to use this data reliably and conveniently in infobox templates. Secondly, certain type of geographical objects are not available for Kartographer (most notably waterway relations). Thirdly, Wikimedia currently generalizes OSM external data in a quite unfit way (most notably for large boundaries and long routes).
  • Who would benefit: Wikimedia projects, mainly Wikipedias that have articles about related geographical objects.
  • Proposed solution: 1) Provide way to check if external data reference returns external data, 2) handle OSM relations at least as well as WIWOSM (older service, largely unmaintained), 3) rework data generalization.
  • More comments: Partly from Wikimedia Maps Improvements proposal which had to be split up.
  • Phabricator tickets: T209067, T156433, T155919
  • Proposer: Pikne 16:59, 9 November 2018 (UTC)

Discussion

Voting

Maps should have option to show users current location

Edit proposal/discussion

  • Problem: In Wikivoyage, when using the mapframe embedded style map you cannot see your current location. Have to go to desktop version and use the map option created by geo shown as icon top right. Far too many clicks to be used.
  • Who would benefit: Any reader on mobile wanting to see what Points of Interest are nearby.
  • Proposed solution:
  • More comments: This is a functionality any mobile user would expect. Other apps do this. Stops Wikivoyage becoming popular with mobile users, which is the largest group of internet accesses.
  • Phabricator tickets: T208713
  • Proposer: Traveler100 (talk) 08:38, 5 November 2018 (UTC)

Discussion

  • I have created a phabricator ticket for this request. I myself also have often have had this idea, and I don't think a ticket already existed. —TheDJ (talkcontribs) 10:33, 5 November 2018 (UTC)
  • WikiShootMe can do this; perhaps its code can be reused? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:15, 17 November 2018 (UTC)

Voting

Replace GeoHack with Kartographer

Edit proposal/discussion

WikiMiniAtlas/GeoHack interface
  • Problem: Even though the Wikimedia projects now have their own map service, Kartographer, some wikis such as English Wikipedia still use the old GeoHack service hosted on Tool Forge (e.g. in WikiMiniAtlas). This is mostly just because converting the old Lua modules is complicated, not because those projects actually want to keep using GeoHack (see for example, the discussion on English Wikipedia). Additionally, the use of GeoHack (which is essentially a 3rd party service) has privacy and security concerns that would be eliminated by switching to Kartographer.
  • Who would benefit: Users of Wikipedias that haven't yet migrated from GeoHack
  • Proposed solution: Migrate en:Module:Coordinates to use Kartographer and make the module available to all wikis by bundling it with the Scribunto extension (or the Kartographer extension).
  • More comments:

Discussion

  • Switching GeoHack to Kartographer in the Coordinates module is quite simple. We did this in Russian Wikipedia almost two years ago (see ru:Module:Coordinates). There are more social issues. For example, what to do with coordinates for other planets? Or should there be links to external maps? PS: If any projects want to use Kartographer, I’m ready to help with this. — putnik 09:09, 30 October 2018 (UTC)
  • There are two problems here: one WMA, which is the map being presented. This is rather easy to replace even when we fully keep using geohack. That is basically what my mobile gadget does already and could be expanded to desktop easily. To replace geohack (which ALSO would replace WMA, as WMA depends on geohack) is a lower level discussion. For this I have created a sandbox version of en:Module_talk:Coordinates/testcases, which uses maplink instead of geohack where possible. I think however that the myriad of problems listed in Community Wishlist Survey 2019/Miscellaneous/Wikimedia Maps Improvements could derail any kind of discussion that would be held on it, which I personally have therfore not kickstarted yet (time and brain drain). I also see a slight problem with that the maplink created doesn't have a proper no-js target link fallback (Do we even have a ticket for that?). —TheDJ (talkcontribs) 10:15, 30 October 2018 (UTC)
  • Personally I'd be reluctant to abandon GeoHack mostly due to Kartographer not allowing on-wiki customization for both global and regional map services (T152971, T146534). Pikne 11:54, 30 October 2018 (UTC)
    • I guess you community tech could address these two issues if this wish is successful, or as a part of the maps wish above. Gryllida 22:40, 30 October 2018 (UTC)

Voting

  • Support Support EneaSuper (talk) 13:52, 27 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 08:28, 17 November 2018 (UTC)
  • Support Support ZellmerLP (talk) 10:10, 17 November 2018 (UTC)
  • Oppose Oppose As far as I can tell Kartographer does not have any links to Google or Bing maps, only OSM maps which don't show contours, landscape or any other information on the terrain. I am quite willing to bet that most actual readers - as opposed to editors - want more than just a road map when they go to a coordinate. Jo-Jo Eumerus (talk, contributions) 10:17, 17 November 2018 (UTC)
    @Jo-Jo Eumerus: It does; if you open the big map view the "External maps" button at the bottom right lists various different maps. Jc86035 (talk) 10:49, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 10:58, 17 November 2018 (UTC)
  • Support Support Jc86035 (talk) 11:44, 17 November 2018 (UTC)
  • Support Support DerFussi 14:11, 17 November 2018 (UTC)
  • Support Support Nouill (talk) 15:04, 17 November 2018 (UTC)
  • Support Support ··· 🌸 Rachmat04 · 18:30, 17 November 2018 (UTC)
  • Support Support Amir (talk) 19:21, 17 November 2018 (UTC)
  • Support Support Yamaha5 (talk) 20:35, 17 November 2018 (UTC)
  • Support Support Tim Landscheidt (talk) 01:38, 18 November 2018 (UTC)
  • Support Support NMaia (talk) 10:34, 18 November 2018 (UTC)
  • Support Support فرهنگ2016 (talk) 10:41, 18 November 2018 (UTC)
  • Support Support Fatemi 18:53, 18 November 2018 (UTC)
  • Support Support Shizhao (talk) 02:47, 19 November 2018 (UTC)
  • I can't support this with the way Kartographer's maplink currently works. I hate having to use it because it makes it really slow, annoying and complicated to get to other map services, which is something I do a lot. In GeoHack I can quickly scan the page for the service I want and then click it. Kartographer requires moving the mouse all over the screen, clicking multiple times, reading multiple lists and it even forces me to stop and think about which category the service will be hidden under. Then it forces the links to open in a new tab, instead of letting me choose whether to open them in new tabs or not. - Nikki (talk) 10:12, 19 November 2018 (UTC)
    @Nikki: If you look at the top right corner of (for example) ru:Россия, you have one-click links for GeoHack, Google, Yandex and OpenStreetMap. Even better, as Kartographer is part of the MediaWiki UI, you can use your own user scripts to do literally anything you want to customize. --Tim Landscheidt (talk) 20:34, 28 November 2018 (UTC)
  • Support SupportTheDJ (talkcontribs) 13:49, 19 November 2018 (UTC)
  • Support Support Shmurak (talk) 08:41, 20 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 01:29, 21 November 2018 (UTC)
  • Support Support Sturm (talk) 04:48, 21 November 2018 (UTC)
  • Support Support Vulphere 07:15, 21 November 2018 (UTC)
  • Support Support Jack who built the house (talk) 18:30, 21 November 2018 (UTC)
  • Support Support Zorzo Mirco (talk) 09:32, 22 November 2018 (UTC)
  • Support Support MarcoMinghini (talk) 14:29, 22 November 2018 (UTC)
  • Support Support Spacearcangel (talk) 18:56, 22 November 2018 (UTC)
  • Support Support SalmanZ (talk) 21:17, 22 November 2018 (UTC)
  • Support Support Ederporto (talk) 16:06, 23 November 2018 (UTC)
  • Support Support Sahaquiel9102 (talk) 17:20, 23 November 2018 (UTC)
  • Support Support Sannita - not just another it.wiki sysop 00:47, 24 November 2018 (UTC)
  • Support Support Matěj Suchánek (talk) 09:10, 24 November 2018 (UTC)
  • Support Support Sorcrosc (talk) 03:06, 25 November 2018 (UTC)
  • Support Support HeinrichStuerzl (talk) 20:01, 25 November 2018 (UTC)
  • Support Support Filipović Zoran (talk) 19:44, 26 November 2018 (UTC)
  • Support Support General Rommel (talk) 00:41, 27 November 2018 (UTC)
  • Support Support Amir E. Aharoni (talk) 11:14, 27 November 2018 (UTC)
  • Support Support GAllegre (talk) 13:48, 27 November 2018 (UTC)
  • Support Support Phoe6 (talk) 03:33, 29 November 2018 (UTC)

Expand functionality of the map editor in VisualEditor

Edit proposal/discussion

  • Problem: To edit maps created with Kartographer, a user need to edit GeoJSON. This makes it a lot harder to make functional maps. Now it is hard to know how to add different kinds of pushpins (which ones are even available) and how to style them.
  • Who would benefit: More editors would be able to make better maps which in the end would benefit readers.
  • Proposed solution: Make an editor with fields/dropdown menus for properties/markers so that need for editing the GeoJSON code gets minimized.
  • More comments:
  • Phabricator tickets: phab:T125539
  • Proposer: Ainali (talk) 23:11, 9 November 2018 (UTC)

Discussion

  • Should this be under the Multimedia section? HLHJ (talk) 07:17, 14 November 2018 (UTC)

Voting

Display results of a SPARQL query on a map in Wikipedia

Edit proposal/discussion

The aim of this proposal is to embed such map from query.wikidata.org in Wikipedia, Wikivoyage, etc.
  • Problem: On query.wikidata.org, you can easily display the result of a SPARQL query on a dynamic map (see the Venues in Broadway for example). But if you want to add this map to Wikipedia or any other Wikimedia project, you can't (except if you take a screenshot..).
  • Who would benefit: All wikis.
  • Proposed solution:
  • More comments:
  • Phabricator tickets: T188291
  • Proposer: Ayack (talk) 15:10, 3 November 2018 (UTC)

Discussion

Voting

OSM map problem on dewiki

Edit proposal/discussion

  • Problem: The Geohack tool on dewiki does not use updated coordinates after update.
  • Who would benefit: all users of dewiki calling up the OSM map of any article (which is systematically displaying the initial coordinates)
  • Proposed solution:
  • More comments: already requested earlier (e.g. [3], [4])
  • Phabricator tickets:
  • Proposer: --Stopfentrudel (talk) 13:44, 4 November 2018 (UTC)

Discussion

Compare for de:Wikipedia:Technische Wünsche/Topwünsche/OSM-Verknüpfungen besser warten: There are many map-related issues in dewiki that, excuse my language, actually are not being cared about. → «« Man77 »» [de] 15:43, 4 November 2018 (UTC)

Specific steps which allow someone else to see the same problem would be super welcome: There is "MediaWiki:GeoHack.js" on some sites, there are https://tools.wmflabs.org/geohack/ or https://tools.wmflabs.org/wiwosm/ , "Template:GeoTemplate" on some sites, and a few more Map related things around, so I'd love to make sure that we're talking about exactly the same thing. Thanks! --AKlapper (WMF) (talk) 17:25, 4 November 2018 (UTC)
You find these specific steps in the proposal, under "more comments". --Stopfentrudel (talk) 18:21, 4 November 2018 (UTC)
A lot of the volunteer maintained maps are a bit in disarray. Most of the volunteers working on that stuff have sort of moved on to different things and a new generation of volunteers has not really materialised. In the mean time, stuff keeps changing around what was built and many of these things slowly break down left and right. Some of these would be easily solvable, others not. There are the production maps of WMF, which have their problems, but at least are a production level service with production level support. To make use of this however, requires people giving up on existing integrations, which the communities seem often reluctant to do. And some of the volunteer services aren't even yet available as WMF services (for instance 'nearby' map layers). As a matter of fact though, the tile servers for some of those maps even need to be updated, because if they are not, they will stop working in january altogether, yet so far no one has shown indications of being willing to work on that. Lots of opportunities here, but hard to navigate this space. Like, do you want WMF to patch up a tool ? Or do you want them to maintain it ? Or do you want to switch to next generation maps ? These are questions that need to be answered by communities. —TheDJ (talkcontribs) 08:43, 5 November 2018 (UTC)
@Stopfentrudel: I had read what's under "more comments" and it was and is unclear to me which exact buttons or links were clicked where. --AKlapper (WMF) (talk) 12:28, 5 November 2018 (UTC)
  • Take de:Municipio Tequisquiapan as example (click the link in this line)
  • In the top right corner, depending on your personal settings, but usually below the place where you click to log off from your account, at the same height as the lemma you should see "Koordinaten: 20° 30′ N, 99° 54′ W", followed by two symbols (one in green with a magnifier symbol, one in blue like a globe with a black triangle). Click the green symbol.
  • A map should have loaded. In this map there are two things missing:
    • The WIWOSM connex should have displayed this outline in the very map that opened. This is currently not the case because the database has not been updated for ages even though according to user:Kolossos this ought to happen daily and automatically. Open the same map in de:Querétaro (Bundesstaat) to see how this outline should de displayed.
    • The map lacks information about other articles which were created after a day X (indeed very very long ago, longer than the last update of problem 1). If you zoom out a little, about 30 km to the northeast of the coordinate in our article you should see a pin with a W which marks the place the article de:Zimapán-Talsperre is describing, 20 km to the north there is a red square for de:Bernal (Mexiko). Younger articles like de:Tequisquiapan virtually next to our example, or de:San Juan del Río (Querétaro) some 15 km to the southwest are not marked. This is increasingly painful, as the map and our stock of articles are extremely out of sync.
This is not merely a dewiki problem. Other wikis like eswiki or itwiki which use WIWOSM have the same issues.
«« Man77 »» [de] 17:38, 5 November 2018 (UTC)
To the two points above:
  • We should test if we could change from WIWOSM to Kartographer-Objects (e.g. https://maps.wikimedia.org/geoshape?getgeojson=1&ids=Q797). For this smaller change I would only need to determine the Wikidata-ID inside my map script. Second problem is perhaps map projection and the need for a proxy. It's a smaller change and perhaps done with some help from an JavaScript-Programmer in some hours.
  • Database updates are an other problem as the sql queries that I run in the past are now much slower and break more often, so I stop the last update after 2 days of frustration. (Same frustration like with my other project templatiger [5]. Other users are also frustrated...) So in my eyes I will not further work on that and say that all objects created after 2016 are not relevant for the map. Sorry for that. It would be much easier to extract coordinates from Wikidata instead of different Wikipedias, but than all objects inside of list would missing. This could be an option to can switch between one old layer from Wikipedia or an updated layer from Wikidata.
My problem is that the WMF has no clue what to do with maps. Where is a map in the mobil app, where it is needed mostly, and not only a nearby map but also a map around each article. And where is a user concept and an clean up for maps... Where are the innovative ideas from WMF about maps where is a contact person to talk about maps? Without such a plan I feel it's more more and more a waste of time. --Kolossos (talk) 15:15, 6 November 2018 (UTC)
The answer to this is basically "no budget"/"no people". With day to day maintenance and several key long term strategy projects, the foundation (and WMDE) are 'full'. Scaling beyond the current levels requires investing more in engineering and past feedback has shown very little support for additional investments from the community (and management honestly). So officially, YOU can determine the direction. The problem is that you need to keep to WMF rules about code quality, stability and scaling and find another person of equal level to approve your code changes. And considering you also need additional services, you probably also need to be a sysop. And honestly that is asking too much of most volunteers. It's why I generally tend to limit myself to bug fixing. But please take the Kartographer project in phabricator and comment on every single ticket with your opinion. Please DO draw mockups and provide a white paper with commentary on how things SHOULD be working. And please do keep pushing the foundation. Also please consider that there are currently a LOT of things out there already. In situations where there is a lot of differences in technology between the various wikis, then the foundation has learned it takes 6months to a year to get significant changes through to the communities. —TheDJ (talkcontribs) 08:59, 7 November 2018 (UTC)
In addition to making it into the "Topwünsche" list of dewiki in 2015 (mentioned above), the proposal had another 19 votes last year on dewiki. [6] --Stopfentrudel (talk) 10:01, 22 November 2018 (UTC)

Voting

GeoLocation selection

Edit proposal/discussion

  • Problem: We have 1000's of village titles in tawiki without geolocation
  • Who would benefit: tawiki
  • Proposed solution: Need a popup to open OSM (openstreetmap.org) and select a point and the point should add in wikidata and in wiki Template (current page).
  • More comments:
  • Phabricator tickets:
  • Proposer: Mdmahir (talk) 06:51, 10 November 2018 (UTC)

Discussion

  • This seems simple. A GUI editing tool to input geographic co-ordinates from a map. I can see someone using this, but maybe not one person for thousands of villages. HLHJ (talk) 07:45, 14 November 2018 (UTC)
see phab:T172122--Shizhao (talk) 07:53, 14 November 2018 (UTC)
  • In my opinion the best new idea of this year's survey! --Dvorapa (talk) 19:42, 18 November 2018 (UTC)

Voting

New Swiss map coordinate system

Edit proposal/discussion

  • Problem: Switzerland has adopted a new coordinate grid by adding additional 2000 km of false easting and 1000 km of false northing. Location 600 000 / 200 000 has thus become 2 600 000 / 1 200 000.
  • Who would benefit: all readers of articles about locations in Switzerland
  • Proposed solution: change of https://de.wikipedia.org/wiki/Vorlage:WGS84-CH1903
  • More comments: [7]
  • Phabricator tickets:
  • Proposer: Stopfentrudel (talk) 08:30, 5 November 2018 (UTC)

Discussion

  • Isn't this something that a bot can do rather easily ? Are there no bot authors within the german community capable of taking on this task ? Maybe a lua module to convert old values to new display values ? —TheDJ (talkcontribs) 08:46, 5 November 2018 (UTC)
    • I assume coordinate values are stored as WGS84, which means degrees latitude and degrees longitude. Therefore, the change should probably be made in the conversion/diplay template, not by using a bot changing thousands of articles. --Stopfentrudel (talk) 09:05, 5 November 2018 (UTC)
  • I see this was brought up last year on German Wikipedia, but no change has been made. It seems to be up to German Wikipedia community if or when they want to make the transition and change easting/northing values (and possibly other parts of conversion formulas if new coordinates' system requires it) in given template. Pikne 16:43, 14 November 2018 (UTC)

Voting

View object location of all images with coordinates on a map

Edit proposal/discussion

  • Problem: There are being added coordinates of "camera location" to images with location template commons:Template:location. Position of all of those images are on the map.

    The map is accesible via the "View this and other nearby images on: OpenStreetMap - Google Earth".

    When a user will add coordinates of "object location" with the object location template commons:Template:object location, then the only one position from object location template (of the image where you just came from) is visible. But all other positions are from the camera location template.

    There currently is no possibility to view more than one position of coordinates from object location on a map.

  • Who would benefit: Users who want to see all images from the certain area. Editors will see all images from the certain area for better categorization, they will also see areas, where are photos lacking from.
  • Proposed solution: It would be helpful to view all positions of camera location and all positions of object location on one map together. Ideally there would be helpful to have more possibilities. 1) view camera location only (this is what we have); 2) view both camera location and object location; 3) view object location only; 4) if there are both camera location and object location in one image, 4a) view both, 4b) view camera location only, 4c) view object location only.
  • Proposer: Snek01 (talk) 13:26, 2 November 2018 (UTC)

Discussion

I think this is a necessary requirement (Mostafameraji (talk) 14:00, 7 November 2018 (UTC))

  • Related proposal: For images of old maps, it would be nice to be able to show all of the bounding boxes on a map. Jheald (talk) 08:24, 11 November 2018 (UTC)
  • It would also be nice to show the categories of all nearby images. Pmau (talk) 15:48, 11 November 2018 (UTC)

Voting