Wouldn't that lead to "mapping for the geocoder"? I'm sure that would be frowned upon as much as "mapping for the renderer".
-- Nicolás 2016-08-16 16:50 GMT-03:00 Hakuch <hak...@posteo.de>: > Hey Sarah, do you have documentations that explain how nominatim > processes the queries? That could be an answer to questions like that one > > On 16.08.2016 21:27, Sarah Hoffmann wrote: >> On Tue, Aug 16, 2016 at 02:29:26PM +0100, Dave F wrote: >>> Hi >>> >>> I've heard a claim from a user who still wants to use the is_in:* >>> tag as well as boundary tags that Nominatim uses is_in as preference >>> because "geospacial mathematics is resource intensive". >>> >>> Is this true? >> >> Not at all. Nominatim happily processes boundaries and always prefers >> it over any other hierarchy information. >> >> It is true that it still understands is_in:* tags but prbably not in >> the way you would think. First of all, they are completely ignored >> on anything at building level (e.g address points and POIs). For >> everything else Nominatim always uses a geospatial match when >> computing the address. is_in:* is just good to help make a decision >> when there are two equally well suited candidates, generally when, say, >> a road is right between two city place nodes. As soon as there are >> boundaries, multiple candidates don't happen anymore, so that is_in:* >> is ignored for all practical purposes. >> >>> I thought geospacial calculations were fairly light on processing power. >>> >>> I also thought is_in:* was to be discouraged. Being hard coding, if >>> a boundary was to change all affected entities would become >>> inaccurate. >> >> Yes, if possible always draw boundaries. They are more precise and easier >> to maintain. is_in is unnecessary. >> >> Kind regards >> >> Sarah _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
