On Tue, Aug 16, 2016 at 09:50:05PM +0200, Hakuch wrote: > Hey Sarah, do you have documentations that explain how nominatim > processes the queries? That could be an answer to questions like that one
Not really. You can have a look at the presentation I gave at SOTM Birmingham[1] but it's a bit dated and not really something where you 'look up' these things. Sarah [1] http://osm.lonvia.de/presentations/2013-nominatim.html > > 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 > > > pub 4096R/3CBE432B 2015-09-17 Hakuch <hak...@posteo.de> > sub 4096R/77F3A4C3 2015-09-17 [expires: 2016-09-16] > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
