Can these maps support multiple points? If so is there a maximum (either a technical maximum or makes the user's computer go really slow maximum). I can see maps like this would be amazing on articles like World Heritage Sites or others that describe a large amount of places that all have Wikipedia articles. Here is a map of all the World Heritage Sites generated using a Wikidata query.
Talk:Wikimedia Maps/2015-2017/Conversation about interactive map use
That Wikidata query is using the wikimedia map tiles (https://maps.wikimedia.org), but I don't believe the same can be said for the points of interest. @Yurik can you confirm I'm right here?
As for the number of points, this might be a good step to test for as we move forward. A 'stress test' for interactive maps to see what the technical limits would be. If a upper ceiling could be identified, perhaps even presenting editors with some sort of notification as they approach that number in a map instance.
Looking at that Wikidata query has me thinking @Yurik, could we create a <mapframe> export from WDQS? So people could copy/paste a map like that into a wiki page?
John_Cummings, CKoerner_(WMF), we can support many points, e.g. this page has about 10, but you can do many more by simply having a list of markers like so:
{
"type": "Feature",
"geometry": { "type":"Point", "coordinates":[37.8013, -122.3988] },
"properties": {
"title": "Exploratorium",
"marker-color": "228b22",
"marker-symbol": "museum"
}
},
...
I have been thinking how we can integrate the result of a wikidata query directly, without doing any copy/pasting, but this is still an open discussion (see phab ticket). Also, at this point we have no way to draw just the points - we only support large markers. Lastly, we need to be certain that a large number of markers is going to be useful, and not just to look at it once and go "wow", and never use it again for anything actually useful.
This is very interesting, thanks. Is there any plan to support other kinds of of systems to show many points in a way that makes them easy to understand e.g clustering or heatmaps?
I wish there was, but so far I only heard WMF is halting anything map, graphs, and interactive-related without any plans/goals/ideas for the future with regards to interactive content.
Please share examples of article types, categories, or other use cases where interactive maps might be useful. Include links to the example articles.
wikiloves monuments article or National Register of Historic Places article, with a locator map in the infobox.
Cuban Friendship Urn, Lieutenant General George Washington (statue), British Museum, Kew Gardens station (London), Fort Ross, California
Minor cleanup by yurik, hope it's ok
Accidents, disasters. Where did the plain crash, which reactor exploded etc.
slowking4, thanks for the links. I think your examples all fall under "show the location of a monument-or-building sized object on a street-level map. Ideally we should show (possibly in one image) the globe (political, country outlines), the country (also political, with some major highways and possibly rivers), and the street-level map. When clicked, the street map becomes interactive so that viewers can easily locate themselves on it (we should add "show user's location on the map" capability when in full screen mode - should be useful for mobile viewers)
yes a streamlined "show user's location on the map" would be useful for public art for mobile users, we have been cobbling together OSM screenshots + gps links on list articles. an integrated "public art near here" or historic buildings near here is a better solution.
Plant and animal species. Imagine we could fill in distribution maps for each species using distribution data loaded from Wikidata. Not sure this is within scope of this project, but I still wanted to draw attention to it.
Absolutely in scope. I would love to provide a way to draw regions like that. What kind of a base map would be better suited for this, and will you ever need to zoom-in, and if yes - how far? Realms are very imprecise, plus they change with time. I don't think you will ever want to zoom to the street level - perhaps zooms 0..8 should be enough? Also I guess that land type is important (desert, tundra, rainforest, etc), and hillshading (its important to see mountains for such maps). But at the same time you want to be able to relate to the political location - at least countries / states / provinces and major cities.
This would be great, you can currently generate maps from Wikidata queries, e.g here is a query for all the World Heritage Sites. I assume with a little fiddling you could get it to output links to specific language Wikipedia articles rather than the Wikidata items. https://query.wikidata.org/#%23defaultView%3AMap%0ASELECT%20distinct%20%3Fsite%20%3FsiteLabel%20%20%3Flocation%0A%0AWHERE%20%7B%20%0A%20%20%0A%20%20%3Fsite%20wdt%3AP1435%20wd%3AQ9259%20.%20%0A%20%20%3Fsite%20wdt%3AP625%20%3Flocation%20.%0A%20%20%0A%20%20%0ASERVICE%20wikibase%3Alabel%20%7B%0A%09%09bd%3AserviceParam%20wikibase%3Alanguage%20%22en%22%20.%0A%09%7D%0A%7D
This post was hidden by Yurik (history)
Hello. Although I understand that historical maps are regarded as something of the future, I still would like to emphasize how much they would help my work. As I write about the German history of the 19th century, I deal with many different states with different borders through the times. Mostly I use the general map of Germany for 1815-1866, but territorial changes are difficult to show. I have also downloaded blank maps of the region and era, but always when borders have changed I have a problem. Also, when I fill in colors it doesn't look as neatly as I'd like to. For the readers it would be great if they have an interactive historical map in order to show the location of a state or city, and if the reader can choose the time and also the scale of the map in order to understand where within a state, within Germany or within Europe the citiy is.
Articles about collections of geographic objects would greatly benefit with a dynamic map plus a geojson / topojson overlay.
Example in this page https://it.wikipedia.org/wiki/Rolli_di_Genova I designed the map with Tilemill, an older version of osm bright and a postgis query
- how to host geojson content?
- how to create it? There could be an editor similar to umap https://umap.openstreetmap.fr/ for this (or a customized umap instance)
Maybe articles about rapid transit (subway, metro, MRT, etc) lines.
I'm a complete noob as far as map-related-"technologies" are involved but... I would use them in articles of monuments, buildings, disasters and "punctual" entries. It would be nice using them for articles of streets or subway lines too, loading a hypothetical Wikidata property where it would be stored street's vertices (coordinates). I don't know if it's possible taking that stuff directly from Openstreetmap. Something like that. Anyways, thanks for your awesome work, folks!
A couple of more suggestions based on the use case of a a researcher/student exploring a topic where location is a focal point.
They user want results of articles and article sections to be visible in a map view so that they can use the map view as a way to filter/explore further more articles they are interested in.
Some example articles:
- Similar to previous suggestions, articles about a group of locations would be great to show on a map; such as in the article about Ivy league universities or about the Colleges of the University of Cambridge.
- Plotting the travels of Magellan
- Mapping the locations along the route in the plot of the novel On the Road
One strong use case I can see is articles on battles (and similar events), where the local geography is very important. These articles often involve a lot of discussion about "a valley with forests to the north and west, and two bridges over the river in the east". These points usually won't have articles themselves, and may not be of any interest outside of this topic, but being able to highlight them on a map in this context is useful. For example, in this article it would be good to have a map identifying the geography, the position of the main landmarks, etc. Where we do have coherent maps - such as the American Civil War articles - it tends to make them a lot easier to follow.
This is an example of a regional map I attempted for an article some years ago - very crude, as it's taking a 1900s map and highlighting relevant locations. If I could have simply dropped four pins onto a pretty map, this would have looked a lot nicer. As soon as the extension is enabled on enwiki, I'll try and replace it!
These types of articles would particularly benefit from a couple of additional features:
- the ability to add lines and polygons, rather than just points, eg to show a front-line (I know this is a major request!)
- a topographic/geographic base layer. On a small scale, it can be very confusing to use a current map which may have a suburb or motorway now built over a site that was still open land at the time. Being able to use a topographic-only layer (contours, rivers, perhaps forestry) would help avoid this problem.
OSM uses Web Mercator projection, which is fine for most uses. As long as it correctly interacts with location markers its probably better than the equirectangular projections typically used by existing location maps.
However, other projections are far better for specific uses. The polar regions need a different projection, and are the most extreme case. The current preferred projection for global maps is the Robinson projection, and maps at the continental and national scale benefit from alternative projections.
Personally, I'd prefer a static map on a good projection to an interactive one on a poor one.
This sounds to me like a great example where a static map, in the proper projection for the intended use, would be preferable over an interactive map using Web Mercator. I'll add it to the list of Pros and Cons.
Agreed - but it would be good in future to allow other projections. An article like Terra Nova Expedition could really benefit from an interactive map.
The interactive web map could be set up to use a different projection than web mercator http://kartena.github.io/Proj4Leaflet/
@Nilfanion:, @Sabas88:, @TheDJ: @Jheald: you might like this demo -- hopefully will be available soon in production as well. All fully dynamic, from OSM database and Wikidata, using graph extension. Try to hover over the state capitals. And yes, the map of USA uses a different projection.
Looks like a decent start. :)
However, the Indonesia and UK maps are particularly poor because the OSM areas do not reflect the coast. The shapes really need to be clipped to the coastline (ideally high water) before being displayed. Major lakes such as the Great Lakes should also be visible.
This reflects one area where OSM data is currently low quality - offshore boundaries. Ideally the maritime boundary should reflect something meaningful, like claimed territorial waters or the EEZ, but they look like more a crude approximation of a 12-mile limit. IMO better not to display this at all than show it as on the Netherlands map.
A stylistic concern - it would be useful to have option to display non-subject areas (such as Canada on the US map). It can be useful to clearly show the relationship to surrounding areas in certain contexts, while on other maps its irrelevant. That is a binary choice, which depends on the intended use of the map.
Also another concern that you may not have considered - POV. Argentina is a good case in point - what about the Falklands, or Antarctica?
I want thank everyone for their participation. I put together some notes on what the Maps team has learned. This helps to identify what the team should focus on in the near future and what we learned from talking with you all. I hope the conversation here will continue.
If you have any feedback please let me know.
Button labels, legends, and some of the maps content labels should be multilingual. --~~~~
A longer term feature request - it would be great to allow production for objects other than the Earth, such as the Moon and Mars. The celestial sphere would also be highly valuable - to illustrate articles about the stars.
I strongly support this proposition. It would be very useful for Astronomy projects on the various Wikipedia projects.
One of the things to discuss is the style of the map - colors, borders, labels, etc.
For those participating, does it make sense to follow these conventions (adopted by English and other wikis) to define the styles of our default/general location map style?
I'd say that's a good starting point. The recent US convention might be more precise as it provides an extension for roads and urban areas. The basic principle of three background shades (fefee9 for area of interest, f6e1b9 for related areas and e0e0e0 for un-related areas) is the main thing to retain - that is the key element of the wiki house-style.
Boundaries: do not show when they coincide with a coastline, and make them as accurate as possible. The French national map on the examples page really suffers on both counts as a result, and the Rhône-Alpes map suffers from generalization when zoomed in too far.
Labels: Please translate according to the language preferences of the user - or the default of the project being used to access the map. For instance, a user on en should see "Moscow", a user on fr "Moscou" and on ru "Москва". Including the local version could be optional?
A different approach will be needed for showing the area of interest (as a solid red background will get awful if zoomed in too far), and points of interest need discussion. For instance what style pushpin, and please allow different styles within a single map as is used here
Is there any thoughts on supporting embedding WMS or/and TMS layers? This would be very useful in articles where for example historic maps could provide context to an article. Such layers could be provided by for example Commons through Wikimaps Warper. I believe that there is many articles that could benefit from such a feature.
@Yurik (WMF) we would relay like to investigate this for the Warper IEG, I personally intend to create a userscript to locally showcase the possibilities with this type of feature.
Tell me more about how you could see layers being used! This sounds interesting.
Here's an early rough POC https://fi.wikipedia.org/wiki/Teemasivu:Aleksanterinkatu/Artikkeli
The map tiles are served from warper.wmflabs.org
The example linked by @Susannaanas is a good example of original(historic) content being displayed on a interactive map, allowing other perspectives to be visualized.
I believe there is a lot of both articles at wikis and content on Commons that could benefit from such a feature.
Hopefully I can get a cool and useful showcase done over the upcoming weekend.
Isn't TMS the same as the regular tiles we have? WMS does have some interesting features, but it seems like it covers most of what geojson does, and unless it is fundamentally different or I am missing something, I would really love to keep to as few formats as possible, and offer an easy way to convert the data to one format when saving. Otherwise we will have the same mess we have with the WP API - which allowed (thanks to my shortsightedness) 8 different output formats that we now have to support instead of improving them.
@Yurik, it's the same. But I would like to have the possibility to add a second layer on top of the default one from sources such as the Warper. No need to add support for new formats.
@Abbe98:, this all depends on the location of the data. For security and privacy reasons, no wikis can access any data outside of the WMF production servers. Which means the Warper needs to store the data somewhere on the wiki itself. We definitely want to be able to store such data on wiki, but need to figure out how. On the other hand, TMS implies there is another tile service - but the only allowed service like this would be our Kartotherian maps tile server, so we still need to figure out how to serve that content.
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:
 |
 |
_p2.300_-_Map_of_Northumberland.jpg) |
 |
| 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.
Interactive maps become less useful as the image displayed gets smaller. When they get below a certain size, it would be better to just freeze and provide a static image.
One cause of this is the buttons. When the map is too small, they will cover up too much.
An additional button that could be very useful in the context of WP articles: A 'reset' button that lets the user return to the initially presented map and undo any panning/zooming they may have done.
I will probably make a number of other small posts as I think of them.
The default thumbnail size for images is 220 pixels wide if I recall correctly. When using the visual editor the Map defaults are 400 by 300 pixels. In the documentation for interactive maps, and maybe in our defaults for editing, would it be useful to recommend a minimum size? Is 400 by 300 a good recommendation?
It doesn't sound unreasonable as a first guess. An interactive map should be substantially bigger than a static image to allow exploration through it.
We do plan to make a static image service, plus i wonder if something like the graph extension with some map data would be better suited for it. I also wonder how small images will cope with mentioning copyright.
Have to say I'm not keen on having the copyright information prominently visible in article. We do not do that for 99.9% of images, and having that on a file description page is deemed sufficient.
Changing that for this one type of media looks unseemly, and has potential to irritate contributors of other media ("why attribute them but not me?").
I realise that may not be viable, but reducing the size to the minimum amount may be beneficial. Static images ought to behave like existing media - with a click through for that info.