[Talk-us] Street Naming Conventions

David ``Smith'' vidthekid at gmail.com
Sat May 15 04:58:34 BST 2010


I'm glad this issue is being discussed, and I'm glad there seems to be
so much support on both sides now.  In my usual style, I'll just make
a quick post here to explain my personal position on the matter.
(This thread has gone far beyond the point at which it would be
appropriate to reply to anyone's specific message or comments as my
first entry...)

1) My previous opinion was that, when signage "commonly and
consistently" abbreviates a name, that abbreviated form should go in
the "name=*" tag.  I now believe that it is /also/ acceptable for the
"name=*" tag to specify the full, unabbreviated name -- however, if
abbreviation of that name is used commonly and consistently, then that
abbreviated form should go in another tag.  (I've been using
"abbr_name=*" for that.)

2) I've heard there's a bot that's automatically expanding names from
the TIGER import.  To the operator of that bot: proceed with caution
if you will, and /PLEASE/ preserve the abbreviated name in some other
tag(s).

3) Note that the abbreviations used in TIGER data don't always match
the abbreviations used on road signs.  The most common example of this
is "Parkway", which TIGER abbreviates "Pky", but all of the signage in
my area uses "Pkwy".  The personal experience of the local mapper
should be expressed in the tagging (in whichever tag holds the
abbreviated form) for situations like this.

4) Directional prefixes (the "S" in "S High St") have always seemed to
me more like a suffix on the house number (in mathematical terms, the
sign of the number) than part of the street name itself.  In central
Ohio, those prefixes are usually left off of the name of the street
when spoken.  (Notable exceptions are for major streets that cross the
entire city, in which case the directional prefix is spoken more often
than not.)  Still, the core of the name "High" is the only part
expressed in full-size on the signs, with "S" and "St" roughly half
the size.  (That's MUTCD standard.)  Anyway, in cases where I've put
the expanded form of the name in the "name=*" tag, I've been
consistent with unabbreviated street names elsewhere, including the
expanded directional prefix.  It would make sense for me to omit that
entirely, however.  That could also be considered consistent with the
rest of OSM, considering how most non-US cities don't have directional
prefixes like that anyway.

4a) Possibly tangential, I'd like to point out that street signs in
central Ohio do not have address block numbers on them.

5) The value of "addr:street=*" should contain the abbreviated form of
the street name according to USPS standards, regardless of the way the
street name is signed.  This tag should also follow any special-case
variations the post office has approved.  (For example, the London, OH
post office conceded that the name "Lilly Chapel Opossum Run Rd" was
unreasonably long, so mail can instead by addressed to "Lilly Chapel
Opossum Rd".  Yes, they could have done a lot better, but that's what
they went with...)  Since the Karlshrue schema doesn't have a field
for "street directional prefix" or "housenumber directional suffix"
and the "housenumber" field is supposed to be
machine-readable/interpolatable, it seems the directional prefix must
remain (in abbreviated form, mind you) prefixed to the "addr:street=*"
tag.

6) The original rationale for using unabbreviated street names in OSM
seemed to be centered around "abbreviation is a job for the renderer."
 Yet, I have yet to see a single renderer to implement any kind of
automated abbreviation.  Having a separate tag for the standard
abbreviated name of a street would be a practical step towards that
goal, which would then allow the renderer to use the "locally correct"
abbreviation rather than guess based on national standards.  When we
decide on exactly what the tag for the abbreviated value should be
called, someone should open tickets on the trac to get the slippy map
renderers to use that information -- specifically, someone who can
contribute bits of code to make it work.

-- 
David "Smith"
a.k.a. Vid the Kid
a.k.a. Bír'd'in

Does this font make me look fat?




More information about the Talk-us mailing list