From: Sarah Hoffmann Date: Fri, 23 Nov 2018 22:52:28 +0000 (+0100) Subject: Add documentation for new ranking level configuration X-Git-Tag: v3.3.0~55^2~6 X-Git-Url: https://git.openstreetmap.org./nominatim.git/commitdiff_plain/211214a8d36ce479fa5c7cf0f84f8da094b05d59 Add documentation for new ranking level configuration --- diff --git a/docs/develop/ranking.md b/docs/develop/ranking.md new file mode 100644 index 00000000..03704937 --- /dev/null +++ b/docs/develop/ranking.md @@ -0,0 +1,89 @@ +# Place Ranking in Nominatim + +Nominatim uses two metrics to rank a place: search rank and address rank. +Both can be assigned a value between 0 and 30. They serve slightly +different purposes, which are explained in this chapter. + +## Search rank + +The search rank describes the extent and importance of a place. It is used +when ranking search result. Simply put, if there are two results for a +search query which are otherwise equal, then the result with the _lower_ +search rank will be appear higher in the result list. + +Search ranks are not so important these days because many well-known +places use the Wikipedia importance ranking instead. + +## Address rank + +The address rank describes where a place shows up in an address hierarchy. +Usually only administrative boundaries and place nodes and areas are +eligible to be part of an address. All other objects have an address rank +of 0. + +Note that the search rank of a place place a role in the address computation +as well. When collecting the places that should make up the address parts +then only places are taken into account that have a lower address rank than +the search rank of the base object. + +## Rank configuration + +Search and address ranks are assigned to a place when it is first imported +into the database. There are a few hard-coded rules for the assignment: + + * postcodes follow special rules according to their length + * boundaries that are not areas and railway=rail are dropped completely + * the following are always search rank 30 and address rank 0: + * highway nodes + * landuse that is not an area + +Other than that, the ranks can be freely assigned via the json file +defined with `CONST_Address_Level_Config` according to their type and +the country they are in. + +The address level configuration must consist of an array of configuration +entries, each containing a tag definition and an optional country array: + +``` +[ { + "tags" : { + "place" : { + "county" : 12, + "city" : 16, + }, + "landuse" : { + "residential" : 22, + "" : 30 + } + } + }, + { + "countries" : [ "ca", "us" ], + "tags" : { + "boundary" : { + "administrative8" : 18, + "administrative9" : 20 + }, + "landuse" : { + "residential" : [22, 0] + } + } + } +] +``` + +The `countries` field contains a list of countries (as ISO 3166-1 alpha 2 code) +for which the definition applies. When the field is omitted, then the +definition is used as a fallback, when nothing more specific for a given +country exists. + +`tags` contains the ranks for key/value pairs. The ranks can be either a +single number, in which case they are to search and address rank, or a tuple +of search and address rank (in that order). The value may be left empty. +Then the rank is used when no more specific value is found for the given +key. + +Countries and key/value combination may appear in multiple defintions. Just +make sure that each combination of counrty/key/value appears only once per +file. Otherwise the import will fail with a UNIQUE INDEX constraint violation +on import. diff --git a/docs/mkdocs.yml b/docs/mkdocs.yml index 1a690e7b..3a0b1913 100644 --- a/docs/mkdocs.yml +++ b/docs/mkdocs.yml @@ -20,6 +20,7 @@ pages: - 'Troubleshooting' : 'admin/Faq.md' - 'Developers Guide': - 'Overview' : 'develop/overview.md' + - 'Place Ranking' : 'develop/ranking.md' - 'External Data Sources': - 'Overview' : 'data-sources/overview.md' - 'US Census (Tiger)': 'data-sources/US-Tiger.md'