search

stactools-packages / goes-glm

stactools package for the Geostationary Lightning Mapper (GLM) on the GOES satellites
Other
2 stars 1 forks source link

Drop "geoparquet" from asset keys #23

Closed TomAugspurger closed 1 year ago

TomAugspurger commented 1 year ago

https://github.com/stactools-packages/goes-glm/blob/c9c3bc42685e66e0eaace599096ef6050c05eb57/src/stactools/goes_glm/constants.py#L96-L98 has the asset keys as "geoparquet_flashes", etc. I'd prefer to have those as just "flashes", "groups", and "events".

The fact that it's geoparquet is embedded in the media type. Since the raw NetCDF file has everything, we don't need to worry about name clashes in the key.

m-mohr commented 1 year ago

Hey @TomAugspurger!

Sure, I can do that. But as I've used a similar approach for all packages I've authored, I'd like to ask:

What should be in the keys generally? STAC spec says we can choose whatever keys as they don't have a meaning in the spec itself, so providers can use it for whatever they like. As you've requested the change, I'm wondering what meaning you've assigned to the keys? I can't fully follow the argument that the geoparquet part is already embedded in the type because then you could also argue to remove "flashes" etc. because it's in the title. ;-) I've chosen to add the "geoparquet_" prefix to have a grouping already with the asset keys so that it's clear directly which assets are all geoparquet and which is the source. In the other packages I somtimes also use keys such as "netcdf", "cog" or so. In these cases I'd also need to choose an alternative (e.g. "source" and "cloud-optimized" or so)...

Thanks!

TomAugspurger commented 1 year ago

Thanks for the background. I was thinking using "flashes" would be more similar to, e.g., getting the blue band from our landsat items which is just "blue". But as you say, including the geoparquet does group those together, so let's leave it as it.