Suggestions

Hi @Yurik (WMF). I've just been playing with this and want to use it on some en.wp articles I've written. Nice work - love having maps!! My first test is on Australia Forum with a simple single-point map.

Here's some things I think this tool really needs to make it more usable:

• From trial and error, I've discovered that the 'world map' in the bottom right corner only displays when the zoom level is 6 or higher. Could you make that clear in the documentation, or make an option to turn on/off at any level of zoom?
• It's clear from the example above that the map should not be taking up the whole pagewidth, but 'float' and have the text wrap around it. Can you please add the ability to have the map center/left/right aligned - like the way images can be.
• Relatedly, can you please allow me to adjust the size of the map. In some cases I will want it to be bigger (e.g. a many-point map taking up the whole width of the page) and in some cases I will want it smaller (e.g. When I try placing this template inside an infobox it makes the infobox take up half the width of the page.
• Please allow the points (the red dot) or, when they are used, the labels (the 'text' field) to be linkable. If I have 20 points on a map I want the user to be able to click on them to go directly to the article or section about that item.
• Captioning the whole map to give an explanation of what the points refer to is important. This is especially when it is a multi-point map showing the results of a query
• Can you explain the relationship of this to other geocoordinate templates already being used on WP which have the geo-hack tool popup when you click on them?

Thanks Wittylama (talk) 13:46, 9 October 2016 (UTC)

Wittylama, thanks for the awesome feedback!

• There are width= and height= params you can use for the map size
• Clicking might need some thinking, TBD
• We are working on getting a <maplink>-based replacement for the Geo hack tool, so that the map is much more responsive and stable. That map will be highly interactive (zoomable/panable), but it won't have as much data-visualization power an the ones made with the <graph> tag. This map was made using the graph tag, so on one hand it has much higher potential with complex visualizations, but on the other it does not support moving or zooming of the map itself. Eventually I do hope that we can get them merged to get both benefits, but there is no ETA for that. Yurik (talk) 17:09, 9 October 2016 (UTC)

@Yurik (WMF)

• the width and height parameters do nothing. I input very large, and also very small numbers to test it - no change. example: https://en.wikipedia.org/w/index.php?title=Australia_Forum&type=revision&diff=743608867&oldid=743379046 Perhaps these parameters refer to the size of the icon that is shown, not the size of the map itself? I suggest that a parameter be added to indicate the pagewidth the map should occupy - not in terms of pixels but in terms of percentage (e.g. "mapwidth": 70, would indicate that the map ought to occupy 70% of the pagewidth.
• The ability to create an annotated map, on Wikipedia, implies to me at least that the ability to LINK those marks/names to something. This is a critical feature. I suggest that: for manually added marks then the user should be able to manually determine the destination of each link. For wikidata generated marks, then the associated Wikipedia article for each wikidata item if it exists should be linked and the Wikidata label should be visible on hover.
• As you can see at my example usage (Australia Forum), the ability to 'float right', and for the text to 'wrap' around the map, is the most obvious missing feature. Is that what this is referring to, I'm not sure: https://phabricator.wikimedia.org/T147768 ? Wittylama (talk) 11:22, 10 October 2016 (UTC)

@Wittylama, ah, no, the width and height are template parameters, not params for the icons. For example, try this: {{Graph:Street map with marks | lat=37.8 | lon=-122.4 | zoom=5 | width=100 | height=100 | { "lat": 37.8, "lon": -122.4 } }}. We are working on the floating graphs - Phab:T147768, should be done soon. The linking is probably the hardest problem - the graph system itself does not yet support it, but I could do some on-wiki magic to implement that.

Yurik (talk) 00:33, 14 October 2016 (UTC)

I'd also love the option to turn off the context-map in the lower right corner. It's helpful in some cases but usually clear from context - if the article's about somewhere in Italy, then the reader might reasonably be expected to know where the country is. Andrew Gray (talk) 21:14, 9 October 2016 (UTC)

It's possible to do, but I just looked at your changed in

En:Battle of San Marino#Prelude

, and I think it would be much better with the mini map - some people might struggle with where they are at, especially if they went directly to the paragraph in question. On the other hand, we might want to make it possible to draw a zoomed-out map, e.g. whole Italy with a dot, because otherwise it is not very clear where it is. Yurik (talk) 02:22, 10 October 2016 (UTC)

In any event, even if you don't provide an ability to turn the global 'mini-map' on/off manually, it would still be nice to include in the documentation the fact that the mini-map will be displayed by default at a zoom level of 6 or higher. Wittylama (talk) 11:22, 10 October 2016 (UTC)

@Wittylama, I added "minimap" parameter (allows 1/0 values, or true/false), and written a usage example (first one in the samples). Also added parameter documentation at the bottom. Yurik (talk) 02:24, 14 October 2016 (UTC)

As a followup - how is it possible to use this system for Wikidata queries that don't have a specific property for them? The example given in the documentation uses the Cultural Heritage Armenia ID (P3170) property to identify all the items. What about when there's not a neat property specifically for the requisite list? For example, there's a lovingly crafted map at List of hydroelectric power stations in Turkey but in order to replace that with this tool and using a Wikidata query I would need (on top of all the features I mentioned above), the ability to create queries - e.g. all instances of -> 'hydroelectric power station' + location ->'turkey'. )Or something similar). Is that possible?

The particular article I would like to try this on is List of public art by Oldenburg and van Bruggen which does not currently have a map, but each artwork in the list DOES have a wikidata item with 'creator', 'instance of' and 'coordinate' statements. Wittylama (talk) 14:24, 9 October 2016 (UTC)

@WittylamaHeh, seems like it's a tricky one. Q677072, Q677072, and Q1090288 are all hydroelectric dams according to the list, but they are all classified as either instance of Dam Q12323 or a subclass thereof. A dam could be, but not required to be a hydro-electrostation. There are only 4 wikidata items that are qualified as hydropower dams, or a subclass thereof: query. In short, the data is not that great yet to generate a good list, and might need some work. Yurik (talk) 03:07, 10 October 2016 (UTC)

You seem to have misunderstood my point @Yurik (WMF) - I only mention the Hydro power in Turkey article as an example, and equally the Oldeburg art is another example. I realise that any wikidata-generated *anything* will need to ensure that the data itself is correct/consistent in order to generate a good result. My question is: HOW to make this map template generate such a map? But your answer only refers to inconsistencies in the data of the specific example I gave.

To reiterate my question, then:

Is it possible to use this map tool to populate a map with "marks" using a wikidata query, where there isn't already a specific Wikidata property for the precise list of items I want to display? The example given in the documentation shows all items with a unique identifier to a specific property (Armenian Heritage ID). What do I do if there is NOT such a specific property which exactly covers the needs of the map I wish to create? Wittylama (talk) 11:03, 10 October 2016 (UTC)

@Wittylama, sorry, I didn't explain it properly. This template allows you to draw absolutely any query result, but it up to the editor to construct a proper query to get specifically the data they want. This template does not understand anything about the Wikidata query - as long as the query returns fields (columns) that the graph recognizes (i.e. lat, lon, img, width, height, text, textFontWeight, textFontSize, textColor, textAlign, textDx, ...), it will simply work. To construct a query, one would have to know SPARQL, and one would have to understand how Wikidata's data is structured, which properties are set, how you can filter the data to just get what is needed, and many other fairly complex questions. How you create that query does not relate to this graph - graph will simply get the results of whatever query you write. For the documentation page, I simply adapted an easy query that I saw on Twitter. For your examples, we would have to find someone from Wikidata community to write it for us. Yurik (talk) 02:34, 14 October 2016 (UTC)

Vega vs. mapframe

I know mapframe is not quite ready for prime time (i.e. Wikipedia) yet, but is this intermediate step really necessary? I'm worried about the confusion all the different way to display maps will cause. Strainu (talk) 21:01, 9 October 2016 (UTC)

@Strainu I would love to avoid confusion myself, so let me clarify, and I would love to get any help & feedback on how to keep the confusion to the minimum.

The <mapframe>/<maplink> technology is targeted exclusively to showing interactive (zoom+pan) maps, and telling a story about that map by drawing extra data on top of it, like points of interest (pushpins), lines, and shaded areas (polygons). It also has good support for popups - clicking the extra data brings up a bubble with some text or images. On the other hand, the <graph> tag is a very generic data visualization technology based on D3/Vega. It can be used to draw everything from a very simple bar chart to complex infographics. Vega can directly use images from Commons, data from PageViews and Wikidata API, and it can also get static snapshots from the maps server. It would be very hard to make it into a movable/zoomable map, but it is very easy to combine several data sources like the map and wikidata, and draw some map-based visualization.

In short, these are two fundamentally different technologies that can both be used to show the basic map, but will allow you to do very different things with it. <mapframe> will always be substantially easier to use, but limited in the information presented. <graph> will allow you to code up any complex image, but it won't give the same map-specific functionality. Yurik (talk) 01:12, 10 October 2016 (UTC)

@Yurik, thanks for the response. Can you then please explain what Phab:T133247 is about? I thought this was precisely about static images, and since it's a subtask of Phab:T138057, I supposed it was about mapframe maps. Strainu (talk) 09:07, 10 October 2016 (UTC)

@Strainu, the snapshot capability of <mapframe> is simply an internal optimization. When you search Google for a location, it shows a static map image in the upper right corner, but if you click it, it become interactive, we need to do a similar thing - <mapframe> would show as a static image (which will look identical to the "live" one), and when you click it (or possibly even move the mouse over it), it will download all the needed code and tiles and data, and it will become interactive. This is needed to make Wikipedia articles much faster, and the servers to have a much lighter load. The maps snapshot service will have exactly the same capabilities as the <mapframe> itself. The <graph> on the other hand allows much much more, but at the expense of programming (vega) difficulty, and also it will not allow moving or zooming the map. Yurik (talk) 17:17, 10 October 2016 (UTC)

Discussion and Floating behaveaur

Please have a look at en:Module talk:Location map.

Would it be possible to get a floating parameter which would work similar to normal pictures (floating a map to the right with similar margin as normal picture frames)? In this context descriptions could also be added underneath to simulate normal wiki pictures.

Thank you very much! T.seppelt (talk) 18:29, 16 October 2016 (UTC)

See Phab:T147768 - we should have it ready within a few weeks, at which point graphs will behave the same as images and mapframes - auto floating on the right. Yurik (talk) 19:17, 16 October 2016 (UTC)

Great, thank you. T.seppelt (talk) 05:28, 18 October 2016 (UTC)

Changing all the dots color

Is there any way to change all the points from a red dot to, let's say, an airport symbol? Theklan (talk) 14:42, 23 October 2016 (UTC)

Hi, I just updated the docs with some more info. For an airport, you can use some icon image from Commons. Yurik (talk) 19:18, 23 October 2016 (UTC)

It's not clear where to change it for all the icons at the same time. For example, if I want all the red dots to be an airport symbol, but it loads automatically from Wikidata... I can't put shape = foo in the top part and make it work. Theklan (talk) 20:51, 23 October 2016 (UTC)

@Theklan when you are using wdqs= parameter, the SPARQL's output should include those fields. So if sparql has "img" field with the image URL, it will get used. The same way you can have a "color" field which will change default red color to some other, possibly different for each dot. Yurik (talk) 01:40, 24 October 2016 (UTC)

Could it be possible to document an example of a SPARQL query in which all the dots are a, let's say, airport symbol? Theklan (talk) 13:58, 24 October 2016 (UTC)

Drawing the boundaries of a given Wikidata item

Hi,

is it possible to draw a map showing the boundaries of a country (like Germany, based on the Wikidata ID Q183 as parameter) plus the position of a city etc.? How does painting shapes with Wikidata / OSM data work?

Thanks! T.seppelt (talk) 17:57, 31 October 2016 (UTC)

Hi @T.seppelt. This template does not (yet) support it, but <graph> allows it. One would have to do something similar to this graph - Template:Graph:Country with regions and capitals - it draws geoshape from the maps service. Yurik (talk) 21:49, 31 October 2016 (UTC)

Language of labels

Can there be an option to override the default OSM label (in the local language of the area shown), with either another language or to supress them entirely?

On WM projects, the local language of the project (eg English on en.wp or German on de.wp) would be the ideal default. The OSM-default labels are borderline useless for English users when the only text is "المملكة العربية السعودية" or "上海市" Nilfanion 10:53, 5 November 2016 (UTC)

@Nilfanion, this is one of the biggest asks at the moment - T112948. Not exactly sure yet when we can get it resolved, but we will try to figure something out soon. Yurik (talk) 11:53, 5 November 2016 (UTC)

template front end

I have written a template called OSM Location map on en:wikipedia to put this template map into a frame, and do various other useful bits and pieces. At present it allows 10 markers to be shown, and is designed specifically for manual use, rather than the wikidata facilities you also provide. I am aware that there are probably parallel developments going on, which is fine if this gets supplanted, but it seemed like a good chance to find out how these maps might start being used. I have taken the chance to include a <maplink> link so that users can both see the static page map as optimised by an editor and link through to a more interactive one.

One strange bug I have come across is that when previewing a page under development, the labels all look very nice, with a fine-lined font, and with lots of colour options. But when changes are saved, all the labels become a clunky font instead, and most colours switch to black (or sometimes to the shape color. There are examples on the doc page for template:OSM Location map, or see En:Old John . I get the same problem when calling the Graph: template direct - the labels - especially small font sizes - look far better in preview than for real. RobinLeicester (talk) 00:52, 9 November 2016 (UTC)

Fonts is an old problem we haven't solved yet - Phab:T127683. Also, graphs will soon get an automatic frame - Phab:T147768. Lastly, I really hope we will get <mapframe> to support most of these usecases eventually, so we can have the best of both worlds. Yurik (talk) 00:59, 9 November 2016 (UTC)

ExternalData

Is there any way of being able to include OSM external data directly into Graph:Street map with marks in the way you can with <nowiki><maplink>. Being able to show a particular administrative boundary, highway etc would be really valuable. Thanks. RobinLeicester (talk) 22:17, 12 December 2016 (UTC)

It is possible, because graph extension supports geoshapes requests, but it has to be implemented in the street_map graph. I actually do something similar in this demo: Template:Graph:Country_with_regions_and_capitals. Yurik (talk) 10:11, 14 December 2016 (UTC)

Used in infoboxes

FYI, I have used this graph template in the "Infobox building" in elwiki and now we have some dozens of articles displaying locator maps with this. It works great! Geraki (talk) 10:03, 5 January 2017 (UTC)

Awesome! I have been experimenting with using the new datasets feature, so that the same data can be shown on multiple pages/wikis, auto-localized --

See or edit source data. -- uses https://commons.wikimedia.org/wiki/Data:Sandbox/Yurik/Street_map_with_marks_sample.tab Yurik (talk) 10:23, 5 January 2017 (UTC)

Dataset possibilites

The External Dataset features look like a great way forward, whether by a more generally editable use of wikidata, or the really useful looking table in Commons. They would massively reduce the clutter that maps introduce into an article edit page. Is there a way of using the same dataset (eg a commons Data table) within <maplink>? In the Template:OSM Location Map I can automatically make use of manually inserted marks into both the graph: template and a <mapframe> link. to do the same with a table would be fantastic. RobinLeicester (talk) 15:16, 8 January 2017 (UTC)

You can use Map Data -- and reference it as External Data from the <mapframe>/<maplink>. Is that what you are looking for? Yurik (talk) 18:45, 8 January 2017 (UTC)

If I have understood it right, the Map Data can be used by <maplink> but not by Graph:Street map with marks, while Graph: can use the table data which is no use to <maplink>. What I am looking for is some way of using the accessible, curatable, table data on both types of map. eg, can the table data be used to generate Map Data in some automated or semi-automated way? RobinLeicester (talk) 00:05, 9 January 2017 (UTC)

This is not exactly correct. The *.map and *.tab pages in Data namespace on Commons can be used by the <graph> tag (Graph extension). Only the *.map pages can be used by the <maplink> & <mapframe> tags (Kartographer extension). The <graph> tags are Vega-based graphs, and Vega allows you to load and draw many different types of data. The "Graph:..." prefix is simply a convention for the templates that use <graph> tag. More specifically, the "Graph:Street map with marks" template (graph) was initially designed with a very specific goal - draw the street map + a few manual elements on top of it. If there is a specific need for a different graph, anyone could create a different template, and use the <graph> tag to draw a completely different image. The Vega syntax inside the <graph> tag is a very powerful, but a bit complex syntax to express such visualizations. I could try to help with getting started, but I simply cannot implement every possible graph required :) Yurik (talk) 01:35, 9 January 2017 (UTC)

Thanks for the helpful explanation. The table option in "Graph:Street map with marks" has already achieved my hopes for that - so that already looks great. What I was hoping for was some way of using the data from the same table to put locator points into a maplink tag (or, when it arrives at en:, a <mapframe>). My guess is that there could be a Lua routine to extract the data from a table of the sort you demonstrated, and turn it into a maplink-ready GeoJSON map file, with the marks simply shown as wikivoyage-style points (If I am using the right terminology). Unfortunately I have no idea about how to achieve that. I was only asking in the hope that it may be on someone's radar. RobinLeicester (talk) 12:18, 9 January 2017 (UTC)

Further to the above, with a bit of lateral thinking, it has occurred to me that both the tab and map data could be generated by a wikipedia template using the same input as OSM Location Map, which would avoid having to worry about lua etc at this stage. Not ideal as it makes subsequent edits more tricky, but would at least provide a starting point, to see how things develop. I will have a go at implementing that and let you know how I get on.

In the mean time, the phrase about 'raw graph data' that appears at the bottom of the maps with tables will not really make sense on a map. Is there any chance of a switch to turn that off. For OSM Location map I would much rather have it under my control, so it could just say '[Data table]' or some such thing, alongside my '[Full Screen]' option, to keep the map as tidy as possible.

And I'm guessing much harder to implement ... is there any chance of having both the table and manual data, so that a general table of data can be set up for use on lots of different articles, and then the specific marks added in for each one manually as appropriate? I am guessing not,

Thanks for such a great set of tools. RobinLeicester (talk) 00:35, 10 January 2017 (UTC)

Lua can access anything data in the commons Data namespace, so it is entirely possible to construct a mapframe and graph using the same data. The only missing piece here is probably the ability to generate files using lua, and then just about anything imaginable (even files that don't exist on commons) could be placed in a map or graph or page.

https://phabricator.wikimedia.org/T66460

https://phabricator.wikimedia.org/T120489 197.218.82.125 (talk) 01:02, 10 January 2017 (UTC)

@RobinLeicester You could already do this with Lua - by simply loading the table by calling mw.ext.data.get(...) and generating the custom mapframe/maplink tag with any kind of content. Yurik (talk) 07:31, 11 January 2017 (UTC)

While it is true that it can be done with lua, currently it is done in a rather hacky manner using stuff like {{tag: . So one has to either accept that it will never get much usage in lua, or long term a proper library like Wikibase (https://www.mediawiki.org/wiki/Extension:Wikibase_Client/Lua) needs to be created for it.

The inherent complexity of graph, the fact that relatively simple graphs such as pie chart or force directed graphs aren't even available in the visualEditor (https://phabricator.wikimedia.org/T100357, https://phabricator.wikimedia.org/T100359), in addition to the issue of needing to arbitrarily concatenate graph json using strings makes it harder to be adopted in articles or lua modules.

So either lua needs libraries or visualeditor graph editing tool would need to be improved to make use of the new dataset software, or both. 197.218.91.204 (talk) 10:02, 12 January 2017 (UTC)

Yurik, I have now produced a template 'en:template:OSM Location map from table' that both generates and then displays .tab and .map files using the OSM Location map parameters. It is pretty geeky to use, so is unlikely to be a mainstream solution, but does provide another way of generating external data for now.

The lack of features on .map files compared to locally supplied <mapframe> results is quite a draw-back though. With .map, I failed to get wikilinks and images to resolve, and the markers can't be numbered, which makes for a much weaker result, unless I am missing something. Is this still in progress? (I have put a comparison between a data:file and 'inline' maplink at en:User:RobinLeicester/sandbox . There is also an example of an 'OSM Location Map from table', which works pretty well. (If only it could have local content as well). But you will see how intrusive the 'raw graph data' line is. RobinLeicester (talk) 01:59, 18 January 2017 (UTC)

Yes, it's a big todo - Phab:T155216 (and should be relatively easy to fix) Yurik (talk) 02:06, 18 January 2017 (UTC)

Need for a no-labels option

Six months ago Nilfanian raised the problem of labels on the base map, and suggested that a version with no labels at all would be helpful. The problem of non-alphabetic script on en: articles was one particular problem mentioned. Arbitrary mention of obscure places at lower zoom levels is another issue, as is the bug that chops up some names in zoom=9. These are all being cited as specific reasons to not use the map on en:wikipedia (eg at WikiProject UK geography). Is there any hope of an option to turn off place names, so that editors can then use the individual marks/labels to put in the ones appropriate to the article in question. (There are of course lots of other contexts - especially at higher zoom levels - where the existing labels are a great help). RobinLeicester (talk) 23:43, 27 April 2017 (UTC)

Hi, technically the map without labels was created around half a year ago (try it) , but I am not sure it got exposed via the <mapframe/maplink> tags. For the street map template, I just added it as a template parameter, but it turns out there is a bug preventing the "osm" value for the style parameter, which I will try to fix tonight, and it should be deployed next week.

P.S. I am running for the WMF board, please support and vote next week :)

P.P.S. Tracking issue phab:T164046. Partial fix is already in place, needs to be submitted and deployed. Yurik (talk) 00:26, 28 April 2017 (UTC)

The base map zoom=9 label problem resolution is much appreciated. (Is it me, or are there now more place names? In busy areas is looks rather full. If I was creating a wishlist I might suggest the names could be smaller!

Looking at this graph source code, I notice that in the line with the style instruction, all the other elements have the quote mark after the '=' whereas the style has it after the '{{{style}}}'. Could that be where the problem lies? (With no knowledge of the routines this is calling, I am just stabbing in the dark though). Thanks. RobinLeicester (talk) 19:34, 4 May 2017 (UTC)

The map labels work is being done at the moment by Paul, and I think there has been an announcement about it somewhere. Due to deployment freeze this week, I think it hasn't been updated yet on the servers, so might be another week until it is fully done. Yurik (talk) 19:52, 5 May 2017 (UTC)

Done - see the 3rd example. Note that "save preview" mode will not work for the next few days, until the servers are updated. The saved page should work fine. Yurik (talk) 21:41, 8 May 2017 (UTC)

marks with a hyperlink

Yurik, thanks for sorting out the no-labels style. Will it automatically migrate to en:wiki at some point? Another feature that would transform the mapswould be if they could be given an extra layer which defines some wikilink areas above the marks. I guess this might be possible with <imagemap>, but that requires an image name, which can't be done outside the graph template. Is there some way this might be achieved? (When the election dust settles...). Thanks. RobinLeicester (talk) 16:01, 13 May 2017 (UTC)

migration = copy/paste the content of the template without any changes from mediawiki :) The overlay clickability ... might require code change for the <imagemap>, or we could use the graph's capability of click handling, but that would require the graph to be generated in SVG (there is a phab ticket for that). Yurik (talk) 17:52, 15 May 2017 (UTC)

P.S. Copied. Yurik (talk) 17:58, 15 May 2017 (UTC)

Thanks for sorting the no labels option. That is great. The maps are already doing great things. A clickable facility would be great. (To my mind one that avoids the clunky 'play video' style launch phase would be much preferred). RobinLeicester (talk) 23:52, 15 May 2017 (UTC)

Internationalized names

Is there any chance that the Maplink 2018 improvements to internationalised names could find their way on to this system as well? To have the new default of 'language of the wiki', even without all the additional versions, would be a huge improvement over the current version for pretty much everyone. (If retaining the current 'osm-intl' it probably could be renamed as osm-local to match the mapframe usage). The no-labels 'osm' style has also been heavily requested and I have found useful, so to end up with all three would be great. RobinLeicester (talk) 20:28, 24 May 2018 (UTC)

This should be fairly simple to add a language parameter to the graphoid service, and let it pass it through to the map service. It's actually a very simple few line change - https://github.com/nyurik/mw-graph-shared/blob/master/src/VegaWrapper.js#L306 Yurik (talk) 20:36, 24 May 2018 (UTC)

P.S. @RobinLeicester I would suggest filing a Phabricator ticket for this (and add alink to the code) - much more likely it would be acted on. Yurik (talk) 02:50, 25 May 2018 (UTC)

Problem with maps in mobile version pages

It has become apparent that the 'graph' originated maps are having trouble displaying on the mobile version of en:wikipedia. I have narrowed the problem down to maps that are in a subsection of the page. If it is in the opening section/lead there is no problem - and they all display fine on the 'normal' wikipedia. But on the mobile version of a page, the ones in a subsection just display as empty boxes. You can see this in my sandbox. The one at https://en.wikipedia.org/wiki/User:RobinLeicester/sandbox havefive different maps, including one direct from Graph:Street map with marks, and one using template:maplink. Whereas the mobile version https://en.m.wikipedia.org/wiki/User:RobinLeicester/sandbox displays the first map (above the 'rest' subsection) and displays the maplink one, but all the others are just white boxes. My guess is that this is related to the way the graph template expects to find the rendered image, and presumably the mobile sections do something non-standard that messes it up. If anything can be done to resolve it, that would be great. RobinLeicester (talk) 00:09, 12 March 2019 (UTC)

After a look at some of the source code on the pages affected, I would guess it is to do with the 'lazy image loading' feature failing to find the rendered image. @Yurik, Is this something you may be able to look at? RobinLeicester (talk) 21:10, 12 March 2019 (UTC)

A bit more digging around the html properties of affected mobile pages (and bearing in mind that I don't really understand the mechanics of html or the lazy loader) has revealed that the 'active' part of the src instruction (as opposed to the <noscript> part) reads as

<img width="0" height="0" class="mw-graph-img image-lazy-loaded" alt="" src="/api/rest_v1/page/graph/png/....png" srcset style>

So the reason nothing is visible is that there is no width or height. But I have no idea how the lazy loader finds these sizes, or why it is failing.

Comparing this to a commons image, this has

<img width="400" height="300" class="thumbimage image-lazy-loaded" alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/5/53/....jpg" srcset="" style="width: 400px; height: 300px;"> RobinLeicester (talk) 22:17, 13 March 2019 (UTC)

I have now posted this problem on the German version of Module:Graph, as it seems to affect all Graph based images, and that seems to be the 'lead' version. RobinLeicester (talk) 20:28, 14 March 2019 (UTC)

There is a phab:T216431 which describes this but has not so far resulted in any progress. RobinLeicester (talk) 00:01, 30 March 2019 (UTC)

A fix has been discovered by Nehme1499. Graph:Chart seems to have found a way to switch off the lazy loader (or resolve the issue by whatever means) and simply including a pie chart of zero size is enough for any other Graph: based templates on the same page to also work in mobile view. RobinLeicester (talk) 01:21, 5 May 2019 (UTC)

A Css fix was the real solution, which inherits the width values etc, and means lazy loader is retained and works as it should. I have applied this via an associated styles.css file. More details at phab:T216431 RobinLeicester (talk) 17:52, 7 May 2019 (UTC)

Awesome improvement to text resolution

Not sure when or how the improvements to rendering on the maps took place, but the end results, especially for small text sizes, are awesome. Thanks to those who made that happen. It is a vast improvement in useability. RobinLeicester (talk) 09:25, 13 October 2021 (UTC)

So it turns out that the improvement is the result of WMF shutting down graphoid (https://phabricator.wikimedia.org/tag/graphoid/) which used to render the maps and just pass on a fairly low-res image. This happened during early 2021 I think, but it is not clear if anyone looked at the implication for the mapping stuff. The improvement in clarity of the maps is massive, but at what download and resource cost?

With graphoid there was no overhead to adding as many markers, details, items etc as an editor wanted. Is it now rendered from scratch every time? and what is the implication for mobile data users in particular? If anyone can offer an observation or reassurance on these points (maybe 'varnish' can keep it all in bounds?). I note some references to 'maps 2.0' https://phabricator.wikimedia.org/T280767, being worked on, so we may have to see what is coming next. RobinLeicester (talk) 19:34, 6 November 2021 (UTC)

Question

Is there any way to label the points when getting the coordinates from a Wikidata query?

Is there any way to change the marker shape when getting the coordinates from a Wikidata query?

Thanks! MSGJ (talk) 13:14, 21 September 2022 (UTC)