[Imports] [Talk-us-newyork] [Imports-us] Draft proposal for import of New York State GIS SAM Address Points

[Kevin Kenny]

On Tue, Jan 12, 2021 at 5:07 PM Jmapb <jmapb at gmx.com> wrote:

> Re: Tagging Plans
>
> I feel there's little value in importing addr:state=NY with these
> addresses, since we have well-mapped state borders and the state is also
> unambiguously encoded in the ZIP code. I wonder if there are good examples
> of addresses that would truly benefit from this field, possibly on
> properties that are very near state lines. (We also share a border with
> Canada of course, so perhaps a similar case could be made for addr:country
> in the northern reaches of Franklin and Clinton counties.)
>
Disagree on this one. There are cases where the post office delivers across
state lines, so that a mailbox in New York can have an address in
Connecticut or New Jersey, or vice versa.  It's also harder on the data
consumer, who has to do a 'point-in-polygon' query against (at least) the
fifty states to determine it.  Let's keep the full street address
associated with the building, please!

Re: Data Reduction & Conflation
>
"... checked against an Overpass API for whether the address already exists
> within a short distance of the point. If any element with the same house
> number, street, or unit exists, then the address point is skipped." Perhaps
> I'm misreading this, but it seems to say you will not import an address
> point if you find another element nearby tagged with the same addr:street?
> I'd expect to see many instances where a currently-mapped address neighbors
> an unmapped address on the same street, sometimes quite nearby in dense
> areas. This sounds like it might exclude a lot of valid addresses.
>
> What's your reasoning behind not conflating address points that lie within
> a building:part? Not a big issue I presume, just curious.
>
Yeah, this one sounds a bit dodgy.

> Re: Modifying Existing Elements
>
> Personally I would love to see city and ZIP added to currently-mapped
> addresses that lack them. Maybe also consider flagging for review when
> currently-mapped values don't match the SAM values. I'm less keen on adding
> nysgissam:nysaddresspointid to addresses that didn't originate with this
> import, since I'd like to be able to tell at a glance if a given address
> was mapped or imported. Perhaps there could be some variation in the
> tagging... nysgissam:imported_addressid versus nysgissam:matched_addressid?
>
 I agree that an incompletely mapped address with a matching
housenumber and no conflicts should have the rest of its missing values
filled in. How we flag it for review could be discussed further.

> Re: Addresses of new developments
>
> It makes sense to add addresses to parcels where construction has actually
> commenced, but IMO adding recordkeeping addresses to completely undeveloped
> land strains the spirit of OSM a bit. If there's truly no way to
> distinguish between these two types of development status, I feel that the
> upside of importing them probably still outweighs the downside.
>
The only way, I think, to distinguish them is the absence of a building.
Given that there's no way to distinguish "there's no building here" from
"there might be a building here, but nobody has mapped it," I think that
Skyler is making the right call.

We also need to flag for review if we find addr:street for which no
corresponding `highway=*` exists. I have found cases local to me where
there are address points on never-built streets, and some of them collide
with buildings that have addresses on adjacent streets. (I actually need to
field-survey in there, because there may actually be one or two houses with
street addresses on the nonexistent street!)


> Numbered Routes
>
> Browsing through the online map of the SAM address points (
> http://www.arcgis.com/home/webmap/viewer.html?url=http%3A%2F%2Fgisservices.its.ny.gov%2Farcgis%2Frest%2Fservices%2FSAM_Address_Points%2FMapServer&source=sd
> ) I see a lot of variation on how the numbered routes, and the street names
> of the associated address points, are named. Eg, Route 23, State Route 23,
> State Highway 23. And of course the current data on OSM is just as messy. I
> can't help but think this might be a good time to discuss standardizing
> these statewide.
>
> Similarly for US routes: Route 6, United States Route 6, United States
> Highway 6.
>
Confounding this, the formal name of the street (State Route 23/State
Highway 23/etc) may well change when it crosses a political boundary. Since
NYS-SAM  derives from county data, unless it's clearly inconsistent on a
single stretch of highway within a county, I'd most likely import it as it
appears. If the counties themselves have not harmonized the naming, we want
to follow what they've done.

> New York City
>
> There was a full import of building footprints and conflated address data
> for all 5 NYC boros in 2013, from the city's own open data. Wondering if
> there's any special consideration given to integrating with these, or is it
> better to just wall it off and work strictly from the city's data?
>

The state's data were obtained from the city, so I'd simply exclude the
five boroughs from the import altogether, until and unless there's a plan
for how address point information will be updated and reconflated after the
initial import.

-- 
73 de ke9tv/2, Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20210112/ab794515/attachment-0001.htm>