stac-utils / stac-rs Goto Github PK

They're required, so we should make people choose if they want them to be empty strings.

This is distinct from #27. A validator that directly translates the specification into code checks would be valuable for multiple reasons:

• better error messages than most jsonschema validators
• ability to handle complex cases that can't be expressed in jsonschema
• better support for multiple errors (rather than bailing on the first validation error)
• warnings and suggestions

I think we should be as small as possible as default.

Wanted by https://github.com/gadomski/stac-server-rs/blob/fc6678dfc372d2aca41421507f9016e0a7c9bd1c/stac-api-backend/src/memory.rs#L82-L86.

There's a lot of code paths that are untested right now. Also might be a good excuse to add coverage.

We could have the behavior in stac-async, and the just use it in stac-cli. https://github.com/gadomski/stac-incubator-rs/blob/b8a180cbda1ff1c93a0e53c2705064d240a1c734/cli/src/download.rs

https://github.com/gadomski/stac-rs/blob/63cc2740179046297da623d10552e43641eb517d/stac-async/src/download.rs#L36

These exist in stac-api-backend but should probably live in stac-api.

The current jsonschema validator uses blocking reqwests under the hood to get network schemas. We should re-implement the schema fetcher using async in stac-async.

Adding the jsonschema option per the docs:

stac = { version = "0.1", features = ["jsonschema"]}

and building gives the error:

the package `foobar` depends on `stac`, with features: `jsonschema` but `stac` does not have these features.

There's a lot of things you might want to do with links and assets when you're rendering a Stac. Sometimes you might want to move the assets alongside the objects. Sometimes you want to re-create the links so they still work relatively. And sometimes you want to reject because the render is going to a different href base and the relative asset hrefs won't be valid.

One way to approach this is composable renderers, e.g.:

let renderer = LinkRebuilder::new(BestPractices::new("root"));
for result in renderer.render(..) {
    // etc
}

It kind of works like BufReader and friends. The LinkRebuilder (and AssetMover, and whatever) would first render the object itself, and then make any modifications necessary to the object before returning.

I think, for the basic read operations, we could add an optional async feature that exposes async versions of the functions that already exist. That could be a useful building block for downstreams.

This would pass through objects exactly as-is, except rebased onto a new root.

If the reqwest feature is enabled (it is enabled by default), it is used for network access:

It's disabled by default.

I probably just copy-pasted the docs from search.

The current ecosystem options for jsonschema validation are:

• https://crates.io/crates/jsonschema
• https://crates.io/crates/valico

These seem more mature than the last time I looked, so I'm hopeful. This should probably be behind a (non-default?) feature.

One thing I'd like to see is storing the released schema documents in the library itself, rather than forcing network access for validation.

A trait to be implemented by all structures and enums that have links. This provides a common links interface between Object and the three types of objects.

Suggestions:

• https://github.com/softprops/action-gh-release
• https://github.com/charliermarsh/ruff/blob/main/.github/workflows/ruff.yaml has some patterns

Right now it reads like it did when I first made it, but I've added more cool stuff since then.

We have search, but we'll want to page through items as well.

https://github.com/crate-ci/cargo-release

Motivation: https://twitter.com/Gankra_/status/1565755448954863618

There's several enhancements that could stand as their own crates, or be included in the main stac crate w/ features. These include:

• gadomski/stac-incubator-rs#3
• gadomski/stac-incubator-rs#1
• gadomski/stac-incubator-rs#2

And maybe others. I'm undecided on how to implement. My instinct right now is to workspace everything, e.g.:

[workspace]
members = [
    "core",   # crate: stac
    "cli",    # crate: stac-cli
    "async",  # crate: stac-async
    "client", # crate: stac-client
]

This will make development easier during the early phases when they're likely to change together quite a bit. We could split them off later into their own repos w/o too much impact.

The downside here is that its just complex, and there may be things we'd want to include in core, e.g. async. I'll mull on this more.

We're still missing a lot, especially around Stac and the render methods.

We removed tree management (aka children, parents, roots, etc) in v0.0.5. It'd be nice to have it back, but I need to think through the strategy a bit more to make it less confusing.

It wouldn't be hard to add ItemCollection to Value. We could even keep supporting links, just by making an optional links vector that isn't serialized if its empty.

This came up here: https://github.com/gadomski/stac-server-rs/blob/1ea25b1a59c76ce0976b38da9ab1a1d814689453/src/main.rs#L100-L117

In the spec examples readme.md the best practices link goes to a repo local file that doesn't exist.

https://github.com/gadomski/stac-rs/blob/main/spec-examples/v1.0.0/README.md

When creating new collections+items via an API (e.g. in stac-siphon-rs), the JSON is POSTed. If we provide a .post() method on our client, downstreams could use that to async-write to APIs.

E.g. #68 (comment). Will unblock #68 and #66.

These are all the stable ones, plus raster:

• Electro-Optical
• File Info
• Item Assets Definition
• Landsat
• Projection
• Scientific Citation
• View Geometry
• Raster

That's wrong, yo.

When validating a Collection with a list in the temporal extents attribute (instead of an object), the error message was ERROR: data did not match any variant of untagged enum Value. We should provide more information than that.

Let's not make it public at the top level either, so you have to be clear you're getting a renderer, e.g. use stac::renderer::BestPractices.

They're not visible right now.

The following command doesn't download any assets:

stac download https://planetarycomputer-staging.microsoft.com/api/stac/v1/collections/io-lulc-9-class .

We can probably do some useful stuff with a Walk trait that is implemented by Handles, Objects and Items:

• breadth_first() and depth_first() builder-pattern methods to switch tree traversal order
• start_at() and start_at_object() (not sure about the names) builder-pattern methods to search the tree for a handle/object, then start walking from there.

Additionally we can add these to Objects and Items:

• take_objects() and clone_objects() builder-pattern methods that switch between taking the objects out of the visited nodes, and cloning them (default take)

One of the selling points of using this library will be (hopefully) performance. Having benchmarks would allow us to quantify that performance.

There's a decent number of branches that aren't checked by CI. We should increase coverage.

Pretty obvious why: https://docs.rs/stac/latest/stac/trait.Read.html#method.read_struct. It reads an Object.