[Talk-us] Street Naming Conventions

[Val Kartchner]

On Thu, 2010-04-08 at 00:59 +0200, andrzej zaborowski wrote:
> Hi,
> 
> 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 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

These goals and the discussions so far have brought up some further
issues for discussion.  These are not all OSM issues may be issues for
OSM consumers.

1) Are these even good goals to work towards?

2) An issue that I brought up with Andrzej in email, the bot has
expanded "E Ave" (in Ogden, Utah) to "East Avenue" when this is a range
of avenues from A - H.  There is another local instance (in Riverdale,
Utah) that the bot hasn't yet expanded where streets are named A - K.
The bot could leave such instances and flag them for manual review.

3) Prefix, body, suffix is available from the TIGER data, but what about
streets that have already been added (or corrected) by users?  As we've
seen, a bot won't always be able to correctly make these separations (as
in the example of "Southbay" vs. "South Bay" given previously)  How do
we make it so that it meets the goals I've given?

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

5) Should suggestions be given to renderers to use the USPS
abbreviations?  This brings up my previous example of "South A Avenue"
burying the important part of the street name.
  a) Should we develop our own guidelines for abbreviations (as brought
up by someone else)?

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)?
  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).

- Val -