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

Kevin Kenny kevin.b.kenny at gmail.com
Wed Jan 13 05:55:34 UTC 2021


On Tue, Jan 12, 2021 at 9:50 PM Paul Norman <penorman at mac.com> wrote:

> On 2021-01-12 3:25 p.m., Kevin Kenny wrote:
> > 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.
>
> What data consumers are saying this? It's not been my experience with
> geocoders.
>

Clarify? Not your experience that it's harder, or not your experience that
the implementors of geocoders complain about it?

It's surely possible, and with a database like PostGIS, it's even possible
to compose a query that will fill in, for instance, a US state on a US
address that lacks one, by selecting a `boundary=administrative` polygon to
fill it in. [something like LEFT JOIN planet_osm_polygon AS state WHERE
state.boundary='administrative' AND state.admin_level='4' AND
ST_Contains(state.way, addressed_object.way) would probably do it, with
then an appropriate CASE or COALESCE to assemble it with
addressed_object."addr:state"] (Of course, internally to PostGIS, that's a
'point-in-polygon' against the fifty states plus whatever other
admin_level=4 objects may be about, with most excluded by the fact that the
point does not lie in a bbox, and the bbox intersection is assisted by a
GIST index)

It's also unavoidably local - different nations have different conventions
for which admin_levels might be part of an address, so the query that
retrieves a default gets relatively complicated. (And a default is all that
it can be, because we do need to be prepared for the case where a post
office's service area does not follow an administrative boundary, and
therefore need to be prepared for addr:city, addr:state, and so on to be
different from what could be inferred from bounday=administrative
containment.

Surely, at least in the abstract, this is more complex for data consumers
than simply pulling a field from the object. If you want to advance the
argument that a geocoder needs to have all that stuff anyway, I suppose
that could be reasonable. But certainly attaching `addr:state=*` to
imported address points totally avoids any possibility that the geocoder
would get it wrong.

I suppose you're going now to argue that it wastes space in the database. I
suppose that could be a fair argument, but I certainly don't want to open
the can of worms regarding what tags might or might not be valuable enough
to spend database space on them. Given how contentious everything else on
these mailing lists is, that discussion would be a never-ending stream of
acrimony.
-- 
73 de ke9tv/2, Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20210113/edbb3144/attachment.htm>


More information about the Imports mailing list