This seems like a more limiting change to the spec than the one proposed in #237, although maybe I am misunderstanding the use case here.

They are very similar, it's one of those tradeoffs where if it's part of an extension you'll get less support in tooling and less folks using it. I guess my thought was, moving it from global to captures doesn't add complexity to the core spec, but gives that little bit of flexibility some might need.

This is certainly more limited than what I proposed in #237 but I do think this adds value and I don't think we have a great way of addressing 237 comprehensively currently. This does allow a sort of strange way where each GPS point is logged in a new capture in a metadata_only sigmf file that is part of a collection but I don't think thats a good solution.

Maybe there's a split of 3 different ways for handling geolocation metadata:

Case 1 (recordings by static receiver at a single location): Use the global geolocation field and no others.
Case 2 (recordings by static receiver at multiple locations): Use the method added by this PR, where each capture has its own geolocation information.
Case 3 (recordings by mobile receiver): Still needs a proper solution, the primary topic of #237

This seems a little fragmented, but I think it's OK. I would not like to see the global geolocation field deprecated, since static receivers performing multiple captures in the same location is a reasonable use case, and this change would require duplication of the geolocation metadata for each capture. An example of this would be a static receiver recording IQ samples at multiple frequencies. Perhaps the global field could remain, and the captures field could take precedence if it exists?

I think I agree that migrating the global scope geolocation object to captures scope is the right way to address a variety of use cases. it still does not cover the situation where you want to capture true time-varying position within a SigMF Collection so we can leave 237 open. Open to ideas over there though!