Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] GeoHexGrid Aggregation based on H3 discrete grid system on geo_points #98

Closed
VijayanB opened this issue Jul 26, 2022 · 2 comments
Assignees
Labels
enhancement New feature or request geospatial roadmap v2.4.0 'Issues and PRs related to version v2.4.0'

Comments

@VijayanB
Copy link
Member

Is your feature request related to a problem?
H3 geospatial indexing system is a discrete global grid system similar to geohash and geotile. This grid system partition the earth into hexagons. OpenSearch maps can accommodate datasets that relies on H3 grid for indexing and visualization.

What solution would you like?
Aggregate geo_points based on H3 grid system similar to geo tile which uses map tile.

What alternatives have you considered?
N/A

Do you have any additional context?
N/A

@VijayanB
Copy link
Member Author

Support aggregation using H3 grid for geo_point field

Summary

OpenSearch Dashboard Coordinate maps can aggregate documents based on the GeoHash grid. Uber introduced a new grid system H3, which partitions Earth's areas into identifiable hexagon-shaped cells that works well for proximity applications. Because the H3 overcomes the shorting comings of Geohash's non-uniform partition, it makes a better choice for proximity applications. GeoHash encodes latitude and longitude pairs leading to significantly smaller partitions near the poles and a degree of longitude near the equator.

The H3 grid system's distortions are low and limited to 5 partitions of 122. These five partitions are placed in low-use areas, i.e, In the middle of the ocean, leaving the essential areas error-free. Hence, grouping documents based on this grid system will provide better aggregation than the Geohash grid.

What / Why

What are you proposing?

The geohex_grid aggregation groups geo_point into grid for geographical analysis. Each grid corresponds to a H3 cell and is identified using the H3Index representation.

OpenSearch currently supports only geohash_grid and geotile_grid aggregation. This feature will add new additional grid system for users to perform bucket aggregation.

What users have asked for this feature?

  1. H3 Grid is better suited for proximity applications with faster computation, visualization, and analytics. You can find more information here.
  2. H3 cell representation offers better performance, high resolution, and more straightforward encoding for over-the-wire communication. More details on encoding can be found here.

What problems are you trying to solve?

When grouping geospatial documents, grid systems are critical to analyzing large spatial data sets, so instead of analyzing at the finest granularity, with exact location using lat/lon points which are very difficult and expensive, they can be analyzed on areas, that are much more practical and efficient.

What is the developer experience going to be?

Users can aggregate documents with geo_points based on H3 grid for given precision. A new aggregation type will be created to aggregate documents based on H3 grid cell similar to geohash_grid and geotile_grid.

# It supports both GET and POST
POST "testindex1/_search"
{
    "aggs" : {
        "grouped" : {
            "geohex_grid" : {
                "field" : "geo_point_field_name",
                "precision" : 1 # H3 precision value
            }
        }
    }
}

@VijayanB
Copy link
Member Author

VijayanB commented Nov 1, 2022

Code is merged and will be released in 2.4

@VijayanB VijayanB closed this as completed Nov 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request geospatial roadmap v2.4.0 'Issues and PRs related to version v2.4.0'
Projects
None yet
Development

No branches or pull requests

1 participant