Talk:Key:destination

uplink / downlink

What does uplink / downlink mean in the context of the examples? Is this the _link road (ramp)? Martijn van Exel (talk) 18:58, 3 July 2014 (UTC)

A quick check on the DE version of the page suggests that these are Abfahrt & Auffahrt, so perhaps better translated as before entry to junction and after exit from junction. SK53 (talk) 09:57, 1 September 2014 (UTC)

I am now changing uplink --> entry, and downlink --> exit. --K1wi (talk) 07:56, 3 September 2014 (UTC)

Use in relations?

In Martijn van Exel's diary post about getting rid of exit_to, he uses a particular interchange as an example. It appears that the various ramps of the intersection could have their destination=information provided by relations to make mapping more efficient. Does destination= support use in relations? In particular, it would be fantastic if navigation packages could read destination relations for two separate relations and combine the outputs; is this supported? Thanks, --Dygituljunky (talk) 02:41, 4 July 2014 (UTC)

For non _link ways, where the destination=* would be the next control city or cities, it would make more sense to have this information on a relation, but that does not seem to be the way folks prefer to do it yet. As it is we end up duplicating the same information on a large number of ways, which is suboptimal. Martijn van Exel (talk) 16:25, 11 July 2014 (UTC)

Use in primary, secondary and smaller

Why can't we use destination=* in primary, secondary and smaller highway=*? It seems to be the simplest, yet powerful solution, instead of using the much more complicated destination sign relation. --K1wi (talk) 20:08, 9 August 2014 (UTC)

Why shouldn't we use it? I use it. Many others do. The "Do not use them..." is just the opinion of someone. You may have a different opinion. As long as it doesn't conflict with any other tagging you may use whatever tag you like. OSM lives from people providing data and not from editing the wiki. Have fun. --Imagic (talk) 06:47, 11 August 2014 (UTC)

I believe that there's a technical answer to this question, and I've put it in both the destination and destination_sign wiki pages. It comes down to whether signs indicating destinations are the same for all inbound ways or not. When all signs are the same, destination tagging is simplest and is quite reasonable to use. When it is not the same, ambiguity is introduced that cannot be resolved in destination tagging, and thus in those cases, destination_sign tagging must be used.

When all inbound signs are the same: destination can be used, and so can destination_sign. Editor's choice.

When all inbound signs are not the same: destination cannot be used; destination_sign must be used.

Skybunny (talk) 16:09, 18 March 2016 (UTC)

Updating the descriptions in the table in the "Keys" section of the page

I just wanted to update the description of the key's table from "Describes the direction of.." to "Describes the destination of". The point of the edit is to make it clearer to those that the value of the 'destination' key indicates the destination indicated in the key's value is where the OSM way is headed toward. -- KristenK 16:34, 28 August 2014 (UTC)

Seems to be a small language update: I just did it. Anyone feel free to correct/update/fix/... --Imagic (talk) 06:58, 29 August 2014 (UTC)

Identifying Signpost Location(s) In Conjunction with ways tagged with 'destination%' tag

I am writing to receive additional clarity with regards to using the 'destination%' tag in the context of signposts.

For a while now, the status quo was to use the 'exit_to' tag on the node where the signpost would be (bifurcation points typically) when representing a signpost location and information. This tag is being deprecated (hence this wiki page). Using the destination tag on the ways (e.g., motorway_link) can provide one with the signpost information, but how would one easily identify the signpost? Are we going to use the 'destination%' tags in conjunction with the highway=motorway_junction tags on the nodes where the bifurcation point is? This isn't clear in the main article for 'Key:destination'.

My thoughts are that tagging both node (bifurcation point) and way(s) (downstream from node representing bifurcation point) would make it easy for downstream OSM data users to identify the signpost locations and the relevant signage information. An existing example (not edited by me!!) is along the lines of what I'm thinking:

• node 140772317, represents the bifurcation point
• way 14406219, represents the right part of the fork/bifurcation
• way 293468020, represents the left part of the fork/bifurcation

Here is a visual example of the bifurcation with the OSM ways and node cited above:

Having the highway=motorway junction on the node and the 'destination' tags on the ways would make signpost information more explicit and easy to extract from the data. Thoughts? -- KristenK 17:15, 29 August 2014 (UTC)

As fas as I know, that is how it's supposed to be mapped, if it's a motorway-exit-node. You tag highway=motorway_junction on the node, and you tag destination=* on the ways leaving from the node. --K1wi (talk) 08:30, 30 August 2014 (UTC)

Abbreviations on signs

The current version of the article says to "take the text of the signpost". I've come across cases where the text contains abbreviations ("Coral Spgs" for "Coral Springs" in Florida), which of course contradicts the general consensus of not using abbreviations in OSM. From the point of view of a data consumer, I guess it would make sense to expand these abbreviations so as to provide better support for text-to-speech. On the other hand, expanding names like Boulevard would take up precious pixels on the display and would likely force a smaller font when displaying the name, which might not be desirable (of course the consumer could apply regional abbreviation conventions when displaying the name, but that's extra overhead). Thoughts? --Carciofo (talk) 14:44, 18 March 2016 (UTC)

For me I think this is an easy one: un-abbreviate signs to give the full name of something, just as we do with roads. Here's why I say so: Different regions will have different abbreviations for the same thing. Consider: 'Spring Ave' and 'Spring Av'. Obviously both mean 'avenue', but on the data consumer side, transcribing a sign exactly will require the data consumer to have a parsing table for 'any abbreviation any given state or locality decides to use'. If the sign is transcribed as 'Spring Avenue', there is no ambiguity, and the data consumer can decide on its end if it wants to abbreviate 'Avenue' with 'Ave' or something else.

I think the intended meaning of 'take the text of the signpost' is to not try to "interpret" the sign beyond abbreviations, and be smarter than the sign indicates. By this I mean: Say a sign has incorrect information on it: bad milage, or a highway reference that no longer exists or doesn't exist yet. That information should still be put in the destination, regardless of whether it's "correct" or not; it's what the user sees. Another example would be the order in which control/direction cities appear on a freeway sign; this should be in the order it appears on the sign, not some other arbitrary standard a user decides on, like 'Which cities are closest'. Skybunny (talk) 15:53, 18 March 2016 (UTC)

I am in favor of avoiding inconsistency and expanding street signs and destination signs the same way. I'm skeptical that there are new arguments for or against abbreviation that haven't been raised in previous discussions. Regarding current OSM practice, if you search taginfo, abbreviations are rare. Are there objections to adding a clarifying sentence to the value paragraph? Zeromap (talk) 17:44, 23 March 2016 (UTC)

I agree that the arguments fall on the same lines as with the name tag. Clarifying the sentence in question was exactly my goal, so I'm for it.--Carciofo (talk) 11:55, 27 March 2016 (UTC)

The point of destination is to document what a person sees on the street sign. We may not like the way it is worded but we have no more right to change abbreviations than the example of changing incorrect mileages above. I strongly think abbreviations should be left as they are on the sign and no change is needed. Just "take the text on the signpost". EDSS (talk) 02:52, 26 March 2016 (UTC)

Well, name=* is also meant to represent what's on street name signs, yet the consensus is that abbreviations are better expanded. I agree with Zeromap that it's pretty much the same argument to be had about name, so unless you put forth some other argument not covered already in that discussion as to why you feel so strongly about it, we'll use the consensus reached there as a precedent. Thinking about it a bit more, from the consumer's point of view, having exactly what's on the sign only means I can visually recreate the sign, whereas having abbreviations expanded allows me not only to have a better chance of reading the sign out loud correctly, but have data that I can match/correlate with other data, which the former does not allow (or at least not without some work and potential ambiguity that the mapper can far more easily disambiguate from the get go).--Carciofo (talk) 11:55, 27 March 2016 (UTC)

First, it seems a little strange to suggest that someone in a vehicle traveling down the interstate at 60 mph will consult OSM for help in reading the next sign out loud correctly.

More seriously, what I think you miss is that a street or whatever has an actual name behind the representation that is on a street sign and we want name= to represent the true name. Destination, however, is about the sign and the roadway and should not be altered. EDSS (talk) 01:20, 28 March 2016 (UTC)

By consumer I meant data consumer, as in a device used for navigation giving spoken turn-by-turn directions, not an OSM contributor looking at Mapnik (or some other rendering). The tag represents whatever we choose it to represent so that it may be useful in fulfilling some functionality, preferably beyond mere rendering. I'm still interested in hearing an opposing view, but so far I haven't heard an actual argument for keeping the sign text as-is, or some use case/functionality which would be better served by having an abbreviation.--Carciofo (talk) 10:40, 28 March 2016 (UTC)

My navigation program is MapFactor Navigator. When it is approaching an exit to navigate off, it displays the text of the destination as shown in OSM for the ramp on the upper left corner of the screen. It is surely a clear advantage for the text on the screen to exactly match the text on the sign.

With respect to a program that speaks the destination, I point out that it is a difficult matter to correctly vocalize proper names in our often oddly spelled language. Any program that solves this problem will have no trouble correctly vocalizing abbreviations. EDSS (talk) 19:51, 28 March 2016 (UTC)

It seems a little strange to suggest that someone in a vehicle traveling down the interstate at 60 mph will consult their navigation device screen to read a sign that is in front of them. If that's the only use case you're putting forward, I'm not convinced that's reason enough to reverse the consensus of the community on the topic. Secondly, I would favor speech output as driving is far more taxing on visual input to the driver.--Carciofo (talk) 16:56, 31 March 2016 (UTC)

The only thing I feel I can be sure of is this: There is no dispute in whether we 'un-abbreviate' names as they appear on highways, and everything else, and until someone said 'maybe we shouldn't', simply because it wasn't explicit in the document, there was no dispute on destination either.

Since it involves an awful lot of work to change a standard, and we need to determine where we are first, I've done some numbers using overpass-turbo. Here's what we have, using two that are hard to get false positives on, looking at North America (looking at 'ways' with a destination tag, whose value matches...)

Avenue: 2773, versus Ave/Av: 114

Boulevard: 1713, versus Blvd: 93

The clear interpretation of whether to use abbreviations, by a ratio of over 20:1 is to follow the standard used everywhere else in OSM's tagging (which is to say, 'no'.). I'm going to add this to the page. I'll mention that whether it should is questioned, but I'm using these numbers to back it up. Skybunny (talk) 20:56, 28 March 2016 (UTC)

Replying to myself: Okay, I'm convinced. I'm going to say my opinion now is flat out "no", we shouldn't be using abbreviations, and the Names page gave the perfect reason why: "Computers can easily shorten words, but not the other way (St. could be Street or Saint)." This is exactly what we're discussing here. Or, basically...yeah, this got figured out years ago, and just wasn't said on this page as it surely should have been? Skybunny (talk) 21:11, 28 March 2016 (UTC)

I think your analysis is bogus because most of the Avenue or Boulevard is what the sign actually says. It is quite possible that by a 20:1 ratio the Ave or Blvd of the actual sign has been retained. I am finding it hard to understand how there can be any argument that signs should be changed when the very start of the Key:destination section says "Thus navigation systems can refer to road signs that the driver actually sees." How can you possibly deliberately report to the navigation system something different than what the driver actually sees? Also I think "computers can easily shorten words" argument is exactly backwards because the one thing a computer cannot possibly do is know if Avenue on a sign is what the sign actually says or whether it has been changed from the abbreviation on the sign. EDSS (talk) 03:07, 30 March 2016 (UTC)

I have been casting about for what could be an acceptable consensus. Could the Wiki say something like: "For this very specialized application "take the text of the signpost" means exactly what it says and we neither abbreviate nor un-abbreviate but this does not apply in any way to any other aspect of Open Street Map"? EDSS (talk) 16:24, 28 March 2016 (UTC)

That's not actually a consensus conclusion. It's simply accepting the point of view that abbreviations should be used when they appear on a sign, as assumed fact. My interpretation of the sentence, "Thus navigation systems can refer to road signs that the driver actually sees" takes 'refer' to mean 'refer to', not 'be biblically identical to', since if not referring to 'a sign a driver actually sees', all that remains are name: or ref: tags which may happen to be on ways a driver will navigate.

If I accept the logic that "what the driver actually sees (abbreviated or not)" is paramount, then the Names policy should be changed too, so that the names of highway: ways should be abbreviated if it appears that way on a sign (whether or not used in the context of a destination:, which is irrelevant), leaving navigation or other map consumers to parse that for themselves. Personally, I haven't been at all convinced by what I've read here that abbreviations (when they appear) are best in destination: tags, and the more I hear (and read elsewhere in OSM's wiki), the less convinced I am. Skybunny (talk) 19:43, 30 March 2016 (UTC)

It seems to me you are going off on wild tangents. The only documented charter of destination that I can find is to tell a navigation program how the signs are worded for any use the navigation program wishes to make of the information. If we un-abbreviate the information we have made it impossible for the navigation program to use the signage as it is on the road. Is that the point; that you think it is important to prevent the navigation from showing the abbreviations if it chooses to?

I point out also that the destination does not appear in the Mapnik or affect it in any way.--Unsigned comment added by EDSS (talk) 01:15, 31 March 2016

What I would like to hear, as I mentioned in an earlier comment, is why you believe this functionality of the device reproducing the sign on-screen is so important, what makes that reason so strong that it merits overturning the current consensus on the usage of abbreviations everywhere else in OSM? Note that there is already consensus on the matter, so unless some very strong argument about functionality is put forth, we're merely discussing personal preference and this thread will continue to deteriorate in discourse and diverge from consensus. In the absence of any further actual argument against expanding abbreviations I move to call the discussion resolved based on the stats and arguments here.--Carciofo (talk) 08:10, 4 April 2016 (UTC)

I think you need to tell me what it is that is so important about maintaining the use of abbreviations in other parts of OSM that we need to deliberately and dishonestly misrepresent the wording of signs to the navigation programs. This robs them of their clear right to use their own judgment on the use of abbreviations.--Unsigned comment added by EDSS (talk) 18:06, 31 March 2016

I am sorry my comments are unsigned. I don't know how to sign them. EDSS

I see you're using the mobile editor, so you'll need to enter ~~~~ at the end of your comment and it will be transformed into a signature with timestamp when you save the page. Also, indenting is accomplished by using : in front of the paragraph. Repeat the character as many times as needed.--Carciofo (talk) 08:10, 4 April 2016 (UTC)

Thanks to Carciofo for attributing and indenting my comments.

It is a disappointment to me that no one has addressed the actual argument as summarized in my last comment above. Could it be anyone sees any possible merit in my position? EDSS (talk) 15:16, 6 April 2016 (UTC)

I was sad to see the 20:1 statistic appear on the main page. As I argued above it is wrong to count Boulevard and Avenue that are spelled out in full on the sign (as they usually are in my neck of the woods) as a vote for changing abbreviations. Surely false statistics have no place in this discussion or the main page.

Question: You are driving down the interstate and your navigation program describes the sign for your exit. Do you prefer a clean copy of the sign or one that has been edited in some way?

EDSS (talk) 21:08, 2 September 2016 (UTC)

I have added a sentence describing this dispute on the page. "The use of abbreviation is currently disputed. Until a consensus is reached please discuss with the original mapper before changing an existing value's state of abbreviation". Zeromap (talk) 16:19, 26 March 2016 (UTC)

:display? (splitting into seperate tags)

I think data on how a sign looks and what it means could be important in different situations. What a sign means (i.e. expanding abbreviations and such) would be important for spoken or simple text-based turn-by-turn directions, and how a sign looks could be important for deaf and hearing impaired drivers or navigators instead of (or in addition to) the former, and it might be a good navigational aid for anyone, including myself. I don't think we could tag them both in one tag though, since "St." could mean Saint or Street, and even without such shared abbreviations, tagging could be very inconsistent between locales with some destination=* tags using abbreviations and some not, and I'm sure there are some areas where you've got one sign abbreviated and another sign down the road, even for the exact same exit, not abbreviated.

I'd like to propose tagging both separately, such as destination="Non-Abbreviated Destination" and something like destination:display="Abbr. Dest.". Could also be used with subkeys, such as destination:street:display=*. That way, one could add exit details, even if they don't know what an abbreviation means, by simply tagging what they know and not what they don't know. A few examples for clarification:

Edit: ":display" is used as placeholder text, and isn't necessarily in the right place in the tag, this is just to roughly demonstrate the idea

--UltimateRiff (talk) 00:38, 8 September 2017 (UTC)

Exhibit A:

Interstate 695 Outer Loop at Baltimore-Washington Parkway exit sign

key	value
destination	Baltimore
destination:street	Baltimore-Washington Parkway
destination:street:display	Balt-Wash Pkwy

Exhibit B:

Exit 155 on eastbound Interstate 40 in Little Rock

key	value
destination:lanes	Jacksonville;Little Rock Air Force Base|Jacksonville;Little Rock Air Force Base|Memphis|Memphis
destination:lanes:display	Jacksonville;L.R.A.F.B.|Jacksonville;L.R.A.F.B.|Memphis|Memphis

Exhibit C:

Exit 156 on eastbound Interstate 40 in Little Rock

key	value
destination	Baptist Health Medical Center - North Little Rock
destination:display	Baptist Health Medical Center - NLR
destination:street	Springhill Drive

Note the absence of periods on C, as opposed to B. Even though they're just an exit apart, :display is meant to be exactly what's on the sign.

I think this could be an excellent compromise, and would also be a great tag to add, as it could, maybe with some extension, allow highway signage to be displayed properly and fully (and spoken properly) in routing applications. I'm definitely open to further discussion on this topic.

--UltimateRiff (talk) 22:38, 3 September 2017 (UTC)

For Example A/B: it should be destination:display:lanes, because of the usual order of subkeys and suffixes. You could also extend this with the other common subkeys, like destination:lang:fr:display if needed.

In general: I would prefer a scheme similar to tags we already have, namely 'short_name' or 'addr:full'. 'display' could just mean anything and doesn't tell what it is intended for. I propose either destination:full or destination:short, depending on what the default for destination is. --Mueschel (talk) 08:01, 4 September 2017 (UTC)

Yeah, we could probably come up with a better word for it, like destination:signed:lanes=* or something like that. I just put 'display' in there because it was the only word I could think of at the time. I do think we might want to keep using destination=* though, because, correct me if I'm wrong, it might be more backwards compatible. Although, if destination:full=* ends up being the better way to go, I'd be alright with that too.

Also, I'm not familiar with the usual order of subkeys and suffixes, could you explain it to me, or at least link me to where I can learn more about that kind of stuff?

--UltimateRiff (talk) 18:58, 4 September 2017 (UTC)

We definitely should keep the normal 'destination' tag, because most signs don't need this special tagging. For tags, and all the :lanes, :forward, :conditional and so on, the order should be:

key[:subkey][:hgv|:bicycle|...][:lanes][:forward|:backward|:both_ways][:conditional][:start|:end]=*

Regarding destination tags, I made my own compilation of current tagging schemes here: https://wiki.openstreetmap.org/wiki/User:Mueschel/DestinationTagging --Mueschel (talk) 19:10, 4 September 2017 (UTC)

It should be clarified that the order actually means something, and is not just an arbitrary fixed order. For example, :conditional can appear both before and after lanes. Likewise, :forward can appear before :lanes in rare cases, such as maxspeed:forward:lanes for a two-way lane with different maxspeeds in each direction (this is essentially just the :lanes suffix appended to the maxspeed:forward key, as opposed to some special case). --Tordanik 15:08, 5 September 2017 (UTC)

It's not the right place to discuss this, but I strongly advice against it. Logically speaking you are right, but the vast majority of mappers won't use the tags correctly. Actually, the order gets mixed up so often, and I've never seen any case where the order was used as an intended means of expressing something. Also, I haven't seen a case where tagging can not be changed in a way that allows to use the standard meaning / order of tags. Maybe we can discuss this in private? --Mueschel (talk) 15:38, 5 September 2017 (UTC)

Alright, thanks for the clarification and the link to your very in-depth guide, I'll make good use of it. In fact, I might write one up for tagging method 2 (relations), specifically for how to tag "sign" members, as it's not easy to find the documentation on the wiki. Also because I'm a fan of micro-mapping, in most cases.

And actually, most signs here in the US would need this special tagging, as we have street names on most every highway sign in urban areas, and quite often in rural areas too. And when there's street names, there's usually abbreviation.

--UltimateRiff (talk) 00:38, 8 September 2017 (UTC)

We really need to remember that the ONLY mission given to the normal key destination=* is to tell navigation programs the wording of exit signs (See the very beginning of the entry). It is in fact used this way in the navigation program I use and I am sure in the other four programs listed in the wiki. If we change the normal destination tag we will break all the navigation programs. The proposed subkeys could be excellent for other uses. I do suggest we tell the navigation program the exact wording of the sign neither abbreviating nor unabbreviating. To quote the wiki entry: "Thus navigation systems can refer to road signs that the driver actually sees." If there a previous sign with different wording, I thing destination=* should be the one at the actual exit. EDSS (talk) 21:13, 4 September 2017 (UTC)

Actually, the way I read it, it could go either way, as it's referring to or describing the content of the road signs, not necessarily quoting them word for word. And either way, as mentioned before, I believe we should have tags for what a sign says and what it means. That way your GPS can tell you, "Take the exit towards Little Rock Air Force Base", instead of "Take the exit towards L.R.A.F.B.", or maybe even let app developers allow you to chose which flavor you want!

I don't believe changing how we use the destination=* tag in the way I'm suggesting will break current navigation programs, as I believe spoken directions are far more important than visual directions. Although, I too would love for my navigation app to show me the highway signs too, (see the examples in Lane assist) and abbreviations could make it easier to read the signs on your device while you're driving. In that case, I'd prefer "L.R.A.F.B.", since it'd probably be easy enough to determine, "Let's see, I'm in Little Rock, A.F.B. usually means Air Force Base, so that must be what it means!" Granted, my GPS would have likely told me that before I even see the sign, but you get my point.

Also, I'm not saying we should abbreviate when it's not on the sign, as seen in Exhibit C above, where I didn't abbreviate "Street", as it wasn't abbreviated on the sign.

I'm simply looking for a way we can tag both, that way you're happy, I'm happy, everyone's happy with how their navigation programs guide them on their way. If that means changing how we use destination=*, following the example of name=*, and adding one tag, that's great! If it means we add a tag for GPS speech, that's alright. Or, if it means adding two tags and not worrying about this issue altogether, that could work too. In fact, I could even see an extra tag, which could define the order they appear on the sign, whether it's "place;street", "street;place", or even "place;street;place". It just depends on how far we want to go defining new tags.

--UltimateRiff (talk) 00:38, 8 September 2017 (UTC)

Guidepost

Clearly, information=guidepost, are related to the tagging of destinations (the subject of this page). Either they are complementary or variations, a note about guideposts should be included on this page. Please don't just plainly delete information if you don't agree with the precise wording. --Pbb (talk) 23:29, 1 October 2017 (UTC)

A information=guidepost tags the location of a signpost, this tag is in no way related to tagging of destinations. You have to use either destination=* or Relation:destination_sign to tag destinations. You stated that one tag should be used "instead" of another - but those are describing different things. Secondly, there is no difference between the two ways of destination tagging depending on hiking or road network. Both can be used in both cases, and in some special cases one of them is not sufficient to describe the full situation. --Mueschel (talk) 08:13, 2 October 2017 (UTC)

Thanks, your explanation makes it more understandable to me. I've changed the wording, I hope it better indicates how direction and signpost can be used to complement eachother.--Pbb (talk) 10:49, 5 October 2017 (UTC)

Waterways

destination is used 17451 times on waterways, e.g. into which other river the first one flows. this is not reflected on this page. Should it?--Polarbear w (talk) 11:39, 28 February 2018 (UTC)

Signposts in multiple languages

Unlikely to be limited to just Ireland so raising on the discussion page. How should signposts that having the same destination in multiple languages be captured? Should they all go in the destination=* tag or should there be a similar convention to destination=*? i.e. destination:en=*, destination:ga=*, destination:fr=* is possible. Dónal (talk) 13:36, 17 July 2020 (UTC)

Example:

We already have tags for this, i.e. destination:lang:ga=*. They were proposed here: [destination:lang] and are in use many thousand times already: [Taginfo] --Mueschel (talk) 13:45, 17 July 2020 (UTC)

destination:ref is the same as ref?

At simple intersections where there isn't a link road, the ref of the road immediately after the junction is the same as that on the road sign. I have been tagging destination:ref here too but should I? It's duplication and results in osmand identifying that I'm on A6038>>A6038 for example. TrekClimbing (talk) 08:17, 26 August 2021 (UTC)

@TrekClimbing: It's probably unnecessary in most cases, but it would be great if data consumers would know to deduplicate the two tags in these circumstances (also in the case of the route itself traversing a link road), so that users don't hear the route number redundantly. In some countries like the U.S., it may be more appropriate to tag destination=* and destination:ref=* than leave them out, based on guide signs that may also include route directions. – Minh Nguyễn ^💬 18:57, 26 August 2021 (UTC)

 Yes, it was for sign replication that I was doing it so I may keep at it. Thanks TrekClimbing (talk) 22:54, 26 August 2021 (UTC)