"TS" plot for trajectory argos type not working properly (branch issue421)

[j-harbin]

This issue relates to trajectories and is therefore only reproducible in the branch issue421. See reprex below for the problem:

library(argoFloats)
ai <- getIndex("traj")
index1 <- subset(ai, ID='1902221')
#> Kept 1 trajectories (0.0057%)
argos <- readProfiles(getProfiles(index1))
#> Warning in FUN(X[[i]], ...): This file has no STATION_PARAMETERS item, so an
#> attempt is made to discover some important fields for inclusion in the data slot
#> of the return value. However, other variabiles will go in the metadata slot, so
#> be aware of this problem during further processing.
#> Warning in readProfiles(getProfiles(index1)): Of 1 profiles read, 1 has >10% of pressure values with QC flag of 4, signalling bad data.
#>     The indices of the bad profiles are as follows.
#>     1
#> Warning in readProfiles(getProfiles(index1)): Of 1 profiles read, 1 has >10% of salinity values with QC flag of 4, signalling bad data.
#>     The indices of the bad profiles are as follows.
#>     1
#> Warning in readProfiles(getProfiles(index1)): Of 1 profiles read, 1 has >10% of temperature values with QC flag of 4, signalling bad data.
#>     The indices of the bad profiles are as follows.
#>     1
plot(argos, which="TS")
#> Warning in oce::plotTS(ctd, cex = cex, bg = bg, col = col, pch = pch, mar =
#> mar, : no valid salinity data

^{Created on 2021-04-08 by the reprex package (v0.3.0)}

This should work, however, because when I individually make this into a CTD object it work's fine (see reprex)

library(argoFloats)
library(oce)
#> Loading required package: gsw
#> Loading required package: testthat
#> Loading required package: sf
#> Linking to GEOS 3.8.1, GDAL 3.1.1, PROJ 6.3.1
ai <- getIndex("traj")
index1 <- subset(ai, ID='1902221')
#> Kept 1 trajectories (0.0057%)
argos <- readProfiles(getProfiles(index1))
#> Warning in FUN(X[[i]], ...): This file has no STATION_PARAMETERS item, so an
#> attempt is made to discover some important fields for inclusion in the data slot
#> of the return value. However, other variabiles will go in the metadata slot, so
#> be aware of this problem during further processing.
#> Warning in readProfiles(getProfiles(index1)): Of 1 profiles read, 1 has >10% of pressure values with QC flag of 4, signalling bad data.
#>     The indices of the bad profiles are as follows.
#>     1
#> Warning in readProfiles(getProfiles(index1)): Of 1 profiles read, 1 has >10% of salinity values with QC flag of 4, signalling bad data.
#>     The indices of the bad profiles are as follows.
#>     1
#> Warning in readProfiles(getProfiles(index1)): Of 1 profiles read, 1 has >10% of temperature values with QC flag of 4, signalling bad data.
#>     The indices of the bad profiles are as follows.
#>     1
pressure <- unlist(argos[["pressure"]])
temperature <- unlist(argos[['temperature']])
salinity <- unlist(argos[["salinity"]])
ctd <- as.ctd(salinity,temperature, pressure)
plotTS(ctd)

^{Created on 2021-04-08 by the reprex package (v0.3.0)}

[dankelley]

Hm. I'll look. It's one of the other arguments to the oce::plotTS() call, because if I remove them, it works.

[dankelley]

Oh, I see. If I remove the eos arg, it works. The eos we are using in this package is gsw, and to compute the things of a TS plot, we need longitude and latitude, and not just salinity, temperature and pressure. Maybe the lon and lat values are NA at those spots where we have salinity and temperature.

[dankelley]

Yes, that's it. The snapshot plots "goodness" (whether not NA) for lon and lat. Note that there are no points on the top-right, meaning that whenever salinity is non-NA, then longitude is NA.

I think this is because no interpolation is being done for the in-water data. For those moments when lon and lat are available, the machine is at the surface (in radio contact to get the GPS signal) and has its salinity pump turned off.

This poses an interesting question about how to proceed. One approach would be to just -- for this purpose ONLY -- interpolate lon and lat across the NA values. After all, the float comes to the surface every 10d and if it's in a 2m/s current (very fast) that means it will have moved only 200km. But the lon-lat grid for TEOS is defined on a 4 degree (lon/lat) grid, which is 400km. So the float is very likely to be at the same grid cell for the TEOS10 computation of "conservative temperature" and "absolute salinity".

Unless I hear an objection from @j-harbin or @richardsc, I'll code this in. I'm not saying that I'll wait a long time on that ...

[dankelley]

This is what I'll get if I fill in the NAs using approx (red is what I'll get)

[dankelley]

Done in commit e3f47f4e54b0f866e2bd74cc7d35991d8036cbae of branch "issue421", with regexp as follows.

``` r library(argoFloats) ai <- getIndex("traj") index1 <- subset(ai, ID='1902221') #> Kept 1 trajectories (0.0057%) argos <- readProfiles(getProfiles(index1)) #> Warning in readProfiles(getProfiles(index1)): Of 1 profiles read, 1 has >10% of pressure values with QC flag of 4, signalling bad data. #> The indices of the bad profiles are as follows. #> 1 #> Warning in readProfiles(getProfiles(index1)): Of 1 profiles read, 1 has >10% of salinity values with QC flag of 4, signalling bad data. #> The indices of the bad profiles are as follows. #> 1 #> Warning in readProfiles(getProfiles(index1)): Of 1 profiles read, 1 has >10% of temperature values with QC flag of 4, signalling bad data. #> The indices of the bad profiles are as follows. #> 1 plot(argos, which="TS") ```  ^{Created on 2021-04-08 by the [reprex package](https://reprex.tidyverse.org) (v1.0.0)}

[dankelley]

@j-harbin I propose you close this if you think it's OK. @richardsc has seen the emails on it, and so of course if he wants to comment, or reopen, that would be great.

[richardsc]

I agree with this approach.

(Though it adds to my grumbles about using gsw vs unesco for stuff like this and the confusion that can cause ...)

[dankelley]

@j-harbin I made a tiny mod (in this branch).

commit 81ee12ee2fa959482df9a0bde871b97e1c840f61 Author: dankelley kelley.dan@gmail.com Date: Thu Apr 8 16:46:24 2021 -0300

don't bother NA-filling for lon and lat if all OK

[j-harbin]

Thanks Dan! It all works on my end and I'll close the issue.