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 >
0x3CBE432B.asc
Description: application/pgp-keys
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
