-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
GeoLine Aggregation #41649
Labels
:Analytics/Geo
Indexing, search aggregations of geo points and shapes
>feature
Team:Analytics
Meta label for analytical engine team (ESQL/Aggs/Geo)
Comments
talevy
added
>feature
:Analytics/Geo
Indexing, search aggregations of geo points and shapes
labels
Apr 29, 2019
Pinging @elastic/es-analytics-geo |
@talevy is this still something we're prioritizing after geo_shape aggs? |
@alexfrancoeur Yes. I will continue to work on this after geo_shape aggs makes it to the finish line! |
@talevy i am dying for this feature, please let me know if i can help writing some code. thanks ! |
Hi! Any news on this feature? Really useful for our use case here! Regards., |
rjernst
added
the
Team:Analytics
Meta label for analytical engine team (ESQL/Aggs/Geo)
label
May 4, 2020
talevy
added a commit
that referenced
this issue
Nov 23, 2020
A metric aggregation that aggregates a set of points as a GeoJSON LineString ordered by some sort parameter. #### specifics A `geo_line` aggregation request would specify a `geo_point` field, as well as a `sort` field. `geo_point` represents the values used in the LineString, while the `sort` values will be used as the total ordering of the points. the `sort` field would support any numeric field, including date. #### sample usage ``` { "query": { "bool": { "must": [ { "term": { "person": "004" } }, { "term": { "trajectory": "20090131002206.plt" } } ] } }, "aggs": { "make_line": { "geo_line": { "point": {"field": "location"}, "sort": { "field": "timestamp" }, "include_sort": true, "sort_order": "desc", "size": 15 } } } } ``` #### sample response ``` { "took": 21, "timed_out": false, "_shards": {...}, "hits": {...}, "aggregations": { "make_line": { "type": "LineString", "coordinates": [ [ 121.52926194481552, 38.92878997139633 ], [ 121.52922699227929, 38.92876998055726 ], ] } } } ``` #### visual response <img width="540" alt="Screen Shot 2019-04-26 at 9 40 07 AM" src="https://user-images.githubusercontent.com/388837/56834977-cf278e00-6827-11e9-9c93-005ed48433cc.png"> #### limitations Due to the cardinality of points, an initial max of 10k points will be used. This should support many use-cases. One solution to overcome this limitation is to keep a PriorityQueue of points, and simplifying the line once it hits this max. If simplifying makes sense, it may be a nice option, in general. The ability to use a parameter to specify how aggressive one wants to simplify. This parameter could be the number of points. Example algorithm one could use with a PriorityQueue: https://bost.ocks.org/mike/simplify/. This would still require O(m) space, where m is the number of points returned. And would also require heapifying triangles sorted by their areas, which would be O(log(m)) operations. Since sorting is done, anyways, simplifying would still be a O(n log(m)) operation, where n is the total number of points to filter........... something to explore closes #41649
talevy
added a commit
that referenced
this issue
Nov 24, 2020
A metric aggregation that aggregates a set of points as a GeoJSON LineString ordered by some sort parameter. A `geo_line` aggregation request would specify a `geo_point` field, as well as a `sort` field. `geo_point` represents the values used in the LineString, while the `sort` values will be used as the total ordering of the points. the `sort` field would support any numeric field, including date. ``` { "query": { "bool": { "must": [ { "term": { "person": "004" } }, { "term": { "trajectory": "20090131002206.plt" } } ] } }, "aggs": { "make_line": { "geo_line": { "point": {"field": "location"}, "sort": { "field": "timestamp" }, "include_sort": true, "sort_order": "desc", "size": 15 } } } } ``` ``` { "took": 21, "timed_out": false, "_shards": {...}, "hits": {...}, "aggregations": { "make_line": { "type": "LineString", "coordinates": [ [ 121.52926194481552, 38.92878997139633 ], [ 121.52922699227929, 38.92876998055726 ], ] } } } ``` Due to the cardinality of points, an initial max of 10k points will be used. This should support many use-cases. One solution to overcome this limitation is to keep a PriorityQueue of points, and simplifying the line once it hits this max. If simplifying makes sense, it may be a nice option, in general. The ability to use a parameter to specify how aggressive one wants to simplify. This parameter could be the number of points. Example algorithm one could use with a PriorityQueue: https://bost.ocks.org/mike/simplify/. This would still require O(m) space, where m is the number of points returned. And would also require heapifying triangles sorted by their areas, which would be O(log(m)) operations. Since sorting is done, anyways, simplifying would still be a O(n log(m)) operation, where n is the total number of points to filter........... something to explore closes #41649
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
:Analytics/Geo
Indexing, search aggregations of geo points and shapes
>feature
Team:Analytics
Meta label for analytical engine team (ESQL/Aggs/Geo)
Feature
A metric aggregation that aggregates a set of points as
a GeoJSON LineString ordered by some sort parameter.
specifics
A
geo_line
aggregation request would specify ageo_point
field, as wellas a
sort
field.geo_point
represents the values used in the LineString,while the
sort
values will be used as the total ordering of the points.the
sort
field would support any numeric field, including date.sample usage
sample response
visual response
limitations
Due to the cardinality of points, an initial max of 10k points
will be used. This should support many use-cases.
One solution to overcome this limitation is to keep a PriorityQueue of
points, and simplifying the line once it hits this max. If simplifying
makes sense, it may be a nice option, in general. The ability to use a parameter
to specify how aggressive one wants to simplify. This parameter could be
the number of points. Example algorithm one could use with a PriorityQueue:
https://bost.ocks.org/mike/simplify/. This would still require O(m) space, where m
is the number of points returned. And would also require heapifying triangles
sorted by their areas, which would be O(log(m)) operations. Since sorting is done,
anyways, simplifying would still be a O(n log(m)) operation, where n is the total number
of points to filter........... something to explore
The text was updated successfully, but these errors were encountered: