start date vs end date vs date
Opened this issue · 3 comments
Currently there is acquisition_start and acquisition_end, which certainly makes sense and is the standard way of specifying collection date times. It's how NASA's CMR publishes metadata.
However for composite data that utilizes data over multiple days I've found just having start and end dates to be lacking.
MODIS data products that use windows, such as MCD43A4 that uses a 16 day window is also described by the 9th day. For this product multiple scenes are used to do BRDF correction and calculate a nadir reflectance that is weighted for the 9th day of the 16 day window. We also see something similar with Proba-V data, which is a 10 day window but the 6th day is what would typically be used.
See the problem? The assumption of just having a start and end date is that all those times are equally represented in the data, which is not necessarily the case.
I'd suggest having a single date field, then making both acquisition_start and acquisition_end optional.
Yeah, I'm going back and forth on start and end date too. I like the simplicity of a single date + time, and most source satellite imagery falls into that. The other use case for me is drones, where a typical 'scene' is a processed composite of many images from a couple hours, but dealing with each individual image captured would be a pain.
When you say single date would that be date and time? Or would you handle time differently?
I've been not wanting too many optional fields, but perhaps they make sense - I agree having those two as optional could make sense. The other optional set I could see are things like look angle, sun azimuth, etc. Not every UAV operator will have all of that, but it's pretty standard for satellite providers.
Many sensors that acquire a scene that is pushbroom in style, then you will need both acquisition_start and acquisition_end to calculate how to best handle calibration of the image processing, and if video then you will need both for telemetry calcs. I would keep both but make acquisition_start required.
Yeah, good point @danlopez00 , in thinking about it more it does make sense to always have an acquisition_start, and I'd also require acquisition_end as well, I don't think they would ever be the same, even for a full frame sensor the there is an acquisition time.
But in addition to that there really needs to be a nominal date/time. For push broom sensors this would be a scene center time. While the MODIS MCD43A4 product is the strongest example of a multi-day mosaic product needing a nominal date/time (because the values have been weighted to be for that date), I think it is useful for other multi-day products. Other multi-day MODIS products and the 10 day Proba-V products have even numbered of days in the window, MODIS uses the 9th day as the center and PV uses the 6th day. Having a nominal date/time allows data providers of composite products to convey what they consider to be the best date/time.
The lack of a nominal date is one of my issues with CMR, because when you search for a single date of a composite product, you end up with all the results where any data whose temporal window overlaps with that date is returned. When I did MODIS on AWS it was a problem because when it queries CMR for a days data, all the tiles are returned from up to 16 days prior, leading to large and slow search queries.
WRT to date/time vs date @cholmes I think they should all be date/time fields. They should all be required, but nominal date/time can default to the average of start and end.