WikiProject U.S. Roads | (Rated Project-class) | ||||
---|---|---|---|---|---|
|
Module:Jctint/USA
The most recent version of jctint templates for US states did mainly the following:
- Assign the state name to
|region=
. - Pass through a parameter to Template:Jctint/core.
- Rename a parameter to a core parameter.
- Build a string for a _special parameter that shares the same structure across these templates, only to differ in the state name.
The approach above has several drawbacks:
- A parameter available in the core module not exposed by these templates becomes unavailable. Parameter additions in the core module do not propagate to these templates automatically.
- A lot of duplicate template code is difficult to maintain.
- These templates can only diverge from one another over time. Template users will have to memorize multiple usage when the interface for these templates could have been uniform.
For the past few days, I have converted most of these templates to use Module:Jctint/USA to eliminate the drawbacks above. You might not have seen any observable changes to articles, because you shouldn't! I am happy to report that the module now handles jctint templates for 40 out of the lower 48 states.
Before I can go into what prevents the templates for the remaining 8 states from being converted, I need to go into some technical details about how |sub2_special=
was implemented for most states.
|location_special=
is used by default. Certain templates permitted multiple locations to be specified as |location1=
through |location4=
. These parameters are concatenated as a list of wikilinks that is passed to the core module as |sub2_special=
. Other templates did the same, but with townships instead of locations (see Interstate 70 in Ohio). The module handles both: |sub2param=township
is used in the latter case; location is the default.
Now, why the templates for 8 states haven't been converted:
- State name is not the correct article link (GA and WA): Road data modules should handle this.
- Different
|sub1name=
(LA): Road data modules should handle this. - Special handling for
|indep_city=
(CA, CO, and MD): Road data modules should handle this. - Cascading
|sub2_special=
(MN): A list of both townships and locations are permitted, but the module doesn't support cascading yet, though it can easily be done. |town=
(WI): It appears that town articles are not named consistently, e.g., Bristol, Dane County, Wisconsin vs Bristol (town), Kenosha County, Wisconsin. So, I could not decide which one to use.
For more details about handling by road data modules, see Template talk:Jcttop/core#sub1name order for an idea, and Module:Road data/strings/USA/NH for an example. This is a longer-term transition, but I would like to avoid adding a boilerplate in the module when this transition is anticipated. See also Template talk:Jct#Inheritance and overriding in road data modules.
During the conversion, I noticed a beginning of divergence in some of the templates. While most states use |mile_ref=
, some use |length_ref=
. Specifically, templates for AL, FL, OH, OR, and TX. This parameter should be deprecated and renamed to |mile_ref=
.
The module opens up other opportunities for uniformly customizing parameters for US junctions, e.g., cascading (above) and support for a list of cities. Additional customizations will not be implemented until there is evidence that they are useful for multiple states.
The templates are still fully backward compatible with the previous version, but the module might have added new features, e.g., list of locations, to some states' templates. These features have already been used in several other states' templates. I hope it is okay for every state's template to have the same leverage.
Of course, if you see any undesirable, observable changes, I will appreciate your report so I can troubleshoot. Constructive comments will also be appreciated. Chinissai (talk) 15:45, 17 May 2016 (UTC)
- Illinois has a mix of townships and precincts. There is no pattern that I can tell for which county uses which subdivision. –Fredddie™ 16:45, 17 May 2016 (UTC)
- Interesting. I didn't see any use of precincts in jctint as a separate parameter, so I was able to convert {{ILint}} without trouble. The module should be able to support future customization for precincts, though, perhaps by using switch tables in road data modules. Chinissai (talk) 17:08, 17 May 2016 (UTC)
- California has the funny postmiles stuff - is this properly supported? --Rschen7754 18:20, 17 May 2016 (UTC)
- Yes, any "funny" parameters can be overridden by passing them to the module. See Template:ORint for example. It's only San Francisco that prevents me from converting CAint. Chinissai (talk) 18:46, 17 May 2016 (UTC)
- On a side note, North Carolina has townships, but most, if not all, of the links don't exist, even as redirects. Charlotte Allison (Morriswa) (talk) 21:08, 17 May 2016 (UTC)
- Yes, any "funny" parameters can be overridden by passing them to the module. See Template:ORint for example. It's only San Francisco that prevents me from converting CAint. Chinissai (talk) 18:46, 17 May 2016 (UTC)
- California has the funny postmiles stuff - is this properly supported? --Rschen7754 18:20, 17 May 2016 (UTC)
- Interesting. I didn't see any use of precincts in jctint as a separate parameter, so I was able to convert {{ILint}} without trouble. The module should be able to support future customization for precincts, though, perhaps by using switch tables in road data modules. Chinissai (talk) 17:08, 17 May 2016 (UTC)
Whatever happened to this? I ask because Module:Infobox road/sandbox2 got nominated for deletion. --Rschen7754 03:50, 29 September 2020 (UTC)
- @Rschen7754: Chinissai hasn't edited since mid-2017. That's what happened. –Fredddie™ 04:38, 21 April 2021 (UTC)
Broken maps
Recently BMACS1002 (talk · contribs) has made new maps for many highways. 100s of them are broken, such as: New York State Route 29, New York State Route 28A, New York State Route 10, New York State Route 5, New York State Route 7, etc. What should be done? -420Traveler (talk) 17:18, 9 August 2021 (UTC)
- They're supposed to be utilizing OSM data, but it's not working unless you click on the map. Personally, I don't think the OSM data is very good and I'd rather have us make interactive maps at commons, like commons:Data:New York State Route 22.map, that can be used by other wikis. That being said, I would be comfortable reverting. –Fredddie™ 18:20, 9 August 2021 (UTC)
- I agree with that. The interactive maps at commons always worked. They were also more accurate to follow the route, versus the OSM maps. -420Traveler (talk) 19:43, 9 August 2021 (UTC)
- @Fredddie:,BMACS1002 (talk · contribs) How do we go about reverting them, is there a way to mass-revert them? -420Traveler (talk) 16:58, 2 September 2021 (UTC)
- It seems to be mainly New York, New Jersey, and Pennsylvania. Does that sound about right? –Fredddie™ 23:20, 2 September 2021 (UTC)
- This problem is happening regardless of the data. There's a relevant discussion here. It seems to be something with the server backend. – The Grid (talk) 23:46, 2 September 2021 (UTC)
- I even see it in Florida (US 17 but other roads I can't think of right now). Although speaking of New York, the map for NY 25 only shows a former reference route near Cross Island Parkway, although that's obviously a better subject for the Maps Task Force. ---------User:DanTD (talk) 23:57, 29 September 2021 (UTC)
- Here are some lists of articles to check and revert:
- New Jersey 188 results
- New York 607 results
- Pennsylvania 507 results.
- This compares articles that have
{{Infobox road}}
and{{Maplink-road}}
from each state. –Fredddie™ 00:26, 30 September 2021 (UTC)- The Bronx River Parkway, Henry Hudson Parkway and Park Avenue Viaduct still have broken maps. ---------User:DanTD (talk) 11:08, 1 October 2021 (UTC)
- Thanks for your suggestion. When you believe an article needs improvement, please feel free to change it. We encourage you to be bold in updating pages, since wikis like ours develop faster when everybody edits. Don't worry too much about making honest mistakes—they're likely to be found and corrected quickly. You can always preview your edits before you publish them or test them out in the sandbox. If you need additional help, check out our getting started page or ask the friendly folks at the Teahouse. –Fredddie™ 15:36, 1 October 2021 (UTC)
- Seriously, though. Just look for the edit(s) BMACS1002 made around February or March and undo it. –Fredddie™ 15:37, 1 October 2021 (UTC)
- I found another Manhattan Street with a broken map; Astor Place. ---------User:DanTD (talk) 14:02, 19 October 2021 (UTC)
- There's also Nassau Street (Manhattan) and Broadway (Manhattan). I have reverted them for now, as a map of the world doesn't help anyone. DDFoster96 (talk) 17:39, 5 November 2021 (UTC)
- U.S. Route 17 in Florida still has a broken map, and User:BMACS1002 didn't even touch that one. ---------User:DanTD (talk) 12:09, 6 November 2021 (UTC)
- There's also Nassau Street (Manhattan) and Broadway (Manhattan). I have reverted them for now, as a map of the world doesn't help anyone. DDFoster96 (talk) 17:39, 5 November 2021 (UTC)
- I found another Manhattan Street with a broken map; Astor Place. ---------User:DanTD (talk) 14:02, 19 October 2021 (UTC)
- The Bronx River Parkway, Henry Hudson Parkway and Park Avenue Viaduct still have broken maps. ---------User:DanTD (talk) 11:08, 1 October 2021 (UTC)
- Here are some lists of articles to check and revert:
- I even see it in Florida (US 17 but other roads I can't think of right now). Although speaking of New York, the map for NY 25 only shows a former reference route near Cross Island Parkway, although that's obviously a better subject for the Maps Task Force. ---------User:DanTD (talk) 23:57, 29 September 2021 (UTC)
- This problem is happening regardless of the data. There's a relevant discussion here. It seems to be something with the server backend. – The Grid (talk) 23:46, 2 September 2021 (UTC)
- It seems to be mainly New York, New Jersey, and Pennsylvania. Does that sound about right? –Fredddie™ 23:20, 2 September 2021 (UTC)
- @Fredddie:,BMACS1002 (talk · contribs) How do we go about reverting them, is there a way to mass-revert them? -420Traveler (talk) 16:58, 2 September 2021 (UTC)
- I agree with that. The interactive maps at commons always worked. They were also more accurate to follow the route, versus the OSM maps. -420Traveler (talk) 19:43, 9 August 2021 (UTC)
November OSM data redux
Other reference threads from December 2016, April 2021, Aug.-Sept. 2021 (WP:Graphics Lab)
Can we in the community decide on what type of maps to use as the interactive map to be displayed on roads' infoboxes? BMACS1002 (talk · contribs) is keen on using OpenStreetMap (OSM) data for these articles but I feel that there have been lots of issues in the past, mostly with linework not displaying at seemingly random times. I have concerns about using an external source for direct displaying of Wikipedia data since OSM's editing/sourcing standards may be different than the WP:RS standards here. When the maps do work, the linework tends to be more blocky, often includes random segments (e.g. interchange ramps, potential old alignments), and often include divided highway segments when not necessarily needed. The main disadvantages of the Commons data from what I see is that it's not dynamic if new segment(s) of a route opens/gets decommissioned, also that once a map is initially added, the map doesn't appear for about an hour, which may confuse editors. BMACS cites a statement on their userpage about Kartographer (but provides no link to a WP-level page here) and includes a concern about redundancy/size of having both Commons and OSM data. Considering in the end the linework is just ones and zeros, with some reasonable manipulation of the data (reducing decimal precision to 5 places and/or generalization of the line itself), the data files can be brought down a couple thousand bytes (I-90's .map file is 52,000 bytes for a 3000-mile-long route). —Mr. Matté (Talk/Contrib) 17:54, 17 November 2021 (UTC)
- Thanks for pinging me! So now that I'm in the loop on this conversation, I see the points that Mr. Matte has brought up, and I do recognize that historically (and to some extent still), using the link between OSM and Wikimedia to create maps has been a buggy solution. To address some earlier concerns, I realize now that in recent months a lot of what I've been doing has been bombastic and with not too much regard for whether it's useful (sorry about that! Y'all can change things back as you see fit if they're still broke); however, I will note that most of the changes that I've added predate the issues with the imposm3 handling of lines, and only became problems in time.
- But with that out of the way, I personally think the long term benefits outweigh the short-term bugs in using Wikimedia's link to OSM. To state a few more points in its favor, I know that updating maps in the case of a realignment isn't a top priority for this WikiProject, but it sure is a priority for OSM editors. Since they usually take care of updates quickly, that change can filter into Wikimedia's systems quicker than waiting from someone to notice the change on this site. Mr. Matte also brought up that some extraneous elements are sometimes included and others inherent to the route are missing, but I see this not as a hindrance but instead a good thing for OSM! If we see something on our end that needs fixing, then that also means that there's an issue with OSM's inclusion of elements within the route relation on their end, and we can either fix it in OSM ourselves or we can ask someone else on their end to fix it. That way, not only we can kill two birds with one stone, but we can also find problems OSM didn't even know they had!
- On the point of bugginess in the imposm3 function, the short-term solution would be to use Commons data as a fallback, but we should also focus some attention on the long-term solution of making sure that the system is reliable. It frustrates me that the system works effectively for polygons and points (or at least usually does), but not for lines and route relations (for context, New Jersey has for some time had reliable interactive maps featuring county and municipal divisions on their respective pages), and us road enthusiasts have been left in wont for a reliable implementation. So let's be the force to make that happen! I think we need to include the engineers that maintain Kartographer and the imposm3 function in this conversation, but let's focus some attention to making that work. Mr. Matte also addressed differences in editing/sourcing standards, so if that becomes a serious issue (although I can't imagine anyone would've implemented this feature in the first place if that was actually an issue), or if this WikiProject concludes for whatever reason this is not something worth pursuing in the long run, then let's decide it now, and forevermore abandon our relationship with OSM. But I would be sad to see this happen- this is a good idea for a feature, and if I've learned anything in this time on the planet, it's much better to work out the bugs in a good if still incomplete idea, than to call it a lost cause and abandon the project.
- But, I wonder if there might be a workaround in the meantime? I don't know how to actually implement this, but could we modify the existing Maplink-road template to check if there's any data sent from Wikimedia to the map, and if not default to a Commons map? I'd see the front end adding a tag that looks like
|defaultFrom="Example.map"
. Or would that be too much...? Also, can we agree on a color to label these roads? Maplink-road defaults to #ff0000, but I've been seeing a trend where people are liking a darker color. I don't care either way, but some consensus there would be nice. Looking forward to y'alls' thoughts! BMACS1002 (talk) 02:13, 18 November 2021 (UTC)- I started using #cc0000instead of #ff0000for aesthetics, really. I think the darker red looks like it matches rest of the map better than #ff0000. I first saw that color used on Japanese road articles with interactive maps and tried it out on USRD articles. It's by no means official, though we can make it that way if there's some sort of agreement here. –Fredddie™ 04:38, 18 November 2021 (UTC)
- But, I wonder if there might be a workaround in the meantime? I don't know how to actually implement this, but could we modify the existing Maplink-road template to check if there's any data sent from Wikimedia to the map, and if not default to a Commons map? I'd see the front end adding a tag that looks like
Insider information on U.S. Route 264
Hello, so here's a question, I recently contacted NCDOT in regards of I-587 and what will happen with US 264. I got a response today that they plan to submit to the AASHTO Fall meeting a rerouting of US 264 and elimination a part of US 264 Alt; and they were even kind enough to provide me the draft files they intend to use in the submission. They hope to have this all done in 2022. So, how do I update this insider information on the article that meets referencing guidelines, should I upload the drafts someplace or would you all suggest another method? --WashuOtaku (talk) 02:21, 28 August 2021 (UTC)
- Technically speaking, you can't upload the drafts as NCDOT would have a copyright in them, and since they haven't uploaded them someplace or published them to the public, they fail WP:V. There's also the idea that until they submit the application, they could change their mind on the idea. I'd just wait until the AASHTO meeting to make updates to the article. Imzadi 1979 → 04:24, 28 August 2021 (UTC)
- That was what I was kind of expecting, but was hoping there was another way, it is frustrating to know what is the expected next steps but cannot add that to the articles until a third party posts it first. --WashuOtaku (talk) 12:22, 28 August 2021 (UTC)
- Nobody else wants to speak up on it. Can I at least mention that I-587 is tentitive to being established in 2022? --WashuOtaku (talk) 17:51, 30 August 2021 (UTC)
- So I'm definitely a little late on this, but I do have a few comments. I think it would be beneficial to start working on draft pages based on that insider info, but not posting anything to the main wiki. The only exception, in my opinion, could be some vague language about how I-587 signage is expected in the future. That could be placed at the end of the I-587 subarticle. As for U.S. 264, I'm happy to host a draft linked to me, like I have User:Ncchild/U.S. Route 220 in North Carolina. I have been dabbling with some U.S. routes in NC and trying to upgrade them to GA status, and US 264 was one of those on my list. My life has just gotten pretty busy, which is why I've fallen flat on my US 220 work.--Ncchild (talk) 03:56, 29 September 2021 (UTC)
An old error resurfaces
"The time allocated for running scripts has expired" has resurfaced to mess up intersection lists again. ---------User:DanTD (talk) 11:56, 21 September 2021 (UTC)
- It was all fairly random, but now another error has turned up on the Special routes of U.S. Route 17 list. Specifically U.S. Route 17-1 where the shield has been replaced by Lua error in Module:Infobox_road/route at line 42: attempt to compare two nil values. ---------User:DanTD (talk) 16:42, 27 September 2021 (UTC)
Discussion at Template talk:Infobox road/shieldmain/USA
Your input is requested to resolve a disagreement. –Fredddie™ 02:42, 1 October 2021 (UTC)
Workshop at WikiConference North America 2021
This coming Friday afternoon, I'll be giving an online workshop at WikiConference North America on how to draw a basic SVG road sign diagram. The workshop will not be recorded, but I'll try to make some of the materials accessible on Commons for those who can't make it. Registration is free; please spread the word. Minh Nguyễn 💬 04:59, 6 October 2021 (UTC)
- I wrote up my presentation and workflow in this Etherpad. If there's interest, I can make a screen recording of the workflow and upload it to Commons, but hopefully this is a decent starting point for interested contributors. Minh Nguyễn 💬 03:56, 12 October 2021 (UTC)
Opportunity Corridor article issues
Edited 2021-11-10 With the Opportunity Corridor opening a week from Friday (12) and the ribbon cutting just having happened, the article needs to be rewritten. I was going to start, but there are some issues to be addressed and I wanted to share them here first before I did any work on it.
- The "History" and "Active project" sections need to be merged, but only the piece of information involving the construction designations 10F and 10P appears to be expendable since those were intentionally temporary.
- The "Opposition" section should probably stay as-is; it appears to be NPOV.
- The name of the road is ambiguous. The project has been called "Opportunity Corridor" from the beginning but that includes the area of development along the road as well as the road itself. The RS that I linked above calls it "Opportunity Corridor Boulevard" but that may be that source's own name for it. The signs in the media that I've seen all say "Opportunity Corridor" but the signs at Kinsman Road just say "Kinsman" so it might be that on the signs they just drop the designator (AKA the "generic" as identified on the Street or road name article). One of the speakers at the ribbon cutting (video available if needed) also called it "the Opportunity Corridor Boulevard" but that could also be small "b" meaning that it's not part of the name but just a description, and that could be where the source above got that "name".
- Since the whole thing appears to be a part of SR-10 now, a merger to Ohio State Route 10 is on the surface the thing to do, but I have WP:UNDUE concerns, even with an expansion of the SR-10 history section, which is why I haven't proposed the merge there yet.
- Incidentally, there isn't really a good RS to prove that 10 now runs between its up-to-now eastern terminus and the Opportunity Corridor. Those were the plans, but there is no confirmation that it happened, so there might be a gap. Even if signage alone could be considered a RS, it might not be there since I don't see it being signed along Ontario St./Orange Ave. with the five routes that are there already (US-422/SR-8/14/43/87), not to mention that one of those (43) is already not signed (there is also the side issue of where Ontario St. becomes Orange Ave.), nor do I see it being signed along I-77 or US-422/SR-8/87 because of how short the concurrencies are/would be. Granted, I haven't been there in person since the ribbon cutting so I can't say for sure; also WP:CRYSTAL. We can probably say in confidence, though, that I-490 has been truncated to I-77. In any case, the map on the SR-10 article needs to be updated.
Mapsax (talk) 22:43, 4 November 2021 (UTC)
- The SR 10 article is so short that a merger would probably be the way to go. The content can be reforked if the history section on SR 10 ever gets overwhelmingly large. SounderBruce 03:48, 5 November 2021 (UTC)
Couple of press releases
This uses the phrases "the new Opportunity Corridor Blvd.", "the Opportunity Corridor Blvd.", and "Opportunity Corridor Blvd.", no "the". It's still a bit vague but I guess that this is enough evidence to be able to use the last of the three, as I just have in the infobox.
I'd like to use this as a ref (primary source, I know) but perhaps I should use one from tomorrow or later that says it already opened.
Also, the infobox says "Maintained by ODOT". If this goes the way of other like roads in Ohio, it will be a road built by ODOT on the ODOT system but maintained by the city of Cleveland, so that line should probably be removed.
Mapsax (talk) 00:45, 13 November 2021 (UTC)
- With the consistency now of "Opportunity Corridor Blvd.", I'm now leaning against a merger because of the distinction of the Opportunity Corridor as a development versus the road itself. The infobox and junction list should be merged, but not the article as a whole. Mapsax (talk) 01:39, 14 November 2021 (UTC)
- I would change the scope of the article to the construction project itself (basically add changes to 105th Street), and mention a bit on SR 10's route description and history. I don't think the corridor itself is notable to have its own article. Nova Crystallis (Talk) 02:53, 14 November 2021 (UTC)
- The road and the corridor as a whole are essentially inseparable; the former was specifically not built as a freeway in order potentially to spur growth. So without a merge but with road content moved to the SR-10 article, there'd be a shell of an article dependent on another; with the merger, there would be a notable amount of non-road content on a road article, which could be objectionable. Mapsax (talk) 18:55, 16 November 2021 (UTC)
- I never said the road content should be removed from the article itself. Nova Crystallis (Talk) 23:01, 16 November 2021 (UTC)
- The road and the corridor as a whole are essentially inseparable; the former was specifically not built as a freeway in order potentially to spur growth. So without a merge but with road content moved to the SR-10 article, there'd be a shell of an article dependent on another; with the merger, there would be a notable amount of non-road content on a road article, which could be objectionable. Mapsax (talk) 18:55, 16 November 2021 (UTC)
- I would change the scope of the article to the construction project itself (basically add changes to 105th Street), and mention a bit on SR 10's route description and history. I don't think the corridor itself is notable to have its own article. Nova Crystallis (Talk) 02:53, 14 November 2021 (UTC)
Missing shield files at List of state highways in North Carolina and List of suffixed Arkansas state highways
There are missing shield files at List of state highways in North Carolina and List of suffixed Arkansas state highways. I poked around a couple of modules but did not find an easy way to make them appear. – Jonesey95 (talk) 17:28, 17 November 2021 (UTC)