[Talk-us] Street Naming Conventions

[Richard Finegold]

On Thu, Apr 8, 2010 at 20:32, Val Kartchner <val42k at gmail.com> wrote:
> On Thu, 2010-04-08 at 00:59 +0200, andrzej zaborowski wrote:
>> On 7 April 2010 20:12, Mike Thompson <miketho16 at gmail.com> wrote:
>> > Having said that, I think it is a bad idea to have a bot going
> through
>> > and attempting to expand abbreviations.

I agree. If a bot can do this then that is evidence that a renderer or
other data consumer can expand them if desired. But is the bot
supplying its source of heightened accuracy? Surely the bot isn't
checking physical signage.

>> I ran the bot ([1]) over the west half of the US [...]
>> [...]  After Oregon I ran the bot on
>> the other states because of the comments I got from mappers on IRC.
>> This was what prompted Val to start the discussion here.  I'm going to
>> hold off with it according to your comment.  Funnily in an IRC
>> discussion we concluded that it was nice that at least one thing had
>> been agreed on in OSM :)
>
> After the brief but lively discussion on this topic that I started, I am
> almost convinced to go with the expanded (unabbreviated) names.
>
> I see these goals, in no particular order but numbered for reference:
>
> 1) Be easy to enter data
> 2) Be easy for automated parsing
> 3) Be rendered in an uncluttered way on the maps

Regarding 3: Some abbreviation expansion seems conclusively
counterproductive. For example, http://osm.org/go/WIdHmwyRJ-- --
which has "SE 3rd St" on its signage -- has its name rendered at Z18
but not at lower zooms. There's a claim of "This will allow a renderer
to introduce abbreviations as necessary." in the wiki, but is it true?
Does andrzej or someone else have an algorithm that can work with the
examples in the essay at http://vidthekid.info/misc/osm-abbr.html
(linked from http://wiki.openstreetmap.org/wiki/Talk:Key:name#Abbreviation_.28don.27t_do_it.29_._Abbreviations_on_street_signs.21)?

[snip]
> 4) Should the issue of making it easy to enter expanded street names be
> pushed off onto the data entry programs?

I daresay that "NE" is quicker to type than "Northeast". But I don't
have a keyboard with dedicated macro keys.

> 6) Should the direction prefix even be part of the street name since it
> (mostly) isn't on the sign?
>  a) Commercial maps provide it as (for example) "W 3300 S".  However, I
> was using the OSM and Garmin routable maps on my GPS today and noticed
> that the Garmin maps show "3300 S" (not "3300 South") for a street name.
> Should this be an issue that is pushed off onto the program that
> generates routable maps (with suggestions from OSM how to process the
> data)?

What does the signage say? Here, when they cross Main or an equivalent
meridian division they lose their direction. Or if they're in a
central district. For example,
http://www.openstreetmap.org/browse/node/53125765 has signage saying
"116th Avenue", but it's NE to the North and SE to the South;
similarly, see http://www.openstreetmap.org/browse/node/53224246 that
has "West Lake Sammamish Parkway" as its base name. I'm guessing that
the lack of direction prefix was a data mistake.

>  b) I have used the alternate names (name, name_1, name_2, etc.) for
> alternates which would include expansions of the abbreviations.  Should
> we establish a standard for how these are used and their order?  For
> instance, north of 200 North, Washington Blvd is also 400 East and State
> Route 235 (though I know that routes are now tagged by relations).

Maybe abbr_name and/or unabbr_name, as that would allow for other languages.