You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However the logger files up to 2012 at SCO_U and up to 2016 at SCO_L do contain coordinates that could be used to estimate the current position. But that would require few changes because the estimation of the latest position is currently done in the find_position function, itself called in the BUFR processing step which is run on the transmission data only.
So we could either:
feed the historical data to the getBUFR function
or
make a separate function for estimating the latest coordinates on both transmission and logger data.
closing this since in pyromice >= v1.4.0 AWS_sites_metadata.csv and AWS_stations_metadata.csv will contain the latest time stamp if transmitted or the best estimate of lat/lon/alt based on interpolation of coordinates done in the L3 product.
This is an expected consequence from not using the latitude and longitude contained in the Iridium emails which were of very poor quality. At these sites, the transmissions do not contain any coordinates from which the current position could be extrapolated.
However the logger files up to 2012 at SCO_U and up to 2016 at SCO_L do contain coordinates that could be used to estimate the current position. But that would require few changes because the estimation of the latest position is currently done in the find_position function, itself called in the BUFR processing step which is run on the transmission data only.
So we could either:
or
This could be related to #142, #152, GEUS-Glaciology-and-Climate/PROMICE-AWS-data-issues#46.
The text was updated successfully, but these errors were encountered: