Geolocation google maps api should be optional?

[andybroomfield]

Trying to enable the localgov_services_landing page in BHCC site installs quite a few dependencies based on localgov_paragraphs:

LocalGovDrupal Paragraphs, Telephone, Entity Usage, Geolocation - Google Maps API, Office Hours, Paragraphs Library, LocalGovDrupal Media, LocalGovDrupal Topics, LocalGov Services: Navigation, Localgov Page Components, Entity Browser IEF, Inline Entity Form modules to install LocalGov Services: Landing page

Since BHCC will not be using Google Maps, is there a reason that has to be enabled?

• core.entity_form_display.paragraph.localgov_contact.default.yml contains config for Google maps on the form
• core.entity_view_display.paragraph.localgov_contact.default.yml contains config for Google maps to display.

Ideally, these should be optional for those that don't use Google maps, becoming avalible when the Google maps plugin gets installed. This allows BHCC to swap out this for our Esri / OSM solution.

[Adnan-cds]

Hi Andy, Yes, Open Street Map is the default solution for mapping in LocalGov. Because the Contact Paragraph has been copied into LocalGov more or less unchanged, it is still stuck in Google maps which is how we built it here in Croydon. We will have to swap Google maps with OSM in Contact Paragraph as part of this ticket.

FAO @andybroomfield

[andybroomfield]

Thanks @Adnan-cds I think it will be the case that some councils will use Google maps, and others their own. I still see ours as being different as we tend to use Openlayers with a push to use Esri, rather than Leaflet which has better Drupal support. It comes down to each council site preferences hence my question on if this should be required or in optional.

[ekes]

That was the intention for building the geo module. The Googlemaps modules are inflexible in the sense that they can't be swapped and plugged. While the geocoder, geofield, leaflet combination are more complicated to configure UI wise they leave the opportunity that the backends (and maps) can then be swapped without further complexity. My assumption was always that the googlemap paragraph type would be swapped for the geo entity.

OH! Addition: It's also not the expectation that people will use OSM Nominatim for Geocoding in production, it's way too clunky in search and often missing data in the UK, but it is the easiest to package as an example as it doesn't require an API key. It really should be swapped for something with more free search, and data, in actual production.

[stephen-cox]

I've created a ticket to move the contact paragraph type to use the LocalGov Geo entity https://github.com/localgovdrupal/localgov_paragraphs/issues/10. This should resolve this issue.