Is file size needed?

[cholmes]

One change I made when shifting from OIN to this updated spec was to remove file size.

I definitely do not think it belongs in the abstract spec - if it is to power API's then there are several API's that serve imagery that do not know the file size ahead of time (like Planet - assets are generated on the fly).

I could see an argument for the JSON + Cloud Optimized GeoTIFF case, as it can be useful for clients to know. But it seems like it should be possible to just query the image file itself.

[tombh]

I think it would be useful to at least have some indication of the size of the asset. So what about making it optional? There is an implied file size from the calculus of footprint * gsd. So instead of 'optional', what about, 'not guaranteed to be actual size on disk'?

[matthewhanson]

I agree file size is best as an optional parameter. The main reason is that metadata generation doesn't necessarily need, or have, access to the original data file. For our NASA work there are several NASA datasets where metadata is generated by lower level metadata files and don't ever look at the actual data files.
Another issue here is that a "scene" might actually be made up of multiple files, so a single file size at the top metadata level wouldn't make sense.