On Thu, Nov 6, 2014 at 12:33 PM, stevea <[email protected]> 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
_______________________________________________ Talk-us mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-us
