-
Notifications
You must be signed in to change notification settings - Fork 75
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
Geolocation in captures/global/annotations #278
Comments
Captures scope geolocation is probably reasonable, though we cannot remove the global scope field for a while. Annotations (where geo info used to be) should probably go into the |
"for a while" how does that even work, e.g. would we mark it as deprecated or something? Yep I'm on board with using the spatial extension for annotations |
Sorry, that was pretty vague. I think if global was undesirable we could formally deprecate in 2.0 and then remove in 3.0? Adding this to captures seems reasonable though. |
Works for me, I'll make a PR |
Thanks, can you do these separately? the spatial one is easy but the other may take some time |
We had a request that geolocation also be allowed in captures for moving receivers that get a periodic location update. This brought up the argument that it might as well only be in captures, just like frequency, the only downside would be backwards combability issues with tooling already pulling it from global. Tooling designed to only have 1 coordinate for a Recording (e.g. a maps interface on a tool) can just pull it from captures[0].
On a related note, it would be nice to have a way for an annotation to contain a geolocation of the emission associated with that annotation (the transmitters location, not receiver). This could be results from TDOA or it could be "label data" known beforehand, etc. This one seems a lot simpler but should it be part of an extension or the core spec?
The text was updated successfully, but these errors were encountered: