Which makes no sense if you work with aggregated data, because your summed aggregations start to deviate from direct ones. You have to basically aggregate the entire dataset of millions of rows again and again for each level, instead of just doing a group-by at lowest level once, and then grouping the groups (which are just thousands).

If you have H3 and several million records, every aggregation takes noteable amount of time.

It also means that you must keep those indice for each record for each level. Because the parent function gives wrong cell for points on the fringe.

> Which makes no sense if you work with aggregated data, because your summed aggregations start to deviate from direct ones.

It depends on the purpose of the aggregation; if you are aggregating based on logical containment and using a consistent grid level for deciding the canonical location, this isn't an issue; if you are doing "aggregation" by doing strict geographical lookup for each datapoint at the grid level of the "aggregate", then it is an issue, but that is not actually an aggregation, that's a separate basic bucketing at each resolution level (though it may be the sensible way to handle data for a particular application.)

In essence, you can use an H3 index at one level as a reference to particular polygon or an a reference to the aggregate of polygons on specified level which are logically contained within it, and which makes sense depends on the application.

It is a true, and a disadvantage for some uses, that these are necessarily different interpretations, and you have to choose and apply one, whereas with lat/long or S2, geographical and logical containment are identical.

The purpose of aggregation is quite simple -- it has to show which area has which amount of some objects/properties. And it must be mathematically consistent.

If a cell is said to be a sum of 7 underlying cells, then their sum of objects must equal to this cell's sum of objects, which is not the case in H3.

You can just hope that the diff of these values is within acceptable limits, and that company management never tries to drill down into your data, and does not put all the blame for some incorrectness on you.

So, even though H3 cells kinda add-up, they actually don't, and you have to either just plainly hope, or take care of data, as I decided to do.

You'd never had this dilemma, nor need to cure the data, with a rectangular grid in either UTM projection, or Google pseudo-Mecrator, both of which preserve horizontal/vertical aspects and are perfect for such aggregative cell grids.

> If a cell is said to be a sum of 7 underlying cells, then their sum of objects must equal to this cell's sum of objects, which is not the case in H3.

If you are using an H3 index as an index to the aggregate of the logically-contained cells at some specified level, it absolutely is true (in this case, the exact geographic border is the border of the set of contained cells ay thr specified level, not the border of the higher-level cell specified by the index.)

But yes, "depending on the purpose" -- probably, to show something to layman users, like external partners, who'd unlikely drill down into particular numbers, and would be excited to see something techy-fancy-looking, it's ok to show a heatmap based on H3.