[OSM-talk] Key:Destination Abbreviations

[Paul Johnson]

On Sun, Dec 18, 2016 at 3:40 PM, Edwin Smith <e.smith64 at ymail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20161219/7e5ead14/attachment.html>