[RFC] Support for Drop a Pin about carto-react

[alasarr]

Kind of related to the comparison mode and #482 (comment).

I feel we should add some kind of new concept in carto for react, some kind of custom views that includes a preset of layers and widgets

[efernandezleon]

Breaking news from today

[efernandezleon]

After some conversation and a bit of analysis with @thedae , I'm going to summarize all the data I have and some of my thoughts in terms of proposals and recommendations:

The use case for this feature seems clear. Basically, the user clicks on a point in the map and the app will show a sidebar with some widgets showing the data for the catchment area. In addition, the user will be able to select how the catchment area is calculated (size of the buffer area, time for the isochrone, etc). This is the basic use of this feature, the thing turns complex when through this feature we want to cover the comparative mode (#479). In this scenario, the issue comes because the different points and their area can be in different locations, very far from others, not allowing the use of the current implementation based on the viewport to get the features.

With that, we have the following subcases:

Single drop a pin

This is the very basic use of this feature. The API will provide a React component to be used in the C4R app, and different widgets will take their data through a spatial filter based on the viewport. I think, there is no challenge here to do that.

An example of the widget declaration can be as follow:

<DropAPinWidget // or DropAPinView
    source='assets' // the base source that activates this feature when the user clicks on
    methods=['buffer','isoline','isochrone'] // more config related with how this component will work
/>

The declaration of this component will draw the following UI element and the app will show a sidebar with the widgets.

Multiple drop a pin

This is the complex use of this feature that includes multiple catchment areas and where each one provide data to different widgets. The alternatives to accomplish this feature in terms of getting the data are:

1. Use a custom method in frontend to get the data from the different layers for the different areas. Even when this is the easiest method, this was discarded because in case you want to compare catchment areas that are in different location, the data linked to the viewport will cause the widgets showing data from different areas will be dropped due to they might not be located in the current viewport.

2. Use a backend side endpoint to get the data for the different widgets. These endpoints will work in the same way that the ones for models like formula, category, etc, but will receive a geometry to perform a spatial filter. The way this geometry is sent can follow the following strategies:

• Send the geometry as a GeoJson in the request. The pros of this method is that the operation is completely stateless and the geometry will travel every time in the request, in addition, the implementation in backend side is not very complex and only an intercept-like method should be provided in the SQL. The cons are related to the cache; if the GeoJson is too complex, this geometry will be in the payload in a POST request which cause the request won't be cached.

• Send the configuration to recreate the area. The idea behind of this is basically to send the parameters to calculate the area in backend, that means that instead of sending the geometry of the isochrone, this method will send the parameters to recreate the isochone, ie "isochrone in this lat/long for drive time of 15mins". The backend will use AT or LDS to calculate the isochrone and perform the intercept in the SQL. The cache issue in the previous strategy is solved because of the lenght of these parameters, but it introduces a complex implementation in backend that needs to add all the responsabilitites related to the area creation and management.

• Send the ID and a table name that holds the geometry. In this method, the frontend side will calculate the area and will store in the remote data warehouse (ie. CDW) and will send the ID and the table name to the request to help the backend to perform the intercept. The good point in this method is the reuse the geometries and not recalculate them every time, to cons is the management of creation of all this data from the frontend side adding possible permissions issues to this problem.

Apart of these methods to send the geometry, the backend strategy faces the challenge of how to send multiples areas for multiples widgets. In a tipical case of 3 areas to be compared and 5 widgets, this will need 15 requests to show the comparative data in the widgets.

3. Store the values of the first catchment area and compare them with the following analysis. In this strategy, every time the user click on the button "Compare next", the current state of the widgets will be stored in frontend side and the next catchment area data will be calculated by following the same strategy through a kind of spatial filter based on the viewport. With this method, the problem in the point 1 is solved because previous data is stored somewhere in the frontend side to be shown in the widgets. I think, we can go deeper in this strategy because it was discarded taking into account the current implementation of the spatial filter and how works with the viewport, but we can split the implementation of the comparative widget to unlink the data from the viewport for catchment areas that have been already calculated.