Handling similar locality names with matchPrecision=LOCALITY

[BK01]

Issue: When using Geocoder 4.2 and specifying matchPrecision=LOCALITY there may be cases where an incorrect (but similar) locality name is found.

Example: The following request results in a tie between 'Vancouver, BC' and 'West Vancouver, BC'. The first result is listed as 'Vancouver, BC'. Moving right-to-left within the original addressString 'Vancouver, BC' appears to be a correct match, but continuing further to the first word in the locality name matches to 'West Vancouver'.

addressString = 1488 Palmerston Ave, West Vancouver, BC fullAddress = Vancouver, BC

https://geocoder.api.gov.bc.ca/addresses.json?addressString=1488%20Palmerston%20Ave,%20West%20Vancouver,%20BC&matchPrecision=LOCALITY&maxResults=2

Task: Investigate options to handle cases where a locality name contains multiple words (West Vancouver) where one word could be a separate locality (Vancouver) and matchPrecision=LOCALITY is used.

[cmhodgson]

Why is this query using matchPrecision=LOCALITY when the input is a full address? If you only want to know the locality of the best match, do a normal query, with no matchPrecision restriction, and then just look at the locality field of the best answer.

The problem isn't just that West Vancouver has multiple words, but that the first word is of the right type and in the right position to be interpreted as the directional of the street name, ie. 1488 Palmerston Ave West, Vancouver BC

By specifying the matchPrecision=Locality, you are specifically telling the geocoder to ignore any information about the street that is in input, and because the "west" could be part of the street, it can then be optionally ignored.

[BK01]

Thanks for taking a look. The example above was an edge-case test attempting to acquire the locality coordinates from an existing complete civic address (from a list). This worked well for most tests, but the inclusion of 'West' complicated the search. Since it's not a common approach, the alternative could be to instead as you mention, complete a civic address search using addressString only, then acquire the localityName from the response and geocode that value (or pre-process your address list and just submit the locality name). If a list of locality only names is available, provide them as addressStrings and validate the response which will show the localityName and matchPrecision.