New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Geolocation google maps api should be optional? #7
Comments
Hi Andy, FAO @andybroomfield |
Thanks @Adnan-cds |
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. |
I've created a ticket to move the contact paragraph type to use the LocalGov Geo entity #10. This should resolve this issue. |
Trying to enable the localgov_services_landing page in BHCC site installs quite a few dependencies based on localgov_paragraphs:
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 formcore.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.
The text was updated successfully, but these errors were encountered: