mirror of
https://github.com/osm-search/Nominatim.git
synced 2026-02-16 15:47:58 +00:00
use consistent naming in doc pages
This commit is contained in:
89
docs/develop/Ranking.md
Normal file
89
docs/develop/Ranking.md
Normal file
@@ -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.
|
||||
Reference in New Issue
Block a user