osm-search/Nominatim
1
1
Fork 0
mirror of https://github.com/osm-search/Nominatim.git synced 2024-12-02 08:36:42 +03:00
Code Issues Packages Projects Releases Wiki Activity
336258ecf8
Nominatim/test/bdd/db/import/addressing.feature

436 lines
19 KiB
Gherkin
Raw Normal View History

for roads add all intersecting boundaries to address list When roads cross boundaries, both administrative entities should be added to the address list, so that both entities can be used for searching. Also allows in a second step to better sort out addresses of POIs on such roads. Fixes #121.
2017-03-18 14:17:48 +03:00
@DB
Feature: Address computation
Tests for filling of place_addressline
add tests for address computation
2020-10-16 12:07:17 +03:00
Scenario: place nodes are added to the address when they are close enough
Given the 0.002 grid
| 2 | | | | | | 1 | | 3 |
null entries need to be typed
2020-12-01 16:54:42 +03:00
And the places
| osm | class | type | name | geometry |
| N1 | place | square | Square | 1 |
| N2 | place | hamlet | West Farm | 2 |
| N3 | place | hamlet | East Farm | 3 |
add tests for address computation
2020-10-16 12:07:17 +03:00
When importing
Then place_addressline contains
| object | address | fromarea |
| N1 | N3 | False |
Then place_addressline doesn't contain
| object | address |
| N1 | N2 |
switch BDD tests to always use search API
2021-06-06 16:27:52 +03:00
When sending search query "Square"
null entries need to be typed
2020-12-01 16:54:42 +03:00
Then results contain
switch BDD tests to always use search API
2021-06-06 16:27:52 +03:00
| osm | display_name |
| N1 | Square, East Farm |
add tests for address computation
2020-10-16 12:07:17 +03:00
Scenario: given two place nodes, the closer one wins for the address
Given the grid
| 2 | | | 1 | | 3 |
And the named places
| osm | class | type | geometry |
| N1 | place | square | 1 |
| N2 | place | hamlet | 2 |
| N3 | place | hamlet | 3 |
When importing
Then place_addressline contains
| object | address | fromarea | isaddress |
| N1 | N3 | False | True |
| N1 | N2 | False | False |
Scenario: boundaries around the place are added to the address
Given the grid
| 1 | | 4 | | 7 | 10 |
| 2 | | 5 | | 8 | 11 |
| | | | | | |
| | | | | | |
| | | 6 | | 9 | |
| | 99 | | | | |
| 3 | | | | | 12 |
And the named places
| osm | class | type | admin | geometry |
| R1 | boundary | administrative | 3 | (1,2,3,12,11,10,7,8,9,6,5,4,1) |
| R2 | boundary | administrative | 4 | (2,3,12,11,8,9,6,5,2) |
| N1 | place | square | 15 | 99 |
When importing
Then place_addressline contains
| object | address | isaddress |
| N1 | R1 | True |
| N1 | R2 | True |
Scenario: with boundaries of same rank the one with the closer centroid is prefered
Given the grid
| 1 | | | 3 | | 5 |
| | 9 | | | | |
| 2 | | | 4 | | 6 |
And the named places
| osm | class | type | admin | geometry |
| R1 | boundary | administrative | 8 | (1,2,4,3,1) |
| R2 | boundary | administrative | 8 | (1,2,6,5,1) |
| N1 | place | square | 15 | 9 |
When importing
Then place_addressline contains
| object | address | isaddress |
| N1 | R1 | True |
| N1 | R2 | False |
Scenario: boundary areas are preferred over place nodes in the address
Given the grid
| 1 | | | | | | 3 |
| | 5 | | | | | |
| | 6 | | | | | |
| 2 | | | | | | 4 |
And the named places
| osm | class | type | admin | geometry |
| N1 | place | square | 15 | 5 |
| N2 | place | city | 15 | 6 |
| R1 | place | city | 8 | (1,2,4,3,1) |
When importing
Then place_addressline contains
| object | address | isaddress | cached_rank_address |
| N1 | R1 | True | 16 |
| N1 | N2 | False | 16 |
Scenario: place nodes outside a smaller ranked area are ignored
Given the grid
| 1 | | 2 | |
| | 7 | | 9 |
| 4 | | 3 | |
And the named places
| osm | class | type | admin | geometry |
| N1 | place | square | 15 | 7 |
| N2 | place | city | 15 | 9 |
| R1 | place | city | 8 | (1,2,3,4,1) |
When importing
Then place_addressline contains
| object | address | isaddress | cached_rank_address |
| N1 | R1 | True | 16 |
And place_addressline doesn't contain
| object | address |
| N1 | N2 |
Scenario: place nodes close enough to smaller ranked place nodes are included
Given the 0.002 grid
| 2 | | 3 | 1 |
And the named places
| osm | class | type | geometry |
| N1 | place | square | 1 |
| N2 | place | hamlet | 2 |
| N3 | place | quarter | 3 |
When importing
Then place_addressline contains
| object | address | fromarea | isaddress |
| N1 | N2 | False | True |
| N1 | N3 | False | True |
Scenario: place nodes too far away from a smaller ranked place nodes are marked non-address
Given the 0.002 grid
| 2 | | | 1 | | 3 |
And the named places
| osm | class | type | geometry |
| N1 | place | square | 1 |
| N2 | place | hamlet | 2 |
| N3 | place | quarter | 3 |
When importing
Then place_addressline contains
| object | address | fromarea | isaddress |
| N1 | N2 | False | True |
| N1 | N3 | False | False |
for roads add all intersecting boundaries to address list When roads cross boundaries, both administrative entities should be added to the address list, so that both entities can be used for searching. Also allows in a second step to better sort out addresses of POIs on such roads. Fixes #121.
2017-03-18 14:17:48 +03:00
# github #121
Scenario: Roads crossing boundaries should contain both states
Given the grid
| 1 | | | 2 | | 3 |
test: make road really cross the boundary
2020-07-26 16:57:07 +03:00
| | 7 | | | 8 | |
for roads add all intersecting boundaries to address list When roads cross boundaries, both administrative entities should be added to the address list, so that both entities can be used for searching. Also allows in a second step to better sort out addresses of POIs on such roads. Fixes #121.
2017-03-18 14:17:48 +03:00
| 4 | | | 5 | | 6 |
And the named places
| osm | class | type | geometry |
| W1 | highway | road | 7, 8 |
And the named places
| osm | class | type | admin | geometry |
| W10 | boundary | administrative | 5 | (1, 2, 5, 4, 1) |
| W11 | boundary | administrative | 5 | (2, 3, 6, 5, 2) |
When importing
Then place_addressline contains
| object | address | cached_rank_address |
| W1 | W10 | 10 |
| W1 | W11 | 10 |
Do not have postcode node appear in addresses directly Many of the postcode nodes are actually derived from incomplete addresses and are as such not even centroids. Better let them only take part in the address computation via the postcode table.
2018-07-22 17:22:07 +03:00
be more strict what areas make up an address Exclude boundaries that touch a line in only one point and that touch areas only along the boundary. Fixes #1900.
2020-08-04 13:08:50 +03:00
Scenario: Roads following a boundary should contain both states
Given the grid
| 1 | | | 2 | | 3 |
| | | 8 | 7 | | |
| 4 | | | 5 | | 6 |
And the named places
| osm | class | type | geometry |
| W1 | highway | road | 2, 7, 8 |
And the named places
| osm | class | type | admin | geometry |
| W10 | boundary | administrative | 5 | (1, 2, 5, 4, 1) |
| W11 | boundary | administrative | 5 | (2, 3, 6, 5, 2) |
When importing
Then place_addressline contains
| object | address | cached_rank_address |
| W1 | W10 | 10 |
| W1 | W11 | 10 |
Scenario: Roads should not contain boundaries they touch in a end point
Given the grid
| 1 | | | 2 | | 3 |
| | 7 | | 8 | | |
| 4 | | | 5 | | 6 |
And the named places
| osm | class | type | geometry |
| W1 | highway | road | 7, 8 |
And the named places
| osm | class | type | admin | geometry |
| W10 | boundary | administrative | 5 | (1, 2, 8, 5, 4, 1) |
| W11 | boundary | administrative | 5 | (2, 3, 6, 5, 8, 2) |
When importing
Then place_addressline contains
| object | address | cached_rank_address |
| W1 | W10 | 10 |
Then place_addressline doesn't contain
| object | address |
| W1 | W11 |
add tests for address computation
2020-10-16 12:07:17 +03:00
Scenario: Roads should not contain boundaries they touch in a middle point
be more strict what areas make up an address Exclude boundaries that touch a line in only one point and that touch areas only along the boundary. Fixes #1900.
2020-08-04 13:08:50 +03:00
Given the grid
| 1 | | | 2 | | 3 |
| | 7 | | 8 | | |
| 4 | | 9 | 5 | | 6 |
And the named places
| osm | class | type | geometry |
| W1 | highway | road | 7, 8, 9 |
And the named places
| osm | class | type | admin | geometry |
| W10 | boundary | administrative | 5 | (1, 2, 8, 5, 4, 1) |
| W11 | boundary | administrative | 5 | (2, 3, 6, 5, 8, 2) |
When importing
Then place_addressline contains
| object | address | cached_rank_address |
| W1 | W10 | 10 |
Then place_addressline doesn't contain
| object | address |
| W1 | W11 |
Scenario: Locality points should contain all boundaries they touch
tests: use larger grid to avoid rouding errors
2020-08-22 17:04:24 +03:00
Given the 0.001 grid
be more strict what areas make up an address Exclude boundaries that touch a line in only one point and that touch areas only along the boundary. Fixes #1900.
2020-08-04 13:08:50 +03:00
| 1 | | | 2 | | 3 |
| | | | 8 | | |
| 4 | | | 5 | | 6 |
And the named places
| osm | class | type | geometry |
| N1 | place | locality | 8 |
And the named places
| osm | class | type | admin | geometry |
| W10 | boundary | administrative | 5 | (1, 2, 8, 5, 4, 1) |
| W11 | boundary | administrative | 5 | (2, 3, 6, 5, 8, 2) |
When importing
Then place_addressline contains
| object | address | cached_rank_address |
| N1 | W10 | 10 |
| N1 | W11 | 10 |
Scenario: Areas should not contain boundaries they touch
Given the grid
| 1 | | | 2 | | 3 |
| | | | | | |
| 4 | | | 5 | | 6 |
And the named places
| osm | class | type | geometry |
| W1 | landuse | industrial | (1, 2, 5, 4, 1) |
And the named places
| osm | class | type | admin | geometry |
| W10 | boundary | administrative | 5 | (2, 3, 6, 5, 2) |
When importing
Then place_addressline doesn't contain
| object | address |
| W1 | W10 |
Do not have postcode node appear in addresses directly Many of the postcode nodes are actually derived from incomplete addresses and are as such not even centroids. Better let them only take part in the address computation via the postcode table.
2018-07-22 17:22:07 +03:00
Scenario: buildings with only addr:postcodes do not appear in the address of a way
Given the scene admin-areas
And the named places
| osm | class | type | admin | addr+postcode | geometry |
| R1 | boundary | administrative | 6 | 112 | :b0 |
| R34 | boundary | administrative | 8 | 112 DE | :b1:E |
| R4 | boundary | administrative | 10 | 112 DE 34 | :b2:N |
And the named places
| osm | class | type | geometry |
| W93 | highway | residential | :w2N |
And the places
| osm | class | type | addr+postcode | geometry |
| W22 | place | postcode | 445023 | :building:w2N |
When importing
Then place_addressline doesn't contain
| object | address |
| W93 | W22 |
Scenario: postcode boundaries do appear in the address of a way
Given the scene admin-areas
And the named places
| osm | class | type | admin | addr+postcode | geometry |
| R1 | boundary | administrative | 6 | 112 | :b0 |
| R34 | boundary | administrative | 8 | 112 DE | :b1:E |
And the places
remove postcodes entirely from indexing place=postcode places are artificial places that collect addr:postcode points for aggration. They should neither show up in the address nor be searchable. That means that there is no need to index them at all. Only let boundary=postal_code through which define correct areas for postcodes.
2020-09-18 16:09:35 +03:00
| osm | class | type | addr+postcode | geometry |
| R4 | boundary | postal_code | 112 DE 34 | :b2:N |
Do not have postcode node appear in addresses directly Many of the postcode nodes are actually derived from incomplete addresses and are as such not even centroids. Better let them only take part in the address computation via the postcode table.
2018-07-22 17:22:07 +03:00
And the named places
| osm | class | type | geometry |
| W93 | highway | residential | :w2N |
And the places
| osm | class | type | addr+postcode | geometry |
| W22 | place | postcode | 445023 | :building:w2N |
When importing
Then place_addressline contains
| object | address |
| W93 | R4 |
add tests for address computation
2020-10-16 12:07:17 +03:00
Scenario: squares do not appear in the address of a street
Given the grid
| | 1 | | 2 | |
| 8 | | | | 9 |
| | 4 | | 3 | |
And the named places
| osm | class | type | geometry |
| W1 | highway | residential | 8, 9 |
| W2 | place | square | (1, 2, 3 ,4, 1) |
When importing
Then place_addressline doesn't contain
| object | address |
| W1 | W2 |
get address terms from address tags for rank 30 For rank 30 objects add extra elements into the place_addressline table.
2020-11-10 21:50:30 +03:00
Scenario: addr:* tags are honored even when a street is far away from the place
add test for placex from addr tags
2020-11-10 18:00:19 +03:00
Given the grid
| 1 | | 2 | | | 5 |
| | | | 8 | 9 | |
| 4 | | 3 | | | 6 |
And the places
| osm | class | type | admin | name | geometry |
| R1 | boundary | administrative | 8 | Left | (1,2,3,4,1) |
| R2 | boundary | administrative | 8 | Right | (2,3,6,5,2) |
And the places
| osm | class | type | addr+city | geometry |
| W1 | highway | primary | Left | 8,9 |
| W2 | highway | primary | Right | 8,9 |
When importing
Then place_addressline contains
| object | address | isaddress |
| W1 | R1 | True |
| W1 | R2 | False |
| W2 | R2 | True |
And place_addressline doesn't contain
| object | address |
| W2 | R1 |
get address terms from address tags for rank 30 For rank 30 objects add extra elements into the place_addressline table.
2020-11-10 21:50:30 +03:00
Scenario: addr:* tags are honored even when a POI is far away from the place
Given the grid
| 1 | | 2 | | | 5 |
| | | | 8 | 9 | |
| 4 | | 3 | | | 6 |
And the places
| osm | class | type | admin | name | geometry |
| R1 | boundary | administrative | 8 | Left | (1,2,3,4,1) |
| R2 | boundary | administrative | 8 | Right | (2,3,6,5,2) |
get additional addresses for rank 30 objects get_addressdata() now also checks if the place itself has entries in the place_addressline table and merges them into the results. Also restrict checking for address tag places to cases where the name cannot be found in the parent's address search terms. Looking up all address tags is just too slow.
2020-11-11 13:52:14 +03:00
And the places
| osm | class | type | name | addr+city | geometry |
| W1 | highway | primary | Wonderway | Right | 8,9 |
| N1 | amenity | cafe | Bolder | Left | 9 |
get address terms from address tags for rank 30 For rank 30 objects add extra elements into the place_addressline table.
2020-11-10 21:50:30 +03:00
When importing
Then place_addressline contains
| object | address | isaddress |
| W1 | R2 | True |
| N1 | R1 | True |
And place_addressline doesn't contain
| object | address |
| W1 | R1 |
switch BDD tests to always use search API
2021-06-06 16:27:52 +03:00
When sending search query "Bolder"
get additional addresses for rank 30 objects get_addressdata() now also checks if the place itself has entries in the place_addressline table and merges them into the results. Also restrict checking for address tag places to cases where the name cannot be found in the parent's address search terms. Looking up all address tags is just too slow.
2020-11-11 13:52:14 +03:00
Then results contain
switch BDD tests to always use search API
2021-06-06 16:27:52 +03:00
| osm | display_name |
| N1 | Bolder, Wonderway, Left |
get address terms from address tags for rank 30 For rank 30 objects add extra elements into the place_addressline table.
2020-11-10 21:50:30 +03:00
more tests for absense of additional addressline entries
2020-11-11 18:02:37 +03:00
Scenario: addr:* tags do not produce addresslines when the parent has the address part
Given the grid
| 1 | | | 5 |
| | 8 | 9 | |
| 4 | | | 6 |
And the places
| osm | class | type | admin | name | geometry |
| R1 | boundary | administrative | 8 | Outer | (1,5,6,4,1) |
And the places
| osm | class | type | name | addr+city | geometry |
| W1 | highway | primary | Wonderway | Outer | 8,9 |
| N1 | amenity | cafe | Bolder | Outer | 9 |
When importing
Then place_addressline contains
| object | address | isaddress |
| W1 | R1 | True |
And place_addressline doesn't contain
| object | address |
| N1 | R1 |
switch BDD tests to always use search API
2021-06-06 16:27:52 +03:00
When sending search query "Bolder"
more tests for absense of additional addressline entries
2020-11-11 18:02:37 +03:00
Then results contain
switch BDD tests to always use search API
2021-06-06 16:27:52 +03:00
| osm | display_name |
| N1 | Bolder, Wonderway, Outer |
more tests for absense of additional addressline entries
2020-11-11 18:02:37 +03:00
Scenario: addr:* tags on outside do not produce addresslines when the parent has the address part
Given the grid
| 1 | | 2 | | | 5 |
| | | | 8 | 9 | |
| 4 | | 3 | | | 6 |
And the places
| osm | class | type | admin | name | geometry |
| R1 | boundary | administrative | 8 | Left | (1,2,3,4,1) |
| R2 | boundary | administrative | 8 | Right | (2,3,6,5,2) |
And the places
| osm | class | type | name | addr+city | geometry |
| W1 | highway | primary | Wonderway | Left | 8,9 |
| N1 | amenity | cafe | Bolder | Left | 9 |
When importing
Then place_addressline contains
| object | address | isaddress |
| W1 | R1 | True |
| W1 | R2 | False |
And place_addressline doesn't contain
| object | address |
| N1 | R1 |
switch BDD tests to always use search API
2021-06-06 16:27:52 +03:00
When sending search query "Bolder"
more tests for absense of additional addressline entries
2020-11-11 18:02:37 +03:00
Then results contain
switch BDD tests to always use search API
2021-06-06 16:27:52 +03:00
| osm | display_name |
| N1 | Bolder, Wonderway, Left |
compute address parts for rank 30 objects on the fly Rank 30 objects usually use the address parts of their parent. When the parent has address parts that are areas but not marked as isaddress, then the parent might go through multiple administrative areas. In that case recheck if the right area has been choosen for the object in question instead of relying on isaddress. Note that we really only have to do the recomputation in the case of 'isarea = True and isaddress = False' which hopefully keeps the number of additional geometric operations we have to do to a minimum. There is one more special case to be taken into account here: a street may go through two administrative areas and a house along that street is placed in one of the area while the addr:* tags says it belongs to the other. In that case we must not switch the isaddress to the one it is situated. To avoid that recheck the address names against the name of the ara. That is not perfect but should cover most cases. Fixes #328.
2020-12-01 13:58:25 +03:00
Scenario: POIs can correct address parts on the fly
Given the grid
| 1 | | | | 2 | | 5 |
| | | | 9 | | 8 | |
| 4 | | | | 3 | | 6 |
And the places
| osm | class | type | admin | name | geometry |
| R1 | boundary | administrative | 8 | Left | (1,2,3,4,1) |
| R2 | boundary | administrative | 8 | Right | (2,3,6,5,2) |
And the places
| osm | class | type | name | geometry |
| W1 | highway | primary | Wonderway | 2,3 |
| N1 | amenity | cafe | Bolder | 9 |
| N2 | amenity | cafe | Leftside | 8 |
When importing
Then place_addressline contains
| object | address | isaddress |
| W1 | R1 | False |
| W1 | R2 | True |
And place_addressline doesn't contain
| object | address |
| N1 | R1 |
| N2 | R2 |
switch BDD tests to always use search API
2021-06-06 16:27:52 +03:00
When sending search query "Bolder"
compute address parts for rank 30 objects on the fly Rank 30 objects usually use the address parts of their parent. When the parent has address parts that are areas but not marked as isaddress, then the parent might go through multiple administrative areas. In that case recheck if the right area has been choosen for the object in question instead of relying on isaddress. Note that we really only have to do the recomputation in the case of 'isarea = True and isaddress = False' which hopefully keeps the number of additional geometric operations we have to do to a minimum. There is one more special case to be taken into account here: a street may go through two administrative areas and a house along that street is placed in one of the area while the addr:* tags says it belongs to the other. In that case we must not switch the isaddress to the one it is situated. To avoid that recheck the address names against the name of the ara. That is not perfect but should cover most cases. Fixes #328.
2020-12-01 13:58:25 +03:00
Then results contain
switch BDD tests to always use search API
2021-06-06 16:27:52 +03:00
| osm | display_name |
| N1 | Bolder, Wonderway, Left |
When sending search query "Leftside"
compute address parts for rank 30 objects on the fly Rank 30 objects usually use the address parts of their parent. When the parent has address parts that are areas but not marked as isaddress, then the parent might go through multiple administrative areas. In that case recheck if the right area has been choosen for the object in question instead of relying on isaddress. Note that we really only have to do the recomputation in the case of 'isarea = True and isaddress = False' which hopefully keeps the number of additional geometric operations we have to do to a minimum. There is one more special case to be taken into account here: a street may go through two administrative areas and a house along that street is placed in one of the area while the addr:* tags says it belongs to the other. In that case we must not switch the isaddress to the one it is situated. To avoid that recheck the address names against the name of the ara. That is not perfect but should cover most cases. Fixes #328.
2020-12-01 13:58:25 +03:00
Then results contain
switch BDD tests to always use search API
2021-06-06 16:27:52 +03:00
| osm | display_name |
| N2 | Leftside, Wonderway, Right |
Reference in New Issue Copy Permalink