Re: [OSM-talk] Nominatim - Does it use the is_in tag?
On 16/08/2016 21:35, Nicolás Alvarez wrote: Wouldn't that lead to "mapping for the geocoder"? I'm sure that would be frowned upon as much as "mapping for the renderer". All tags are 'mapping for the renderer/geocoder/router. Otherwise you have just black lines, lots of 'You are here' signs stacked on top of each other & vehicles going round in circles. Tagging *incorrectly* to suit the above is what's frowned upon. Dave F. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Nominatim - Does it use the is_in tag?
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 > 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
Re: [OSM-talk] Nominatim - Does it use the is_in tag?
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 : > 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
Re: [OSM-talk] Nominatim - Does it use the is_in tag?
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
Re: [OSM-talk] Nominatim - Does it use the is_in tag?
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
Re: [OSM-talk] Nominatim - Does it use the is_in tag?
On 16/08/2016 16:19, Hakuch wrote: following the wiki, its not deprecated https://wiki.openstreetmap.org/wiki/Key:is_in I was surprised when I read that the other day too... However, I really would love to see a scheme that shows how nominatim finds it results.. There's the nominatim.openstreetmap.org site (but that might not be want you want). http://nominatim.openstreetmap.org/details.php?place_id=660625 Doesn't explicitly mention "is_in", but I guess you could try it somewhere there are enclaves and exclaves and see what it returns. Best Regards, Andy ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Nominatim - Does it use the is_in tag?
following the wiki, its not deprecated https://wiki.openstreetmap.org/wiki/Key:is_in However, I really would love to see a scheme that shows how nominatim finds it results.. On 16.08.2016 15:29, 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? > > 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. > > Thanks > Dave F. > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk 0x3CBE432B.asc Description: application/pgp-keys 0x3CBE432B.asc Description: application/pgp-keys ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
