Firm up the definition of `ColumnObject.type`

[TomAugspurger]

The ColumnObject has a loosely specified type field that's intended to capture the column's dtype:

Data type of the column. If using a file format with a type system (like Parquet), we recommend you use those types.

This definition is pretty vague, but maybe that's OK. It depends on what this is used for. When the Asset is a typed file format like Parquet, the type in ColumnObject is irrelevant when you're actually loading the data. Under that scenario, I think it's mostly just useful for humans learning about the data. But if the Asset is something like a CSV, a reader might want to use the types from the table:columns to avoid inferring a data type from the values.

IMO, we have a few choices:

1. Leave type as is: don't take a strong stance on what values types can take. Make it clear to users that this field is primarily informational.
2. Adopt a specific type system (e.g. parquet or json-table-schema's) and require users to translate the Asset's type to that system.
3. Drop type in favor of multiple fields like, parquet_type, arrow_type, jsonstablechema_type, etc. Let the provider choose which one they provide.

[m-mohr]

Could we adopt what is already used in some other extensions?
https://github.com/stac-extensions/raster#data-types

[TomAugspurger]

Yes, I suppose that using something else from the STAC ecosystem would be a good rule to use. Though depending on the dataset, you might just end up with a bunch of "other".

---

One other thing I didn't note originally, but should be considered, is the distinction between storage types and logical types. From parquet's spec

Logical types are used to extend the types that parquet can be used to store, by specifying how the primitive types should be interpreted.

https://github.com/apache/parquet-format/blob/master/LogicalTypes.md has parquet's full list of logical types,

Arrow makes a similar distinction.

[m-mohr]

Maybe go with multiple fields then?
data_type from raster seems to be the storage type?
And then make something more flexible for the logical types?

[TomAugspurger]

Yep, that sounds like a good plan.