Re: [Talk-us] New I.D Feature
On Sat, Nov 8, 2014 at 3:51 PM, Minh Nguyen m...@nguyen.cincinnati.oh.us wrote: On 2014-11-07 22:35, Greg Morgan wrote: 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. To be pedantic, the two-letter state abbreviations are codified in ISO 3166-2: https://en.wikipedia.org/wiki/ISO_3166-2:US The standard covers virtually all of the countries in ISO 3166-1 with alphabetic, numeric, or alphanumeric codes. In the U.S., the codes are instantly recognizable as USPS abbreviations, but I don't know whether the codes elsewhere are as commonly recognizable. Not a Canadian but can confirm the ISO 3166-2:CA abbreviations are immediately recognizable as the standard Canada Post/Postes Canada abbreviations. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
Hi, On Sun, Nov 09, 2014 at 10:33:58AM -0500, Richard Welty wrote: 1) the Census Bureau has an area based version of zip codes (postal codes to the non-US types) called ZCTA. it is not a complete representation, it covers about 30,000 of the 50,000 unique zip codes, but it covers all the ones that can be reasonably envisioned as areas. Nominatim is already using a version of the ZCTA data as an additional source. I know there are some bad errors in there preceisly because it seems that US zip codes don't really cover areas. The search allows a certain degree of fuzziness by accepting all nearby zip codes but that is really not good enough. 2) missing from ZCTA is the mapping from zip codes to postal city as you call it. there is more to it than just a many-to-one mapping, which i'll address in a minute. 3) most of the US mappers are opposed to importing this into OSM for a couple of good reasons, i'm one of those opposed. I can see that there are good reasons not to import ZCTA. It is just an estimate after all. Until now I was under the impression that the postal cities are different than postcodes in that they are well defined areas, i.e. I thought that they are much more similar to administrative boundaries just created by a different branch of the government. But from your mail, it sounds like they are much closer to the zip codes. 4) however, there is also a movement in the US mapping community towards having certain types of data kept out of the core OSM database, including various types of admin boundaries. there are two projects looking at admin boundaries in this manner; i'm working on one of them. 5) so if we could 1) come up with the ZCTA-City mappings and 2) provide them in a convenient external database for use by geocoders, is this something that might reasonably be made use of in Nominatim? i've been considering what a project to crowdsource the zip-city mappings for the US might look like. currently the data exists in OSM to handle about 4% of the mappings, but a maproulette style challenge might get us a lot of the rest. as for that many to one mapping that isn't, basically, for each zip code there is a primary city and potentially a number of secondary cities. the primary city is the city name of the post office that serves the routes; the secondary cities are generally traditional place names within the delivery area; for example, for years i lived in the Lansingburgh neighborhood of Troy NY, and the post office would deliver mail for either city name. any effort to crowd source this data would need to take care of that detail. If I understand you right then the 'secondary cities' are the actual cities/towns/villages already mapped as either place nodes or administrative boundaries. Those are already used by Nominatim. So it seems the primary cities are what I was thinking of when referring to postal cities and they can actually be inferred from the postcode. If that is right, it should be somehow possible to add that concept to Nominatim. I'd have to give it a bit of thought. Sarah ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
On Wed, Nov 12, 2014 at 1:10 PM, Sarah Hoffmann lon...@denofr.de wrote: If I understand you right then the 'secondary cities' are the actual cities/towns/villages already mapped as either place nodes or administrative boundaries. Those are already used by Nominatim. So it seems the primary cities are what I was thinking of when referring to postal cities and they can actually be inferred from the postcode. If that is right, it should be somehow possible to add that concept to Nominatim. I'd have to give it a bit of thought. I think that might solve a problem with Census Designated Place, CDP. If the CDP has a different name than the postcode city, Nominatim might have a problem today. Clifford -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
I share Sarah's skepticism about importing ZCTAs. ZCTAs are generalized polygons created by the US Census Bureau and derived from *point* data furnished by the US Postal Service. Given the variability of ZIP codes in general, and the fact that OSM is two steps removed from the source data makes ZCTAs problematic. Likewise, postal cities are a fiction of the US Postal Service and in many localities, bear little relation to the actual, legally recognized administrative boundaries. Similarly, CDPs serve as a place name for named places that typically have no boundary, e.g. Tysons Corner in suburban Washington, DC. I can see CDPs imported into OSM before postal cities. The CDPs have a regular and well-understood update cycle and a centroid. The same cannot be said of postal cities and I think that trying to map ZIP to city on a one-to-one basis is fraught with difficulty all the way round. Sort of related to this: I gave a presentation at SotM-US in Portland where I tried (with very modest success) to argue that our addr:* tagging scheme is overloaded, making it difficult to search for the 'Stone Brook Drives', to disambiguate directional prefixes/suffixes, and so on. Might be worth talking about the general addressing scheme in the larger context of addresses. -- SEJ -- twitter: @geomantic -- skype: sejohnson8 There are two types of people in the world. Those that can extrapolate from incomplete data. On Wed, Nov 12, 2014 at 4:16 PM, Clifford Snow cliff...@snowandsnow.us wrote: On Wed, Nov 12, 2014 at 1:10 PM, Sarah Hoffmann lon...@denofr.de wrote: If I understand you right then the 'secondary cities' are the actual cities/towns/villages already mapped as either place nodes or administrative boundaries. Those are already used by Nominatim. So it seems the primary cities are what I was thinking of when referring to postal cities and they can actually be inferred from the postcode. If that is right, it should be somehow possible to add that concept to Nominatim. I'd have to give it a bit of thought. I think that might solve a problem with Census Designated Place, CDP. If the CDP has a different name than the postcode city, Nominatim might have a problem today. Clifford -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ 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/12/14 4:33 PM, Steven Johnson wrote: I share Sarah's skepticism about importing ZCTAs. ZCTAs are generalized polygons created by the US Census Bureau and derived from *point* data furnished by the US Postal Service. Given the variability of ZIP codes in general, and the fact that OSM is two steps removed from the source data makes ZCTAs problematic. i did say i had no intention of importing ZCTA data and am also opposed to that idea. 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
Just wanted to throw this out there in case you guys have forgoten, but we also use the two letter abbreviation in almost all relations for highways in the USA (however, there are a few that do spell out the state). However, we use 'is_in:state=PA instead of the addr scheme of course. This also goes for the 'network' tag (network=US:FL) for state highways relations. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
On Sat, Nov 8, 2014 at 12:35 AM, Greg Morgan dr.kludge...@gmail.com wrote: 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. To be clear, addr:city *IS* being used on imports and is useful information. Postal addresses for cities often extend far beyond the physical city boundaries and therefore can not be inferred by use of boundary relations. This is not the case with state and country which means the information in these tags is duplicated data. 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? Nominatim actually does not correctly use addr:city. You are correct in that it does assume a better match between physical border and postal city address. What happens is it actually puts city information on *roads* based on boundary relations and place=* nodes. Then it links individual address points to the roads. The addr:city tags on POIs and building outlines is actually completely ignored. This leads to things like this address not being found if you search for it in Manhattan, KS: https://www.openstreetmap.org/node/2209430502 On the other hand, this one on the next street over is found because I added an addr:city tag to the road: https://www.openstreetmap.org/node/2209427353 road: https://www.openstreetmap.org/way/13226787 I consider this to be a nominatim bug and haven't attempted to do a mass tagging of roads with addr:city because I see this as essentially tagging for the renderer. Toby ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
I believe that the is_in tag has what you may be looking for and it appears to have a well thought out structure.[1] You can still use addr:city to reflect the correct postal city.[2]. The tag has the same concern as addr:state When a region has a well developed set of boundary polygons the information that could be placed in the is_in tag on an object can usually be derived from the boundaries that contain it. In this case, the information in the tag is redundant. Some contributors even go as far as to delete this tag when they see it as equivalent to the boundary information.[2] Add the debate goes on: it is redundant and removed but uses for offline non-GIS use are overlooked. more importantly when searching by street name, e.g. for 'High Street', it can tell you which of the many results you get back is likely to be the one you want, by saying 'High Street;Fulbourn;Cambridgeshire' and 'High Street;Chapel-en-le-Frith;Derbyshire'. David.earl https://wiki.openstreetmap.org/wiki/User:David.earl October 14, 2006This is already accomplished automatically without the use of is_in tag in Nominatim https://wiki.openstreetmap.org/wiki/Nominatim, the latest search engine. --Gorm https://wiki.openstreetmap.org/wiki/User:Gorm 15:08, 6 April 2010 (UTC)Yeah, Nominatim is great! Where can i download it for offline navigation on my android with 8 GB sdcard? --Themroc https://wiki.openstreetmap.org/w/index.php?title=User:Themrocaction=editredlink=1 20:46, 21 May 2011 (BST) [2] [1] https://wiki.openstreetmap.org/wiki/Key:is_in [2] http://www.openstreetmap.org/way/310321442 Regards, Greg On Sat, Nov 8, 2014 at 1:11 PM, Sarah Hoffmann lon...@denofr.de wrote: Hi, On Sat, Nov 08, 2014 at 02:05:44AM -0600, Toby Murray wrote: Nominatim actually does not correctly use addr:city. You are correct in that it does assume a better match between physical border and postal city address. What happens is it actually puts city information on *roads* based on boundary relations and place=* nodes. Then it links individual address points to the roads. The addr:city tags on POIs and building outlines is actually completely ignored. This leads to things like this address not being found if you search for it in Manhattan, KS: https://www.openstreetmap.org/node/2209430502 On the other hand, this one on the next street over is found because I added an addr:city tag to the road: https://www.openstreetmap.org/node/2209427353 road: https://www.openstreetmap.org/way/13226787 I consider this to be a nominatim bug and haven't attempted to do a mass tagging of roads with addr:city because I see this as essentially tagging for the renderer. Well, agreed that Nominatim still misses the feature to mix in addr:* tags. It is somewhere on the todo list. To be honest, I'm not very motivated to fix it for the sake of US postal towns because I'm not yet convinced that the addr:city tag is the right solution for that concept. Postal towns are by all technical means areas and you should really consider tagging them as such. Let me just outline why addr:city is difficult from a point of view of searching. Assume Nominatim would handle addr:city correctly. That would alow you to find '6001 Stony Brook Drive, Manhattan'. But what about 'Stone Brook Drive, Manhattan'. I expect you would want to be able to find that too? That would only work if you added addr:city to the road as well or Nominatim added some means to infer from the addresses that the road is postal code-wise in Manhattan. It gets even more difficult for the addresses that have not yet been mapped. If there are addr:city tags on addresses in other streets nearby, then some dark magic might still guess the expected postal town correctly but it still means you need to add some addresses first. Any tagging schema that implies that much guessing really should be reconsidered. Postal towns is really a concept that wasn't taken into account when the Karlsruhe address schema was developped and IMHO doesn't really fit. I'd really like to see some discussion in the US community about how it can be tagged including considering the possibility to come up with a brand new way of tagging it. If you then come to the conclusion that addr:city is still the best way to go, so be it. But I'd be far more happy to support something in Nominatim that fits exactly the US situation than hack some European tagging system until it hopefully gives the right result most of the time. Kind regards Sarah (your friendly nominatim maintainer) ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
I agree with SteveA Greg on the points they made. I would also like to add the following suggestions and opinions. 1.) We the U.S osm group need to make decisions on address problems that remain unresolved. 2.) Document the changes if any are made/agreed upon in the wiki. 3.) I disagree that adding state data in addresses in the U.S is of little value. Either abbreviated or not. This now seems to point to a much larger problem overall that the osm community has had. Not just in the U.S but in the osm community as a whole. The need for us to come to agreement on address issues that have come to light continue to grow. It seems to me if we want addresses to be apart of the map and done right these issues need to be resolved soon. Other wise we will continue to be held back in any further progress we can make. Making the problem much more difficult to solve in the future. Regards, Hans On Sat, Nov 8, 2014 at 12:35 AM, Greg Morgan dr.kludge...@gmail.com wrote: 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. To be clear, addr:city *IS* being used on imports and is useful information. Postal addresses for cities often extend far beyond the physical city boundaries and therefore can not be inferred by use of boundary relations. This is not the case with state and country which means the information in these tags is duplicated data. 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? Nominatim actually does not correctly use addr:city. You are correct in that it does assume a better match between physical border and postal city address. What happens is it actually puts city information on *roads* based on boundary relations and place=* nodes. Then it links individual address points to the roads. The addr:city tags on POIs and building outlines is actually completely ignored. This leads to things like this address not being found if you search for it in Manhattan, KS: https://www.openstreetmap.org/node/2209430502 On the other hand, this one on the next street over is found because I added an addr:city tag to the road: https://www.openstreetmap.org/node/2209427353 road: https://www.openstreetmap.org/way/13226787 I consider this to be a nominatim bug and haven't attempted to do a mass tagging of roads with addr:city because I see this as essentially tagging for the renderer. Toby ___ 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 2014-11-07 22:35, Greg Morgan wrote: 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. To be pedantic, the two-letter state abbreviations are codified in ISO 3166-2: https://en.wikipedia.org/wiki/ISO_3166-2:US The standard covers virtually all of the countries in ISO 3166-1 with alphabetic, numeric, or alphanumeric codes. In the U.S., the codes are instantly recognizable as USPS abbreviations, but I don't know whether the codes elsewhere are as commonly recognizable. -- m...@nguyen.cincinnati.oh.us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
Thanks Minh. I did not know that. I thought that they were a convention of USPS. I always hear about the codes relating to mailing concerns. Regards, Greg On Sat, Nov 8, 2014 at 2:51 PM, Minh Nguyen m...@nguyen.cincinnati.oh.us wrote: On 2014-11-07 22:35, Greg Morgan wrote: 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. To be pedantic, the two-letter state abbreviations are codified in ISO 3166-2: https://en.wikipedia.org/wiki/ISO_3166-2:US The standard covers virtually all of the countries in ISO 3166-1 with alphabetic, numeric, or alphanumeric codes. In the U.S., the codes are instantly recognizable as USPS abbreviations, but I don't know whether the codes elsewhere are as commonly recognizable. -- 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
As long as we have clever mappings like this (two-letter codes to whatever, especially if/as/when they are ISO standards), I am OK with data remaining as two-letter codes. (I am not thrilled, but if there is a way to explain how the dots are connected and how to connect other dots given clever mappings, great). I am glad we are having this discussion. I'm not sure whether pedantic, but it is an interesting and distinct boundary. (One I made off list to Richard Weait and Elliott Plack). Still, for things that need their state address entered in Arizona, I'll do that, instead of AZ. Just me? No. Seriously, understanding a more total semantic (instead of a single or vague concept) as represented by a syntax unit, like a two letter abbreviation, is something we should wave various colored flags about. Careful that as many as possible both discuss and understand larger issues. (Talk-us is a larger stage). It seems to me that OSM remains resilient, talking to itself (ourselves) well. So far, so good. (Nothing like dotting an i or two and crossing some ts here and there). SteveA California On 2014-11-07 22:35, Greg Morgan wrote: 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. To be pedantic, the two-letter state abbreviations are codified in ISO 3166-2: https://en.wikipedia.org/wiki/ISO_3166-2:US The standard covers virtually all of the countries in ISO 3166-1 with alphabetic, numeric, or alphanumeric codes. In the U.S., the codes are instantly recognizable as USPS abbreviations, but I don't know whether the codes elsewhere are as commonly recognizable. -- m...@nguyen.cincinnati.oh.us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
Hi, On Sat, Nov 08, 2014 at 02:05:44AM -0600, Toby Murray wrote: Nominatim actually does not correctly use addr:city. You are correct in that it does assume a better match between physical border and postal city address. What happens is it actually puts city information on *roads* based on boundary relations and place=* nodes. Then it links individual address points to the roads. The addr:city tags on POIs and building outlines is actually completely ignored. This leads to things like this address not being found if you search for it in Manhattan, KS: https://www.openstreetmap.org/node/2209430502 On the other hand, this one on the next street over is found because I added an addr:city tag to the road: https://www.openstreetmap.org/node/2209427353 road: https://www.openstreetmap.org/way/13226787 I consider this to be a nominatim bug and haven't attempted to do a mass tagging of roads with addr:city because I see this as essentially tagging for the renderer. Well, agreed that Nominatim still misses the feature to mix in addr:* tags. It is somewhere on the todo list. To be honest, I'm not very motivated to fix it for the sake of US postal towns because I'm not yet convinced that the addr:city tag is the right solution for that concept. Postal towns are by all technical means areas and you should really consider tagging them as such. Let me just outline why addr:city is difficult from a point of view of searching. Assume Nominatim would handle addr:city correctly. That would alow you to find '6001 Stony Brook Drive, Manhattan'. But what about 'Stone Brook Drive, Manhattan'. I expect you would want to be able to find that too? That would only work if you added addr:city to the road as well or Nominatim added some means to infer from the addresses that the road is postal code-wise in Manhattan. It gets even more difficult for the addresses that have not yet been mapped. If there are addr:city tags on addresses in other streets nearby, then some dark magic might still guess the expected postal town correctly but it still means you need to add some addresses first. Any tagging schema that implies that much guessing really should be reconsidered. Postal towns is really a concept that wasn't taken into account when the Karlsruhe address schema was developped and IMHO doesn't really fit. I'd really like to see some discussion in the US community about how it can be tagged including considering the possibility to come up with a brand new way of tagging it. If you then come to the conclusion that addr:city is still the best way to go, so be it. But I'd be far more happy to support something in Nominatim that fits exactly the US situation than hack some European tagging system until it hopefully gives the right result most of the time. Kind regards Sarah (your friendly nominatim maintainer) ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
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
Re: [Talk-us] New I.D Feature
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. For example, I insist that I live in a place called California. I absolutely do not live in a place called CA. They are two different places, and one is not the other. If we are being truly accurate, these are absolutely not freely interchangeable. While I agree that in some circumstances it is very convenient to use a two-letter abbreviation for a state, and I do on occasion take advantage of this convenience, please keep in mind the very distinct semantics which differentiate these entities. SteveA California wiki says to use abbreviated. see http://wiki.openstreetmap.org/wiki/Key:addr:state#For_countries_using_hamlet.2C_subdistrict.2C_district.2C_province.2C_statehttp://wiki.openstreetmap.org/wiki/Key:addr:state#For_countries_using_hamlet.2C_subdistrict.2C_district.2C_province.2C_state I almost had a panic attack because I use abbreviated state in all my addresses. Mike On Wed, Nov 5, 2014 at 8:51 PM, Hans De Kryger mailto:hans.dekryge...@gmail.comhans.dekryge...@gmail.com wrote: ÐAs seen in this photo, the new feature in I.D has me a bit confused, As is the rule already in osm. We do not abbreviate addresses at all. My question would be, how do we add state data. Abbreviated as seen here (AZ) or spelled out (Arizona) ? Any help would be appreciated. Regards, Hans ___ Talk-us mailing list mailto:Talk-us@openstreetmap.orgTalk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ushttps://lists.openstreetmap.org/listinfo/talk-us Content-Type: image/png; name=Capture.PNG Content-Disposition: inline; filename=Capture.PNG Content-ID: ii_i25ilfei0_149830049aa034b6 X-Attachment-Id: ii_i25ilfei0_149830049aa034b6 ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
Interesting about the Buck Act, however, the only info I could find about this oddity is from some websites written by conspiracy theorists, anti-government types, etc. Still, it would be in keeping with our practice of discouraging the use of abbreviations elsewhere in addresses. It would be very easy for a machine or renderer to abbreviate full state names down to USPS postal abbreviations, AP style guide abbreviations, or any other custom abbreviation. On Thu Nov 06 2014 at 2:36:47 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. For example, I insist that I live in a place called California. I absolutely do not live in a place called CA. They are two different places, and one is not the other. If we are being truly accurate, these are absolutely not freely interchangeable. While I agree that in some circumstances it is very convenient to use a two-letter abbreviation for a state, and I do on occasion take advantage of this convenience, please keep in mind the very distinct semantics which differentiate these entities. SteveA California wiki says to use abbreviated. see http://wiki.openstreetmap.org/wiki/Key:addr:state#For_countries_usin g_hamlet.2C_subdistrict.2C_district.2C_province.2C_state I almost had a panic attack because I use abbreviated state in all my addresses. Mike On Wed, Nov 5, 2014 at 8:51 PM, Hans De Kryger hans.dekryge...@gmail.com wrote: ÐAs seen in this photo, the new feature in I.D has me a bit confused, As is the rule already in osm. We do not abbreviate addresses at all. My question would be, how do we add state data. Abbreviated as seen here (AZ) or spelled out (Arizona) ? Any help would be appreciated. *Regards,* *Hans* ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us Content-Type: image/png; name=Capture.PNG Content-Disposition: inline; filename=Capture.PNG Content-ID: ii_i25ilfei0_149830049aa034b6 X-Attachment-Id: ii_i25ilfei0_149830049aa034b6 ___ 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 Thu, 2014-11-06 at 21:10 +, Elliott Plack wrote: Interesting about the Buck Act, however, the only info I could find about this oddity is from some websites written by conspiracy theorists, anti-government types, etc. Still, it would be in keeping with our practice of discouraging the use of abbreviations elsewhere in addresses. It would be very easy for a machine or renderer to abbreviate full state names down to USPS postal abbreviations, AP style guide abbreviations, or any other custom abbreviation. In the case of US state and Canadian province abbreviations, there is a 1:1 correspondence with no ambiguity. Elsewhere this may or may not be the case. That said, using the USPS abbreviations in the US makes the most sense to me, as that is the format most of us who mail things with any regularity are used to writing and seeing addresses in. I realize it's an exception to the don't abbreviate rule but it does make some sense at least to me. -- Shawn K. Quinn skqu...@rushpost.com ___ 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 2:21 PM, Shawn K. Quinn skqu...@rushpost.com wrote: In the case of US state and Canadian province abbreviations, there is a 1:1 correspondence with no ambiguity. Elsewhere this may or may not be the case. That said, using the USPS abbreviations in the US makes the most sense to me, as that is the format most of us who mail things with any regularity are used to writing and seeing addresses in. I realize it's an exception to the don't abbreviate rule but it does make some sense at least to me. +1 -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
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. Before the state showed up in iD, I had assumed someone could just easily derive the US state from the postal code. Perhaps the tag should be addr:us_state? Kindly, Elliott On Thu Nov 06 2014 at 4:24:14 PM Clifford Snow cliff...@snowandsnow.us wrote: On Thu, Nov 6, 2014 at 2:21 PM, Shawn K. Quinn skqu...@rushpost.com wrote: In the case of US state and Canadian province abbreviations, there is a 1:1 correspondence with no ambiguity. Elsewhere this may or may not be the case. That said, using the USPS abbreviations in the US makes the most sense to me, as that is the format most of us who mail things with any regularity are used to writing and seeing addresses in. I realize it's an exception to the don't abbreviate rule but it does make some sense at least to me. +1 -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ 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 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
Re: [Talk-us] New I.D Feature
That's a rather extreme definition of third party data and cumbersome for that matter. d. On Nov 6, 2014, at 20:32, 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 ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
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] New I.D Feature
As seen in this photo, the new feature in I.D has me a bit confused, As is the rule already in osm. We do not abbreviate addresses at all. My question would be, how do we add state data. Abbreviated as seen here (AZ) or spelled out (Arizona) ? Any help would be appreciated. *Regards,* *Hans* ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
wiki says to use abbreviated. see http://wiki.openstreetmap.org/wiki/Key:addr:state#For_countries_using_hamlet.2C_subdistrict.2C_district.2C_province.2C_state I almost had a panic attack because I use abbreviated state in all my addresses. Mike On Wed, Nov 5, 2014 at 8:51 PM, Hans De Kryger hans.dekryge...@gmail.com wrote: As seen in this photo, the new feature in I.D has me a bit confused, As is the rule already in osm. We do not abbreviate addresses at all. My question would be, how do we add state data. Abbreviated as seen here (AZ) or spelled out (Arizona) ? Any help would be appreciated. *Regards,* *Hans* ___ 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
