Support as many stactools subcommands as is reasonable

[gadomski]

If we do want to be The One STAC CLI™, we should provide most of the functionality that exists in other CLis.

• add: Add an item to a catalog/collection.
• add-asset: Add an asset to an item or collection.
• add-raster: Add raster extension to an Item.
• copy: Copy a STAC Catalog
• create-item: Creates an item from an asset
• describe: Prints out a list of all catalogs, collections and items in this STAC.
• info: Display info about a static STAC catalog.
• layout: Reformat the layout of a STAC based on templating.
• [ ] lint: Lint a stac object with stac-check. Will not support, don't want to depend on stac-check
• merge: Merge items from one STAC into another.
• migrate: Migrate a STAC object to the latest version
• move-assets: Move or copy assets in a STAC catalog to the locations...
• summary: Summarize a STAC collection's contents.
• update-extent: Update a STAC collection's extent.
• update-geometry: Update an item geometry from an asset footprint
• validate: Validate a stac object.
• version: Display version info.

[alekzvik]

I have seen support for the item command in the history, but you removed it.

I also suspect that adding some commands requires a dependency for reading the asset metadata (e.g. projection, spatial extent, etc.). I think GDAL bindings can cover this, but it's a significant dependency.

Is feature-parity with stactools still a goal for this project?
Do you mind adding GDAL as a dependency?

[gadomski]

Do you mind adding GDAL as a dependency?

I've had it, and I've removed it. I think it'd be best as a separate crate, e.g. stac-gdal. I think the main stac crate has enough optional features.

So for stuff like item, we'd add a stac-gdal crate, add the functionality there, then use that in stac-cli.