[Talk-us] New I.D Feature

[Greg Morgan]

On Thu, Nov 6, 2014 at 12:33 PM, stevea <steveaOSM at softworkers.com> wrote:

>  Without getting all political on people, I do wish to remind everybody
> that Arizona is not AZ.  The former is one of the fifty sovereign states of
> the union, the latter is a (federal) corporate entity created by the Buck
> Act (oh, and coincidentally, conveniently used as a postal address by the
> USPS).  They are NOT the same thing, and they ARE two different things.
> Let's be careful to use the proper one, which I believe is Arizona.
>

SteveA and Hans,

Thank you for drawing attention to this problem.  It has always bothered me
that we expand all other parts of the address but use AZ for Arizona based
on the wiki documentation.  I dutifully follow this but I don't think it is
the correct choice.

Analogously, building:entrance was changed to entrance. A decision was made
to refine the tagging scheme along the way.  I now use the tag entrance in
my new edits.  I have gone through and changed all my former edits from
building:entrance to just entrance.  I am only worried about US addresses
here.  How do we:

1.) Deprecate the idea of two letter US postal abbreviations in OSM?
2.) Change the wiki to say use spelled out state names and not the USPS
codes?
3.) Approach tools like OSM Inspector or KeepRight to flag missing state
codes in the US and also flag two letter codes to use the spelled out value.

Here's a host of reasons to support the change and repair missing values.

It is unfortunate that importers are dropping values like addr:city and
addr:state during US imports.  Especially when they appear to have clean
data at the time of import.  There are other users of the OSM data than
just Nominatim.  I imagine that our data looks crappy to a person wanting
addresses without the concerns or abilities of GIS applications.

It is OK to spell these codes out.  All the postal address correction
software that I have seen will return the correct two digit code for the
spelled out state name.  That's where I believe there has been a missed
opportunity to serve addressing customers better.

I tried to think about the reasons for putting an address in OSM.  If all
that we are trying to do is geocode an address for location searches, then
say, "200 West Washington Street" plus the the lat and long is all that is
required. Yes a city and state would also be helpful but they are not as
important because we have search engines and html5 location assists.
Nominatim and other software have other sources to look up the missing
data.  That minimal address makes the data and map useful.

In a similar vein, I sometimes start a new address with just the
addr:housenumber key and value when I am adding data from a survey.  That
makes the OSM map useful as well.  I am thinking of a person using OSM
tiles to find a location.  That person is also in the desired area. The
number alone can help them find their way to a building/POI/site, etc.
Other area information on the map such as surrounding street names provide
the complete information to make the correct human judgement.  Eventually,
I'll complete the address.  Hey it is a wiki like, "release early and
release often", or agile sprint kind of improvement process.

In these cases, I could care less about the USPS "200 W WASHINGTON ST"
version required to make the USPS world more efficient for mail delivery.
I've come to understand that the USPS version of the corrected address is
less useful on a worldwide map.  The automated version presents another
barrier to use.  Not only do you have to understand English but then you
have to know some secret sets of codes in English to decipher a location.

OK. Someone wants to use our addresses for mailing.  Adding City, State,
and zipcode would be useful.  "Phoenix Arizona" is "corrected" to "Phoenix
AZ" in all the address correction software that I've seen and used for
mailing automation and mailing discounts.  A zipcode can help these systems
locate the correct _postal_ city if city and state are missing.

Alrighty! I still don't care about the USPS values for mailing address uses
either. I add addresses to OSM as part of my adventure of discovery and
exploring the world.  We have had discussions about zipcodes before.  The
Census Zip Code Tabulation Areas could be crowd sourced into a freely
available city, state, and zip code validation table available in for US
geographical areas.  Work would have to be done to remove the fake census
zip codes.  The rest of the world could crowd source there data into the
same validation table.  There may be enough worldwide city to postalcode
issues that a background display for US editing my the only useful
background tile similar to the 2013 TIGER maps.  I do not care that the zip
code or zip plus four are for line geometries for delivery routes.  All I
need is a geometry that can provide me with city, state, and zipcode
value.  Zip code correction software can fix any issues or add any missing
plus four digits for the delivery route part of the zip code, if people
desire to use OSM address data.

In contrast to the addr:state debate that we are having, I always
use addr:country key with the "US" value. The difference here is that
addr:country is an agreed upon ISO standard.

The AZ/Arizona issue isn't the only problem with addressing in the US.

 1.) I use addr:flats for addr:suite or addr:unit kinds of tags.  My
reasoning is that it may be a British English way of saying the same
thing.  Most of the other keys have a British feel to them.  I am also lazy
enough that there is a Josm preset ready for me to fill in suite data in
the addr:flats key when required.

 2.) The one good thing about AZ and Arizona values or the ISO country
value is they closely locate and refer to the same geographical boundary of
what I think of Arizona or the US in most cases. USPS addr:city and
addr:postcode don't always refer to the same geographical area. For
example, 13838 North Scottsdale Road, Scottsdale Arizona  85254-3433 is the
address from a business receipt. [1]   The actual taxing jurisdiction is
the City of Phoenix, Arizona not the City of Scottsdale, Arizona. If I am
feeling exceptionally precise I will add is_in tags. [2]  In this day of
tax collection on Internet purchases, Phoenix AZ residents that have
Glendale AZ postal areas pay higher taxes on some of their Internet
purchases or other billing services.  The billing company uses the postal
area as the taxing jurisdiction.  I have heard of large companies that can
afford massive GIS precision rely on USPS as the jurisdiction. They make
the customer prove them wrong.  Currently, Glendale AZ has a higher rate
than Phoenix AZ.  You might check your phone bills and the like to make
sure that you're not getting over charged!

3.) I have mixed emotions about the use of addr:city in non-addressing
situations such as when I see the addr:city tag added to, say, a
playground.  I started seeing these appear when OSM Inspector added the
wonderful address correction feature worldwide. [3]  I was amazed that I
made so many mistakes when adding survey data.  The tool also points out
abbreviated USPS styled address values in need of correction.  The use
of addr:city tag with playground adds a bunch of noisy zits to weed through
on the OSM Inspector tool.

4.) Though not confirmed by me, it feels like to me that European addr:city
values actually mean a city boundary.  I am guessing Nominatim prefers
addr:city over is_in tags because of my perceived idea that European
addr:city values more closely match the actual jurisdiction geometric
area.  What does addr:city in the US mean then?  The jurisdiction of the
POI or the postal value for the POI?

5.) I saw discussions of mappers removing directions or street types from
TIGER imported data. In my practice I am loath to make these kinds of
changes.  There are some city signs I have seen where the direction and
type are not displayed.  That does not mean these values should be
removed.  The real street name have these values.  I've seen whole areas
that have been modified this way. [4]  I have repaired as much of the area
as I can from memory but I now have a big question mark about the data
quality in this area.  Interestingly enough I have some cases of address
correction software removing street types when the street sign has the
correct, say, ST, type value on the sign.

Long story short: Addressing is being improved in the US OSM part of the
map.  At times it also feels like US OSM addresses take a step backwards
depending on the use case that mappers feel are valid.

Regards,
Greg


[1] https://www.openstreetmap.org/way/227545783
[2] https://wiki.openstreetmap.org/wiki/Key:is_in
[3]
http://tools.geofabrik.de/osmi/?view=addresses&lon=-112.12268&lat=33.56825&zoom=11&overlays=buildings,buildings_with_addresses,postal_code,no_addr_street,street_not_found,nodes_with_addresses_defined,nodes_with_addresses_interpolated,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads,nearest_areas
[4] https://www.openstreetmap.org/#map=18/33.42209/-111.87704
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20141107/5cc34de2/attachment.html>