-
-
Notifications
You must be signed in to change notification settings - Fork 164
Description
Describe the bug
I have a self-hosted instance of Pelias running in docker. I've identified a unexpected behavior when searching for an address with a unit number.
When i search for
658 Glen St, Edmonds, WA, USA
I get results from openaddresses
. The results come from two sources: us/wa/snohomish_county
and us/wa/snohomish
.
Example results:
"properties": {
"id": "us/wa/snohomish:e99defb40a47f1cb",
"gid": "openaddresses:address:us/wa/snohomish:e99defb40a47f1cb",
"layer": "address",
"source": "openaddresses",
"source_id": "us/wa/snohomish:e99defb40a47f1cb",
...
"label": "658 Glen Street, Edmonds, WA, USA"
},
"properties": {
"id": "us/wa/snohomish_county:0d812baf4a6952d8",
"gid": "openaddresses:address:us/wa/snohomish_county:0d812baf4a6952d8",
"layer": "address",
"source": "openaddresses",
"source_id": "us/wa/snohomish_county:0d812baf4a6952d8",
...
"label": "658 Glen St Unit 201, Edmonds, WA, USA"
},
...
These results differ from the https://api.geocode.earth and https://api.dev.geocode.earth, presumably because they are using an older version of the openaddresses sources for Snohomish, WA.
From the results we see, the address with unit 658 Glen St Unit 201, Edmonds, WA, USA
exists in the database.
When we search for it, we get no exact results. In contrast, when we run the same text against the autocomplete
api, we get correct results.
This is an example document from the ES Index:
address_parts.number:658 address_parts.street:Glen St Unit 101 address_parts.zip:98020 center_point:{ "coordinates": [ -122.372608, 47.814323 ], "type": "Point" } layer:address name.default:658 Glen St Unit 101 parent.country:United States parent.country_a:USA parent.country_id:85633793 parent.county:Snohomish County parent.county_a:SN parent.county_id:102087537 parent.locality:Edmonds, Seattle, Woodway parent.locality_id:101729915, 101730401, 101729921 parent.region:Washington parent.region_a:WA parent.region_id:85688623 source:openaddresses source_id:us/wa/snohomish_county:bbdb0b1bf9529290 _id:openaddresses:address:us/wa/snohomish_county:bbdb0b1bf9529290 _index:pelias _score:1 _type:_doc
When i debug the request with debug=1
i see that pelias is trying to apply the following filters:
{
"must": [
{
"match_phrase": {
"address_parts.unit": {
"query": "unit 101"
}
}
},
{
"match_phrase": {
"address_parts.number": {
"query": "658"
}
}
},
{
"match_phrase": {
"address_parts.street": {
"query": "glen st",
"slop": 4,
"analyzer": "peliasQuery"
}
}
}
]
}
But if we look at the document in the index, Pelias did not import the Unit 101
as a address_parts.unit
from openaddresses, but instead as part of the street name which is weird because nowhere in the openaddresses repo i could find a place where we concatenate the unit number to the street name.
Here's how the raw data looks from the openaddresses geojson:
{
"type": "Feature",
"properties": {
"hash": "6ebd0d2a50899152",
"number": "658",
"street": "GLEN STREET",
"unit": "101",
"city": "EDMONDS",
"district": "",
"region": "WA",
"postcode": "98020",
"id": ""
},
"geometry": {
"type": "Point",
"coordinates": [
-122.3727031,
47.8143613
]
}
}
Steps to Reproduce
https://pelias.github.io/compare/#/v1/search?text=658+Glen+St+Unit+101%2C+Edmonds%2C+WA%2C+USA
Add our environment as a host: https://pelias.databyte.so
Expected behavior
/search
should return results for address that has a unit number as part of the address.
Environment (please complete the following information):
Self hosted.
Minimal pelias.json configuration to replicate:
"imports": {
"adminLookup": {
"enabled": true
},
"openstreetmap": {
"download": [
{
"sourceURL": "https://download.geofabrik.de/north-america/us/washington-latest.osm.pbf"
}
],
"leveldbpath": "/tmp",
"datapath": "/data/openstreetmap",
"import": [
{
"filename": "washington-latest.osm.pbf"
}
]
},
"openaddresses": {
"datapath": "/data/openaddresses",
"files": [
"us/wa/snohomish.csv",
"us/wa/snohomish_county.csv",
]
},
"whosonfirst": {
"datapath": "/data/whosonfirst",
"importPostalcodes": true,
"countryCode": [
"US"
],
"importPlace": "102191575"
}
}
References
This issue might be connected to #1395 but it is the inverse behavior. the /search
api doesn't give correct responses, but the /autocomplete
does.