[Imports] [Talk-us-sfbay] Proposed import of San Francisco addresses

[Minh Nguyen]

(Resending to the imports list)

Vào lúc 21:24 2023-02-09, Belov, Charles đã viết:

>> 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.
> The building on the southeast corner of Market & Van Ness has three 
> addresses: 1525 Market Street (the bank branch on the ground floor), 
> 11 South Van Ness Avenue (the SFMTA Customer Service Center), and 1 
> South Van Ness Avenue (the office lobby on the first floor, as well as 
> the entire basement and 2nd and higher floors, which are also above or 
> below the bank branch and the SFMTA Customer Service Center) .
>
> In the City data from 
> https://data.sfgov.org/Geographic-Locations-and-Boundaries/Addresses-Enterprise-Addressing-System/3mea-di5p:
>
> 1525 Market Street has lat/long of 37.77514082, -122.4189106. This 
> points to the entrance.
> 1 South Van Ness Avenue has lat/long of 37.75385644, -122.4161123. Bad 
> data. See below.
> 11 South Van Ness Avenue has lat/long of 37.77450185, -122.4188237. 
> This points to the entrance.
>
> Since the building is in the same place for each of these, it's clear 
> that the lat/long does not refer to the building, but to the 
> respective entrances.
>
> It appears that the lat/long given for 1 South Van Ness Avenue is 
> wrong; Google Maps is giving me a location at South Van Ness and 23rd 
> Street, over a mile away from the actual South Van Ness and Market. If 
> we can't trust the data, then bulk importing is not going to work. 
> (I've reported the 1 South Van Ness issue to the DataSF dataset owner.)
>
> The building on the northwest corner of Geary and Presidio has at 
> least four addresses, 949 Presidio Avenue, and 2620, 2630 and 2640 
> Geary. 949 Presidio is both behind and above the other addresses.
>
> 949 Presidio: 37.78312314, -122.4460813 points to the entrance.
> 2620 Geary is not in the data. I'm not necessarily concerned with 
> missing addresses as they will at least do no harm.
> 2630 Geary: 37.78285206, -122.4463834 points to within the building.
> 2640 Geary: 37.78283298, -122.4465738 points to within the building.
>
> I'm thinking that there might be a way to run a sanity check on 
> lat/longs within a particular hundred block, for example that 1 South 
> Van Ness is reasonably close to 11 South Van Ness (which in this case 
> the data isn't even though the addresses are close in real life). San 
> Francisco generally has 100 numbers per block counting from the 
> beginning of the street. We might need to separate odd and even, as on 
> the 700 block of Duboce.
>
> That said, the inconsistency as to whether an entrance or a building 
> is used sounds like it would be problematic with regard to 
> OpenStreetMap's practices.

I believe the discrepancy has been overstated. While it’s true that 
buildings are often tagged with addresses, it’s very common for 
addresses to be mapped as standalone point features whenever they don’t 
correspond one-for-one to buildings, such as with duplex houses or 
downtown office blocks. Various imports in the U.S. have made exceptions 
for address points within condominiums, duplex houses, strip malls, and 
downtown office blocks.

For example, the building/address imports in nearby San José [1] and 
Cupertino [2] even included sometimes very dense arrangements of address 
points for individual units within apartment complexes when available. 
This mapping style is also common inside retail buildings, since each 
address point might get upgraded a point of interest later on. We’re 
actively upgrading these points while manually mapping points of 
interest in Santa Clara County. [3] The address data we’re working with 
generally correlates to parcels or units, rather than entrances per se, 
but it could be different in the data you’re working with.

Conflating addresses that may or may not be tied to buildings can be 
more challenging. Popular QA tools like JOSM’s validator will warn 
whenever they detect multiple identical addresses within a certain 
distance. While this heuristic easily flags false positives in certain 
situations, it could still be a good starting point for planning your 
import.

>> The
>> "Materials (inputs, code, output)” link on the import page doesn’t 
>> work so I can’t see how they’re being applied.
> I didn't post that file. It was apparently posted to that page three 
> years ago. I don't know why it might be protected. I've requested 
> access and will update the list if I gain it.

I’ve reached out to the mappers who coordinated that original import, 
some of whom are still active in OSM. Hopefully you’ll be able to 
coordinate an update of this data with them. Down here in the South Bay, 
we’re going to need to update some of our older imports before long, so 
any solution you come up with could help us as well.

[1] 
https://wiki.openstreetmap.org/wiki/Santa_Clara_County,_California/San_Jose_building_import
[2] https://wiki.openstreetmap.org/wiki/Cupertino_import
[3] 
https://wiki.openstreetmap.org/wiki/Santa_Clara_County,_California/Social_distancing_protocol_import

-- 
Minh Nguyen <minh at nguyen.cincinnati.oh.us>