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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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*
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
27 matches
Mail list logo
