From OpenStreetMap Wiki
Jump to: navigation, search

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:

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

Bifurcation example.PNG

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)