You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue:
Including the word 'Block' in an address (to report road accidents) is resulting in incorrect results. Specifically, the word 'Block' is being interpretted as a street name, and the actual street name is interpretted as locality garbage.
Example:
The following addressString provides a correct location based on the address range of that highway segment.
800 Trans-Canada Highway, West Vancouver, BC
The following addressStrings provide a location in a different locality.
800 Block Trans-Canada Highway, West Vancouver, BC
800 Blk Trans-Canada Highway, West Vancouver, BC
Task:
Is it possible to enhance the BC Address Geocoder to handle this use case without impacting other aspects of the parser?
The text was updated successfully, but these errors were encountered:
If the word "block" is something we wish to give special treatment we can totally do this, I think with causing only minor impact in cases where the word block or a word that could be misspelled as block is actually the street name (Brock St is one example provided by the results to the above queries). Possible a very minor 1 point penalty (or we had previously discussed fractions of a point, or some level of penalty that didn't show as a penalty but pushed things down in the sort order) would help to limit the impact.
Issue:
Including the word 'Block' in an address (to report road accidents) is resulting in incorrect results. Specifically, the word 'Block' is being interpretted as a street name, and the actual street name is interpretted as locality garbage.
Example:
The following addressString provides a correct location based on the address range of that highway segment.
The following addressStrings provide a location in a different locality.
Task:
Is it possible to enhance the BC Address Geocoder to handle this use case without impacting other aspects of the parser?
The text was updated successfully, but these errors were encountered: