User talk:Yarfpr/Archive 1
 | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
| Archive 1 | Archive 2 | Archive 3 |
Welcome!
Welcome to Wikipedia, Yarfpr! I am WereSpielChequers and have been editing Wikipedia for quite some time. I just wanted to say hi and welcome you to Wikipedia! If you have any questions, feel free to leave me a message on my talk page or by typing {{helpme}} at the bottom of this page. I love to help new users, so don't be afraid to leave a message! I hope you like the place and decide to stay. Here are some pages that you might find helpful:
- Introduction
- The five pillars of Wikipedia
- How to edit a page
- Help pages
- How to write a great article
I hope you enjoy editing here and being a Wikipedian! Also, when you post on talk pages you should sign your name on talk pages using four tildes (~~~~); that should automatically produce your username and the date after your post. If you need help, check out Wikipedia:Questions, ask me on my talk page, or place {{helpme}} on your talk page and ask your question there. Again, welcome!
File copyright problem with File:PR secondary 159.svg
Thank you for uploading File:PR secondary 159.svg. However, it currently is missing information on its copyright status. Wikipedia takes copyright very seriously. It may be deleted soon, unless we can determine the license and the source of the file. If you know this information, then you can add a copyright tag to the image description page.
If you have uploaded other files, consider checking that you have specified their license and tagged them, too. You can find a list of files you have uploaded by following this link.
If you have any questions, please feel free to ask them at the media copyright questions page. Thanks again for your cooperation. FASTILYsock(TALK) 07:45, 19 March 2010 (UTC)
Problems with upload of File:PR primary 3R.svg
Thanks for uploading File:PR primary 3R.svg. You don't seem to have said where the image came from, who created it, or what the copyright status is. We require this information to verify that the image is legally usable on Wikipedia, and because most image licenses require giving credit to the image's creator.
To add this information, click on this link, then click the "Edit" tab at the top of the page and add the information to the image's description. If you need help, post your question on Wikipedia:Media copyright questions.
For more information on using images, see the following pages:
Thank you for your cooperation. --ImageTaggingBot (talk) 19:05, 6 March 2016 (UTC)
ArbCom Elections 2016: Voting now open!
Hello, Yarfpr. Voting in the 2016 Arbitration Committee elections is open from Monday, 00:00, 21 November through Sunday, 23:59, 4 December to all unblocked users who have registered an account before Wednesday, 00:00, 28 October 2016 and have made at least 150 mainspace edits before Sunday, 00:00, 1 November 2016.
The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.
If you wish to participate in the 2016 election, please review the candidates' statements and submit your choices on the voting page. MediaWiki message delivery (talk) 22:08, 21 November 2016 (UTC)
ArbCom 2018 election voter message
Hello, Yarfpr. Voting in the 2018 Arbitration Committee elections is now open until 23.59 on Sunday, 3 December. All users who registered an account before Sunday, 28 October 2018, made at least 150 mainspace edits before Thursday, 1 November 2018 and are not currently blocked are eligible to vote. Users with alternate accounts may only vote once.
The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.
If you wish to participate in the 2018 election, please review the candidates and submit your choices on the voting page. MediaWiki message delivery (talk) 18:42, 19 November 2018 (UTC)
A barnstar for you!
|
The Special Barnstar |
| Your work on the highways of P.R. is much appreciated! Level C (talk) 10:14, 22 March 2019 (UTC) |
Change of Puerto Rico Tertiary network roads into Secondary network roads
Hello. In this edit HERE you changed the PR road network type for road PR-503 from a Tertiary network road to a Secondary network road. (On that date -24 August- you made several other similar Tertiary-to-Secondary changes.) However, you did not include a summary of your change in the Edit Summary line. On what basis was the change made? Mercy11 (talk) 04:11, 30 March 2019 (UTC)
- Hi, @Mercy11: I appreciate that you helped me with the situation of the PR-503. I see that you reversed some changes made by me in the PR-9, which I thank you for. However, I have a question: should PR-123, PR-132 and PR-163 appear as primary urban routes instead of secondary ones? I say this because, according to the criteria that is being followed in Wikipedia, you forgot that detail. I hope you clarify me the doubts I have to be able to reverse all the changes I made during the past days. Regards. Yarfpr (talk) 16:19, 31 March 2019 (UTC)
- There's a lot to that question, but I'll try to be brief.
- It is OK for PR-123 to be both Secondary and Primary Urban, depending on the segment of that road under consideration. The article should display both shields. The main basis for shield type (as opposed to the main basis for numbering) is how the road is used. The bulk of that road is Secondary, but the segment from Port of Ponce to the road's intersection with PR-132/Calle Villa in Barrio Canas Urbano is indeed used as Primary Urban, that is, it "provides mobility between zones and important generators [of commerce and traffic] within the ... Ponce metro area." Note that it also says, "Primary Urban are those roadways within [the Ponce] urban zone that complement the Primary network in the Ponce metro area." (DOC) Because different segments of PR-123 have different uses, the road qualifies for both shields (and both are planted on the physical road itself by DOT). If you check that road, you will see it provides mobility between PR-12 and PR-2, both unarguably Primary network roads. The same is true with PR-132, which intersects (in the Ponce urban zone) with PR-9, and PR-10. Again, both PR-9 and PR-10 are unquestionably Primary network roads.
- As for PR-163, that road has no Secondary network legs to it, yet DOT used a number in the Secondary range (100 to 299) in the shield for it. Why? First, based on its use, it is a Primary Urban network road because it does "provide mobility between zones and important generators [of commerce and traffic] within the ... Ponce metro area. Primary Urban are those roadways within [Ponce] urban zone that complement the Primary network in the Ponce metro area." The Primary roads in question in this case are PR-2, PR-12, and PR-9.
- That said, why didn't DOT use a number between 1 and 99 for PR-163? There are 3 possible explanations I can think of. (1) It's possible that with the building of so many new roads in recent years, that all numbers from 1-99 were used up and DOT needed to start using numbers from some other network (e.g., from the 100-299 group) to designate a Primary road by using such (Secondary) 100-299 number but on a Primary network shield. So you end up with, for example, PR-163 on a Primary Urban shield, instead of on a Secondary as its number would suggest. (2) DOT could have all other "remaining" numbers in the 1-99 range already committed, or "on reserve", for use on other roads yet to be built. (3) DOT could have an Island-wide road grid map and number "163" happened to fall in the Ponce area (notice that PR-133, also with a Primary Urban shield but with a Secondary range number, is in Ponce as well). Again, these are my own theories regarding that subject based on field observations, etc.
- I think the thing to remember is that as a general rule roads numbered 1 to 99 all fall in the Primary network and are roads that traverse the Island or significant portions of it (think PR-2, PR-52, PR-3, PR-10, PR-66, etc); roads numbered from 100 to 299 all fall in the Secondary network and are roads that move you from one municipality to another (think PR-100, PR-149, PR-177, PR-199, etc); and roads numbered 300 to 999 all fall in the Tertiary network and are always roads that have both of their termini in the same municipality (think PR-301, PR-413, PR-503, PR-715, PR-873, etc). This is not a perfect rule, just a rule of thumb. For example, try to find a road numbered 300 to 999 that traverses the Island; I don't believe you will find it. Try to find a road numbered 1 to 99 that has both termini in the same municipality. There may be a handful, but they are all used to connect two roads belonging to the 1-99 range that do, themselves, terminate in different municipalities.
Citing an Amazon sales page
I've noticed that you've including links to a map for sale at Amazon.com. I assume that you want to cite the map, not the sales page. If so, you shouldn't be linking to that page.
To simplify, you can use <ref name="NGAdvMap">{{cite map |author = National Geographic Maps |year = 2011 |title=Puerto Rico |series = Adventure Map |scale = 1:125,000 |location = Evergreen, CO |publisher = National Geographic Maps |sections = |isbn=978-1566955188 |oclc = 756511572 }}</ref> to cite:
National Geographic Maps (2011). Puerto Rico (Map). 1:125,000. Adventure Map. Evergreen, CO: National Geographic Maps. ISBN 978-1566955188. OCLC 756511572.
One thing to note though: a proper map citation should include a reference to where on the map, the grid section or inset, that's being cited; this is analogous to citing a specific page within a book. Additionally, WorldCat.org is a great resource to find additional information about a source; you can access the WorldCat.org entry about this map by clicking the OCLC number in the citation. Imzadi 1979 → 03:17, 13 April 2019 (UTC)
- Hi, @Imzadi1979: Thanks for the clarification. In the case of the date, I did not use the year 2011 because I think the map search must coincide with the date of creation of the article of the road that is being talked about (access date), but now I understand your code. I will correct that error on all roads that I modified. Regards. Yarfpr (talk) 13:56, 13 April 2019 (UTC)
Your cites
Hello Yarfpr. Your edit here was awesome! However, I don't seem to find the cite for the highway lengths that you added. Unless they are already there but I am somehow missing them, can you add them while the information and source is still fresh in your mind? Thanks, Mercy11 (talk) 00:11, 24 April 2019 (UTC)
- Hi! This link is the one I am currently using to indicate the length of the roads (the other one that appears in the article is broken). This list includes the road networks to which each segment of the road belongs. Yarfpr (talk) 00:18, 24 April 2019 (UTC)
- That's an awesome, awesome cite. Thanks! I am so busy now, but can't wait to make use of that cite in other articles. Really excited about it! Thanks! BTW, if you wouldn't mind, which is "the other one that appears in the article [that] is broken"? I would like to try find a copy that might still alive somewhere online. If you can take a sec and put it in a reply, I would appreciate greatly. Thanks! Mercy11 (talk) 23:54, 24 April 2019 (UTC)
- What I really meant was that the link I shared with you was broken in other road articles (sorry), but you're right: I forgot to put it initially in the new lists. This other link can also be used and appears to be more updated than the previous one (it is basically the same list, but it is not in PDF). Yarfpr (talk) 03:13, 25 April 2019 (UTC)
- Hi Yarfpr, Your edit here continues to puzzle me. You edited that, for example, PR-9 has a length of 4.52mi/7.27km. However, when I got to the link you provided me above (this link), and I searched for either 4.52 or 7.27, it doesn't find them. Now, that document arranges routes numerically so when I go to page 28, I find it describes routes PR-8 and PR-10, but doesn't seem to list PR-9 at all. And when I searched the entire document for the string "PR-9", it returns one hit only: the entry at page 70 for route PR-123, which reads "Entre PR-501 y PR-9". That, of course, doesn't give the length. So, how exactly did you arrive at the conclusion that PR-9 is 4.52 miles long, or, since the document doesn't list miles but kilometers only, how did you end up with PR-9 having a length of 7.27 kilometers? Thanks, Mercy11 (talk) 02:37, 2 May 2019 (UTC)
- Hi, @Mercy11: Forgive me for making you wait too long for this response (I hadn't noticed your messages in this section)! The reference that was used in the list to indicate the PR-9 length is located in the first reference of its article because it isn't available in the list that I shared with you. Yarfpr (talk) 02:43, 3 May 2019 (UTC)
- OK, I picked a bad example. I was using PR-9 only as an example. My interest is in knowing, per WP:V, how you got the tens of other distances you added there. It puzzles me because the link you provided me above (this link), is a document where DTOP lists the AADT at various points of various roads. The "km" colunm there, for example, has nothing to do with road length; it's just the point on the road where they set up their AADT counter. It has nothing to do with the distance that roads have -- which is how, if I ain't mistaken, you seem to have used it. Thanks, Mercy11 (talk) 02:55, 3 May 2019 (UTC)
- @Mercy11: Oh, I understand what you meant (sorry). You're right. The km that I used as a reference was the last one indicated in each route (the largest). If you believe that the correct thing is to remove them until the truth of the information is confirmed, do it. Anyway, they had to be fixed because not all the lengths match the list I gave you.
- One recommendation I am going to make is that the lengths in all the lists should show first the km (on the left) and then the miles (on the right) because the roads of Puerto Rico are measured in km, not miles (this consistency should be maintained throughout the article). For some of the lists, the
|length_mi=should be replaced by|length_km=. Yarfpr (talk) 03:18, 3 May 2019 (UTC)
- One recommendation I am going to make is that the lengths in all the lists should show first the km (on the left) and then the miles (on the right) because the roads of Puerto Rico are measured in km, not miles (this consistency should be maintained throughout the article). For some of the lists, the
- I agree, kilometers first, then miles. In fact, we may be able to have just one column with both kms and miles using Convert. For example, for Primary highway PR-1 (under the "Primary highways" section):
- 128.51 km (79.85 mi)
- BTW, In light of what you said above, I will looking for cites for each of the highway distances (just like PR-9 which doesn't come from the AADT document), and add them in. Any existing distances I can't find a cite for, I will remove. Then, as we find more distances, they can be added together with their cite info.
- Regards, Mercy11 (talk) 21:09, 3 May 2019 (UTC)
- I agree, kilometers first, then miles. In fact, we may be able to have just one column with both kms and miles using Convert. For example, for Primary highway PR-1 (under the "Primary highways" section):
Missing PR shields
Hello Yarfpr: Please take a look at this conversation. I know it's lengthy but it can give you a sense of the scope to which I was trying to take the PR road articles in the past. Unfortunately even today articles such as PR-505 still display the wrong shield (Urban Primary instead of tertiary take care, Mercy11 (talk) 03:08, 27 April 2019 (UTC)
- Hello, @Mercy11: Thanks for sharing that old conversation with me. At the moment I finished with the creation of all the primary and urban primary shields that were missing. Soon I will be creating more secondary and tertiary shields to replace the incorrect shields in the articles. In addition to that, and as indicated above, we must be aware of the incorrect changes made by another registered user. A part of the problem is due to the lack of shields, but also the increase of them can result in that person can continue to make mistakes. If there were any way to eliminate those shields that are not needed in Wikimedia Commons, it would be great. Regards! Yarfpr (talk) 03:41, 27 April 2019 (UTC)
- Thanks. I am am trying to work on getting the offending files in Commons deleted. My first step was in identifying the offending files. To accomplish that, I created a (temporary) Commons Cat to group all such files. Someone (24.50.193.43) moved back the files I had placed in the new category and once the Cat was empty, nominated it for deletion. See HERE. You might want to comment there based on your experiences. Take care, Mercy11 (talk) 11:12, 27 April 2019 (UTC)
- I thank you for the modification to the Commons categories. In relation to that unregistered user, I have been watching him closely because sometimes he makes good contributions but sometimes he does strange things for no apparent reason. He is something similar to the user to whom we sent a message yesterday. Yarfpr (talk) 14:26, 27 April 2019 (UTC)
- I left him info on his talk page as to why I undid his changes. I think he means well but is still "green" in terms of understanding the PR govt road numbering system and the invalidity of many of the PR shields in Commons. (A large number of them were uploaded around 2010 by somewhere who apparently wasn't very familiar with the numbering system either.) Thanks for the Tertiary shields above - I am already putting them to good service! It's a large undertaking working with all of PR road articles in a consistent, uniform manner. I am sure you already know that. I have placed all the shields that are candidates for deletion from Commons HERE. Would you mind taking a look and adding other I might have missed, or question me about any that are there which you might find questionable. I occasionally make error too! Thanks, Mercy11 (talk) 15:11, 27 April 2019 (UTC)
- I think it's great that you sent him a message, so he can see things from the same point of view you raised. I understand your interest in prevailing the consistency between number, network and shield, but that same consistency has generated misinterpretations or little understanding by other people, including me at an initial moment. I say this because a road can change network and retain its number. For that reason many wrong shields appear in Commons and improper editions are still made in WP. By the way, do you think that some duplicate shields, badly made or with incorrect names could move to that category (like this, this and this, to mention a few)? Yarfpr (talk) 15:41, 27 April 2019 (UTC)
.png){kind=link}
- The govt of PR doesn't perfectly implement it's own numbering system. Perhaps partially because, above having a neat numbering system, the government must first respond to the administrative reality of changing traffic needs, which introduces a very dynamic, constantly changing, environment based on real-life pressing needs. Also, despite the DTOP's best intentions, actual road-building is a process that takes years, sometimes even decades (example: PR-10), and is further complicated by appropriations from two governments (PR and US Congress). So by the time the segment of a highway is actually built or enhanced, there are already new needs that may require it to be part of a different network than the one it was initially designed for. It's not a perfect system but it's almost perfect. What these various factors mean is that roads that were initially designed as, for example, Tertiary (300 to 9999) can be enhanced and become Secondary (in reality the most likely event is that segments of a Tertiary are enhanced and the road becomes a mix of Tertiary and Secondary), and the neat numbering system starts to become less so.
- So, while THIS document clearly states (on p. 1-2,) the numbering breakdown of 1-99, 100-299, and 300-9999, THIS OTHER document clearly shows, under the "Sistema" column, that roads almost always belong to 2 or more networks. Take for example, PR-505: THIS first document above defines it as a Tertiary road, so its article says it belongs to the tertiary network. However, THIS OTHER second document above (on p. 114) states that, for some short segments (0.85 km, and 3.40 kms each) of this 16.6-km long road, the road isn't always Terciary but Primary Urban. Worse yet, it doesn't categorize its entire length by Sistema/Network on the latter document, and perhaps even worse yet, it leaves blank the Network (Sistema) column for the 3 other entries there. This is then compounded by the evidence on the article itself (see the actual Secondary shield in the photo in the article PR-505) that the road does have some Secondary components that aren't even mentioned in that last document. So, go figure.
- This leaves open questions such as, should we delete the PR-505 Secondary shield from Commons (by luck, there isn't one but there are Sec shields for 503 and 504)? I say yes, it should be removed. For PR-505, specifically, this leaves open the question, should we delete the PR-505 Primary Urban shield? Again, I say yes. And the reasons I have are at least 2: (1) We already have a doc that states that roads numbered in the 500-9999 range are Terciary, but #2, and perhaps most important, if shields such as PR-505 Primary Urban were kept, I can already see future well-intended editors replacing the 505 Terciary shield with the 505 Primary Urban. To address this dichotomy my rule of thumb here is, Wikipedia is an encyclopedia, not a government highway design document and, as such, it should provide only the basic and most general and applicable information about a highway. It should not be a record of everything that there exists about a road. Newbies would be totally lost if a simple system that works across all highway cases isn't agreed upon. Otherwise, we may find ourselves endlessly undoing edit made by others who aren't fully aware of the complexities of the numbering problem. Give me your thoughts. Mercy11 (talk) 17:46, 27 April 2019 (UTC)
@Mercy11: Thank you for your valuable explanation because I had not seen it that way. I totally agree with everything you said because the same DTOP is not consistent with the signaling of its roads. For my part, I have no problem with the elimination of incorrect shields (both in articles and Commons) or any objection to implementing the consistency in number, network and shield in articles, but how will other users take it? I mean, how will we make other people stay on the same line with us? What will the creators of some shields think about the elimination of them?
On the other hand, I need to recapitulate the shields that are still needed to avoid falling into the creation of one that could eventually be led to elimination. According to your last update in the Puerto Rico Highway List article and the old conversation you shared with me:
- Primary shields - from 1 to 99 || Secondary shields - from 1 to 299 || Tertiary and Urban Primary shields - from 1 to 9999
I am right? Note that any road could be an urban primary regardless of its number. In that sense, there would be no need to eliminate the urban primary shield of PR-505 unless that information is corrected in the main article. Yarfpr (talk) 19:05, 27 April 2019 (UTC)
- I agree; let's leave all the urban primaries alone, including PR-505. It's a dynamic environment and, a road that has no PU (primary urban) segments today, could have them in the near future.
- As for how would other editors take it, other users can chime in. We could, for example, move this conversation to the List of highways in Puerto Rico article to give it more visibility but I don't think it's necessary: (1) What's going on is no secret to the other 2 major contributors to these articles (Anon IP @24.50.193.43:, and @Harrison Canyon: ), and their lack of response says they don't care either way; (2) We aren't establishing anything that could be controversial because none of it is contrary to what's already in place and documented by DTOP, (3) at worse, we are just invoking the W:BOLD principle which WP encourages, and (4) based on several discussions with Freddie and Imzadi on this matter (such as this one (from Jan 2011) and this one (from March 2019), I think both @Fredddie: and @Imzadi1979: are both aware something needs to be done to control the increasing number of PR shields in Commons that are invalid. That is, I think they are both aware there is a problem with a some of the PR shields that were created but which are being misused by uninformed editors because the shields are invalid and editors are using them in place of the correct (and sometimes missing) shields. I am pinging them in case they still any additional last minute input.
- As for what "shields that are still needed", it depends on whether you are referring to (a) articles missing shields (or the right shields) or to the overall universe of PR road shields as defined by DTOP. If "a", I can let you know as I come across them. If "b", they are all listed here in the huge list you see there. I stopped at 999 (i.e., no 1000-9999) because I think the 4-digit shields can be requested as they are needed. BTW, please take a look at this Commons Category. Note I created 3 new subcats: (1) Primary, (2) Misc, and (3) Unused. The plan is to submit for deletion the entire repertoire of shields in the "Unused" subcat. I can submit them for deletion, but you might be the best person to submit them because since you were the initial uploader (to most of them anyway) they cannot require you to contact the uploader. If you are ready to take on the task, be sure to remove or skip Primary-901 based on what you wrote here.
- Take care,
- @Mercy11: Thanks for the great explanation! Since these numerical ranges have been validated for each shield, everything is easier now. Obviously I will not create an urban primary shield if a highway does not need it (not all of them cross an urban area), but I wanted to highlight that detail added in the main article. Soon I will be adding more shields and correcting others as they are needed. Meanwhile, I'm going to take the liberty of moving to the unused category some duplicate, badly designed or incorrectly named shields. If someone does not agree, return them to their corresponding categories. Yarfpr (talk) 14:38, 28 April 2019 (UTC)
- If we still want to be more consistent with the number, network and shield of a road:
- Primary sheilds: from 1 to 99 only || Secondary shields: from 100 to 299 only || Tertiary sheilds: from 300 to 9999 only || Urban primary shields: any road between 1 and 9999
- If we want all this to be fulfilled effectively, we must know that the infobox road has five road types: Pri (primary), Sec (secondary), Ter (tertiary), Urban (urban primary) and PR (the four road networks of Puerto Rico simultaneously, according to the shields available in Commons). In the junction and previous/next routes sections, PR type is used only for the primary shields. I have seen that in the Puerto Rico categories there are no tertiary shields for many roads between 1 and 299, but they are also generated by the Ter type. This is because Ter type uses shields from other categories. The same happens with Sec type, which uses county routes shields of other categories that are not related to Puerto Rico (at least this does not appear in the upper part of the infobox road, contrary to the Ter type).
- What do I mean by all this? That if we want to ensure that consistency, there must be some way for Ter type to use only the tertiary shields available in the Puerto Rico categories. I also want to add that shields for roads between 1000 and 9999 should be allowed to be used without any problem in the junction and previous/next routes sections (they can only be used at the top of the infobox road). Unfortunately I do not know how these problems can be solved. Yarfpr (talk) 18:01, 28 April 2019 (UTC)
- Thanks for pointing the Pri and PR types. I hadn't noticed that! Again, IMO, you are definitely the guru with these shields! The road infobox template is here but it doesn't seem to document PR road types to that level. Many templates have a separate doc page, but I can't seem to locate the one for this template; maybe there isn't one.
- I am not sure I followed everything you said in your 2nd paragraph above (the "If we want all this to be fulfilled effectively..." paragraph). The 3rd paragraph I could follow a bit better, but I am not sure what everything in the 2nd paragraph meant. It would be best if you included examples of the problem by using wikilinks to existing WP articles containing the problems so I can visualize what you are experiencing. In the 3rd paragraph, for example, I am wandering about the "there must be some way for Ter type to use only the tertiary shields available in the Puerto Rico categories", but As opposed to what? I don't know what you are currently experiencing that gets you to say that, so you lost me there too.
- @Mercy11: Basically what I wanted to say was that in the tertiary category of Puerto Rico there are no shields available for many of the roads between 1 and 9999, but the Ter type responds to that need by using the shields of this other category. That is, suppose that PR-505 needs a tertiary shield. If I do not have that shield available in the tertiary category of Puerto Rico, the Ter type uses an equivalent of the elliptical shields category (you can only see what I am saying when you edit an article of any road that does not have a tertiary shield in the tertiary category of Puerto Rico). However, when a tertiary shield is loaded into the tertiary category of Puerto Rico, then it uses the latter because it is already in the category it should be. When I speak of the upper part of the infobox road I am referring to the shield in large size, and when I talk about the junction and previous/next routes sections, I am talking about small shields.
- In relation to the pentagonal shield, the upper part of the infobox road uses only the secondary shield that is available in the secondary category of Puerto Rico. However, in the sections where the smallest pentagon appears, the pentagons of this category or this other will always be used, depending on how many digits the road has (roads with three or more digits use a wider shield). Suppose I am going to create an article for PR-143. If I already have a secondary shield in the secondary category of Puerto Rico, the Sec type will only use it in the upper part of the infobox road because the small shields of the other sections will always be those of the county shields categories. Contrary to elliptical shields, if it happens that there is no secondary shield for PR-143 in the secondary category of Puerto Rico, that shield is not replaced by those of the county routes categories at the top of the infobox road, so that you would have to upload a file to the corresponding category.
- @Mercy11: Recapitulating once again, we can standardize the secondary and tertiary shields of roads according to two criteria (you choose the one you like or agree to):
- Primary shields: from 1 to 99 (unchanged)
- Urban primary shields: from 1 to 9999 (unchanged)
- Secondary shields (option 1): from 1 to 299
- Secondary shields (option 2): from 100 to 299 only
- Tertiary shields (option 1): from 1 to 9999
- Tertiary shields (option 2): from 300 to 9999 only
- In option 1, roads from 1 to 99 could have shields from all four networks, and roads from 100 to 299 would have tertiary shields (in addition to secondary and urban primary shields). In option 2, the shields would be perfectly standardized according to the number of each road and other users would be prevented from placing wrong shields on road articles.
- If option 1 is preferred, we would simply have to create the missing shields in each category. However, if option 2 is preferred, not only should the missing shields be created in each category, but some of them should also be eliminated. In addition to that, with option 2 we would have to correct the Ter type functions to avoid the appearance of shields of the elliptical route shields category. In that, @Fredddie: and @Imzadi1979: can help us. Yarfpr (talk) 19:30, 29 April 2019 (UTC)
- Wow! Great research! I am testing your observations with a newly-minted road: PR-588. I'll get back to you once I have had a chance to digest everything you wrote above. Thanks, Mercy11 (talk) 00:21, 30 April 2019 (UTC)
- I finally digested everything you had there. Thanks for being so structured; this sort of work requires logical thinking, structured planning, and methodical implementation, or the results could be a big mess. That said, I think we should go with Option 2. My reasoning is that, while Option 2 may initially require a bit more work than option 1 (i.e., removal of some shields from Commons, help from the US Roads Wikiproject team, etc) it seems to me Option 2 will make it easier for other users to add the correct shields to articles as well as prevent users from unintentionally placing invalid shields. Option 2 hardens the environment, making the system of shield-addition more foolproof, while simultaneously enforcing DTOP's 1-99P/100-299S/300-9999T/1-9999PU system. It can be annoying having to deal with cases of road articles having the wrong shields on a constant basis and, as the road articles increased in quantity, the problem was getting exponentially worse. Besides, and perhaps most important, when users realize they is a rational system behind it all, which they can readily catch up to, there is a greater possibility they will stick around and help. I am pinging @Rschen7754: because in the past he has provided great guidance. (That entire US Roads team runs a tight ship which is beneficial to everyone.) You can make requests at their Talk Page here If you have never submitted Commons file for deletion and want to try it, fine; if you need help with that, I may be able to help. You can then perhaps work with the US Roads team to achieve the other end of things. If you want to do both, I am fine with that too (I am loaded with stuff in real life, but will help for a good cause!). BTW, you might want to consider breaking this project down into 2 parts, for now: (1) The infobox top shields, and (2) the issue of shields for roads between 1000 and 9999 not working in junction and previous/next routes sections. I agree the junction box/previous/next thumbnail shields are a significant limitation that needs addressing soon, but I think the issue of getting all the various shields to display correctly on the infobox's top is more impacting right now and perhaps represents enough work for now. Just my thought. Mercy11 (talk) 01:30, 30 April 2019 (UTC)
- Let me know when you are ready to delete all the files in the Commons "unused" category. Before that, please make sure you remove any files that for whatever reason (Primary 901 was coming to mind) I might have placed there but which should be saved. We can, btw, create another cat at the same level as the "unused" for shields in a "transient" state (for P-901 perhaps?). Also, for delete nomination purposes, I may need to moved several files out of the unused into another temporary holding place so we can, hopefully, mass delete all the invalid files (invalid because there is shield-to-route# disagreement) and later mass delete the much smaller number of files whose deletion might be controversial (e.g., "Cuatro de Honor", "Puerto Rico Urban 1", etc.). Mercy11 (talk) 02:14, 30 April 2019 (UTC)
- @Mercy11: I also prefer option 2 because it provides that consistency that you mentioned so much to me from the beginning. Also, I feel uncomfortable to keep seeing other people adding wrong shields to the articles even though we've already sent them a message about it. I agree with the implementation of the changes only at the top of the infobox road, but I would like to be helped promptly by experts in these matters. In the same way that the pentagons of other categories only appear in the bottom sections where the small shields are placed, I would like the same thing to happen with the elliptical shields and that the numbers between 1000 and 9999 can be added freely.
- Tomorrow I will find a way to eliminate the shields of the Commons categories. I know you are very busy, but I would not like you to leave me alone in this matter because there are many things that I still do not know how to execute them correctly. If you want to make a new category, feel free to do so. For my part, I would eliminate all those shields as soon as possible, including the primary shield of PR-901, to prevent other people from continuing to use them unduly.
- NP. Anyway, you seem to have developed a better grasp of the entirety of the work that needs to be done as well as have a better register somewhere of all the existing (valid and invalid) shields than even I myself had just a few days ago! I don't know how you do it but, for example, the correct native Puerto Rico tertiary shield for PR-588 didn't exist just before I created the PR-588 article today. I then witnessed for myself your description of how shields for tertiary roads that don't exist in the current repertoire of native PR Tertiaries in Commons get "borrowed" from a pool of similar generic shields elsewhere in Commons when a call is made for a native PR tertiary that hasn't been built yet. That was the main reason I created the article to begin with (at the time, I checked all existing Tertiary road articles in List of highways in Puerto Rico and none of them were running off a non-native PR tertiary shield, so I couldn't use wny of tehm to check the behavior you were describing - thus the reason I had to create a new road article, and making sure its native PR shield didn't yet exist in Commons tertiaries cat.) Then, within minutes after I witnessed the behavior you had described, suddenly, the native PR shield appeared in the PR-588 article! Checking your contributions list I could see you did something but it's not clear to me how you did it so fast when, according to Rschen7754 himself, sometimes it takes him "months" to complete some shield requests. I don't know how you did it, but whatever you did, keep doing because it's working wonders!!
- BTW, when reviewing the shields currently in the "Unused" category, please be careful not to submit for deletion any valid ones. For example, I just noticed that PR-1 Secondary is among them (filename = "PR secondary 1.svg"). If we were to delete everything that's currently in the "Unused" group, that shield, which is valid within the context of "|type = PR" (the option that produces all 4), would also be deleted. Please use your well-developed expertise to skip from deletion shields (Secondary or otherwise) that may be in the "Unused" category, but which in reality shouldn't be part of that group. If my assessment here is wrong, perhaps I am missing something that I am sure is crystal clear to you. Thanks. Mercy11 (talk) 04:06, 30 April 2019 (UTC)
@Mercy11: When I saw that you created an article for PR-588, I decided to create a shield in the tertiary category of Puerto Rico. For that reason everything happened very fast. I forgot to say that there are two categories of elliptical shields: this (previously mentioned), for small shields, and this one, for large shields (those on the top of the infobox road). Precisely, that last one is the one that I need to dissociate from Puerto Rico or, at least, some algorithm should be developed that only allows the use of those shields for the roads between 300 and 9999.
The reason why I moved the secondary and tertiary shields from PR-1 to unused category was, precisely, to impose the consistency that we already discussed, but you can allow an exception with that road. The PR type only works with the shields available in the Puerto Rico categories. That is, if PR-143 only has a secondary shield, PR type will only show that because it is the only one available in the Puerto Rico categories. Therefore, if PR-1 has its secondary and tertiary shields removed, PR type will only show the primary and the urban primary. This is because PR type never adds the shields of other categories not related to Puerto Rico, unlike Sec or Ter types. Yarfpr (talk) 13:57, 30 April 2019 (UTC)
- Perhaps the US Roads team can help (let's not go to them until we have the entire logic worked out and the plan laid out for them to implement). That team includes guys that work with the various road templates. We need them bc most templates use logic not always fully/properly documented, or algorithms based on codes and/or scripting languages that the standard editor would not generally be familiar with. In addition, we need them bc generally all templates throughout English WP are locked, but they have aditional access rights that we don't.
- Perhaps they can create the equivalent of the PR type, but to affect the other 3 network type shields. That is, perhaps they could create 2 additional (plus 1 modified) types, something like these:
- (1) Rename type=PR to type=PRPri (Description: a type that only works with the shields available in the Puerto Rico categories (Pri, Sec, Ter, and PU), and which displays the Pri, Sec, Ter, and PU shield types for the road in question when PRPri is invoked [Ex: PRPri for PR-1 would display the PR-1 Pri, Sec, Ter, and PU shields for PR-1]) Note that this type already exists, so they would only need to rename it for consistency with the following 2 below. Alternatively, it could be left alone altogether since it already does everything in the description.
- (2) Create type=PRSec (Description: a type that only works with the shields available in the Puerto Rico Sec, Ter and PU categories, and which displays the Sec, Ter, and PU shield types for the road in question when PRSec is invoked [Ex: PRSec for PR-143 would display the PR-143 Sec, Ter, and PU shields for PR-143])
- (3) Create type=PRTer (Description: a type that only works with the shields available in the Puerto Rico Ter and PU categories, and which displays the Ter, and PU shield types for the road in question when PRTer is invoked [Ex: PRTer for PR-500 will display the PR-500 Ter and PU shields for PR-500]) Note that at PR-500, the shield at top of the Infobox is Tertiary but, since PR-500 connects PR-9 (a primary) to PR-132 (a secondary), the picture at PR-500, here shows a PU 500 on the roadway.
- (1) Rename type=PR to type=PRPri (Description: a type that only works with the shields available in the Puerto Rico categories (Pri, Sec, Ter, and PU), and which displays the Pri, Sec, Ter, and PU shield types for the road in question when PRPri is invoked [Ex: PRPri for PR-1 would display the PR-1 Pri, Sec, Ter, and PU shields for PR-1]) Note that this type already exists, so they would only need to rename it for consistency with the following 2 below. Alternatively, it could be left alone altogether since it already does everything in the description.
- @Mercy11: I decided to save the secondary and tertiary shields of PR-1 because they appear in several articles external to Puerto Rico. I have already started the process of deleting the wrong shields in the unused category. For now, tertiary PR-2R was chosen, but I don't know if I did it correctly. Yarfpr (talk) 15:31, 30 April 2019 (UTC)
- @Mercy11: I just read what you sent me before my last response. We don't necessarily have to complicate with those types that you propose. There must be some way to unlink those shields that we don't want to use. For example: I created old shields in this category, but since there is no code or algorithm for them, they are not used in the types unless you add the
| marker_image = [[original file here]]together with the others. Maybe the only way to unlink those shields in PR categories from the algorithms could be renaming the files. The primary shields are named PR primary XX; the urban primary, PR urban primary XX; the secondary ones, PR secondary XX, and the tertiary ones, PR tertiary XX. If that format is changed, maybe they would de-link from the types and, possibly, there would be no need to eliminate them, at least at this time.
- @Mercy11: I just read what you sent me before my last response. We don't necessarily have to complicate with those types that you propose. There must be some way to unlink those shields that we don't want to use. For example: I created old shields in this category, but since there is no code or algorithm for them, they are not used in the types unless you add the
- Yarfpr, if it won't be necessary to created more types, but we will still be able to have unique types that do exactly what's needed, then let's go for it!
- However, how will we prevent users from creating invalid shields (such as a primary shield for PR-600, which is nonsense)? Will we still need US Roads team to implement a protocol whereby their bot will deny creation of invalid shields? That part concerns me a bit. We need to remember that there is a behind-the-scenes rule at play here that associates the route number with a network level and that, in addition, also determines the number of shields that will validly display at the top of the infobox. The rule says that
- "For Puerto Rico highways, the number of valid shields for any route number (say, PR-250) consists of the shield design associated with the network represented by its number (in this example, the pentagonal Secondary shield design) plus the shield designs associated with all other network level above the network level of the route number in question." (This rule holds true except for extremely rare instances, like the special case with Tertiary route PR-901 that you brought up recently.)
- However, how will we prevent users from creating invalid shields (such as a primary shield for PR-600, which is nonsense)? Will we still need US Roads team to implement a protocol whereby their bot will deny creation of invalid shields? That part concerns me a bit. We need to remember that there is a behind-the-scenes rule at play here that associates the route number with a network level and that, in addition, also determines the number of shields that will validly display at the top of the infobox. The rule says that
- This means that lower-numbered routes (say, PR-50) will have 3 valid shields -- the shield associated with the Pri network plus shields associated with the Sec and Ter networks as well, which are networks above the Pri of PR-50 (this explains why the Pri, Sec, and Ter shields are all valid for PR-1) -- yet higher-numbered network routes (like, say, PR-750) can have valid shields consisting only of the Ter level shields (the B&W round/oval) because there are no levels above the Ter level. Valid shields for the Sec level network are, likewise, the Sec and Ter, but never Pri, because only the Ter level is above the Sec level. So, for Tertiary numbered routes the number of shields will be 1, for Secondary numbered routes the number of shields will be 2 and for Primary number routes, the number of shields will be 3.
- Also, how will we prevent users from creating invalid shields related to PU shields? For example, we know PR-500 has a valid PU shield and any user should be able to get such valid PU shields created. But allowing for the creation of a PU shield for PR-588, would be a problem. PR-588 (and most other Ter roads in the 300-9999 range) do not connect to Primary networks and will, thus, never have a PU shield planted on the physical road. So how will these be controlled and these problems be eliminated?
- @Mercy11: That rule that you shared with me returns to this discussion the option 1, which worries me because it would continue to allow other users to continue using or creating the wrong shields. In that sense, the types you mentioned could definitely help our interests. In any case, we will have to consult with the US Roads team about our concerns and see what solutions they present, if any.
- What is still unclear to me is whether all the shields present in the unused category will be eliminated or if there would be some that are not. By the way, I also ordered to remove the PR-2 secondary shield. If I have to cancel both requests (the other is PR-2R tertiary shield), let me know as soon as possible. Yarfpr (talk) 21:08, 30 April 2019 (UTC)
- @Mercy11: The only thing that I don't agree with that rule or with the examples of types you gave me is that they perpetuate the option 1. While it is true that a secondary road should not have a primary shield or a tertiary road should not have a primary or secondary shields, I also think that the absolute consistency promoted by the option 2 was the best alternative for everyone, even if it did not coincide with the information provided in the main article, which states that a highway can belong to more than one network.
- That's why I think that, if new types are made, they should be like this:
- PRPri - only Pri and Urban Pri || PRSec - only Sec and Urban Pri || PRTer - only Ter and Urban Pri
- (Oops, there was an edit conflict when I tried to post. Here is my response to the above; I still need to read and respond to you new material below (the one that caused the edit conflict). Please try to wait till you get the response before posting additional stuff): Yarfpr, maybe we (ahem, I) do not yet have all the facts fully sorted out in terms of advantages and disadvantages of both options. You have a better hold on what the repercussions of both options are than me. One thing is for sure, if and when we head to the US Roads group to make our case, we need to have everything fully "digested" and ready for them. At a minimum, we need to have (1) a complete understanding of what the current problem/s are, (2) all the possible solutions well figured out, and (3) full confidence that we can answer all their likely questions. Every time you respond I perceive you are a step or two ahead of me on this subject -- very likely helped by the additional time you had already been working with the roads article before I got a bit more involved (as for me, when I go to those articles, it's usually to add facts and citations; for me shields are pretty, but facts and cites are my thing). So, ultimately I will support what you think and decide is the better of the 2 options and, if I don't like it later, well, too bad for me, and I will have to live with it. :-(
- Whether or not all the shields in the Unused category are deleted is up to us (really, you). I think you aren't giving yourself enough credit; you have really learned this thing inside out! In reality, it will be driven by the choice of option you ultimately settle with. If you think you want to think about this a bit more or to discuss it a bit further, then, sure, you can stop any delete request you already made. As a thought, it is almost always safer to start deleting first those shields that represent lesser-known routes. That way, if you need to undo anything, but it's too late to, then a shield or two may have been lost but only for lesser known route (less impact). Once you feel comfortable with the results (meaning, after deleting say some 5-10 of the lesser known route shields) you can then go for the heavyweights of PR-1, PR-2, PR-3, etc. To conclude, can you create a "table" of sorts with the advantages of Each Option, including criteria such as (1) ability of users to add invalid shields, (2) maximum # of shields that will display at top of the infobox for the Primary Network (if there is a 3 for Pri, then we know that the option in question will display a 2 for Sec and a 1 for Ter), (3) whether or not, regardless of option chosen, PR-1 will display all 3 shields (4 with the PU), at least for PR-1's example in List of highways in Puerto Rico, (4) any other criteria you have have seen is important and that gives different results for the 2 different options.
@Mercy11: After I spent a while analyzing all the possibilities, you should talk to the US Roads team to correct the types as follows:
- PR: 1-99 - Pri, Urban, Sec and Ter
- PR: 100-299 - Urban, Sec and Ter (excludes Pri)
- PR: 300-9999 - Urban and Ter (excludes Pri and Sec)
- Pri: 1-99 only. For the other roads the shield would not be generated although there are some in the primary category.
- Sec: 1-299 only (for roads between 300 and 9999 the shield would not be generated even though there are some in the secondary category.
- Ter and Urban: any road between 1 and 9999.
The shields of categories external to Puerto Rico can continue to be used in the small shields of the lower sections of the infobox road. If a secondary or tertiary shield is needed at the top of the infobox road, the shields of categories external to Puerto Rico could be used, as long as the Sec and Ter types are used, respectively, so that the PR type would only use the shields that are available in the Puerto Rico categories. With this proposed restriction to the PR type according to the road number, it would be avoided to eliminate bad shields because the code or algorithm would take care of the rest. Basically, it would be your PRPri, PRSec and PRTer without using so many type options.
Let me know if that idea is good or if it can still be improved (or if I still don't understand something you said to me). Yarfpr (talk) 22:30, 30 April 2019 (UTC)
- Hi. I don't mind posting a question at the US Roads Talk Page, except I am not sure I can decode your message above, that is, the following lines:
- PR: 1-99 - Pri, Urban, Sec and Ter
- PR: 100-299 - Urban, Sec and Ter (excludes Pri)
- PR: 300-9999 - Urban and Ter (excludes Pri and Sec)
- Pri: 1-99 only. For the other roads the shield would not be generated although there are some in the primary category.
- Sec: 1-299 only (for roads between 300 and 9999 the shield would not be generated even though there are some in the secondary category.
- Ter and Urban: any road between 1 and 9999.
- I am sure it's clear to you, but it's not to me.
- My guess is that what you are suggesting is probably something like this:
Click "[SHOW]" on the right to see inside ->
|
|---|
|
- Is this what you are suggesting? Did I read you right?
- If I did get it right, then please let me know now AND please give me time to re-read through and "digest" your last paragraph which I haven't yet studied. Mercy11 (talk) 00:20, 1 May 2019 (UTC)
- @Mercy11: Sorry to write too much without waiting for you to answer me first! When something comes to my mind, I find it difficult to hold it, LOL!
- In the last messages we didn't understand each other completely, but I think I have already made a happy medium decision for both, or at least I hope so. While it is true that option 2 is the best for both, option 1 is easier to digest for others. Option 1 allows the information provided in the list of roads in Puerto Rico to be effectively complied with in the types of routes.
- The idea with the last message I said above was that in the same way that you have to make a special request for the shields of the roads between 1000 and 9999, you should also do the same with any highway between 100 and 9999 that justifies a primary shield, or a secondary one in the case of roads between 300 and 9999 (PR-901 could be taken into consideration). In this way, the "wrong" shields could not be used in the algorithms, unless someone directly asks the US Roads team to include it. In this way, we should not eliminate those shields in Commons and we would not have to retain the unused category anymore.
- Don't worry about the cross-messages; we worked it out alright! As for your last paragraph that I still needed to "digest" - Yes! , now I understand everything you said there and in fact, I had already reached those same conclusions (about not having to submit any shields for deletion) in my "Significance/Implications" section above, not knowing they were already there further down in your summary! hahaha! I agree with everything you said there.
- Listen, remember you have no need to reach a "happy middle" with me: you are the main contributor to those articles, so I will go with whatever you decide. Let me know what your final decision is and if I can help further. I feel VERY comfortable with whatever decision you make because you really mastered all the logic in this stuff, and very quickly! wow! BTW, I found your 2 Commons delete requests and commented with "oppose" for both, just to give you time to decide what you really wanted to do. Sometimes those delete requests are performed within minutes if they came from the author, which was the case in these instances.
- Got to get get up early tomorrow for work (para ganarme el arroz y las habichuelas - jaja!) but leave me a message how else I can help and I should be reading it tomorrow after work. Cuídate! Mercy11 (talk) 01:52, 1 May 2019 (UTC)
- @Mercy11: Gracias por soportarme, LOL! I believe that with the last things we said, we are more than ready to execute the next big step: talk to the US Roads team. I hope that my idea is possible, easy, logical and acceptable to them.
- I already canceled the deletion requests of PR-2 and PR-2R shields. Thank you for opposing it. I hope I have made all the right arrangements. By the way, I would like to speak more often in Spanish with you (I have a talk page in that language, if you're interested). :-) ¡Cuídate! Yarfpr (talk) 03:28, 1 May 2019 (UTC)
- @Mercy11: ¡Hola de nuevo! :-) Before we go to the US Roads team, we must recapitulate everything we discussed earlier:
- Large markers at the top of infobox road / infobox road small:
|type=PR- Will only generate the available markers in the Puerto Rico categories. For|route=1-99, it will include the primary, urban primary, secondary and tertiary markers. For|route=100-299, it will include the secondary, urban primary and tertiary markers, excluding the primary marker. For|route=300-9999, it will include the tertiary and urban primary markers, excluding the primary and secondary markers.|type=Pri- Will only generate the available markers in the primary category. For|route=1-99, it will include the primary marker, excluding the urban primary, secondary and tertiary markers. For|route=100-9999, it will exclude the primary marker in the primary category because they are not roads with primary numbers. For|route=100-9999, the urban primary, secondary and tertiary markers will not be included.|type=Sec- Will only generate the available markers in the secondary category. For|route=1-299, it will include the secondary marker, excluding the primary, urban primary and tertiary markers. For|route=300-9999, it will exclude the secondary marker because they are not roads with secondary numbers. For|route=300-9999, the primary, urban primary and tertiary markers will not be included.|type=Ter- Will only generate the available markers in the tertiary category. If a marker does not exist in that category, it can be replaced by an elliptical marker of another category. For|route=1-9999, it will include the tertiary / elliptical marker, excluding the primary, urban primary and secondary markers.|type=Urban- Will only generate the available markers in the urban primary category. For|route=1-9999, it will include the urban primary marker, excluding the primary, secondary and tertiary markers.
- Small markers in lists and sections at the bottom of the infobox road (jct, prev / next routes, etc.):
|type=PR- Will only generate the available markers in the primary category (replaces|type=Pri). For|route=1-99, it will include the primary marker, excluding the urban primary, secondary and tertiary markers. For|route=100-9999, it will exclude the primary marker in the primary category because they are not roads with primary numbers. For|route=100-9999, the urban primary, secondary and tertiary markers will not be included. This type should be replaced by|type=Prito create consistency.|type=Sec- Will only generate the available markers in the generic county routes categories. For|route=1-299, it will include the pentagonal marker, excluding the primary, urban primary and tertiary markers. For|route=300-9999, it will exclude the pentagonal marker because they are not roads with secondary numbers. For|route=300-9999, the primary, urban primary and tertiary markers will not be included.|type=Ter- Will only generate the available markers in the tertiary category. If a marker does not exist in that category, it can be replaced by an elliptical marker of another category. For|route=1-9999, it will include the tertiary / elliptical marker, excluding the primary, urban primary and secondary markers.|type=Urban- Will only generate the available markers in the urban primary category. For|route=1-9999, it will include the urban primary marker, excluding the primary, secondary and tertiary markers.
- NOTE 1: The primary markers available in the unused / primary category for
|route=100-9999can not be generated by|type=PRor|type=Pri, unless a special request is made for it. - NOTE 2: The secondary markers available in the unused / secondary or generic county routes categories for
|route=300-9999can not be generated by|type=Sec, unless a special request is made for it.
- NOTE 1: The primary markers available in the unused / primary category for
- Hi. I know this is a strange question to ask this late in the game but, in your own words, what problem(s) are the shields causing that we are trying to address and solve? Nothing long but, can you list them in two groups: (1) Problems related to the large route shields that display at top of the road infobox (Template:road), and (2) Problems related to the thumbnail junction route shields that display under the "Major Junctions" section of the road infobox (Template:jct) as well as thumbnail "navigational" route shields that display under the "Highway System" section of the road infobox?
- I ask you because I am convinced you have been exposed more, much much more, to the problems with the shields that I have, and you understand them fully. Your proposal above is very good, but remember when we go to the US Roads team with our request, these people --unlike us-- haven't been analyzing and digesting this issue for 5-6 days, so they well need the request in just a few sentences that clearly articulate the problem and how we would like the system to behave.
- So what I need is to, first, make sure that I am myself thoroughly familiar with the problem, so I know why we are making the request and, then, I will be in a position to articulate to them how we would like the system to behave.
- Thanks, Mercy11 (talk) 00:10, 2 May 2019 (UTC)
- @Mercy11: Hello! Thanks for asking me those questions. After all, it is necessary to perform them and understand the situation well before heading to the US Roads team. In this way, we would also facilitate the situation to them.
- The problem is that route types cause users to use the wrong markers for many of the Puerto Rico highways as there are no limitations in their use and handling. This problem is reflected both in the main markers on the top of the infobox road and in the thumbnails of other sections and lists. To solve this problem, it is necessary that Pri type be compatible with roads between 1 and 99 only, and that Sec type be compatible with roads between 1 and 299 only, excluding from these restrictions Ter and Urban types because any road between 1 and and 9999 can have Ter and Urban type markers.
- In the case of the PR type, it is necessary to make a correction according to the recommendations given in the other types discussed above. While it is true that a road can belong to more than one network, it is preferable that PR type only shows the shields that are compatible with the number or network of the route in question, proposing the creation of a special request when the need arises to add other markers that do not match the route number or network in question.
- Hi. I am starting to compose our request to US Roads wikiproject. I may be using the existing set of shields in Commons in some of my examples to them. So as to minimize the possibility of confusing them due to the potential interference with my examples that could be created by the addition of new shields, please be sure you do not upload any additional shields to Commons until they have both read my request and finalize their delivery of a solution to us. Do you currently have any pending shields you already requested but which have not yet received? If so, please let me know, as we will have to either cancel the request of such shields, or else wait for it to be fully completed and posted in Commons. Thanks, Mercy11 (talk) 02:57, 4 May 2019 (UTC)
Hi, @Mercy11: Right now I have no plans to add new shields to Commons. The last ones I added were for the list of primary roads (to complete the list) and for highway PR-6693 because a user added information about that road in the PR-693 article (related route). If you need help explaining the situation to the US Roads team, don't hesitate to contact me, please. I don't want to leave you alone in this situation. Yarfpr (talk) 03:50, 4 May 2019 (UTC)
Question in preparation for Request
Hi. Here you said that "if we want to ensure that consistency, there must be some way for Ter type to use only the tertiary shields available in the Puerto Rico categories." (I think what you really meant was "if we want to ensure such consistency, there must be some way for the Ter type to use tertiary shields from the pool of tertiary shields available in the Puerto Rico-specific categories only, and not some generic substitute.") You said that, because you were pointing out that when the Ter type was invoked in the infobox road template, but there was no Ter shield available in the pool of PR-specific Ter shields (this pool is currently here), then the infobox would grab a similar shield from the generic pool of shields that the US Roads group keeps at this site. Other than the noble goal of bringing the Ter type into consistency with the Pri type (and perhaps with the Sec type - I still have to look more into the Sec types), are there are problems caused by the use of generic shields for Puerto Rico roads? That is, are any problems caused by using a similar generic shield where a Pto Rico-specific shield would had been used? Let me use an example to further describe my question: If the PR-specific shield for tertiary route PR-385 (which shield currently doesn't exist here --but please don't created it yet, so I can use it to demonstrate the problem to the US Roads team) isn't available, and a generic one that is available is used, are any problems created by the use of such generic shield? Mercy11 (talk) 14:35, 5 May 2019 (UTC)
- Hi, @Mercy11: What I meant there was based on option 2 (Ter type = any highway between 300 and 9999 only), but it is no longer necessary to take that comment into consideration because we chose option 1 (Ter type = any highway between 1 and 9999). Remember that Ter type uses a generic marker when it doesn't exist in the PR tertiary shields category, but PR type doesn't include that generic marker if it doesn't exist in the PR tertiary shields category. For example: if I use PR type in the PR-52 article, PR type will not include a tertiary marker next to the primary one (because it doesn't exist in the PR tertiary shields category), but if I change the PR type to Ter type, then will use a generic marker (to cover that need in the PR tertiary shields category). All this occurs because PR type only includes the markers available in the PR categories. Having explained that detail, there is no need to eliminate that versatility of the Ter type because it doesn't affect our goals of identifying roads correctly.
- In relation to the secondary markers, it isn't necessary to make any correction with them (beyond being used only by roads between 1 and 299) because Sec type at the top of the infobox road will always use the secondary marker available in the PR secondary shields category (same as the PR type). What happens with Sec type is that it doesn't use the markers available in the PR secondary shields category when thumbnail markers are needed in other sections, but that isn't an inconvenience either.
- If you still have doubts about something that I have said, don't hesitate to ask me. Regards. Yarfpr (talk) 16:03, 5 May 2019 (UTC)
- Hi Yarfpr, thanks for your response. Your example with PR-52 above made all the difference in my understanding your perspective. You stated here that "the problem is that route types cause users to use the wrong markers for many of the Puerto Rico highways as there are no limitations in their use and handling." Using an example (or 2, or whatever number), as you did with PR-52, can you describe this problem that "the route types cause users to use the wrong markers for many PR roads". Thanks for your patience, but I think I was "getting lost in the forest" (with the many road 'problems' that keep distracting my attention) and "losing track of the tree." You, on the other hand, seem to be very focused on exactly what the problem is. Can you send me an example or two that show the problem?; I think examples will work wonders in helping wrap this thing out. From there, if I have any other question, then I will know they are ancillary to this main problem that you have stated and will treat them likewise. Thanks, Mercy11 (talk) 21:18, 5 May 2019 (UTC)
- Hi, @Mercy11: I was referring with these arguments to two existing problems: the first is that there are incorrect markers in the PR shields categories, and the second is that the route types—because they have no restrictions on their use—cause users to make use of those incorrect markers present in the PR shields categories. For example: PR-100 has a primary shield in the PR primary shields category. If I use the PR type at the top of the infobox road, the primary shield will appear next to the secondary one, which is incorrect because PR-100 doesn't belong to the primary network. Another similar example occurs with PR-511, which has a secondary shield. If I use the PR type, the secondary shield will appear next to the tertiary one, which is incorrect because PR-511 doesn't belong to the secondary network. This is the case with many other roads. Yarfpr (talk) 21:48, 5 May 2019 (UTC)
- Hello Yarfpr. I didn't forget about you! Sorry if it looked like I was "dragging my feet" on this - I will try to submit it today before bed. I will ping you when I do, so you know the process has started. Or, I can send you a message before I submit it so you can review it to make sure you agree with the wording and that it's got everything you think is important. Let me know if you prefer that 2nd option, please. Thanks for your patience. Mercy11 (talk) 00:02, 7 May 2019 (UTC)
Yarfpr, please review the proposed request wording and comment as needed.
Proposed request to USRD group
|
|---|
|
[I am not posting this at the Shields Page because it isn't exactly a request for shields; but, if it's more appropriate there, feel free to move it - thx.] [1] There are shields stored in Commons here that would never be shields seen on a Puerto Rico road because they don't derive from the the PR Government official documents (this one (pp. 1,2) and this one p. 1-2, section 1-03.01) that establish the guidelines for route numbering in PR. A sampling of some such "invalid" shields (there are many, many others) are:
Proposal: While a temporary solution to this would be to delete all such invalid shields from Commons, a more permanent, robust approach is needed so that they will not be re-created in the future in the first place. We think the best solution is to either (a) for the USRD team to implement procedures whereby requests for such shields aren't honored in the future or (b) to integrate logic into the bot that currently aids in the shield-creation process so that it will not allow for the creation of such invalid shields any longer. Then, also, to delete all the invalid shields from Commons. Of course, we are open to your suggestions and advise as to alternate solutions. [2] Well-intended editors make changes to the Infobox road's "type" field turning what was a correct shield display into an incorrect one. We have traced the culprit in this problem to be the lack of restrictions (i.e., lack of controls) in the Infobox road "type" field. When we say "lack of restrictions" we mean that, in spite of whichever route number is specified in the "route" field (remember, there is a govt-established correlation between route number and shield design) editors can still enter whichever of the 5 available options in the Infobox's "type" field ("Pri", "Sec", Ter", "Urban" or "PR" [this last one, displays shields for all 4 networks]). As long as the shield exists in Commons (again, here), the Infobox will display it. To illustrate, PR-100 is a Secondary Network route, yet it has this primary shield in the Puerto Rico Commons categories, here. This invalid shield exists in the Commons categories even though PR-100 is not a Primary Network route number, but a Secondary Network route number. Now, if were to populate the "type" field for PR-100 with "PR" (the code to display all shields with that route number on it, regardless of their design, the (invalid) Primary Network shield for route 100 would appear next to the valid secondary Network shield, this one. Such display would be incorrect because PR-100 doesn't belong to the primary network, but to the Secondary Network only. To illustrate further, PR-511 is a tertiary Network road, but it has a secondary shield stored in Commons. If we were to populate the "type" field with "PR", the shield for the Secondary Network routes would appear next to the valid tertiary network shield this one. Again, such display would be incorrect because PR-511 is not part of the Secondary Network, but part of the Tertiary Network. Proposal: We believe the solution to this second problem is to introduce logic into the Infobox road for cases where state=PR to enforce the following restrictions:
Thanks. |
Let me know what additions/deletions/clarifications are needed. Thanks, Mercy11 (talk) 03:44, 7 May 2019 (UTC)
- @Mercy11: Hi! I took the liberty of replacing the example of PR-760 with PR-585 because PR-760 doesn't have an independent article (it redirects you to the Ruta Panorámica). In relation to everything else, it's perfect! For now, it doesn't occur to me that other explanations should be added unless requested later. After all, it is a summary (obviously general) of all the details and situations observed. Yarfpr (talk) 14:05, 7 May 2019 (UTC)
- Posted here! Mercy11 (talk) 00:33, 8 May 2019 (UTC)
Autopatrolled granted
Hi Yarfpr, I just wanted to let you know that I have added the "autopatrolled" permission to your account, as you have created numerous, valid articles. This feature will have no effect on your editing, and is simply intended to reduce the workload on new page patrollers. For more information on the autopatrolled right, see Wikipedia:Autopatrolled. Feel free to leave me a message if you have any questions. Happy editing! -- Lofty abyss 19:21, 6 May 2019 (UTC)
- Thanks to both, Lofty abyss, Mercy11! Yarfpr (talk) 01:56, 7 May 2019 (UTC)
Request follow up
It seems to me that if the guys at US Roads project can help us implement the required logic so Option 1 takes effect, then we can have all road articles with type=PR, and the appropriate shields will be displayed. That is, there will no longer be a need for types = Pri, Sec, Ter or Urban; the only type needed will be type=PR. Do you agree? Is this what you also foresee? Mercy11 (talk) 23:52, 9 May 2019 (UTC)
- @Mercy11: Hi! I don't think I have fully understood what you said to me, but if only the PR type is used, two things could happen:
- 1. All shields for a road (the correct and incorrect ones) will be shown at the top of the infobox road, unless option 2 is used to show only the shield that corresponds to the network to which the road belongs according to its number. If option 2 is used, the urban primary shields could be lost and all the necessary shields would have to be added manually (both the urban primary and those of other networks).
- 2. Small shields in other sections wouldn't be compatible with option 1. To avoid errors, option 2 would have to be implemented in them. The urban primary shields would also disappear if that proposal is implemented and there would be no way to manually add them.
- I would like you to correct me because I feel lost at this moment. :-( Yarfpr (talk) 01:26, 10 May 2019 (UTC)
- OK. Currently type=PR displays all the possible shields for a route with the qtty of shields (1,2,3, or 4) being controlled only by the availability of the shields for that route in Commons, right? So, if there are 4 shields for PR-1 in Commons, 4 get displayed. But if we were to remove PR-1 Sec and PR-1 Urban shields from Commons, then type=PR for route=1 would display only the PR-1 Pri and Ter shields, agree? (This was scenario [1] in the Request)
- However, now we are introducing logic to control which shields get displayed based on the route number (Pri will display Pri shield only if route=1-99, Sec will display Sec shield only if route=1-299 and Ter will display Ter shield for 1-9999, and any other combinations of route # and types, (e.g., route=585, type = Pri) will result in a blank display, not because the 585 Sec shield doesn't exists in Commons but bc it doesn't pass the Restrictions logic test). This still assumes that all the qualified shields are available in Commons, but now will not display the wrong shield for a route; for example, PR-503 will not display a Pri shield. If the editor enters type=Pri for route=503, (nothing will get displayed).
- Now, if we are going to clean up Commons such that availability of shields will be reduced to only the subset of "valid" shields (again, Scenario [1]), then we will end up with shields only according to a predefined conventional set of rules (Pri shields only for routes #1-99; Sec shields only for routes #1-299 ; and Ter shields for #1-9999) and nothing else; so all existing shields will, for once, be "valid" shields. This, it seems to me, means that now I can have route=585 and type=PR and, since Restrictions does not affect what gets displayed (i.e., it doesn't affect the qtty of shields displayed) but controls what not to display, for a Ter route like 585 it will display only Ter shield (it will not display Pri and Sec shields bc the Restrictions logic disqualified those shields for routes #s beyond 299) which is the desirable output anyway. (This was scenario [2] in the Request)
- These 3 examples, all with type=PR, should help visualize it:
- route=PR-1
- type=PR
- >> displays all 4 shields [Restrictions restricted no routes bc Rt 1 is present in all 3 Logic tests]
- >> displays all 4 shields [Restrictions restricted no routes bc Rt 1 is present in all 3 Logic tests]
- route=PR-143
- type=PR
- >> displays 3 shields (Sec/Ter/Urban) [Restrictions restricted Pri bc Rt 143 is not present in the Pri group Logic test]
- >> displays 3 shields (Sec/Ter/Urban) [Restrictions restricted Pri bc Rt 143 is not present in the Pri group Logic test]
- route=PR-503
- type=PR
- >> displays 2 shields (Ter/Urban) [Restrictions restricted Pri and Sec bc Rt 503 is not present in the Pri or Sec group Logic test]
- >> displays 2 shields (Ter/Urban) [Restrictions restricted Pri and Sec bc Rt 503 is not present in the Pri or Sec group Logic test]
- route=PR-1
- Again, this seems to suggest that, once USRD group implements the needed logic, that we will no longer need to use type=Pri, type=Sec, type=Ter, or type=urban. Scenario 1 Strategy will take care of making the necessary shields available, and Scenario 2 Strategy will take care of displaying only the correct shields for that network type.
- @Mercy11: If I didn't misunderstand, everything you explained to me always referred to the shields on the top of the infobox road, but what would happen to the small shields of other sections?
- Of course PR type will work perfectly with large shields, but if a road has a shield that is left over, how will we avoid its appearance next to the others? Should it be removed from Commons? It must be borne in mind that a primary numbering road doesn't always belong to the four networks at the same time (they can be pri+urban, pri+sec, pri+ter, pri+urban+sec, pri+urban+ter, pri+sec+ter or simply pri). Similarly, a secondary route doesn't necessarily belong to the other three networks at the same time (sec+urban, sec+ter or simply sec), and a tertiary road doesn't belong to an urban primary at the same time (ter only). I know that "I'm drowning in a glass of water", but a situation like these should be taken into account to avoid the presence of wrong shields despite the proposed changes. That's why I don't consider it appropriate to remove the Pri, Urban, Sec and Ter types. Yarfpr (talk) 05:00, 10 May 2019 (UTC)
- What I am seeing is the following (and correct me, please):
- The large shields at the top of the infobox road will always be identified with the PR type. The PR type will generate up to four shields available in Commons for roads between 1 to 99; it will generate for the roads from 100 to 299 any shield that isn't the primary one, and the roads from 300 to 9999 may have only tertiary and urban primary shields. In this way, it will not be necessary to use the Pri, Urban, Sec and Ter types because the PR type will be responsible for not showing the shields that aren't compatible with the number or the road network.
- However, the removal of Pri, Urban, Sec and Ter would generate the appearance of shields that don't correspond to a road in question (see the last paragraph that I wrote in my previous comment). Likewise, in the sections where the small shields are shown, the Pri, Urban, Sec and Ter types can't be removed because errors could arise. I remember that you told me to focus on the top of the infobox road for now because that is where the most important shields are, but I believe that changes must be made everywhere to guarantee the consistency we want.
- My suggestion is that, so that the PR type can be used at the top of the infobox road, all the surplus shields in Commons will be removed, but that the use of Pri, Urban, Sec and Ter in the small shields will continue to be maintained, adjusting the types to the number and network of each road (option 1), and also removing the surplus shields from them. Another alternative for small shields is to use the PR type based on option 2, but keep the Urban type when needed. That is, PR = pri, sec or ter, depending on the number of the road, but Urban = any road that has an urban segment. Yarfpr (talk) 06:12, 10 May 2019 (UTC)
- Hi. No, I wasn't remotely suggesting that any of the types be removed. Also, I had worked thru in my mind all the stuff you included in your response already -- but didn't include it bc I didn't wanna make my email a mile long! That said, my purpose was to "pick your brain" and check if you agreed that what I was envisioning would, in fact, happen once the Restrictions are implemented. Looking at it from the other end, I wanted you to check on my logic and perhaps find something I was missing or overlooking that could make my "vision" faulty, incorrect.
- As for the thumbnail shields, again, you are always one or two steps ahead of me (which is a good thing!). My approach so far has been to worry about the thumbnails after we have been able to bring the regular-sized shields under control. But, since I am not suggesting getting rid of any types, I believe your concern with the thumbnail shields is then no longer applicable anyway. And, no, I didn't think you were "drowning in a glass of water"; you make very valid points, that I haven't always even remotely thought of. On that note, you ought to give yourself some credit! You understand more of the repercussions of each of the 5 types when mixed with the numerous scenarios of presence/absence of shields in Commons, the results under the two different options, etc. As for me, sometimes when I think about this entire "enchilada" I have to scratch my head bc my brain starts to hurt!!
- However, let's think about the thumbnail shields for a second. Remember that everything we have done so far officially at USRD pertains to (1) the planned removal of "invalid" shields from Commons and (2) modifications wanted to the "Infobox road" template to implement Restrictions. As for #1, remember that if a shield is invalid (i.e., nonsense) in real life, it will be invalid in both, its regular and its thumbnail size depictions. As for #2, remember that the thumbnail shields result from a different template, the {{jct}} template, not the Infobox road template. You might want to go here for more info on the jct template, and see if it uses similar types (Pri, Sec, Ter, Urban, PR) or if it runs on its own separate nomenclature (I guess it's the latter). These comments are true for, at least, the thumbnail shields under the "Major Junctions" section of the Infobox; I don't yet know how the Infobox road generates the thumbnail shields under the "Highway System" section of the Infobox.
- And, yes, I support the idea of removing invalid shields from Commons, but since we went with the Option 1 [Ter type = any highway between 1 and 9999], to display up to 4/3/2/1 shields (depending on the network type), instead of Option 2 [Ter type = any highway between 300 and 9999 only)], to display only the ONE shield associated with the network resulting from the route number, then there is no need to remove any shields yet. I say, let's wait until the USRD team has implemented the requested logic. It will give us a stronger voice at Commons as we petition for removal of shields if the Commons admins can see we have the USRD team behind us. (Correct me if I am wrong but, in my recollection, when you submitted the remove requests at Commons for (a) Sec shield of PR-2 and (b) Tertiary for PR-2R, we were projecting on going with Option 2, the option that displays 1 shield and 1 shield only; but we abandoned Option 2 shortly after that, and have since decided to go with Option 1, and we haven't switched back to Option 2 again.)
- @Mercy11: Hello! You're right in your last paragraph. The reason why I asked for the removal of both shields was because at that time we thought to apply the option 2, but then we went with the option 1 and I decided to cancel the removal. As for the types in regular shields (top of the infobox road), now it was clear to me that it wasn't that you wanted to remove them, but that you wanted to replace them little by little in all the articles to corroborate the tests by the US Roads team. In relation to the small shields (jct), there will be no changes to be made nor will the incorrect ones have to be removed from Commons. Last night my brain "went to fly", LOL! Yarfpr (talk) 03:16, 11 May 2019 (UTC)
Source
Have you seen this source? If not, I hope it may be of help.--The Eloquent Peasant (talk) 04:07, 10 May 2019 (UTC)
- @The Eloquent Peasant: Hi! I saw it before but I don't know how Mercy11 and I can definitely solve this problem because that PDF and his last message revive the option 2 discussed above and we already established the criteria shown in the List of highways in Puerto Rico#Highway markers (option 1). For now I'm going to rest because the tiredness has blocked me. Maybe tomorrow I'll have things clearer. Regards. Yarfpr (talk) 04:24, 10 May 2019 (UTC)
Good luck, get some rest. so far it looks good to me ...--The Eloquent Peasant (talk) 04:30, 10 May 2019 (UTC)
- @The Eloquent Peasant: Thanks for your help. I'm so clueless that I don't know if that PDF you sent to me was because of my conversations with Mercy11 or to add it to the articles I've been creating recently. LOL! Now I'm leaving. Yarfpr (talk) 05:05, 10 May 2019 (UTC)
- If it'll make you feel better. I had no motive to share it with you. There was nothing (no message) no reason for you to understand any hidden message from me LOL ===> or for you to read into my question of "did you see that?" LOL. Just yes I saw it or no I didn't would have worked 'cause I'm completely clueless on this and just following your and Mercy's lead... I got interested only 'cause I'm currently taking pics of shields and kilometers....--The Eloquent Peasant (talk) 05:10, 10 May 2019 (UTC)
- BTW, I read the .pdf just to see if there was anything there to expand the stub article to make it a start. And I think I did destub one --> Puerto Rico Highway 111 I think the criteria for destubbing is good references on all parts of the article and more than 1500 B of readable prose.--The Eloquent Peasant (talk) 05:25, 10 May 2019 (UTC)
- @The Eloquent Peasant: Thanks for all the pics you've shared in the articles! They are giving them an incredible life! BTW, thanks for the stub detail. I didn't know when it should be removed from an article. Yarfpr (talk) 14:30, 10 May 2019 (UTC)
- If it'll make you feel better. I had no motive to share it with you. There was nothing (no message) no reason for you to understand any hidden message from me LOL ===> or for you to read into my question of "did you see that?" LOL. Just yes I saw it or no I didn't would have worked 'cause I'm completely clueless on this and just following your and Mercy's lead... I got interested only 'cause I'm currently taking pics of shields and kilometers....--The Eloquent Peasant (talk) 05:10, 10 May 2019 (UTC)
- @The Eloquent Peasant: If you're interested, I'm correcting the major junctions section of the infobox road based on the MOS:RJL. Here SounderBruce responded to Mercy11 that the east-west roads must be west-east and the north-south must be south-north to maintain consistency. Yarfpr (talk) 15:11, 10 May 2019 (UTC)
- Yarfpr, keep in mind how Dough4872 here later qualified SounderBruce's response to indicate that, while in general the directions are as SoundBruce stated (South to North and West to East), because that's how the WP:RJL MOS has it, the real reason is that in the US roadway mile markers generally start at Zero in the south (or west) terminus and increase as you travel towards the north (or east) terminus. So, it's not really just an S->N and W->E convention, its actually that junctions in the junction lists should be arranged in order of increasing mile markers (km markers in PR). So, for example for PR-52, mile markers start at zero in the North (San Juan) and increase as you move towards the South, so the junctions list for PR-52 would actually be the reverse of WP:RJL. I haven't read the entire WP:RJL yet, to see if here are any exceptions, but seems to me order of increasing mile markers (which almost always is S->N and W->E in US roads) is the real criteria to follow. You might want to look at that "standard" more closely before investing time standardizing routes along purely S->N / W->E lines. Hope this helps! Mercy11 (talk) 01:43, 12 May 2019 (UTC)
Carretera Central request
Hello Yarfpr - A couple of editors here have taken up the task of creating a map for the historic Carretera Central, and the map is now almost done. See it this location in OSM. Check it out!
It's good to have maps of roads in the infobox, and most major PR roads have them (e.g., PR-52, PR-10, PR-22, even PR-12). However, Carretera Central doesn't yet. With the new map of Carretera Central they created, the next step is to link it to the CC article. However, because of Hurricane Maria, the editors have not completed the map and have a question about whether the bridge over Rio Descalabrado on the border between Coamo and Juana Diaz on PR-14 (and which Maria had apparently swept) has been replaced by a new bridge, as that may mean that their new map may need to be adjusted a bit. Their request is for someone to physically go there and check out the status of the bridge for them and report back. They thought I was in PR, but I am not. Since Eloquent Peasant was in PR taking pics of roads and shields (here) and visiting an Hacienda this weekend (here), I emailed him here to see if he could check out the bridge, but he hasn't responded.
So, sorry if this was long-winded but I wanted to give you some background info. The fact is that the 2 editors (Doncram and Ipoellet) could use someone to check out that bridge for them. Are you in PR and within range of the Coamo/Juana Diaz area that you could provide them the answer they need (so they can activate their Carretera Central map in OSM and have it appear in the WP article's infobox)? If you are in PR and able to perform this "field survey" for them, you can email them directly here. Thanks! Mercy11 (talk) 03:17, 19 May 2019 (UTC)
- @Mercy11: Hello! I'm in Puerto Rico, but I don't live near that area (I'm from Corozal). The last time I was in that area, the old bridge was still being used. Before the hurricane, a new bridge was being built because the old one could no longer bear the weight of the trucks (the truck drivers had to deviate towards PR-536, PR-52 and PR-153 or PR-545 to reach Coamo). I understand that the new bridge was finished, but I don't know if the old bridge survived the hurricane.
- I take this message to let you know that I'm interested in creating a list of insular roads of the first half of the 20th century. In my sandbox I developed a prototype that already has several references that maybe can help Doncram and Ipoellet with the historical background of the Carretera Central and other places of interest in Puerto Rico. I'm currently planning to obtain the road shield that was used in the middle of last century, but the book where I saw it I don't have it at hand at this time. :-( Yarfpr (talk) 03:50, 19 May 2019 (UTC)
- Thanks for considering the request, anyway! As for insular roads, that's a great idea! Please be sure to cite any sources you use (I love citations!), since that falls within historical articles and readers may want to do further digging in. I am sure you will include how PR-10 (the old one, today's PR-123) was numbered Carretera No. 6. I am interested in all of that old stuff. I don't know how much Doncram and Ipoellet would need additional historical background for CC. I gave them Mari Mut's, Castillo's and Pumarada's works which I consider the holy trinity of CC but, of course, there were other roads in addition to CC back then. Doncram's specialty is, as I remember, NRHP's stuff. He adds sites as they get registered with the NPS and, if they are from Ponce or nearby, I try to write the article for it. It's more than I could handle to write articles for all the sites in PR that get registered, so I just do the Ponce region. Ian Poellet, on the other hand, likes to take pics, like this one of the historic bridge over Rio Portugues and, for what I can see now, he also likes to draw maps.
- Now I am hoping I caa get back to my former project which was taking 2nd place after the irregularities you and I discovered with PR roads, including dealing with el mudo de Harrison! tc Mercy11 (talk) 23:06, 19 May 2019 (UTC)
Post-implementation of Template updates
@Mercy11: Here I share my observations:
1. PR type shows the shields in the following way:
1.1. PR type on a primary road will generate the following combinations: Pri (see PR-10), Pri+Urban (see PR-25), Pri+Sec, Pri+Ter (see PR-28), Pri+Urban+Sec (see PR-5), Pri+Urban+Ter (see PR-27), Pri+Sec+Ter (see PR-31) and Pri+Urban+Sec+Ter (see PR-1). In the case of PR-22, PR-52, PR-53 and PR-66, the Autopistas de Puerto Rico shield is automatically included next to the primary shield. The urban primary, secondary and tertiary shields are only shown for the roads that the Transit Data document considers valid.
1.2. PR type on a secondary road will generate the following combinations: Sec (see PR-100), Sec+Urban (see PR-132), Sec+Ter (see PR-143) and Sec+Ter+Urban (see PR-102). PR type excludes any invalid primary shield and only adds urban primary and tertiary shields to those roads that have segments of either of the two networks (Transit Data). In the case of PR-186 and PR-191, the forest shield is automatically included next to the secondary and tertiary shields.
1.3. PR type on a tertiary road will generate the following combinations: Ter (see PR-511 and Ter+Urban (see PR-500). PR type excludes any invalid primary or secondary shields and only adds the urban primary to those roads that have segments of that network (Transit Data).
1.4. The primary, urban primary and secondary shields are obtained from the Puerto Rico categories of Commons. The tertiary shields are of the Elliptical shields category. If a shield doesn't exist in that category, it is replaced by one of the PR tertiary category (mainly for 4-digit roads).
2. Urban, Sec and Ter types have no restrictions on their use. That is, any highway can show the shields present in the Puerto Rico categories. Ter type doesn't use shields from the Elliptical shields category, but those from PR tertiary category.
3. Infobox road small and JCT templates: Pri (infobox), Urban, Sec, Ter and PR (infobox/JCT) types have no restrictions on its use. That is, any highway can show the shields present in the Puerto Rico categories. Sec type uses shields from both PR secondary (infobox/JCT) and Generic county shields categories (JCT). Ter type uses shields from both PR tertiary (infobox/JCT) and Elliptical shields categories (JCT).
3.1. The shields for 4-digit roads no longer have restrictions on their use. That means that it is no longer necessary to make a special request to generate them.
I hope I have helped you in this project. Yarfpr (talk) 03:50, 19 May 2019 (UTC)
- Wow! That you have,...you have!! Thank you for sticking with me on this shields stuff till the end!
- BTW, does all of this means that we will no longer need to use the Pri, Urban, Sec, and Ter types for the large shields in the PR road articles infoboxes? That is, did my previous rationale materialized, the one where it seemed to me that if we implemented Restrictions (as it appears Fredddie has now done), that we could use only the PR type no matter what the route # was (i.e., no matter what network the road was in), and no matter what invalid shield were stored at Commons, and we would get the correct set of shields to display.
- In summary, can we now be confident that this solution will make it impossible for edits like those done by Harrison Canyon to occur in teh future?
- Lastly, shouldn't a "doc" page be added to the Template:Infobox_road/shieldmain/USA/PR page containing your points 1 thru 3.1 above, in the same way that, for example, Template:Infobox museum (and most other infoboxes) has a "doc" page here? For example, Template:Infobox_road has a its doc page here. By documenting your points above on the Template Template:Infobox_road/shieldmain/USA/PR space itself, as opposed to your Talk page, we can memorialize it into perpetuity. Mercy11 (talk) 19:18, 19 May 2019 (UTC)
- @Mercy11: With PR type at the top of the infobox road, it's no longer necessary to use Pri, Urban, Sec or Ter types because PR type is in charge of placing the correct shields (if there is an error, I can manipulate the codes in our favor). However, these types still exist, but only use present shields (valid and invalid) with the PR_shield (pri, urban, sec or ter) files format (I noticed something new about Ter type today and I explain that in the next paragraph). What does this mean? That people like Harrison Canyon could continue to make mistakes or vandalism as long as they know in advance all this background, of course, but the good news is that he is no longer with us.
- In relation to Ter type, Fredddie renamed mostly of the PR_tertiary files to Ellipse_sign. What does this mean? That the PR Tertiary category was "merged" with the Elliptical Route Shields category. He made this decision because the Elliptical category has all the shields from 1 to 999, plus some of 4 digits and others with suffixes that he and I created or moved to there. This prevents the shields from duplicating because they have the same design in both categories (the only thing that changed was the file name). This also allows 4-digit roads to have their small shield in the JCT template without the need to create a special request.
- Do you remember that I once told you that Ter type used circular shields when these weren't in the Tertiary category? Now this dynamic was reversed. If you place the Ter type at the top of the infobox road, the following things will happen:
- 1. PR-52 has no tertiary shield linked with PR_tertiary file name. In earlier times, a circular shield was obtained to cover that need. Now that doesn't happen because Ter type only uses the PR_tertiary shield present and there is none for that road. If I replace Ter type with PR type, that shield won't be generated by Ellipse_sign file either because the code doesn't allow that to happen with that road.
- 2. PR-64 has a tertiary shield linked with PR_tertiary file name. If I use PR type, that type will use the Ellipse_sign file (that was established in the code), but if I use the Ter type, that type will use the PR_tertiary shield because PR-64 has a PR_tertiary file already. In this sense, to prevent a highway from showing its tertiary shield with PR_tertiary file name, maybe is necessary to rename its file or delete it. In other words, Ter type will use both Ellipse_sign and PR_tertiary files. This case doesn't occur in the JCT template. There the PR_tertiary was permanently replaced with Ellipse_sign. In that sense, the space where the PR_tertiary shield is placed will show an error.
- Regarding your last paragraph, it would be great if someone could show on one of those pages the explanations I have given you for the benefit of all of us. Everything happened very fast. I think some improvements can still be made to avoid what I mentioned in my first paragraph, but at this moment I'm satisfied with everything that was achieved. For now, I'll go into "sleep mode" and see how things work before I take action. Yarfpr (talk) 22:23, 19 May 2019 (UTC)
Puerto Rico Highway 722 listed at Redirects for discussion
An editor has asked for a discussion to address the redirect Puerto Rico Highway 722. Since you had some involvement with the Puerto Rico Highway 722 redirect, you might want to participate in the redirect discussion if you wish to do so. signed, Rosguill talk 17:27, 22 May 2019 (UTC)
Assessing new USRD articles
We use a simple formula to assess articles, detailed at WP:USRD/A. Even if you're not comfortable assessing articles for quality and importance, could you add the |needs-map= and |needs-jctint= parameters? For the former parameter, it's a yes/no option. For the latter, it has a third option, |needs-jctint=missing if the junction list is missing, versus if it needs to be converted to use {{PRint}} or another {{jctint}} option. Imzadi 1979 → 02:41, 7 June 2019 (UTC)
- @Imzadi1979: I got it! I really wasn't familiar with what you explained to me and I didn't dare to mark incorrect things. Thanks for helping me. Yarfpr (talk) 02:49, 7 June 2019 (UTC)
A barnstar for you!
|
The Graphic Designer's Barnstar |
| Everything looks good! The historic refs look great too! The Eloquent Peasant (talk) 05:14, 23 July 2019 (UTC) |
- Thank you, The Eloquent Peasant! Yarfpr (talk) 05:17, 23 July 2019 (UTC)
Thanks for creating and uploading this article. I was really glad to see you took on such self-challenge and happier yet that you did accomplish it! History articles aren't always easy to put together, especially with accompanying cites to back it up. The article's myriad of references will be very useful to many of us I am sure. Again, thanks for your contributions to Puerto Rico articles. Mercy11 (talk) 19:40, 27 July 2019 (UTC)
- Hi, Mercy11! Thanks for your comments! One of the reasons I'd returned to WP was because I saw the need to collect and provide the information shown in that article. I trust that many of the references will be very useful for you and the other users who contribute greatly in topics related to Puerto Rico. The truth is that it entertained me to read all the documents that led me to the creation of that list and I couldn't pass up that opportunity. Regards! Yarfpr (talk) 03:22, 28 July 2019 (UTC)
- You really did find such great references. I added the history section, the map and some some refs. (Other historic maps were later ommitted but can be found in Commons.) YARFPR, I enjoyed this very much because I like working with others, but you did MOST of the hard work! It was fun working on this with you in your sandbox YARFPR! Until next time! Let me know anytime!--The Eloquent Peasant (talk) 14:45, 28 July 2019 (UTC)
- Thank you a lot, The Eloquent Peasant! That article was made possible thanks to all your help and support. I don't know how I didn't mention you in my previous comment (sorry); I think it was because of the emotion, haha. I would love to continue helping with other articles about Puerto Rico. Thanks again for the trust and ear halons that both have given me on WP. Yarfpr (talk) 15:18, 28 July 2019 (UTC)
- WP:LOL. You definitely don't need to apologize. I would never want to do anything to interfere with your productivity. We need many hands on deck to deal with things. Peace. --The Eloquent Peasant (talk) 15:20, 28 July 2019 (UTC)
Thanks
Hi Yarfpr. Thanks for all your additions. They are great! I recently came across THIS which might be of interest to you too. Cheers, Mercy11 (talk) 02:34, 13 August 2019 (UTC)
PR-511
Hi Yarfpr. Thought this might be of interest to you. Cheers, Mercy11 (talk) 01:49, 17 August 2019 (UTC)
1953 Puerto Rico highway renumbering - Revisited
Hi Yarfpr, I recently edited this article as well as placed a tag on a claim that I couldn't understand/figure out. You might want to take a look and see where it could be made clearer or if I am missing something! Again, thanks for putting that article together -- great, great job! Mercy11 (talk) 00:16, 4 November 2019 (UTC)
- Hi, Mercy11! Thanks for your edits. Answering your question, between pages 1558 and 1560 of this link there's a list of the 12 districts that existed in Puerto Rico before 1953. For Eloquent and I it was important to add them to the article because that was the subdivision that was created at that time (c. 1928) as part of the construction, expansion and maintenance projects of the road network. I don't care if the word district is replaced by region because for me they mean the same thing. It's just a matter of interpretation, but if you understand that it isn't necessary to include the districts in the article, they can be removed without any problem. Regards. Yarfpr (talk) 02:14, 4 November 2019 (UTC)
- Great! I hadn't seen that page before. Now I see why you used district, because it says district! I am going to add that cite so anyone can see the 12 districts at the time of the renumbering. Thanks! Mercy11 (talk) 02:57, 4 November 2019 (UTC)
- I'll be printing 2 of those great sources you attached to send to my family. They probably know some of the family names of the people documented in the 1955 maps. Love the way they used people's names to indicate where a town's limits began and ended - pretty amazing historical documents. (I learned that detail also in the barrios of Puerto Rico article that Mercy11 worked on). Also, my grandfather has a Sector named after him 'cause he'd been there more than 50 years (and 5 homes in the area belong to family members) and I wish I could find a reference for how "Sectors" are named. Thanks again for such a really nice article.--The Eloquent Peasant (talk) 14:07, 15 November 2019 (UTC)
- @The Eloquent Peasant: I'm glad to have shared with you those wonderful documents. A couple of years ago I found them and it was in them that I discovered the old road numbers, so I couldn't ignore that great information. Yarfpr (talk) 15:29, 15 November 2019 (UTC)
- I'll be printing 2 of those great sources you attached to send to my family. They probably know some of the family names of the people documented in the 1955 maps. Love the way they used people's names to indicate where a town's limits began and ended - pretty amazing historical documents. (I learned that detail also in the barrios of Puerto Rico article that Mercy11 worked on). Also, my grandfather has a Sector named after him 'cause he'd been there more than 50 years (and 5 homes in the area belong to family members) and I wish I could find a reference for how "Sectors" are named. Thanks again for such a really nice article.--The Eloquent Peasant (talk) 14:07, 15 November 2019 (UTC)
- Great! I hadn't seen that page before. Now I see why you used district, because it says district! I am going to add that cite so anyone can see the 12 districts at the time of the renumbering. Thanks! Mercy11 (talk) 02:57, 4 November 2019 (UTC)
ArbCom 2019 election voter message
| | Hello! Voting in the 2019 Arbitration Committee elections is now open until 23:59 on Monday, 2 December 2019. All eligible users are allowed to vote. Users with alternate accounts may only vote once.
The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail. If you wish to participate in the 2019 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add |
Yarfpr, a barnstar for you!
|
The Tireless Contributor Barnstar |
| Great job with Puerto Rico road articles! Kind regards, Mercy11 (talk) 02:53, 3 December 2019 (UTC) |