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 255,454 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)
Show zoomed in Show zoomed midway Show zoomed out
... infobox headings, labels, and data omitted ...

Point feature with switcher (auto)
Show Buchforst Show Mülheim Show Cologne Show Cologne Government Region Show North Rhine-Westphalia Show Germany
... infobox headings, labels, and data omitted ...

Point/shape features with switcher
Show Cambridge Show Massachusetts Show United States of America
... infobox headings, labels, and data omitted ...

Line feature

... infobox headings, labels, and data omitted ...

Specified coordinates

... infobox headings, labels, and data omitted ...

Custom mapframe
(George Floyd protests)

... infobox headings, labels, and data omitted ...

Template:George Floyd protests map has over 1000 data points, transcluded to ~20 articles, collaborated on by over 100 editors in over 1000 edits – without having to create a new image each time, and with advanced options like filtering by jurisdiction.
High Line has a map collapsed in the infobox.
Interstate 75 shows a map with data coming from Data:Interstate 75.map on Commons.

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]

Q1. Availability: Demonstration
`\|mapframe=`	Infobox with mapframe mapping capability	Infobox without mapframe mapping capability
`yes`	Mapframe map is displayed	No map; Unknown parameter error when previewing
`no`	Mapframe map is not displayed	No map; Unknown parameter error when previewing
ommited	Depends on Q2 consensus	No map

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. b uidhe 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. Reh man 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. --Rs chen 7754 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 Mac Dui 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

|mapframe= On by default Off by default

omitted

Demo

... infobox headings, labels, and data omitted ...

Demo
... infobox headings, labels, and data omitted ...

yes

Demo

... infobox headings, labels, and data omitted ...

Demo

... infobox headings, labels, and data omitted ...

no

Demo
... infobox headings, labels, and data omitted ...

Demo
... infobox headings, labels, and data omitted ...

Support option (a)—unless a good alternative for mapframe will show for an article; subject to editors' discretion via consensus. ((ping|Higad Rail Fan)) 05:38, 24 June 2020 (UTC)[reply]
Support option (b) per my comment above. Strongly oppose option a as it would lead to highly undesirable outcomes on articles on historical locations (such as Jasenovac concentration camp) where the subject would be shown ahistorically with modern borders. b uidhe 06:01, 24 June 2020 (UTC)[reply]
Support option (a) for articles that use basic static maps. Special cases such as historical maps or other special maps should be manually handled, such that they don't use mapframe (for now). Reh man 06:19, 24 June 2020 (UTC)[reply]
Option (b) per Buidhe. Peacemaker67 (click to talk to me) 07:36, 24 June 2020 (UTC)[reply]
Option (b) per Buidhe. Gog the Mild (talk) 10:26, 24 June 2020 (UTC)[reply]
Leave it up to each infobox On by default makes a lot of sense for roads but not for historical articles. --Rs chen 7754 18:17, 24 June 2020 (UTC)[reply]
Support option (b) per my rationale in Q1. --RexxS (talk) 18:27, 24 June 2020 (UTC)[reply]
Support option (b) care and oversite should be taken when anything is added.--Moxy 🍁 19:46, 24 June 2020 (UTC)[reply]
Leave it up to each infobox per User:Rschen7754. Please bear in mind the note to the above question that This question applies to any infobox which has consensus to display automatic mapframe maps, either local consensus, or any consensus reached in Q1. In my opinion this renders moot the opposition given above citing the example of Jasenovac which uses the Infobox concentration camp which is historical. E.g. Ancient Rome uses Infobox former country. Unlikely those IBs would opt in at all. --Cornellier (talk) 12:39, 26 June 2020 (UTC)[reply]
Option (b). Wrong, misleading, or otherwise inappropriate content shouldn't magically appear in articles without at least one editor knowing about it and responsible for deciding to include it. Alsee (talk) 21:20, 26 June 2020 (UTC)[reply]
Option (b) — GhostInTheMachine ^{talk to me} 08:36, 27 June 2020 (UTC)[reply]
Support option (b) Ben Mac Dui 10:33, 27 June 2020 (UTC)[reply]
Support (a). Our current locator maps are terrible - you can't cleanly copy/paste or zoom them, because the locator is an overlaid HTML element. And you certainly can't interact with them. They need to be sent to the dustbin of 1990s-era relics and replaced with this more modern solution. This, that and the other (talk) 11:43, 6 July 2020 (UTC)[reply]
Option (a). I primarily edit articles on archaeological sites so I do appreciate the concern about the OSM basemap being inappropriate for historical places. But these articles are a minority compared to ones on contemporary populated places. It makes more sense to set the default for the most common case and override for special cases (i.e. historical places). Besides, the mapbox functionality could easily be just as useful for historical places if we had the option of different basemaps, e.g. historical boundary maps and topographic maps. – Joe (talk) 13:38, 6 July 2020 (UTC)[reply]
I think I tend toward a per Joe. --Izno (talk) 13:59, 6 July 2020 (UTC)[reply]
Support (a) as nearly all of these infoboxes would be used for pinpointing a building/monument/place's current or former location. Infobox military conflict might not use it as frequently, but without coordinates, a map wouldn't display anyway, right? $ɱ$ (talk) 15:11, 6 July 2020 (UTC)[reply]
Option (a) in general as being appropriate for most cases, per Joe, ɱ and others – but allow specific infoboxes to be off-by-default (based on consensus for that at individual templates) - Evad37 [talk] 02:25, 9 July 2020 (UTC)[reply]
Support (a) . Easy for editors to choose that -- naveenpf (talk) 02:55, 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.

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?

Q3. Position: Demonstration

Positioned towards the top

Positioned at the bottom

Demo
image caption
map caption
... infobox headings, labels, and data omitted ...

Demo
image caption
... infobox headings, labels, and data omitted ...

map caption

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. Reh man 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]

Where they are already per infobox. Let's give IB maintainers options, but the position in the IB seems out of scope for the discussion here. In any case the position in the source code is one thing, the final rendering is another, e.g. on mobile devices. In general the final layout the user sees and the data structure of the IB should not have a 1:1 link since we don't know what presentation will be used.--Cornellier (talk) 12:43, 26 June 2020 (UTC)[reply]
Where they are already I don't see the need in mandating a specific position across the entire site. --Rs chen 7754 18:04, 26 June 2020 (UTC)[reply]
At the bottom — playing with the map is generally an exit path, so the map should be after the "data" — GhostInTheMachine ^{talk to me} 08:36, 27 June 2020 (UTC)[reply]
Neither I don't support the idea that there needs to be a wiki-wide position on this topic. Ben Mac Dui 10:33, 27 June 2020 (UTC)[reply]
Er, I'm pretty sure the question is "if present, where would it appear". I thought that was implicit but user:Evad37 you might wish to reframe the question. --Cornellier (talk) 13:28, 2 July 2020 (UTC)[reply]
Each infobox including a map already puts it in a certain spot. I assume it's possible for these maps to be placed similarly. If not, the bottom. --Izno (talk) 13:54, 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.

Q4. Wikidata coordinates[edit]

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?

|coord= Using Wikidata (if coords not specified) Not using coordinates from Wikidata

omitted

Demo

... infobox headings, labels, and data omitted ...

Demo
... infobox headings, labels, and data omitted ...

((Coord|47.31|N|5.04|E))

Demo

... infobox headings, labels, and data omitted ...

Demo

... infobox headings, labels, and data omitted ...

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. Reh man 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]

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)?

Q5. Switcher: Demonstration

Switcher

Examples

zooms

Demo
Show zoomed in Show zoomed midway Show zoomed out
... infobox headings, labels, and data omitted ...

Demo
Show zoomed in Show zoomed midway Show zoomed out
... infobox headings, labels, and data omitted ...

geomasks

Demo
Show Buchforst Show Mülheim Show Cologne Show Cologne Government Region Show North Rhine-Westphalia Show Germany
... infobox headings, labels, and data omitted ...

Demo
Show Western Australia Show Australia
... infobox headings, labels, and data omitted ...

none

Demo

... infobox headings, labels, and data omitted ...

Demo

... infobox headings, labels, and data omitted ...

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. Reh man 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 Mac Dui 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.