Re: [OSM-talk] Key:Destination Abbreviations

[Dave F]

On 19/12/2016 20:50, Andy Mabbett wrote:
The phrase, which is also used as the title of the corresponding page 
on the wiki, is "Tagging for the renderer": 
http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer 


How is 'Destination' "/deliberately entering data incorrectly for the 
renderer"/? (From the first paragraph of the wiki page)


DaveF.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Key:Destination Abbreviations

[Paul Johnson]

On Sun, Dec 18, 2016 at 3:40 PM, Edwin Smith  wrote:

> Hi all,
> There is a disagreement that could use a few more eyes.  Destination has
> the explicit purpose of telling a
> navigation program the wording of a sign.  It is typically used as a tag
> of a Motorway Link.  It is not visible
> in the Mapnik in any way.
>
> One side of the disagreement argues that if an abbreviation appears on the
> sign (Ave for instance)
> it should be expanded to Avenue in the Destination Tag.  The arguments are:
> 1) OpenStreetMap discourages abbreviations
> 2) If you search through Destinations every time Avenue appears it is a
> mapper vote for expanding Ave to
> Avenue.
>

I'd go with the intended phrase, not the abbreviation, same as we do now
for name=*.


> The other side of the disagreement (which I support) argues to present the
> sign to the navigation program
> exactly as it appears, neither abbreviating or expanding abbreviations.
> The arguments are:
> 1) Destination is for the use of the navigation program.  If abbreviations
> are changed it has no way to
> know if the sign says Ave or Avenue.  If they are unchanged it can make
> its own decision as to what use
> of abbreviations is best for its users.
> 2) It is just wrong to count every Avenue as a mapper vote for expanding
> Ave because it very often is
> just the mapper's correct reporting that the sign has Avenue spelled out.
>

This is just pedantic.  Maybe destination:transcription=* for literal
strings if it's that huge of a thing?  Most humans are going to be
listening for the prompts anyway and aren't going to be bothered by a
difference between the literal string and the intended phrase on the
screen.  If you're shooting to rebuild sign assemblies for display, you're
probably better off creating a series of SVG's for your specific
application.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Key:Destination Abbreviations

[Andy Mabbett]

On 18 December 2016 at 23:48, Colin Smale  wrote:

> I believe the phrase is "tagging wrongly for the renderer"

The phrase, which is also used as the title of the corresponding page
on the wiki, is "Tagging for the renderer":

http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Key:Destination Abbreviations

[Andy Mabbett]

On 19 December 2016 at 14:31, Edwin Smith  wrote:
> Hi all,
> Thanks for the responses.
> The point I think you miss is that it is impossible for the navigation
> program to have the policy "show the driver exactly what his sign will say"
> if it has been altered in any way.

I didn't miss that; I wrote:

   if you want to record, literally, what's on a sign, use
   something like 'transcription='


-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Key:Destination Abbreviations

[Aun Johnsen]

> On Dec 19, 2016, at 10:00, talk-requ...@openstreetmap.org wrote:
> 
> Well, it still can, the software just needs to know
> how to abbreviate words, which is easy to do. The other way round,
> automatically expanding an abbreviation (i.e. reading aloud) may be
> ambiguous.
Let me expand a little on ambiguity, so that this get clearer:

Ave is both a valid abbreviation and a valid part of a street name “Street of 
God’s Ave”

Dr have multiple meanings (Doctor, Drive, Driveway, etc.)

Some countries have distinct rules where some words appear in a street name, 
while others.

In some countries street names can contain the same abbreviation meaning 
different things: “R. Hilary R. Clinton” for “Rua Hilary Rodham Clinton”

The software should know that Dr is a valid abbreviation for Drive, but should 
not be expected to understand that Dr is a valid abbreviation for Drive, as it 
could as well be Driveway or Doctor.

Aun
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Key:Destination Abbreviations

[Dave F]

On 18/12/2016 23:12, Andy Mabbett wrote:

On 18 December 2016 at 21:40, Edwin Smith  wrote:


1) Destination is for the use of the navigation program.

That's a form of "tagging for the renderer".

Besides, if you wan to record, literally, what's on a sign, use
something like 'transcription='



There is absolutely nothing wrong with "tagging for the 
renderer/router". *Every* tag is to allow them to adapt the data into 
coherent maps, if not everything would be black & white & all roads 
would lead to Rome..


Tagging *incorrectly* for the renderer is, however, to be discouraged.

DaveF.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Key:Destination Abbreviations

[Colin Smale]

I believe the phrase is "tagging wrongly for the renderer" - we
constantly consider the users/consumers of the data when tagging, but it
is clearly frowned upon to "lie" in the tagging to get something to show
up in a particular way or otherwise to achieve a particular effect.
Whether tagging is "correct" or not depends entirely on your frame of
reference. The destination of a road can also be derived geometrically
by following the road to see where it leads, but that would not be at
all useful or appropriate to the navigation use case.

 //colin 

On 2016-12-19 00:12, Andy Mabbett wrote:

> On 18 December 2016 at 21:40, Edwin Smith  wrote:
> 
>> 1) Destination is for the use of the navigation program.
> 
> That's a form of "tagging for the renderer".
> 
> Besides, if you wan to record, literally, what's on a sign, use
> something like 'transcription='___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Key:Destination Abbreviations

[Andy Mabbett]

On 18 December 2016 at 21:40, Edwin Smith  wrote:

> 1) Destination is for the use of the navigation program.

That's a form of "tagging for the renderer".

Besides, if you wan to record, literally, what's on a sign, use
something like 'transcription='

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Key:Destination Abbreviations

[Tobias Zwick]

Hey Edwin

I read through the discussion on that page.

I think you focus too much on this 20:1 statistic. I too think this does
not really belong on the main page, but this is not really the issue.

I do not have the impression that anyone is using the 20:1 statistic as
an argument whether the destination name should be abbreviated or not.
The argument is that abbreviations in names being expanded for the DB is
the standard _in general_ and that the destination-value is just another
name(-like) tag.
Which I can totally follow. After all, where is the difference between a
sign on a freeway saying "Argument Ave" for the next exit and an actual
street sign at an intersection saying "Argument Ave"?

Why should this one sign not be abbreviated (street name) but that other
sign (freeway exit name) should?

As Carciofo said on the discussion page, I don't see the use case why
this consensus on names should be overturned for a specific tag.
You mentioned so that the actual sign could be displayed by the
navigation software. Well, it still can, the software just needs to know
how to abbreviate words, which is easy to do. The other way round,
automatically expanding an abbreviation (i.e. reading aloud) may be
ambiguous.

This is an old argument, it has been brought up years ago when talked
about whether to abbreviate names or not in general. That the same
argument applies to Key:destination again is a clear sign that
Kay:destination is in fact just another name tag.

Cheers
Tobias Zwick

On 18.12.2016 10:40 PM, Edwin Smith wrote:
> Hi all,
> There is a disagreement that could use a few more eyes.  Destination has
> the explicit purpose of telling a
> navigation program the wording of a sign.  It is typically used as a tag
> of a Motorway Link.  It is not visible
> in the Mapnik in any way.
> 
> One side of the disagreement argues that if an abbreviation appears on
> the sign (Ave for instance)
> it should be expanded to Avenue in the Destination Tag.  The arguments are:
> 1) OpenStreetMap discourages abbreviations
> 2) If you search through Destinations every time Avenue appears it is a
> mapper vote for expanding Ave to
> Avenue.
> 
> The other side of the disagreement (which I support) argues to present
> the sign to the navigation program
> exactly as it appears, neither abbreviating or expanding abbreviations. 
> The arguments are:
> 1) Destination is for the use of the navigation program.  If
> abbreviations are changed it has no way to
> know if the sign says Ave or Avenue.  If they are unchanged it can make
> its own decision as to what use
> of abbreviations is best for its users.
> 2) It is just wrong to count every Avenue as a mapper vote for expanding
> Ave because it very often is
> just the mapper's correct reporting that the sign has Avenue spelled out.
> 
> Check it out in the Key:destination Discussion.  As you will guess, the
> EDSS comments are mine.
> 
> Cheers,
> Edwin Smith
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk