Open main menu

Template talk:Infobox road

Active discussions
WikiProject Highways (Rated Template-class, Mid-importance)
This template is within the scope of WikiProject Highways, a collaborative effort to improve the coverage of highways on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 Template  This template does not require a rating on the project's quality scale.
 Mid  This template has been rated as Mid-importance on the project's importance scale.

LuaficationEdit

Are there any plans to convert parts of this infobox to Lua, specifically the shield, route name, and translation? Now that we have fairly robust road data modules, I think these three items should be handled by the road data modules. Yes, I know that these will eventually be handled by Wikidata, but who knows when that will happen? We can use Lua now.

For those locations that don't yet have a road data module, we could utilize a tracking category to catch them, but I don't think there are very many. –Fredddie 16:01, 16 May 2015 (UTC)

There's no reason why we couldn't have the shield handled by Wikidata, similar to how the maps are now, though Happy might be waiting on other development last I heard (several months ago). --Rschen7754 16:04, 16 May 2015 (UTC)
Yes, my Summer of Code development.   I have no problem with migrating the infobox shields, names, and translations over to the road data string modules. That can be done right now while we're waiting for the corresponding Lua code, since adding unused keys won't cause any errors. The only issue with using shields from Wikidata is an override for highways with non-free shields. I would also like to migrate the colors to the string modules at some point. As for the rest of the infobox, I'm still waiting for mw:Extension:Capiunto to be deployed. -happy5214 00:42, 17 May 2015 (UTC)
@Happy5214: do you have anything to report from the last four months? –Fredddie 01:37, 3 September 2015 (UTC)
No, nor might I have anything over the next four months. Feel free to migrate the infobox-specific data to the string modules, but module development has been stalled due to lack of progress on Capiunto and my own personal inactivity. -happy5214 07:13, 3 September 2015 (UTC)

Something that might be possible is to have Module:Infobox_road/length get the length from Wikidata, if available and not specified locally. I added length to [1] and we at least can use the same source for all US Interstate articles. Aude (talk) 09:09, 9 October 2015 (UTC)

@Aude: I have a few concerns about doing this now, although I'm sure it will be done eventually. Do you happen to know how quantities with units are handled in the Wikibase Lua library? Are unit conversions available from the library, or will client code (Infobox road/length) still be required to convert between miles and kilometers? -happy5214 11:10, 9 October 2015 (UTC)
@Happy5214: I don't think there is special handling (yet) in the Wikibase lua library for quanitites (e.g. conversion), but there is Module:Convert. What (else) do you have in mind that we need in the lua library? Suppose for now, I could help with adding this data to Wikidata and maybe experiment with lua in a sandbox module. Aude (talk) 12:29, 9 October 2015 (UTC)
Since I already have unit conversion code in my module, I guess all I would have to have is a way to determine the unit used for the statement. -happy5214 03:32, 10 October 2015 (UTC)
In the past, the only reason we never used {{Convert}} was because we wanted it to appear <length><reference> (<conversion>). So long as that's preserved, there will be no opposition from the "it's always been that way" lobby. –Fredddie 13:02, 10 October 2015 (UTC)
@Happy5214: now that I've thought about it for a little while, you really shouldn't need units. There are only a handful of countries (US, UK, Liberia, maybe one more?) that use miles for anything, so the country property should influence what unit is used. –Fredddie 14:11, 10 October 2015 (UTC)

RFC: Transitioning to Lua moduleEdit

For the past week, I have been converting this template into a Lua module. The sandbox now does not transclude templates, except for certain fallbacks where (1) arguments to the live template need to be changed (discussed in issues below), and (2) data are yet to be defined in road data modules. There was a lot of data movement, and I think I am at a point to request for comments on where I decided to put things.

The goal is to use road data modules as much as possible. For USA, the following data are to be moved to road data modules (see Module:Road data/strings/USA and Module:Road data/strings/USA/NH for examples of an updated modules):

  • shieldmain: moved from Template:Infobox road/shieldmain/USA to each state's road data module. Defaults to shield if undefined.
    • shieldmainsize: size for shieldmain if it were to be displayed in {{jct}}. Defaults to shieldsize if undefined.
  • name: moved from Template:Infobox road/name/USA to each state's road data module.
  • translation: moved from Template:Infobox road/translation/... to each country's road data module. (I have yet to test this.)
  • law: moved from Template:Infobox road/law/USA to each state's road data module, if defined.
  • maint: moved from Template:Infobox road/maint/USA to each state's road data module.
  • browse: moved from Template:Infobox road/browselinks/USA to each state's road data module. Since browse links may be associated with route types or states, these links have to be moved to two places:
    • For links associated with route types, these move to the definition of the route type, e.g., USA.I.browse.
    • For links associated with states, these move to the common section for each state, e.g., NH[" common "].browse.
    • By default, the common browse is shown, but this might be undesirable for certain route types, e.g., county routes. To disable common browse, such route types may specify nocommonbrowse = true in the definition of the route type.
  • aux: moved from part of Template:Infobox road/meta/spur of to each stata's road data module. This is the full wiki markup describing auxiliary types, e.g., [[Business route]]. Lua loops can be used to fill these out automatically without explicitly writing them down.
    • For an irregular route that is auxiliary, but their route type is not auxiliary in general, e.g., New Hampshire Route 3A, |spec_auxtype= can be specified, where spec_auxtype is auxiliary code such as Alt and Bus. The definition of these types is at USA[" aux "].aux. This can be further overridden by providing full wiki markup in |spec_aux=. Defaults to Auxiliary route if none of these is unspecified.

For other countries, the data are to be moved to road data modules in a similar way.

Some data remain in the Infobox road namespace, because they govern how data are displayed and not themselves data:

These modules are structured so that they can be fetched with mw.loadData.

Issues

  • |subtype= should be deprecated, since |type= can now include auxiliiary types directly, as in US-Alt. Moreover, certain route types have multiple subtypes, e.g., US-Truck-Alt. This change will make route types consistent with {{jct}}. Transclusions using this parameter must be modified as part of the transition. To help with this, the sandbox concatenates subtype to type before invoking the road data module.
  • Translations depend on {{lang}}, which I don't know how to replace with modules yet.

Additional features

These are incorporated from past discussions and are independent of the transition.

  • Added support for nested infobox.
  • Automatically display country and state (without wikilinks for now).

Dependencies

Extended content

Future work (we should discuss)

  • Rework the location section to allow custom labels (e.g., rural municipalities, divisions) instead of dedicated parameters. There are too many of them now, and I think these could get out of hand.
  • Rework the browse section to break things up from the current browse parameter. For example, multiple rows of previous and next routes can be specified with numbered suffixes, in the same way as multiple route sections.

Template:Infobox road/testcases and its subpages may be of your interest. Some shields therein might be incorrect because road data modules need an update. While the current sandbox is robust enough for the transition, template warnings should be inserted first so transclusions needing corrections can be readily identified. Chinissai (talk) 11:14, 6 May 2016 (UTC)

Mapframe mapsEdit

Mapframe maps are now available on English Wikipedia, and can be inserted with template {{maplink}} (or with <mapframe>...</mapframe> and raw JSON code). This is what the New Jersey Turnpike example from the documentation would look like with a mapframe map:

 

New Jersey Turnpike
Map of the New Jersey Turnpike mainline and spurs in red
Route information
Maintained by the New Jersey Turnpike Authority
Highway system
{{Infobox road
|state=NJ
|type=Turnpike
|maint=the [[New Jersey Turnpike Authority]]
|map={{maplink|frame=yes|plain=yes|frame-align=center|frame-width=290|frame-lat=40.219850|frame-long=-74.699190|zoom=7|type=line|id=Q811504|title=New Jersey Turnpike}}
|map_custom=yes
|map_notes=Map of the New Jersey Turnpike mainline and spurs in red
<!-- other parameters omitted -->
}}

If OSM data is unsuitable or unwanted, mapframe maps can draw from GeoJSON data (which can be derived from KML files), either on Commons (must be CC-0) or locally (just needs to be CC-BY-SA compatible):

{{Maplink|frame=yes|plain=yes|from=Sandbox/Evad37/St Georges Terrace.map|type=data|frame-lat=-31.95|frame-long=115.86|zoom=13}}

{{maplink|frame=yes|plain=yes|raw={{Wikipedia:Map data/Main Roads Western Australia/Forrest Highway}}|title=Forrest Highway|frame-lat=-32.9|frame-long=115.7|zoom=8}}

What would be really interesting would be if the infobox template could automatically insert a mapframe map if there is no map image for the road. Which seems like it should be possible in Lua, but might be quite a bit of work. - Evad37 [talk] 06:36, 10 May 2018 (UTC)

It would be a lot easier if this template (which is backed by Module:Mapframe) could be called directly from Lua, which does not appear to be possible without the use of frame:preprocess. I'd suggest that such direct calling functionality be added before we worry about writing our end of the Lua code. -happy5214 22:24, 10 May 2018 (UTC)
 Y Done, can now be called from other modules - Evad37 [talk] 01:40, 11 May 2018 (UTC)
I also had a go at the Lua coding, and came up with Module:Infobox mapframe / {{Infobox mapframe}} - Evad37 [talk] 07:09, 11 May 2018 (UTC)
You should consult with Dschwen, who created WikiMiniAtlas. It'd be great if the KML automatically centered the mapframe map, which is something that WMA does already. My biggest dread to deploying this is finding central coordinates for the map. –Fredddie 21:56, 11 May 2018 (UTC)
If everything worked properly, it wouldn't be necessary to specify frame coordinates or zoom – mapframe maps can do automatic zooming and centering, but at the moment it only happens in preview mode or after opening the map, and not for regular page viewing. (Reported on Phabricator, but its probably not likely to be fixed any time soon since mw:Map improvements 2018 is just about over.) - Evad37 [talk] 02:37, 12 May 2018 (UTC)
@Evad37: What am I doing wrong here: Iowa Highway 192Fredddie 02:30, 15 May 2018 (UTC)
@Fredddie: The data has to exist on OSM first, and be linked to wikidata from there (and takes about 1 day to be available here after being linked); see mw:Help:Extension:Kartographer/OSM. But OSM is only really for current information, former roads should probably use geoJSON. - Evad37 [talk] 03:02, 15 May 2018 (UTC)

Conversion done at Wikipedia:Map data/Wikipedia KML/Iowa Highway 192, using a script I made: User:Evad37/kmlToJson.js On the attached kml subpages, the script adds a "GeoJSON" link near the "Move" link (In the 'More' dropdown menu for Vector skin; a tab in Monobook skin) that does the conversion when clicked. I'll also look into coding something to suggest appropriate frame coordinates. A further possibility would be to automate the creation of the geoJson map data pages. - Evad37 [talk] 04:42, 15 May 2018 (UTC)

I also fixed Iowa 346 on OSM [2] – the relation existed on OSM, but was missing a fair chunk of the route, and wasn't yet linked to Wikidata. The data should be available to mapframe maps in about a day. It seems like there is likely to be a fair amount of cleanup to do on the OSM side of things. - Evad37 [talk] 05:36, 15 May 2018 (UTC)

All Indian National Highways having articles have qid linked in OSM if you want to experiment you can try in NH articles. Currently there is a limit in no of Highways displayed.

T193458 --naveenpf (talk) 05:53, 15 May 2018 (UTC)

  • @Mr. Matté: this may be relevant to your interests.

@Evad37: one problem I'm seeing is for national routes like Interstate 10. It has an OSM relation, but if you go to OSM, no line shows up at all so no line shows up on our map. The state OSM relations work just fine, see Interstate 10 in Texas. –Fredddie 22:34, 13 June 2018 (UTC)

@Fredddie: The OSM relation for Interstate 10 only contains other relations. That doesn't work, only roads (and other lines/shapes) that are directly in a relation will be displayed (see phabricator task). You could create a new relation on OSM that directly contains all of Interstate 10, but the best option is probably just to display all the data from state articles together, i.e. {{maplink|type=line|id= |type2=line|id2= |...etc...}} filling in the wikidata ids for all the state articles. - Evad37 [talk] 01:08, 14 June 2018 (UTC)
Thanks, I'll give that a try. –Fredddie 01:26, 14 June 2018 (UTC)

Map data on CommonsEdit

We can now store CC-BY-SA data can on Commons. We should probably migrate the Map data subpages over to Commons so that other wikis can more easily reuse the data. - Evad37 [talk] 06:24, 28 August 2018 (UTC)

I've noticed that Commons can handle much larger files than the raw map data pages. See U.S. Route 80 in Arizona and commons:Data:U.S. Route 80 in Arizona.map for an example. –Fredddie 14:04, 28 August 2018 (UTC)
@Evad37: are the data maps going to be linked on Wikidata eventually? –Fredddie 14:04, 28 August 2018 (UTC)
There's already a property for that: geoshape (P3896) - Evad37 [talk] 15:09, 28 August 2018 (UTC)
How are we going to move the files - Special:Import? Or just link to the original file (but that means we have to keep the JSON or the KML on enwiki around indefinitely - which could be a mess if it gets updated) --Rschen7754 14:46, 28 August 2018 (UTC)
I don't know if Special:Import would work, since the source pages would have a wikitext content model, which is not what the .map pages on Commons use. And it's probably not as simple as just changing the content model, since the software requires a very specific syntax to be used, including a properly specified licence, before allowing an edit to be saved. We probably need to do a test case to see if it's possible to do an import with Special:Import, and then change the content model, and edit the page to specify the licence and otherwise comply with the syntax requirements. - Evad37 [talk] 15:09, 28 August 2018 (UTC)
Special:Import is an admin-only tool) and I don't have the hat on Commons. I tried on test.wikipedia which doesn't have the map.json model apparently, just plain JSON. Import worked fine but it was just plain wikitext. I was able to change the content model to plain JSON but I had to remove the header template at the top. --Rschen7754 18:56, 28 August 2018 (UTC)
To clarify, Special:Import is only available to admin and importers. Special:ChangeContentModel is admin-only (perhaps it shouldn't be, but that is how the config of that wiki is set up). --Rschen7754 19:01, 28 August 2018 (UTC)
I'm an admin on Commons and would be happy to lend a hand. I see that for your test on test.WP you imported Wikipedia:Map_data/Wikipedia_KML/Iowa_Highway_192. Would you like me to import that page to commons:Data:Wikipedia KML Iowa Highway 192.map (or maybe commons:Data:Highway 192 in Iowa.map following the naming convention adopted by commons:Data:U.S. Route 80 in Arizona.map) and then change the content model of the new page to map.json? —RP88 (talk) 01:00, 29 August 2018 (UTC)
That would be appreciated (using the second name), though I don't know how we would move thousands of files if we wound up going that route. --Rschen7754 02:06, 29 August 2018 (UTC)
(edit conflict) @RP88: Yes, that would be good, to see that it does in fact work. If so, then we could perhaps start looking at a more automated or semi-automated solution, starting from the KML source files (which we have thousands of) – i.e. a tool or bot to (semi-/)automatically do some or all of the steps: import the KML, convert to GeoJSON, add licence/source info, and change content-model to map.json.
I'm not entirely sure what the naming convention should be... I think a lot of pages in the Data: namespace are in the format Data:source/filename.map so that the source acts a pseudo-namespace. Which is why the map data pages here have the /Wikipedia_KML/ in the page name, for those derived from KML files. On the other hand, it would be nice to have a consistent set of data files regardless of source. Especially since going in to the future we would likely be generating new files as GeoJSON directly, rather first publishing as a KML file. But in any case, pages can be renamed later on. - Evad37 [talk] 02:07, 29 August 2018 (UTC)
OK, I just gave the import a try. An attempt to import to the Data namespace failed with the error "Page "Data:Map data/Wikipedia KML/Iowa Highway 192" was not imported because you are not allowed to create it." (probably because of name/format issues). An import to the default location (i.e. Commons namespace) followed by a move succeeded, but then the attempt to change the content model to json/map.json failed with the error "Invalid content data". Viewing the resulting data (in both wikitext and plain text model) shows a "Fatal exception of type "Exception" error. I am going to try importing the data to a non-Data namespace, fixing the content to comply with map.json, and then moving it to Data namespace. —RP88 (talk) 02:32, 29 August 2018 (UTC)
I've created c:Data:Highway 192 in Iowa.map, but I can't seem to change the content model to the map-specific version of JSON. —RP88 (talk) 02:46, 29 August 2018 (UTC)
Maybe blanking the page would allow a successful change of content model, after which the JSON could be copied back in? - Evad37 [talk] 02:53, 29 August 2018 (UTC)

OK, a working version is now at c:Data:Highway 192 in Iowa (3).map. The procedure I used to create this map file was:

  1. Use Special:Import to import Wikipedia:Map_data/Wikipedia_KML/Iowa_Highway_192 to Commons namespace.
  2. Copy the content to a text editor and fix to match map.json format.
  3. Move the page to the Data namespace under the correct name.
  4. The content can now no longer be edited or viewed.
  5. Delete the .map page.
  6. Recreate the .map page using the fixed content from the text editor.
  7. Restore the deleted revisions.

The resulting page c:Data:Highway 192 in Iowa (3).map works a little strange (you can't diff between the older non-map revisions, but you can view them as non-maps, etc.). —RP88 (talk) 03:14, 29 August 2018 (UTC)

It works in a mapframe map:

{{Maplink|frame=yes|plain=yes|type=data|from=Highway 192 in Iowa (3).map|frame-lat=41.2609|frame-long=-95.86|zoom=11}}
- Evad37 [talk] 03:25, 29 August 2018 (UTC)
Excellent! I did try your suggestion of blanking the page, but it didn't work because the .map page couldn't be edited. I couldn't find any method other than the steps above (which was essentially a history merge). It doesn't seem like a practical process if thousands of maps need to be imported. —RP88 (talk) 03:39, 29 August 2018 (UTC)
It should be possible to automate all those steps via script, so it could be done in one click (and then just checked afterwards) - Evad37 [talk] 06:26, 29 August 2018 (UTC)
Yes, it should be possible for a script to be written that a Commons admin could use (or, alternatively, a bot with the admin bit could be written to do the task). —RP88 (talk) 07:18, 29 August 2018 (UTC)
After some more experiments, there doesn't seem to any way to correctly set the content model of a page to the map.json content model, even a page named "xxxx.map" in Data namespace, other than by directly creating the page. I tested with valid map.json contents and I couldn't get it to work with a page move, neither setting the content model before the move or after the move worked. This seems like a bug to me. —RP88 (talk) 03:59, 29 August 2018 (UTC)
Reported as phab:T203062 - Evad37 [talk] 06:57, 29 August 2018 (UTC)

Should we change templates like Template:USRD to refer to needing JSON (and sending it to Commons) instead of KML? Should we go through and change project pages to suggest using JSON instead of KML? It seems that if we keep encouraging KML, or uploading JSON to enwiki, we'll just be stuck with more pages on enwiki that we can't delete due to our inability to import to Commons (or with KML, being stuck with it forever). --Rschen7754 18:31, 31 August 2018 (UTC)

I think the banners need to have the ability to check for the Wikidata page first. I think there is a surprising number of articles that aren't linked to WD. –Fredddie 21:01, 31 August 2018 (UTC)

There is some related discussion at Wikipedia:Village_pump_(proposals)#OpenStreetMap. It's not clear what most people over there are talking about, but it seems some of them are against any kind of map on road articles. Nemo 16:45, 5 August 2019 (UTC)

Template-protected edit request on 1 November 2019Edit

I would like to request some additions to the following section:

 |AZ 1927|AZ pre-1956|AZ 1956|AZ 1963=Maintained by [[Arizona Department of Transportation|Arizona Highway Department]]

Which would look as follows if the additions were to be implemented:

 |BL|BS={{#switch:{{{state}}}
  |AZ=Maintained by [[Arizona Department of Transportation|ADOT]]
  |NM=Maintained by [[New Mexico Department of Transportation|NMDOT]]
  |TX=Maintained by [[Texas Department of Transportation|TxDOT]]
  |#default=
  }}
 |AZ 1927|AZ pre-1956|AZ 1956|AZ 1960|AZ 1963=Maintained by [[Arizona State Highway Department|ASHD]]
 |US 1926=Maintained by {{#switch:{{{state|}}}
  |AZ=[[Arizona State Highway Department|ASHD]]
  |CA=[[California Department of Public Works|CDPW]]
  |NM=[[New Mexico State Highway Department|NMSHD]]
  |NY=[[New York State Department of Highways|NYSDH]]
  |OR=[[Oregon State Highway Department|OSHD]]
  |PA=[[Pennsylvania Department of Highways|PDH]]
  |TX=[[Texas State Highway Department|TSHD]]
  |WA=[[Washington State Department of Highways|WSDH]]
  |#default=
  }}
 |US 1956=Maintained by {{#switch:{{{state|}}}
  |AZ=[[Arizona Department of Transportation|ASHD]]
  |#default=
  }}
 |US 1960=Maintained by {{#switch:{{{state|}}}
  |AZ=[[Arizona State Highway Department|ASHD]]
  |#default=
  }}
 |US 1963=Maintained by {{#switch:{{{state|}}}
  |AZ=[[Arizona Department of Transportation|ADOT]]
  |#default=
  }}

These add the various organizations and highway departments that maintained the above set of highways. Thanks. — MatthewAnderson707 (talk|sandbox) 06:53, 1 November 2019 (UTC)

I didn't do it exactly this way, but all the functionality you requested has been added. –Fredddie 17:44, 3 November 2019 (UTC)
Return to "Infobox road" page.