[Imports] Address import for Allen County Indiana

[Mike H]

Pierre, I'll probably end up using that on some of the places that get
skipped from the import, but it might not work on all of them so I'm going
to add those points by hand, after the import.

Everyone else, I haven't heard anything from anyone in a few days, so I'm
guessing no one has anything more to add. Am I good to proceed with the
actual import?

On Fri, Apr 20, 2018 at 5:20 PM Pierre Béland <pierzenh at yahoo.fr> wrote:

> For buildings with multiple addresses, you can use an interpolation way
> with first and last nodes indicating the range of addresses.
>
>
> Pierre
>
>
> Le vendredi 20 avril 2018 16 h 40 min 27 s HAE, Mike H <1jgon6 at gmail.com>
> a écrit :
>
>
> Max, I have spot checked the data and the only problems I was able to find
> is in some places, mostly apartment complexes, there would be many
> addresses on a single point. These points I'm just not importing, but I
> will be saving them to a separate file, so the locations can be reviewed
> and mapped at a later date.
>
> For your second message, my understanding from reading the wiki is that
> the address tags should contain the postal address, so that's what I'm
> using. As far as zipcode boundaries go my understanding is that they aren't
> really a thing except for the census bureau, and zipcodes are really just a
> collection of points. For that reasoning, I think it's a good idea to have
> them on address points, so that's why I have kept them in the import plan.
> I'm not really sure if you had a question about that, but I hope that helps.
>
> I forgot to provide a link to the sample data that was request earlier, so
> you can find it here:
> https://gitlab.com/jgon6/allen_county_address_import/blob/master/Sample-data/46835.osm
>
>
>
> On Fri, Apr 20, 2018 at 3:38 PM Max Erickson <maxerickson at gmail.com>
> wrote:
>
> >In these areas, the addr:city tag should not be added.
>
> US postal addresses often differ from administrative units.
>
> Also, the boundaries imported from Tiger probably aren't accurate
> enough that other data should be rejected based on them.
>
> Of course I don't mean to propose a mass removal of the tiger
> boundaries when I mention they haven't yet achieved perfection.
>
>
> Max
>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20180427/55468b9a/attachment.html>