Include interface for searching for a place name or address in Cesium

[robyngit]

Cesium includes an optional widget for searching for a location by address or name, and then navigating to the searched-for location. To enable this, we'll need a key for one of the Geocoder services

[robyngit]

Also look into using the GNIS database for U.S. placenames, and geonames for places outside the U.S.

[robyngit]

We have a list of placenames that we are going to add as a layer to the PDG. It would be great to incorporate these into the places search, see PermafrostDiscoveryGateway/pdg-portal#5

[robyngit]

From #2229 (duplicate):

PDG and other portals would be more usable if users could search for and zoom to specific places, such as named local communities, rivers, and other relevant places. This was discussed and raised at the PDG mini-workshop. Need to develop out the ideas here, this ticket is just a placeholder.

One issue is we would need to be able to search place-name to location gazeteers, such as GNIS (see https://gnis-ld.org/ that we run, and https://geonames.org/).

[ianguerin]

I've outlined a recommendation in a Google doc exploring various geocoder APIs. With input from Matt, Robyn, and Yvonne, we've elected to go with the Google Maps API. Below is a summary of the discussion had there in the case that this Google doc is no longer reachable.

There are a few reasons we've chosen this API. It supports international place name geocoding, it is an industry standard that we (MetacatUI) are already integrated with for using the Google Maps UI component, there's no additional server-side setup, and the story for integrating with the Places API for generating place name autocomplete suggestions similarly ought to be easy given the expected compatibility between Google APIs.

In the discussion we also noted that the desire to search for local Arctic place names may become a challenge with Google API place names, so we should implement this integration in such a way that if we need to migrate to a different third-party service it is impossible or even very difficult.

[mbjones]

Thanks, @ianguerin -- great summary. For the local place names not found in the Google Maps API, another option might be to enable searching two or more services in parallel and merging the results. GMaps will likely cover 99%+ of our needs. Being able to merge in a few results from some local placename datasets would probably cover the local edgecases, if we could do that efficiently. I gave some examples of those in the gdoc.

[ianguerin]

In the case of multiple data sources, I think we will want to create a single API that fans out to call the separate data sources. That limits the number of outgoing requests for our users and will keep the FE code simple

[ianguerin]

Here's a quick outline of engineering design.

Essentially we are integrating with Google Maps Places Autocomplete and Google Maps Geocoder APIs. This will build off of the work done to support searching by latitude and longitude in the forthcoming "viewfinder" toolbar view.

[robyngit]

@ianguerin, great job on the design doc for the viewfinder places search! Just a couple of things I wanted to clarify:

1. Will the viewfinder model be independent of the map view and map model? I'm wondering if it could be used anywhere in our UI for place name searches, not just tied to the map.

2. Regarding the integration with Google Maps API and future geocoding services, is there a separate model planned for these APIs, or how do you envision this integration? Specifically, I'm curious about how we might make it easy to configure and swap between different geocoding services in the future.

[ianguerin]

1- Yes, I'll create a viewfinder model (that could be renamed/moved in future for reuse) that takes an input and returns a list of GeoPoints + plus some display metadata.

2- I am planning to use the same, new, Viewfinder model. Would you suggest having a GoogleMapsApi model?

[robyngit]

2- I am planning to use the same, new, Viewfinder model. Would you suggest having a GoogleMapsApi model?

I think there are multiple good approaches here. Whatever the design in the end, it should take into account two situations that we'd like to avoid:

1. the Viewfinder model growing overly complex (like some of our existing models) as we continue integrating more and more services in the future.
2. the Viewfinder model becoming too closely integrated with the GMaps API, making it difficult to switch providers in the future.

One approach could involve some sort of generic GeoCoderService model that acts as an extensible template for any service we use, and serves to standardize how other models/views interact with those services. So the GoogleGeoCoderService would be an extension of the base GeoCoderService. The Viewfinder model could do the work of instantiating, configuring, and orchestrating getting results from the various GeoCoderServices. No need to follow this idea specifically. I just think it would be useful to have a clear separation of concerns between the Viewfinder and the GMaps API. What are your thoughts on this?

[ianguerin]

I agree with not wanting to make Viewfinder model overly complex. I would argue that integrating with more services should necessitate creating a new API endpoint so that the user's browser only emits a single API call. In this way we can aggregate the search results on the backend before returning a result to the user. In this way, Viewfinder model should only ever be integrating with a single API.

I understand the concern of making Viewfinder model too closely integrated with a specific API, I think it makes sense to create a separate model for Google Maps integration, one which returns a model, lets call it Place that will contain a GeoPoint and other metadata and will persist even if we decide to adopt a different or multiple geocoding APIs in the future.

[yvonnesjy]

Documenting the following fixes that we will implement as a part of the April release (R1):

• Update active state when focused on search field. Bug report
• Update search button after typing into the search field. Bug report
• Style autosuggest buttons and add hover state. Bug report
• Add clear button (x) to the search field. Persist the search button in all cases. New mock. Bug reports
• Reset error message in lat/long search. Bug report