[Imports] Proposed import of San Francisco addresses

[Matthew Whilden]

Are there any buildings that have more than one addr:street in addresses
for that building? Or addr:unit numbers for different addr:housenumbers?
This happened for the Indianapolis data set. Delimiting works great until
you have to delimit more than one field. Maybe this doesn't happen in
practice in your area.

However, it's also nice to have addresses on nodes for buildings with
sizable footprints because you can then get the node closer to where the
address goes (ex: strip mall). I don't know how your dataset handles that.
The Indy dataset had addresses more or less where each tenant would be
located.

Matt

On Thu, Feb 9, 2023 at 6:22 PM Tyler Brown Cifu Shuster <t at fust.us> wrote:

> Buildings with multiple addresses use semicolons to separate their
> addresses in the field, like any field with multiple values.
>
> T
>
> > On Feb 9, 2023, at 5:38 PM, Eliot via Imports <imports at openstreetmap.org>
> wrote:
> >
> > On 10/02/23 10:50, Belov, Charles wrote:
> >> I am proposing importing all San Francisco addresses with their
> corresponding latitude and longitude, as served by DataSF at Addresses -
> Enterprise Addressing System <
> https://data.sfgov.org/Geographic-Locations-and-Boundaries/Addresses-Enterprise-Addressing-System/3mea-di5p>
> (
> https://data.sfgov.org/Geographic-Locations-and-Boundaries/Addresses-Enterprise-Addressing-System/3mea-di5p
> <
> https://data.sfgov.org/Geographic-Locations-and-Boundaries/Addresses-Enterprise-Addressing-System/3mea-di5p>)
> as open data. Specifically, I am seeking to import the columns Address,
> Latitude, and Longitude. This is because not all San Francisco addresses
> are in OpenStreetMap, leading to unsuccessful matches when trying to
> retrieve missing addresses.
> >> My concern is that many San Francisco addresses are already in
> OpenStreetMap, and there may be a conflict as to the Latitude and Longitude
> between those existing addresses and the San Francisco address data,
> leading to duplicate and mismatched data.
> >
> > An import that creates duplicate data must not happen.
> >
> > The most obvious solution to this is to remove all addresses that are
> already in OSM from your import dataset. I.e. import only the missing
> addresses.
> > The process of finding existing addresses that are wrong (location,
> name, number etc) and fixing them could be considered as a separate project.
> >
> >
> >> I note there is an OpenStreetMap wiki page San Francisco Address Import
> <https://wiki.openstreetmap.org/wiki/San_Francisco_Address_Import> (
> https://wiki.openstreetmap.org/wiki/San_Francisco_Address_Import <
> https://wiki.openstreetmap.org/wiki/San_Francisco_Address_Import>) which
> was last updated in 2020 and noted as ready for review. I’ve requested
> access to the review.
> >
> > The files linked from the wiki page are not publicly accessible
> (requires google login).  They probably should be made publicly readable.
> >
> > Tyler also said
> >> The most important thing to note is that addresses should be applied to
> buildings and not as points
> >
> > Food for thought (I'm not local, so no opinions on what is right for you)
> > Does this imply that every building has at most one address?  An OSM
> object can't have more than one address.
> > How are units/apartments within multi-unit buildings addressed?
> >
> > --
> > Eliot
> >
> >
> > _______________________________________________
> > 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/20230209/305e4540/attachment.htm>