At 2010-07-31 18:54, Kevin Atkinson wrote:
Since someone objected to my proposed changes to Salt Lake City, I am
going to go ahead and give my proposal for how I think directional
prefixes should be handled. I am going to stay out of the debate on
street name abbreviations and focus on just the directional prefix/postfix
parts. I want to come an agreement on talk-us, and then would like to
make it an official standard (at least in the U.S.).
INTRO)
A full street address included more than just a Number and a Street, it
also includes a directional prefix. Vid the kid, gave an excellent
overview at http://vidthekid.info/misc/osm-abbr.html. For example (from
his page) in the address:
4242 S Champion Ave E
The 'S' is a directional prefix and the 'E' is the suffix and in:
1337 Rainbow Dr SW
The 'SW' is a directional suffix (really a quadrant suffix).
I would like to formally propose two things
1) An exception to the abbreviation rule for directional indicators
with the fully expanded name going into alt_name
I think that it would be better to leave the name tag as it is for now, and
add new tags for the name components. This way, existing code that uses the
name tag won't break, and can be modified at the developer's discretion to
work with the new tags if necessary.
2) New tags to record the presence of directional indicators in the
address.
#1)
I propose an exception to the abbreviation rule be made for directional
indicators. 'North, 'South', 'East', and 'West' when a directional
indicator (and not part of the street name) shall be abbreviated 'N.',
'S.', 'E.', and 'W.' (with a period, will explain why below), and
Northeast, Southeast, Northwest, Southwest shall be abbreviated as 'NW',
'SW', 'SE', and 'NW' (without any periods). The fully expanded name may
be included in alt_name.
I don't think the period convention will end up being well-used. In the
expanded name (where it is used), I'm not sure it matters, since
consumer-oriented searches generally use just a single query field, and the
engine has to do the work of handling the various possibilities. If it does
use separate fields (or parses the query into separate fields), it would
then use the component tags instead of the expanded name.
#2)
I propose two new tags:
name_prefix
name_suffix
If the directional prefix is not part of the name than the appropriate tag
shall be used to indicate the need for a directional prefix in an
address. North, South, etc, shall be abbreviated as one of
'N' 'S' 'E' 'W', 'NW' 'SW', 'NE', 'SE'
There is no need for a period here.
+1
If it is included in the word included shall be used instead. This
means the the first word (for a prefix) or the last word (for a suffix) is
a directional indicator and shall be left in abbreviated form by name
correction bots and the like.
Some Examples)
To encode South 700 East in Salt Lake City:
name = S. 700 East
name_prefix = included
alt_name = South 700 East
I would use
name = South 700 East
name_prefix = S
name_prefix_included = yes
name_root = 700
name_suffix = E
name continues to be used for the full expanded name
name_prefix_included indicates that the name_prefix is normally given on
the signage in front of the name_root, and used in naming a place or giving
directions verbally.
I don't think the distinction needs to be made between the suffix's
inclusion in the name or not (at least I can't think of an example in the
places I know to use them - DC and UT). That is, it is always considered in
the same way. If that's not the case, name_suffix_included could be used.
K Street NW in Washington DC,
name = K Street NW
name_suffix = included
alt_name = K Street Northwest (would anyone really write this?)
I'd use:
name = K Street Northwest (or is it K Street NorthWest?)
name_root = K
name_type = St
name_suffix = NW
Note splitting out the type of street into name_type while we're at it.
alt_name = K Street Northwest (would anyone really write this?)
I agree, but the abbreviation police held their ground last time we tried
this, so...
Some examples from southern CA:
1. Most places do not include the directional prefix as part of the signed
name. If it is present, it is thought of more as a suffix to the address.
It may be shown next to the address range on the signs in that smaller
font, not in front of the name in larger font.
Current value of name = North Euclid Avenue
name = Euclid Avenue
name_prefix = N
name_root = Euclid
name_type = Ave
Note that, in many places, TIGER had these prefixes and they were imported
as part of the name because TIGER made no distiction between this and case
#2 (below). They were then expanded to the incorrect form North Euclid
Ave. In this example, the prefix isn't even really a prefix to the name,
but instead a suffix to the housenumber, though I'm OK with using the
name_prefix tag to avoid confusion. An
