f_corr values given as 0 in vgp_database

[Swanson-Hysell]

In the data tables there are sedimentary sites for which the f_corr is given as 0.

I presume that this should be 1 given that No flattening = 1.0

[LenGallo]

Actually, 0 means that no correction for inclination shallowing was performed. It's easy to catch these cases in order to apply the E/I correction. @matdomeier any thoughts?

[matdomeier]

Yes, '0' is just used to flag sites for which the f-value is unknown (no checks on potential shallowing were performed), as this is otherwise an impossible value (in contrast to '1', which could result from a unit which was experimentally verified to have not suffered any shallowing).

[Swanson-Hysell]

Given that 1 means the same thing, it seems like we might as well use it. Or just leave the entry blank when there is not f correction like is the case for the vast majority of entries. By doing so, we are not creating a Boolean type filter in the same column that could have meaningful values between 1 and 0.

[matdomeier]

The original idea was that blank entries were ones for which inclination shallowing concerns shouldn't apply (e.g. igneous rocks), whereas 0 was used for rocks where there is a concern but no tests had been conducted. 1 is (hypothetically) for a rock that has been experimentally shown to have not been shallowed. So 1 and 0 are different in this case. We could leave all the zeros as blanks as you suggested, but then would have to check the rock-types when applying corrections (rather than just looking for 0's). But if that is easier to merge with the MagIC format I have no problems with that.

[Swanson-Hysell]

A solution to this that was implemented in the MagIC database for tilt-corrections was to make it -1 if no tilt-correction was implemented. By using this value, it is not possible to mix up with any number between 0 (for no tilt correction) and 100 (full tilt correction). So we could take that approach.

One additional point of discussion is that there is not a current field for an f value at the site level only at the pole level (in the locations table) in the current MagIC data model. We can have that added. @duserzym and I took the approach of taking all the additional metadata in our compilation for which there wasn't a convenient match in the data model and building up a dictionary that keys out those values which we put into the site description column of the data model. I think that this approach works well. We can discuss which of those fields we think should be added to the data model or kept in this description dictionary.