<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 12, 2021 at 9:50 PM Paul Norman <<a href="mailto:penorman@mac.com">penorman@mac.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2021-01-12 3:25 p.m., Kevin Kenny wrote:<br>
> It's also harder on the data consumer, who has to do a <br>
> 'point-in-polygon' query against (at least) the fifty states to <br>
> determine it.<br>
<br>
What data consumers are saying this? It's not been my experience with <br>
geocoders.<br>
</blockquote></div><br clear="all"><div>Clarify? Not your experience that it's harder, or not your experience that the implementors of geocoders complain about it?</div><div><br></div><div>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)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div>-- <br><div dir="ltr" class="gmail_signature">73 de ke9tv/2, Kevin</div></div>