Wikimedia Meta-Wiki

Community Wishlist Survey 2019/Maps

< Community Wishlist Survey 2019
Community Wishlist Survey 2019
Maps
13 proposals, 199 contributors, 416 support votes
The survey has closed. Thanks for your participation :)



  • 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)[reply]

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)[reply]

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 (talk • contribs) 10:25, 5 November 2018 (UTC)[reply]

Voting

Geographic coordinates check

  • 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.

Discussion

Voting

Maps Improvements: Vector Structure, Disputed Borders, Cleaner Style

  • 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

more tickets, not part of this proposal and older discussion

Removing this session from initial proposal

Minor wishes are the move of all controls to the left map side like nearby, full-screen, layers controls, adding an additional zoom-level control, several pushpin symbol improvements like usage of short strings, 3-digit numbers etc. A nearby map mode showing links to nearby articles should be added. Kartographer documentation should be improved. T155601, T145475, T147184, T141715, T141335, T140212, T140209, T140092, T140087, T140083, T180909. T208350

Here are some bugs that I consider a high priority:

  • Enable auto-positioned snapshot on Kartographer side (T158919)
  • Maps fast preview is broken on 2nd attempt (T151524)
  • Geoline/geoshape does not work with relations other than multipolygon/route/boundary (T156433)
  • Automatic zoom and positioning doesn't work for geomasks (T178370)
  • Remove map offset when quitting full screen mode (when screen > 1024px) (T161065)
  • Maps that contain Wikidata ids and are stored on Commons fail to display when called via <maplink> or <mapframe>(T155927)
  • Kartographer geoline service has low accuracy at high zoom levels (for long features) (T155919)
  • Ability to define a map legend (T154585)
  • Introduce global or per-wiki styles (T146343)
  • maps with "type": "ExternalData" have pointing hand mouse pointer over unclickable objects (T192613)
  • Should we use the marker cluster plugin with `<mapframe>` and `<maplink>` ? (T136455)
  • Customize map markers in Kartographer (T131618)
  • Kartographer full page view cuts off longer captions (T197735)
  • 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. Gareth (talk) 23:45, 29 October 2018 (UTC)[reply]

In addition to T156433 and T155919 mentioned above by Gareth I'd like to highlight automatic zoom/centre issue (T187741). I think from end-users perspective these are significant deficiencies in the way OSM external data is currently handled. What else bugs me the most about external data support is that there is no way to check if reference to external data actually returns any external data, e.g. so that template/module could decide not to show map if nothing is returned for QID related to given page. (Maybe T155925 would be sufficient for the latter, or maybe it should be something more generic that also covers .map page external data.) --Pikne 09:54, 30 October 2018 (UTC)

Goog point by Pikne. It is hard to include maps in templates, or modules, whitout knowing if there is any external data. --Vriullop (talk) 10:45, 30 October 2018 (UTC)[reply]
I think T187741 is a duplicate of T158919. Gareth (talk) 23:04, 1 November 2018 (UTC)[reply]

I think this wish needs to be structured better. Perhaps the two "major" wishes (vector tiles and international borders) need to be their own wish, and "minor improvements" could be a second wish that people can vote for separately. Otherwise it is going to cause problems for the Community Tech team, who are not possibly going to be able to work through all the linked tasks, particularly if they don't have anyone experienced in mapping on their team. This, that and the other (talk) 10:54, 30 October 2018 (UTC)[reply]

I think that the wishlist should be kept monolithic until WMF acknowledges that the Maps works needs a proper allocation of work / team. Then in case we can split it --Sabas88 (talk) 11:32, 30 October 2018 (UTC)[reply]

Please consider also these, which were closed due to a lack of resources from WMF but are of interest

  • Use Wikidata international labels when OSM data is not available (T193198) (this is necessary also for OSM community)
  • Deploying new vector tiles to production (T156682) (this was practically ready to deploy)

--Sabas88 (talk) 11:38, 30 October 2018 (UTC)[reply]

@Naveenpf: Note that Community Wishlist proposals should be discrete tasks, while this proposal seems to be a catch-all for many many actually separate proposals. --AKlapper (WMF) (talk) 12:57, 30 October 2018 (UTC)[reply]

Hi naveenpf and all: I'm happy to see another Maps proposal this year, and I hope it's as successful as the Maps wish last year. As it's written, though, it's too big for a Wishlist proposal. This process determines what the Community Tech team works on next year, and they're going to investigate and address the top 10 wishes over the course of the year. A request for a year or two of Maps support is beyond what Community Tech can provide, and we don't have another team to do that work. This proposal will need to be trimmed down to a few main wishes, in order to move forward to the voting phase. Do you want to talk here about which requests are most important? -- DannyH (WMF) (talk) 21:56, 30 October 2018 (UTC)[reply]

Vector maps, internationalized maps, improval of docs sound great ideas. Gryllida 22:36, 30 October 2018 (UTC)[reply]

Judging by the No. 1 place of Kartographer improvements last year I think there probably would be enough support that splitting it into 2-3 proposals as suggested above that could all get enough support for the Top 10 would be possible Galobtter (talk) 08:17, 31 October 2018 (UTC)[reply]

Yes, I definitely would advise splitting into 3 of 4 chunks rather than "fix all da things" —TheDJ (talk • contribs) 10:36, 31 October 2018 (UTC)[reply]
Same here, splitting the proposal would be more practical approach. Capankajsmilyo (talk) 10:40, 31 October 2018 (UTC)[reply]

The style of this proposal is very much the same as last year's proposal (which wasn't split up). Even "It is very difficult to estimate the developing time. I think minimumly a year, better two years are needed." comes directly from that proposal (and, yes, it's clearly an unrealistic suggestion). Gareth (talk) 23:04, 1 November 2018 (UTC)[reply]

Unfortunately, that was a problem with last year's proposal that we don't want to repeat. :) Last year's proposal was very broad, and expectations were very high. The team delivered on several important changes this year, but there was still a sense that some people in the community were disappointed, because they assumed it was possible that a Wishlist proposal would result in a long-term, full-time Maps team. We want to be clear this year about what the team can deliver for one Wishlist proposal. You'll need to take the "minimum a year/two years" out of the proposal, and scale down (or split up) the requests in this proposal before it moves to the voting phase. -- DannyH (WMF) (talk) 15:23, 2 November 2018 (UTC)[reply]
Or maybe we/ WMF need to recognise the need for a full-time maps team, and start to look for grant- (or other) funding for such? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:25, 3 November 2018 (UTC)[reply]
+1 --Sabas88 (talk) 10:59, 4 November 2018 (UTC)[reply]

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)[reply]

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)[reply]
Naveenpf: Yes! Vector tile structure and fix the international borders would make a great proposal. -- DannyH (WMF) (talk) 20:47, 8 November 2018 (UTC)[reply]
@DannyH (WMF): And will this proposal be renamed to better reflect its hobbled status? Gareth (talk) 08:01, 14 November 2018 (UTC)[reply]
I created one with the OSM issues [2] --Sabas88 (talk) 15:33, 9 November 2018 (UTC)[reply]
I created another one about OSM external data issues (above one being about styles/i18n). Pikne 17:07, 9 November 2018 (UTC)[reply]
  • 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)[reply]

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)[reply]

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)[reply]
Proposal does not state a problem. --Traveler100 (talk) 14:41, 17 November 2018 (UTC)[reply]

Voting

Fix bugs relating to map data stored at Commons

  • 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)[reply]

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)[reply]
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)[reply]
  • 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)[reply]

Voting

Improve OSM external data usability in Kartographer

  • 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)[reply]

Discussion

Voting

Maps should have option to show users current location

  • 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)[reply]

Discussion

Voting

Replace GeoHack with Kartographer

 
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)[reply]
  • 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 (talk • contribs) 10:15, 30 October 2018 (UTC)[reply]
  • 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)[reply]

Voting

Expand functionality of the map editor in VisualEditor

  • 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)[reply]

Discussion

Voting

Display results of a SPARQL query on a map in Wikipedia

 
The aim of this proposal is to embed such map from query.wikidata.org in Wikipedia, Wikivoyage, etc.

Discussion

Voting

OSM map problem on dewiki

  • 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)[reply]

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)[reply]

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)[reply]
You find these specific steps in the proposal, under "more comments". --Stopfentrudel (talk) 18:21, 4 November 2018 (UTC)[reply]
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 (talk • contribs) 08:43, 5 November 2018 (UTC)[reply]
@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)[reply]
  • 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)[reply]
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)[reply]
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 (talk • contribs) 08:59, 7 November 2018 (UTC)[reply]
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)[reply]

Voting

GeoLocation selection

  • 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)[reply]

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)[reply]
see phab:T172122--Shizhao (talk) 07:53, 14 November 2018 (UTC)[reply]

Voting

New Swiss map coordinate system

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 (talk • contribs) 08:46, 5 November 2018 (UTC)[reply]
    • 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)[reply]
  • 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)[reply]

Voting

View object location of all images with coordinates on a map

  • 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.

Discussion

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

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2019/Maps&oldid=18684604"