-
Notifications
You must be signed in to change notification settings - Fork 31
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
Radio Location Estimates with hexes #426
base: master
Are you sure you want to change the base?
Conversation
we use hexes in many places in the system, let's conform to that here as well
Enumerating all the possible valid hexes for a location estimate can create extremely large messages for estimates with large radius. Sending the center hex and grid distance does a few things. - Compacts the message - speaks in terms of hexes like most other things in the system - Provides an easy way to check locations using h3.grid_distance(center, target) <= grid_distance
At this time, the most imformation we can expose about the events that led to the radio location estimate is an id and timestamp. There may be more information in the future, but this is enough information for someone to give us and we can fetch the underlying record for investigation.
f0e0592
to
96df87b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per my comment on the the correlation event message, I guess the radio_location_estimate_v1
message type is doing exactly what I was asking for, so I guess my real question is really "do the list of correlation events attached to an estimate really provide any value?" such that they belong in this public data structure. They have no meaning to anyone outside of the private backend that processed the location estimate so they just seem like noise here.
This is an extension of #419 that changes (lat,lon,radius) to a series of res12 hexes.