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.
Topic on Template talk:Graph:Street map with marks
You can use Map Data -- and reference it as External Data from the <mapframe>/<maplink>. Is that what you are looking for?
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?
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 :)
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.
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.
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
@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.
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.
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.
Yes, it's a big todo - Phab:T155216 (and should be relatively easy to fix)