Topic on Talk:Wikimedia Maps/2015-2017/Conversation about interactive map use

It's all very well to talk about interactive maps, but in my view there is also a continuing role for static maps -- eg, maps for each of the four types that we have a property for on Wikidata

These are all useful -- and in particular, can be useful to offer as images on Commons, that people can find and use for other purposes (Commons and Wikidata are here to provide content for the whole world, not just for Wikipedia).

It seems to me for many uses the maps do not need to be dynamic. But instead it may be valuable to make sure they are re-generated every 12 months, or every 3 months, or as triggered by an editor, eg to show a new motorway that may have been opened.

I am particularly dubious of the idea that seems to be prevalent in the RfC page of trying to fit everything into a "one size fits all purposes" single mould. Instead I think there is a value for continuing to offer P242-style maps, and P1943-style maps, and not P1621-style map to create everything.

An important part of the P242 and P1943 maps are the inset maps found in corners. A simple macro language should be found, to specify the design of the main map with any inset maps, to allow them in turn to be easily regenerated and updated.

Summary of Wikidata map properties below from d:Template:Map property comparison:

Comparison of map properties

locator map image (P242) is a map suitable for an infobox for the item itself, showing where an entity is located in a wider area	location map (P1943) is a largely blank map, suitable for a push-pin to be added in an infobox for a place within the item -- the most major roads, railways and rivers are marked, but not the details of most settlements.	detail map (P1621) is for a detailed map or plan of the item, which is probably already too 'busy' to allow further annotation	relief location map (P1944) for a relief variant of the location map

Other specific map types might be added -- eg maps to show precipitation catchment area of river systems.

@Jheald This is really useful information on the use of static maps. Thank you for taking the time to share. When this page was being put together the goal was to organize a conversation around interactive maps in the hope that they will be at least as useful as static maps, not to replace them carte blanche. :)

Maybe I didn't word things well. Our biggest goals is building tools for editors that makes adding interactive maps easy, and making sure those resulting maps have a good community-driven style for their intended use.

If you think the language is a little misleading, please correct it.

I suggested once that we could put some of these static maps in a separate layer of a live map. Especially for the older maps that would be very interesting, but it would require quite some infrastructure work probably.

Another common element i see returning is that often we have 2 zoom levels in one 'map'. It would be interesting to see if we could do something with that for live maps. (animation ?)

A dynamic map is a map that could tell a "zoom-in" story. For example, an article about 2016 US elections may have a per state voting map. On mouse-over, it would show state statistics. On zoom-in, the map would show per-district voting.

I don't think we should get rid of the static maps. But we should always try to tell a "better", more informative story. So the static maps should only be used when article's quality would not improve from panning and zooming.

Lastly, I think the Graph extension could be used to draw static maps because it allows much richer community-contributed visualizations and interactions. The maps service could provide the needed geodata. The graph would query it by giving a wikidata ID. TheDJ, I think <graph> could fairly easily draw multiple zooms in one image.

I think both static and interactive maps could, and should, be used in developed articles. They are different tools for different roles. A static map is better at delivering a simple fact (or a limited set of them), while an interactive map can provide immersive understanding.

That suggests to me the single most common use of maps - infobox-style locators - are best done via static maps, and attempting to provide this function via interactive maps is the wrong approach.

Where interactive maps are far better is it allows in-depth exploration. This should probably be done by a relatively large map some distance into the article (maybe even a full section at the end), not a small image in the lead.

As an example, the infobox of Lyon should retain static maps - to show where Lyon is. A large interactive map should be provided later - it allows the reader to explore what is in Lyon.