Do not trigger an error when non point geometries have aggregation options

[elenatorro]

Project: https://github.com/CartoDB/product/issues/30

• Related issues: Add default point aggregation cartodb#13683
• Discussion: First approach to add aggregation options to CartoDB layers cartodb#13718

We are discussing in this PR how to enable default point aggregation in builder/cartodb.js. There is no way to know the geometry before sending a layer to Windshaft, and as we are sending aggregation options, we are receiving an error when the geometries are not points.

In order to make it transparent to the user, we may not need to receive an error when aggregation options are sent for a non point geometry. Instead, Windshaft could just ignore the aggregation.

[ivanmalagon]

As @elenatorro said, we're adding the default server aggregation to Builder. We'd need Windshaft not to return an error when the default aggregation is taking place. If you find any problem with this approach, one option could be to swallow the error only in the default aggregation is set.

Perhaps instead of an error, you could add some information back in the map instantiation endpoint about if the layer was not aggregated and why.

[alonsogarciapablo]

@ramiroaznar can the RT (@enekid?) take a look at this to unlock @elenatorro 🙏 ?

[dgaubert]

Despite we can avoid returning the error and add info back in the map instantiation without much effort, we are not going to do that, it's returning an error by design and it's the right behavior. Basically, whoever wants to aggregate a layer needs to know what kind of geometry that layer has.

From the point of view of Builder, we already know when a layer has points and then applies the right style for points when creating a new map. From carto.js point of view, anyone building an application should know this kind of info (geometry type, dataset, query, etc..) and create maps with the options based on this.

Maybe the problem is bigger than we thought initially, enabling aggregation by default for new and existing maps raises a lot of open questions:

• What happens with dataviews? Aggregation may change completely the dataview. For instance: a category dataview shows 3 different categories before aggregating and just 1 category after aggregation.
• Same with Turbo-CARTO: a map could be rendered in a totally different way because the colors applied before aggregation is going to change after applying aggregation because of the calculated steps/bins are different.
• Legends?
• Pop-ups?
• ...

[alonsogarciapablo]

Ok. Closing this for now.

[alonsogarciapablo]

Reopening this after this comment from @rochoa:

Although it's far from ideal, I'm OK with your proposal about telling the Maps API to try to aggregate a layer —this requires changes in the Maps API— when not knowing in advance the geometry type.

We basically need it to be able to enable Default Point Aggregation in Builder soon.

cc: @dgaubert @jgoizueta @ivanmalagon