4 ms·

has anyone used this information to make something with hex grids? I first saw this page years ago, when considering a hex grid-based game design, and, despite

has anyone used this information to make something with hex grids? I first saw this page years ago, when considering a hex grid-based game design, and, despite the page's excellent information, my takeaway was: eh, too complicated, not worth it.

culebron21 3y ago
I wrote my heatmaps & isochrone polygons based on this page 4 years ago, with Python & GeoPandas.[1] It was rather easy, and didn't damage performance. But looking back, it wasn't worth the hassle. Because what's the advantage of hex, apart from looking unusual? If you have, let's say, a road on a map, and some heatmap should highlight it, then cells of rectangular heatmap are going to be like low-res pixel art -- only in 2 directions it coincides with cells and looks nice. Well, with hex grid you have +50% of such directions. Uber's H3 advocates insist there's also exactly the same distance between cells centroids. Well, that's all advantages. Anti-bonus of hexgrid: you can't aggregate it. Hexagons don't sum up into bigger hexagons. [1] https://github.com/culebron/erde/blob/master/erde/op/isochrone.py https://github.com/culebron/erde/blob/master/erde/op/isochro...
- dragonwriter 3y ago
  > Anti-bonus of hexgrid: you can't aggregate it. Hexagons don't sum up into bigger hexagons. They don't nest perfectly the way squares do, but if you rotate at alternate levels they have a decent approximate 7-in-1 nesting that H3 leverages.
  - culebron21 3y ago
    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.
    - dragonwriter 3y ago
      > 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.
      - culebron21 3y ago
        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.
        dragonwriter 3y ago
        > 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.)
- nologic01 3y ago
  Its a good question but I suspect the answer depends on your context. I have seen hex grids used a lot in approximating geographic contours. Its possible that for a given number of cells they do better approximations than a regular, but one would need to check this mathematically
- adamrezich 3y ago
  one interesting use of hex grids I came across is Sunset Overdrive's implementation of a streaming open-world system: https://www.gdcvault.com/play/1022268/Streaming-in-Sunset-Overdrive-s https://www.gdcvault.com/play/1022268/Streaming-in-Sunset-Ov... hexagons are closer to circles than squares are, so they define chunks of the world as circles (positional coordinates for stuff in the chunk are offset from the center of the circle), packed in a hex grid. they explain the rationale more in the video, but if I remember correctly it just kinda makes a lot of sense given that a.) Sunset City's layout isn't very square-grid-based, and b.) it reduces the number of chunks per concentric "LOD layer" surrounding the chunk the player presently occupies (6 instead of 8 for the first layer, etc.)

culebron21 3y ago

I wrote my heatmaps & isochrone polygons based on this page 4 years ago, with Python & GeoPandas.[1] It was rather easy, and didn't damage performance. But looking back, it wasn't worth the hassle. Because what's the advantage of hex, apart from looking unusual? If you have, let's say, a road on a map, and some heatmap should highlight it, then cells of rectangular heatmap are going to be like low-res pixel art -- only in 2 directions it coincides with cells and looks nice. Well, with hex grid you have +50% of such directions. Uber's H3 advocates insist there's also exactly the same distance between cells centroids. Well, that's all advantages. Anti-bonus of hexgrid: you can't aggregate it. Hexagons don't sum up into bigger hexagons. [1] https://github.com/culebron/erde/blob/master/erde/op/isochrone.py https://github.com/culebron/erde/blob/master/erde/op/isochro...

dragonwriter 3y ago
> Anti-bonus of hexgrid: you can't aggregate it. Hexagons don't sum up into bigger hexagons. They don't nest perfectly the way squares do, but if you rotate at alternate levels they have a decent approximate 7-in-1 nesting that H3 leverages.
- culebron21 3y ago
  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.
  - dragonwriter 3y ago
    > 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.
    - culebron21 3y ago
      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.
      - dragonwriter 3y ago
        > 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.)
nologic01 3y ago
Its a good question but I suspect the answer depends on your context. I have seen hex grids used a lot in approximating geographic contours. Its possible that for a given number of cells they do better approximations than a regular, but one would need to check this mathematically
adamrezich 3y ago
one interesting use of hex grids I came across is Sunset Overdrive's implementation of a streaming open-world system: https://www.gdcvault.com/play/1022268/Streaming-in-Sunset-Overdrive-s https://www.gdcvault.com/play/1022268/Streaming-in-Sunset-Ov... hexagons are closer to circles than squares are, so they define chunks of the world as circles (positional coordinates for stuff in the chunk are offset from the center of the circle), packed in a hex grid. they explain the rationale more in the video, but if I remember correctly it just kinda makes a lot of sense given that a.) Sunset City's layout isn't very square-grid-based, and b.) it reduces the number of chunks per concentric "LOD layer" surrounding the chunk the player presently occupies (6 instead of 8 for the first layer, etc.)