Polygon map search results

[camdendotlol]

Summary

Currently, the map search in Core Data only allows us to select points. This makes sense for cities, but not for countries or regions. Users should be able to connect a Place record with a full polygon on the map and then view that polygon on the map in core-data-places.

Plan

The behavior of the main example on the MapTiler website is almost exactly what we want to implement.

1. Go to https://www.maptiler.com/maps/#style=streets-v2&lang=auto&mode=2d&position=1.57/52.2/0.3
2. Search "iceland"
3. MapTiler makes an API call to https://api.maptiler.com/geocoding/iceland.json, which contains search results for the term iceland. Each search item from this endpoint contains a) a point in the center of the country's capital, and b) four coordinates for a bounding box that's also not very useful. The search data does not include polygons, and as far as I can tell there's no way to get them directly from a search request.
4. Click the first country result for Iceland.
5. MapTiler uses the id field from the search item to make another API request, this time a direct ID lookup: https://api.maptiler.com/geocoding/country.42.json (country.42 is the ID). This response includes full geographical data, including all the points in a polygon of the country's borders.
6. MapTiler uses the data from the direct lookup endpoint to plot the borders on the map. Note that the point remains on the map too - we may or may not want to keep it there.

Steps 5-6 are the parts that Core Data doesn't do, and the ones we want to add.

Core Data Cloud and react-components

The MapDraw component from react-components has an onGeocodingSelection prop that I think will allow us to handle steps 5-6 from within Core Data Cloud, without requiring changes to react-components. However, react-components might require a small PR if my understanding of that prop is incorrect or if e.g. it expects the function to be synchronous.

Core Data Places and Typesense

See https://pan-african-data-project.netlify.app/en/map/#/&map=4.21/28.27/-3.48

I manually drew a polygon around Algeria to see how well Core Data Places handles it. Like Derek said in our meeting, the Typesense index only includes the central point and not the polygon. But when you click on Algeria in the list, the data is fetched from Core Data and you can see the polygon.

This status quo might be okay? The search result map would look really busy with tons of polygons on it. Storing the center point of a country in the Typesense index and then fetching the full polygon from Core Data makes sense to me, so we might not need to make changes to Core Data Places or to the way that core-data-connector indexes places.

[dleadbetter]

On the Core Data Cloud side, it looks like the MapDraw component already has a "geocoding" prop that accepts either "point" or "polygon". The Core Data Cloud client hard codes this to "point", so we always get a lat/lng back. It should be possible to set this prop by exposing an input to the user to allow them to select "point" or "polygon". The default should be "point" as to not change the default behavior.

The Typesense index should include a geometry property which is the full GeoJSON of whatever was draw/input into the MapDraw component in Core Data. However I agree that bunch of overlapping polygons on a map probably won't be very useful. In certain situations it would probably look okay, for example, very few non-overlapping polygons. If this is a valid use case, we could probably add a configuration option to core-data-places to pull the map data from either the coordinates or geometry properties. The default should be coordinates as to not change the default behavior.

[camdendotlol]

Sounds good. So it seems like the first thing I should focus on for Monday is adding that toggle to the component on Core Data Cloud, and maybe discuss with Jamie/Ben/Rebecca on Slack to determine whether any projects would need polygons in their search results?

I wonder if we should automatically use polygons for countries/regions and points for cities/addresses without making the user toggle between them. It's possible that >99% of users will expect cities to be points and countries to be polygons, making the manual toggle feel tedious.

[dleadbetter]

Sounds good. So it seems like the first thing I should focus on for Monday is adding that toggle to the component on Core Data Cloud, and maybe discuss with Jamie/Ben/Rebecca on Slack to determine whether any projects would need polygons in their search results?

That sounds good to me. With more developers coming onto Core Data, I'm hoping to have us all follow a process for moving issues through development/testing. I'd like to keep high-level concepts and discussion separate from the actual dev tasks. Could you convert this issue into an epic and add issues in the core-data-cloud and core-data-places repos for the specific features we want to implement?

I wonder if we should automatically use polygons for countries/regions and points for cities/addresses without making the user toggle between them. It's possible that >99% of users will expect cities to be points and countries to be polygons, making the manual toggle feel tedious.

I think this is probably fine if it's simple enough to do. Depending on the type of project and the source data, I could see situations where users may only want coordinates regardless of the type of place. I think defaulting to points/polygons are you described above is fine as long as users have a may to override if necessary.