How to best handle GEMPAK surface data timestamps?

[nawendt]

In working with more GEMPAK surface data files, I have learned a little bit more about how those files are structured. That being said, some questions are raised in my mind as to how best to handle these files in GempakSurface.sfjson and GempakSurface.nearest_time.

GEMPAK surface files essentially bin the observations into time windows. There is some ability for a user to configure the window size. However, from discussions with folks experienced with GEMPAK and just seeing enough files, 20-minute time windows appear to be the highest resolution. This means that, for example, a file you read from the IEM GEMPAK archive will have observations stored on :00, :20, and :40. When reading this data, the output will then put data on these times despite when the actual observation was taken. This has implications for what gets returned by the nearest_time method. You could actually get an observation that was not the nearest time.

The other challenge here is that GEMPAK stores the METAR observations as a decoded item, but stores the SPECI observations as text. To truly get the nearest observation time, you have to decode the SPECI text. That was done as part of #2658. Now, however, that introduces a bit of an inconsistency with how standard METAR observations are handled. They are still processed with the GEMPAK "bin time" as described above. I think the best course of action is probably to also decode the regular METAR observations and output them with their actual time much like is now done with SPECI reports. I just wanted to make sure that I implement a solution that makes sense to folks.

[sgdecker]

Let's say a station issued a METAR at 1153Z and then a SPECI at 1201Z. As a user, I'd still want to be able to access the "12Z" METAR easily for stations across the region, since certain remarks like SLP or the six-hour high temperature are only in the METARs. So, I'd want a way to get the 1153Z METAR even if my target time was 12Z. I suppose nearest_time should have a logical argument which would allow the user to specify they want the 1153Z observation (the nearest METAR) or the 1201Z observation (the nearest observation, period). I'd vote for "nearest METAR" being the default, with the argument allowing the user to obtain the nearest observation instead.