[Talk-us-massachusetts] Plymouth Import Test

[Peter Dobratz]

In my opinion, the addr:* tags should be used to capture address
information as commonly used in each country.  In the US, we only use:

addr:housenumber
addr:street
(optional) addr:unit
addr:city
addr:state
addr:postcode

addr:housenumber may contain fractions (31 1/2) or suffixes (10A)
addr:street is the name of the street which may also include directional
prefix, suffix, and directional suffix, with abbreviations expanded (for
example: Southwest Main Street North)
addr:unit is a secondary number or letter to addr:housenumber and is
usually prefixed by Apt, Unit, Lot, Suite, etc in the full address.
addr:unit only contains the number and not any of the Apt/Unit/Lot/Ste
designators.
addr:city contains the postal city that is used for the address.  In many
cases this matches up exactly with the name of an admin level 8 boundary,
but not always.  For example, "North Chelmsford" addresses are all located
within Chelmsford, MA. In many cases, this is not a city at all but a
smaller entity like a town or village or even in some cases the name of a
county or a business (Tektronix, OR used to be a thing but I think they
have changed these to be Beaverton, OR now)
addr:state is the standard 2-letter state abbreviation
addr:postcode is generally the 5 digit zip code

Although in many cases, you could try to derive addr:city, addr:state, and
addr:postcode from admin boundaries, there are plenty of cases where this
doesn't work out and whenever capturing address data by hand, I include
these 3 tags.

The 5 tags that I have listed are what is presented to the user editing
places in the US when using the iD editor.

I avoid using other addr:* tags like addr:housename, addr:suburb,
addr:place as these are not really part of standard US addresses.  They
have specific meanings in other countries.

Peter


On Fri, Apr 12, 2019 at 8:42 AM Greg Troxel <gdt at lexort.com> wrote:

> Greg Troxel <gdt at lexort.com> writes:
>
> > I think that we should not be adding points with just street/number, but
> > also town and state.   This is just making it harder to fix later since
> > town and state belong.   I don't understand why you think it is lower
> > risk to omit town state; that doesn't make it more likely that the other
> > data is right.
>
> The first question is what OSM norms are, in terms of if address points
> should have town/state/etc., or whether they should not, or if it is
> truly ok either way.  I have always had the impression that at least
> town/state should be filled in, and it seems we've generally been doing
> this when hand mapping.
>
> A related question is if data consumers are obligated to process address
> points with implicit town/state/country from level 8/4/2 admin
> boundaries, and whether substantially all of them do.
>
> A difficult issue is places like Barnstable (the level8 town), which as
> I understand it has level9 (or 10?) divisions with names like Yarmouth,
> Hyannis and even Barnstable, and in addressing these are treated as the
> town name, even though the actual legal town is Barnstable.  I expect
> there are more places like this, but I'm not sure of any specific ones.
> (This is different than named neighborhoods, in that addresses use the
> sub-names.)  I don't see how this can work with implicit town names.
> But I have been saying repeatedly that we should leave Barnstable out
> for now!
>
> It could be that it's ok to omit town in the osm data, when the town in
> the MAD address point matches the admin level8 name and thus the
> implicit matching data consumers do is correct, and that we'll need to
> be adding it for Barnstable .
>
> Do we know that every point in MAD with the name Plymouth is within the
> osm level8 polygon, and that every point in MAD within that polygon says
> Plymouth?
>
>
>
> _______________________________________________
> Talk-us-massachusetts mailing list
> Talk-us-massachusetts at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us-massachusetts
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us-massachusetts/attachments/20190413/63a24198/attachment.html>