Re: [Talk-us] New I.D Feature
This thread seems like a storm in a teacup. From a data perspective addr:state is not really needed. Nominatim in particular and probably other geocoders as well assign it automatically based on state (admin_level=4) boundary relations. These relations are also tagged with ref=2 letter code which is why searching for something in Manhattan, KS works in nominatim just as well as Manhattan, Kansas The addr;state field has generally been left off of address imports. Adding the field in iD to reduce user input errors might be nice and a good idea but the addr:state tag that results from it is of very little value. Toby On Fri, Nov 7, 2014 at 1:18 AM, Minh Nguyen m...@nguyen.cincinnati.oh.us wrote: On 2014-11-06 20:17, Elliott Plack wrote: Thinking more on this, and using my experience in the foursquare superuser editing community, trying to have a single state type entity is really quite hard to scale globally. Political boundaries and administrative levels vary all over the world, and trying to establish a single name for a smaller political unit than the country is really challenging. State? Province? Municipality? There are many names for what a US State is (if you can really compare it out), and so to use addr:state does seem fairly USA focused. iD supports country-specific address formats. The State field only appears for features in the U.S., while Canadian address get a Province field. Vietnamese addresses get separate fields for subdistrict, district, city, and province, befitting the customary address format there. Before the state showed up in iD, I had assumed someone could just easily derive the US state from the postal code. That would be the case if everyone entered ZIP codes. However, I got this field added [1] because its absence was confusing inexperienced mappers, leading to inconsistent or erroneous data entry. For example, people were setting addr:city to Youngstown, Ohio or Dublin, OH [2][3], or setting addr:postcode to OH 45202, OH, or Ohio [4][5][6]. This happened primarily in iD but also to a lesser extent in Potlatch, which also lacks a State field in simple mode. [1] https://github.com/openstreetmap/iD/pull/2402 [2] http://osm.org/node/2647332019/history [3] http://osm.org/node/2152729301/history [4] http://osm.org/node/2573293336/history [5] http://osm.org/node/392309592/history [6] http://osm.org/node/357466455/history -- m...@nguyen.cincinnati.oh.us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
On 11/6/14 11:32 PM, Shawn K. Quinn wrote: On Fri, 2014-11-07 at 04:17 +, Elliott Plack wrote: Before the state showed up in iD, I had assumed someone could just easily derive the US state from the postal code. Usually, yes, but that introduces a dependence on third party data (USPS) that really should not be there. That, and it can be cumbersome. plus zip codes do sometimes cross state boundaries. it's not frequent but it happens. richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
A given Zip Code can potentially be in more than one US state, since they are based on delivery routes. On November 6, 2014 10:32:19 PM CST, Shawn K. Quinn skqu...@rushpost.com wrote: On Fri, 2014-11-07 at 04:17 +, Elliott Plack wrote: Before the state showed up in iD, I had assumed someone could just easily derive the US state from the postal code. Usually, yes, but that introduces a dependence on third party data (USPS) that really should not be there. That, and it can be cumbersome. -- Shawn K. Quinn skqu...@rushpost.com ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
On Thu, Nov 6, 2014 at 12:33 PM, stevea stevea...@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
