Capture Information Block (CIB) addition

[antoniovazquezblanco]

Following #51, this is simply a rebase of the original PR.

[guyharris]

Presumably multiple CIBs can be provided for the same interface if the interface is in motion.

[guyharris]

The zero frame for global location is presumably the frame whose origin is at the intersection of the IERS Reference Meridian and the Equator, at an altitude that's relative to some reference point at that location (mean sea level, which would make it height above mean sea level?).

The plane for local location is presumably a plane tangent to the Earth's surface at some point; is that a fixed point, or could it move relative to the origin of the zero frame for global location?

[antoniovazquezblanco]

Presumably multiple CIBs can be provided for the same interface if the interface is in motion.

Yes. Two paragraphs relevant to this:

1. Each CIB is associated with a specific interface and applied to all packets received on this interface following the CIB until superseded by a new CIB on the same interface.

2. Note that issuing a new CIB will clear all existing CIB options on an interface, for example, the CIBs for a non-moving but rotating interface with a known position must all contain both location and orientation data.

The second paragraph is a bit conflicting for me. I understand this may be done because updating location and not updating positioning error it may be very common but this may also cause errors...

What do you think?

[guyharris]

2. Note that issuing a new CIB will clear all existing CIB options on an interface, for example, the CIBs for a non-moving but rotating interface with a known position must all contain both location and orientation data.

Presumably the options are cleared because in case an update removes an option, as a CIB just has a list of options, not a list of changes to the options including "add", "change", and "remove".

IDBs could also use a mechanism to allow options to be added, removed, or changed options might be useful.

The second paragraph is a bit conflicting for me. I understand this may be done because updating location and not updating positioning error it may be very common but this may also cause errors...

Errors as in "a second CIB might forget to include options that aren't getting changed"?

[antoniovazquezblanco]

IDBs could also use a mechanism to allow options to be added, removed, or changed options might be useful.

Agree although for my particular usecase both options would fit.

Errors as in "a second CIB might forget to include options that aren't getting changed"?

Yes, I was thinking about that. Maybe today, after rethinking about it, it seems not that important.

Do we agree on keeping the existing mechanism and not changing it to a an "add", "change" or "remove" one?

[antoniovazquezblanco]

Do we agree on keeping the existing mechanism and not changing it to a an "add", "change" or "remove" one?

Given that this was a doubt I raised myself and that you did not show support for it, I guess we have an agreement for the time being and I will keep on going with the next comments/questions. Thanks!

[antoniovazquezblanco]

I would like some imput regarding this one. If both Global and Local location information is used in the same pcap files it should result in the removal of all position information: Would it make sense to include a global location information to tag the specific pcap in a global position and then start using local coordinates referencing this origin? Does this make sense for any usecase? Thanks

[antoniovazquezblanco]

Would it make sense to use global + local positioning in a case where you are performing a capture in a reference frame that is moving on which you would like to have local measurements of high precission? Example: Performing captures on a train where local frame would map the interior of the train but global one would position the train globally? 🤔