andrzej zaborowski <balr...@gmail.com> writes:
> Hi,
>
> On 7 April 2010 07:36, Val Kartchner <val...@gmail.com> wrote:
>> The "Editing Standards and
>> Conventions"
>> ("http://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions";)
>> page says: "In the name tag, enter the full name as it appears on the street
>> name signs. [...] Do not abbreviate words."
>>
>> Some sample ACTUAL street signs around here say "14th Street", "1400
>> South", "A Ave", "Bee Ct", "Cheyenne Dr". If we expand the
>> abbreviations, this still doesn't carry the other directional
>> identifier. (e.g.: W 1400 S) However, if the directional identifer is
>> added and expanded then "A Ave" becomes "South A Avenue" which really
>> buries the most important part of the street name "A". (Two areas I've
>> mapped have single-letter street names, one A-H Ave and the other A-K
>> Street.) Even expanding the local convention (for instance) of "S 1000
>> E" should be expanded to "South 1000 East Street" (according to the
>> wiki), again burying the most important part.
>>
>> Using USPS abbreviations is the convention used by all commercial online
>> mapping providers that I've seen. (i.e.: maps.google.com,
>> maps.yahoo.com, www.bing.com/maps ) I think that OSM should adopt the
>> same convention.
>>
>> What do people think?
>
> I'd like to see them as separate tags, but I'd really like the name=
> tag to remain consistent across the world, i.e. have an unabbreviated
> name in it, that can be passed to something like a text-to-speech
> system without having to keep a list of possible abbreviations for
> every language in the database. Especially names like "St Park St"
> (State Park Street) or "St Tropez St" (Saint Tropez Street) would be
> difficult to deal with. Changing from unabbreviated to abbreviated in
> a renderer or another tool is much easier on the other hand, with less
> space for ambiguity.
Yes, this is exactly my view, too. It is much easier for tools to
abbreviate the string than to expand it without ambiguity. Because in
the latter case it has to make assumptions.
Matthias
_______________________________________________
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
