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

Geolocation in captures/global/annotations #278

Open
777arc opened this issue Apr 17, 2023 · 5 comments · May be fixed by #281
Open

Geolocation in captures/global/annotations #278

777arc opened this issue Apr 17, 2023 · 5 comments · May be fixed by #281

Comments

@777arc
Copy link
Member

777arc commented Apr 17, 2023

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?

@jacobagilbert
Copy link
Member

jacobagilbert commented Apr 19, 2023

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 spatial extension.

@777arc
Copy link
Member Author

777arc commented Apr 19, 2023

"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

@jacobagilbert
Copy link
Member

jacobagilbert commented Apr 19, 2023

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.

@777arc
Copy link
Member Author

777arc commented Apr 19, 2023

Works for me, I'll make a PR

@jacobagilbert
Copy link
Member

Thanks, can you do these separately? the spatial one is easy but the other may take some time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants