OS Places geocoder

[Adnan-cds]

Summary of code changes

• PHP Geocoder plugin for the OS Places API. This is the plugin File.
• Drupal Geocoder plugin for the OS Places API. This one is a Drupal specific wrapper for the above plugin.
• Further changes to the LocalGovAddress class to make room for OS specific fields (e.g. Building number, Organisation name, etc.)
• Improvements to how we prepare address line 1 and address line 2.

Test steps

• Testing this could be difficult as the OS Places API doesn't seem to have a free plan. But I could be wrong.
• Assuming you are in possession of an API key, Add the Localgov OS Places Geocoder plugin from /admin/config/system/geocoder/geocoder-provider
• Add the Localgov address lookup Webform element to any Webform. While configuring this Webform element, select the Localgov OS Places Geocoder plugin.
• Search for any postcode. Special ones like XM4 5HQ won't work as the OS Places API doesn't recognise these. But others should be fine.

Notes

• The OS Places API is returning All numeric grid references instead of latitude/longitude. So the latitude and longitude values for each address entry are empty. Easting and Northing Grid reference values are available as separate fields. Rich has pointed out that there are conversion algorithms available. And they are indeed available. We will have to implement that in a future ticket. This will allow us to populate the latitude and longitude values.
• The OS Places API is returning building numbers containing alphabets (e.g. 30B, 9B-5C) as Building names instead of Building numbers. This breaks the address formatting as I have placed Building names on the first address line and Building numbers on the second. This may need some further processing. I am thinking of leaving this for a later ticket. I hope that's acceptable.
• Ekes wanted the Geocoder plugin to be a stand-alone composer package and the Drupal Geocoder plugin to be part of the localgov_geo module. He has also just confirmed this in a comment below. I will take steps to relocate the relevant files to those repos in consultation with Ekes. This is done now.

@andybroomfield @andrew-wallis @ekes @finnlewis @MattOz-CDS @richardaclarke @tom-steel

[ekes]

The Geocoder plugin could be put somewhere on github - just as https://github.com/geocoder-php/bing-maps-provider for example, and could also make a PR on the geocoder-php project to include it - they do include several country specific plugin already. The linked plugin also gives an example of how they are testing them, by storing json responses and serving them as 'cached responses'.

The Drupal Geocoder plugin could stand alone too - and go on drupal.org - or again be a merge request against that project.

By making both of them separate it shouldn't slow things down waiting on PRs, but if they do get merged would be a bonus for everyone.

Changes to the address class - support for additional fields for example - might make sense in LocalGov Geo so that people can use it for the Address Entity and its address autocomplete too?

[Adnan-cds]

could also make a PR on the geocoder-php project to include it

Sure. So this will have to be a totally new repo rather than just a pull request. Something like https://github.com/geocoder-php/os-places. Wondering how to request a repo.

The linked plugin also gives an example of how they are testing them, by storing json responses and serving them as 'cached responses'.

+1 I will check.

The Drupal Geocoder plugin could stand alone too - and go on drupal.org - or again be a merge request against that project.

Yeah, if Laravel can have its own repo within the geocoder-php project then no reason why Drupal can't. Although it's just one file so I am slightly hesitant even to ask for a new repo :(

Changes to the address class - support for additional fields for example - might make sense in LocalGov Geo

I was thinking of keeping the LocalgovAddress class and the related LocalgovAdressInterface together with the OS Places Geocoder Provider plugin since the plugin relies on these. But it is possible you are referring to something different. Please let me know.

By making both of them separate it shouldn't slow things down waiting on PRs, but if they do get merged would be a bonus for everyone.

Okay, this one needs some thought. Does it mean we should:

• Merge this pull request first if it passes review.
• Request new repos under geocoder-php.
• Raise pull requests elsewhere as needed.
• Once all the new composer packages and pull requests are in place, localgov_forms should use those and drop the redundant files?

Or did you mean something different?

[Adnan-cds]

The linked plugin also gives an example of how they are testing them, by storing json responses and serving them as 'cached responses'.

I have added two test methods for the Ordnance survey geocoder that use this cached response-based approach. I have retained the previous pure Drupal test.

Composer is having issues grabbing the geocoder-php/provider-integration-tests package, I will sort it out next week.

[Adnan-cds]

Ready for testing. I had to explicitly instruct the test runner to grab dev dependencies. Do let me know if there is a better way of doing this.

[Adnan-cds]

Had a Merge Monday chat with Ekes and Steve about the structure of the OS Places API related code. For now, we have decided to:

• Move the OS Places Geocoder plugin file into its own localgovdrupal Git repo. We will eventually try to contribute it to the geocoder-php project.
• Move the OS Places Drupal Geocoder plugin (that wraps the above mentioned plugin) into the localgov_geo module. We will also try to contribute it to the Drupal Geocoder module.
• Require the above two from the localgov_forms module.

[Adnan-cds]

Ready for review once again now that localgovdrupal/localgov_os_places_geocoder_provider is housing our Ordnance Survey Places Geocoder. @andybroomfield @ekes @finnlewis

[ekes]

Makes sense, is just updating code to work with the new gecoder lookup.

[Adnan-cds]

Thanks for the approval. Merging...