After https://github.com/pelias/api/pull/1622, which extends the boundary.country API parameter to include the dependency placetype, we noticed that venue and address records often have a 2-character country code when they are part of a dependency.
The boundary.country parameter currently checks only for 3-character codes, and so the best solution is to ensure the relevant property on all records in Elasticsearch is a 3-character country code whenever possible.
This change expands on the logic for selecting an abbreviation for an admin record to be used for point in polygon lookup. Logic specific to countries is expanded to include dependencies, and some additional possible fields that might contain 3-character codes are checked.
Because the abbreviation logic is now a bit more substantial, it's extracted into its own function. It's also been made a bit less redundant and hopefully more clear.
After https://github.com/pelias/api/pull/1622, which extends the
boundary.countryAPI parameter to include thedependencyplacetype, we noticed that venue and address records often have a 2-character country code when they are part of a dependency.The
boundary.countryparameter currently checks only for 3-character codes, and so the best solution is to ensure the relevant property on all records in Elasticsearch is a 3-character country code whenever possible.This change expands on the logic for selecting an abbreviation for an admin record to be used for point in polygon lookup. Logic specific to countries is expanded to include dependencies, and some additional possible fields that might contain 3-character codes are checked.
Because the abbreviation logic is now a bit more substantial, it's extracted into its own function. It's also been made a bit less redundant and hopefully more clear.