Jump to content

Wikipedia:Requests for comment/Mapframe maps in infoboxes

Add links
From Wikipedia, the free encyclopedia

Should infoboxes in general have mapframe mapping capability, and how should such maps operate by default? - Evad37 [talk] 03:18, 24 June 2020 (UTC)[reply]

Background

[edit]

Maps in infoboxes have traditionally either been static images, which have to be manually created and updated, or pushpin maps, which display location marks on top of a static base map at specified coordinates. Since May 2018, Mapframe maps have been available on English Wikipedia. Mapframe maps show a base map from OpenStreetMap, which when clicked opens a dynamic, interactive full screen map that can be panned and zoomed. One or more features can be (and usually are) displayed over the basemap, either as markers (with or without icons) at specified coordinates, or as highlighted line or shape features (if the relevant item on OSM is tagged with a Wikidata ID).

Of all the current options for creating maps in Wikipedia, Mapframe is the fastest and easiest tool to use, the most likely to be up-to-date, and shows the most information, from street-level detail all the way to a location's position globally. There are already approximately 40 infoboxes using some form of mapframe mapping, approximately 107,000 pages transcluding {{Infobox mapframe}}, and more generally 341,005 pages using maplink or mapframe maps.

Mapframe maps are commonly inserted via {{maplink}} templates, but that requires several parameters. An alternative suitable for infoboxes is Module:Infobox mapframe, which can insert a mapframe map with minimal user input – instead using data from existing infobox parameters and/or Wikidata, depending on how it is configured. Such "automatic" maps can be on by default (require a parameter to be specified to turn on), off by default (require a parameter to turn on), or be on by default if another type of map is not already present. Other options, such as marker icon or styles, can have default values specified on an individual infobox basis and/or in individual articles.

This RFC is intended to gauge the broader community consensus on how mapframe maps should be used within infobox templates.

Previous discussions
Wikipedia:Village pump (technical)/Archive 159 § Should we ask for mapframe to be turned on?
Wikipedia:Village pump (proposals)/Archive 161 § OpenStreetMap (re mapframe use in countries and other territorial articles)

Examples

[edit]
Point feature with switcher (zooms)
Map
Map
Map
...
infobox headings, labels, and data omitted
...
Point feature with switcher (auto)
Map
Map
Map
Map
Map
Map
...
infobox headings, labels, and data omitted
...
Point/shape features with switcher
Map
Map
Map
...
infobox headings, labels, and data omitted
...
Line feature
Map
...
infobox headings, labels, and data omitted
...
Specified coordinates
Map
...
infobox headings, labels, and data omitted
...
Custom mapframe
(George Floyd protests)
Map
...
infobox headings, labels, and data omitted
...

Q1. Availability

[edit]
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is consensus that yes, mapframe mapping capability, and standard parameters for displaying mapframe maps (i.e. use of Module:Infobox mapframe), should be added to the infoboxes listed at Wikipedia:Mapframe maps in infoboxes, and more generally any infobox which displays coordinates, or image-based maps, or pushpin maps.
Whether it should be on or off by default is outside the scope of this subsection and is addressed by Q2, but the comments here may be taken into consideration in the close of Q2. (non-admin closure) Levivich [dubious – discuss] 19:23, 25 July 2020 (UTC)[reply]

Should mapframe mapping capability, and standard parameters for displaying mapframe maps (i.e. use of Module:Infobox mapframe) be added to the infoboxes listed at Wikipedia:Mapframe maps in infoboxes, and more generally any infobox which displays coordinates, or image-based maps, or pushpin maps?

Note: Default settings, including whether such mapframe maps are on or off by default, will depend on either local consensus, or any consensus reached in the questions below.
Addendum: This question is supposed to be about whether maps are available as at least an option. Please discuss the on or off by default behaviour in Q2 - Evad37 [talk] 00:06, 25 June 2020 (UTC)[reply]
  • As option, not default what option is correct depends on the article. I do not think that all the infoboxes which currently show static maps should automatically be switched over, it should be evaluated case to case which is most helpful to our readers. For example, correct me if I'm wrong but Mapframe does not support historical maps, whereas we have many historical location maps such as Germany 1937, Occupied Yugoslavia, Czechoslovakia, Sudan (2005-2011), etc. buidhe 05:59, 24 June 2020 (UTC)[reply]
  • Make mapframe the default for obvious uses. Moving away from the manual static maps is long overdue. Of course, as Buidhe highlighted, the option of using non-mapframe maps should be retained for special cases. Rehman 06:16, 24 June 2020 (UTC)[reply]
  • Optional, not default from what I can tell, it is of no use whatsoever for many thousands of historical articles where current country borders and names don't apply. Happy to be proven wrong. Peacemaker67 (click to talk to me) 07:35, 24 June 2020 (UTC)[reply]
  • No. Add it as an option by all means, but I oppose simply including it per Buidhe and Peacemaker. Gog the Mild (talk) 10:25, 24 June 2020 (UTC)[reply]
  • Optional, not default I'm not averse to putting historical data over a modern map (For example), as a means of putting a historical event into a contemporary context, something that is, I believe more to the advantage to our WP:READER than their disadvantage. (And some of those old maps, untouched up, are frankly illegible.) However, there are many occasions where it would be inappropriate: borders changes, modern non-contemporaneous settlements and transport routes, for example. Any map of Yugoslavia; showing the Battle of Chantilly as now a suburb dissected by multiple interstates; or the Battle of waterloo adjacent to the Brussels–Charleroi mainline spring to mind... ——Serial # 11:20, 24 June 2020 (UTC)[reply]
  • Note was this question about 'default or not'? Seems to ask just if the mapframe maps should be coded into the infoboxes. Pinging @Evad37:. ɱ (talk) 15:41, 24 June 2020 (UTC)[reply]
    • The intention was to ask just about availability, but people have strong feelings about on/off by default. I've added an addendum above in blue to clarify. - Evad37 [talk] 00:08, 25 June 2020 (UTC)[reply]
  • Yes coded in..but not default Have had many problems and debates over boundaries demarcations. Best have the ability to add accurate maps if need be.--Moxy 🍁 15:50, 24 June 2020 (UTC)[reply]
  • Leave it up to the maintainers of each infobox This makes a lot of sense for some infoboxes (i.e. roads) but not others (historical articles). I don't see the need to force or prohibit the use of mapframe maps sitewide. --Rschen7754 18:16, 24 June 2020 (UTC)[reply]
  • Yes, as an option. There is a fundamental problem when you make significant changes to functionality to infoboxes, especially when it involves Wikidata. When the changes are made, if they are enabled by default, articles will change without the change showing up in editors' watchlists and they really, really don't like that. As long as the functionality has to be enabled in each article where it is used, an editor will make a positive decision to do that, and can be expected to check the results of doing so. --RexxS (talk) 18:25, 24 June 2020 (UTC)[reply]
  • Yes. --Cornellier (talk) 11:43, 26 June 2020 (UTC)[reply]
  • Yes (as an option) — GhostInTheMachine talk to me 08:36, 27 June 2020 (UTC)[reply]
  • Optional, not default per Peacemaker67 etc. Ben MacDui 10:33, 27 June 2020 (UTC)[reply]
  • Yes, should be available as at least an option, and the parameters for styling/adjusting the maps should be consistent between infoboxes. - Evad37 [talk] 01:17, 1 July 2020 (UTC)[reply]
  • Yes. It might not be appropriate on all articles, but it's definitely a very useful function. – Joe (talk) 13:31, 6 July 2020 (UTC)[reply]
  • Of course. --Izno (talk) 13:51, 6 July 2020 (UTC)[reply]
  • Yes, goes without saying for me. ɱ (talk) 15:18, 6 July 2020 (UTC)[reply]
  • Yes, it is easier user to select that. -- naveenpf (talk) 02:52, 10 July 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Q2. Display

[edit]
The status quo is that there are no default mapframes, so the question here is whether we should turn mapframes on by default. There is no consensus that we should do so, and the result is that mapframes should not be on by default — Wug·a·po·des​ 01:56, 13 August 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should "automatic" mapframe maps be:

  • (a) on by default (and can be turned off in individual articles); or
  • (b) off by default (and can be turned on in individual articles); or
  • (c) on by default if another type of map is not already present (and can be turned on or off as required in individual articles)?
Note: This question applies to any infobox which has consensus to display automatic mapframe maps, either local consensus, or any consensus reached in Q1
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Q3. Position

[edit]
There is consensus against placing the map after the image. The status quo is that each individual infobox determines map placement based on local consensus, and editors were split between continuing that or standardizing map placement to the bottom of the infobox. Leaving aside the issue of quorum, there is no consensus that the map should go at the bottom of the infobox, and so map placement should be determined by local consensus at each infobox. — Wug·a·po·des​ 02:02, 13 August 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should mapframe maps be positioned towards the top of infoboxes (after any images), or at the bottom?

  • After the image. It should always be just below the main infobox image. That should be a standard, unless there is a strong need otherwise. Rehman 06:20, 24 June 2020 (UTC)[reply]
  • At the bottom. We want the reader to get to the dense detail of the infobox readily, not to have to keep scrolling down looking for it. Putting the map at the top - unless it is there instead of an image - seems to subordinate the standard infobox info to the map. Gog the Mild (talk) 10:29, 24 June 2020 (UTC)[reply]
  • At the bottom - the tops of infoboxes are often cluttered already with images (sometimes collages), and very often logos, seals, flags, and other identifying imagery. I think some identifying parameters are important early on, and the map would balance out the infobox best by displaying at the bottom. ɱ (talk) 15:44, 24 June 2020 (UTC)[reply]
  • At the bottom - non instantly serviceable info should come after real sourced data.--Moxy 🍁 19:44, 24 June 2020 (UTC)[reply]
Everything relating to the feature in question can be instantly serviceable. Points can be moved instantly by adjusting coords. As for shapes/boundaries - I created shapes for the articles: Goodale Park, High and Gay Streets Historic District, etc... by using Commons data files to hold the shapes, which can just be overlaid on top of a maplink map. Anytime we disagree with OSM shapes, we can create our own shape files, use, and edit them. ɱ (talk) 23:14, 24 June 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Q4. Wikidata coordinates

[edit]
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is consensus that yes, if users do not specify coordinates in a parameter, coordinates from Wikidata should be used. (non-admin closure) Levivich [dubious – discuss] 19:25, 25 July 2020 (UTC)[reply]

If users do not specify coordinates in a parameter, should coordinates from Wikidata be used?

  • Use wikidata coordinates —Should accuracy be disputed, that can be rectified with the coordinate template anyway. {{ping|Higad Rail Fan}} 05:29, 24 June 2020 (UTC)[reply]
  • Yes. If the local value is missing, Wikidata value should be used. This is a net benefit, and any rare issues of the Wikidata value being incorrect, can be fixed then and there. Furthermore, any changes on Wikidata now shows on the local watchlist. Rehman 06:22, 24 June 2020 (UTC)[reply]
  • Yes, of course. Now will maplink pull coords from an article, included elsewhere on the page, and not inside the maplink template? If not, is that a possibility to create? ɱ (talk) 15:46, 24 June 2020 (UTC)[reply]
  • Yes per Rehman. There are some issues with Wikidata having had values imported with a nonsensical precision, but they are easy to fix and that benefits other Wikipedias as well. --RexxS (talk) 18:30, 24 June 2020 (UTC)[reply]
  • Yes --Cornellier (talk) 12:46, 26 June 2020 (UTC)[reply]
  • Yes -- Explore setting a tracking category if infobox co-ordinates are present but do not (approx) match the wikidata values — GhostInTheMachine talk to me 08:36, 27 June 2020 (UTC)[reply]
  • Yes. This is exactly the sort of data that should come out of Wikidata by default (i.e. if not overridden). – Finnusertop (talk ⋅ contribs) 15:50, 28 June 2020 (UTC)[reply]
  • No, no, no for the usual reasons. I remain opposed to any further creep of Wikidata usage, including this. I would prefer Wikidata not be an option at all in this use case, but at the very least it ought not to appear by default. Wikidata has several core problems: lower/nonexistent standards for sourcing, easy for vandalism to sneak in since it doesn't appear on watchlists, potential for citogenesis since Wikidata often cites various Wikimedia projects, as well as making things even more confusing for editors. "Magical" code makes things much more confusing to the new editor, anon IP, or non tech savvy editor who sees an error and wants to fix it. It's best to have information all in one place (the article), instead of automagically pulling it from other locations that most people have no idea exists. A while back I had a summer internship in which I worked on a codebase where basically everything was chained through four or five levels of indirection - worst programming experience of my life. We already have a huge problem with editor recruitment and retention. Let's not make things even more confusing than they already are. −−− Cactus Jack 🌵 21:45, 30 June 2020 (UTC)[reply]
    These fears about Wikidata are unfounded. "It's best to have information all in one place" is why we centralize images on WikiMedia and on some data on Wikidata. As for "automagic" it doesn't seem to be a problem with interlanguage links. A "new editor, anon IP, or non tech savvy editor" editing coordinates is an edge case, not a use case. --Cornellier (talk) 13:48, 2 July 2020 (UTC)[reply]
  • Yes. Just as we use images from Commons and ILLs from Wikidata, coordinates are language-agnostic structured data that belong on WD. Encouraging our editors to add coordinates there instead of just locally helps improve WD and by extension other Wikimedia projects with little to no cost for enwiki. I understand the concern about lack of sourcing on WD, but in practice coordinates are rarely sourced on enwiki either (it's one of the few places we turn a blind eye to Google Maps-based OR), and WD at least has the functionality to do so. – Joe (talk) 13:43, 6 July 2020 (UTC)[reply]
  • Yes. --Izno (talk) 13:55, 6 July 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Q5. Switcher

[edit]
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is consensus for option (c), switcher functionality should not be enabled by default and can be turned on in individual articles. (non-admin closure) Levivich [dubious – discuss] 19:27, 25 July 2020 (UTC)[reply]

Module:Infobox mapframe allows for automatic Template:Switcher-style switching between multiple mapframes, either:

  • switching between three zoom levels: "zoomed in" (default zoom level, or minimum 3), "zoomed out" (zoom level 1, and "zoomed midway" (average of "zoomed in" and "zoomed out")
  • switching between geomask areas, either manually specified, or automatically found by recursively looking up location (P276) and located in the administrative territorial entity (P131) values on the page's Wikidata item. E.g. that item's city, that city's state, and that state's country

Should switcher functionality be:

  • (a) enabled by default for zooms (and can be turned off or changed to geomasks in individual articles); or
  • (b) enabled by default for automatic geomasks (and can be turned off or changed to manually-specified geomasks or changed to zooms in individual articles); or
  • (c) not enabled by default (and can be turned on in individual articles)?
  • Not enabled by default. The vast majority of articles are fine with just one interactive mapframe map. Any switching function should be opt-in. Specific groups of articles (such as countries or regions, for example) may have the geomask enabled by default, based on consensus, but that should be a separate discussion. Rehman 06:26, 24 June 2020 (UTC)[reply]
  • Not enabled by default, agree with Rehman, but I think a tutorial for instituting this switcher tool should be linked from/described in each infobox that supports it, easily allowing individual editors to institute it on their own. ɱ (talk) 15:49, 24 June 2020 (UTC)[reply]
  • Not enabled by default: There are many pitfalls in locations, especially when trying to iterate through a hierarchy when a region is split between two higher-level regions (see function _location in Module:WikidataIB for work-around code). It's essential that every implementation in an article is checked by an editor, and that means they have to take a positive action to enable the functionality. --RexxS (talk) 17:51, 24 June 2020 (UTC)[reply]
  • Option (c) not enabled by default — The map has [ ] and [-] and the switcher is rather bulky. — GhostInTheMachine talk to me 08:36, 27 June 2020 (UTC)[reply]
  • Not enabled by default. Ben MacDui 10:33, 27 June 2020 (UTC)[reply]
  • Option (c) it's takes up a lot of pixels and has functional overlap with existing zoom. Also implementation could be risky on mobile apps, which are an increasing share of clients. --Cornellier (talk) 13:56, 2 July 2020 (UTC)[reply]
  • I think I agree that one map is generally enough, so I suppose that puts me in c. --Izno (talk) 13:57, 6 July 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_comment/Mapframe_maps_in_infoboxes&oldid=972621293"