Interest in a cloud-optimization validation/linting tool for the guide?

[chrislyonsKY]

Hey all — I'm a GIS Developer and a CNG Forum member. I've been thinking about a gap in the cloud-native geospatial workflow that this guide is well-positioned to address:

validation.
The guide does an excellent job explaining how to create cloud-optimized formats. But once you've converted your Shapefiles to FlatGeobuf or your CSVs to GeoParquet, how do you verify the result actually follows best practices? Specifically:

• Is the spatial index present in your FlatGeobuf, or was it generated without one?
• Does your GeoParquet have the geo metadata key with proper CRS encoding per the spec?
• Is your Shapefile missing its .prj or .cpg sidecar files?
• Would a different format better suit your access pattern?
• Is your file too large for efficient single-file cloud access and should be partitioned?

I'm building an open-source CLI tool called Tissot (named after Tissot's indicatrix) that answers these questions. It's a Rust-based geospatial diagnostics engine with Python bindings — you run tissot check data.parquet --domain cloud and get findings with direct links back to the relevant sections of this guide. It also does projection distortion analysis, data quality checks, and produces a Lighthouse-style quality score.

The cloud-optimization rules are specifically designed around the format landscape documented here:

• cloud/format-recommendation — flags Shapefile/GeoPackage in cloud pipelines, suggests FlatGeobuf or GeoParquet
• cloud/spatial-index — validates spatial index presence per format
• cloud/crs-metadata — checks CRS embedding per format spec
• cloud/compression — flags uncompressed GeoParquet
• cloud/multi-file-integrity — catches orphaned Shapefile components

Two questions for the community:

1. Would a cookbook entry on validating cloud-optimized data be useful for this guide? I'd be happy to contribute one once the tool is installable.
2. Are there other validation checks the community would want? I want to make sure the rules reflect real pain points, not just theoretical best practices.

Repo : https://github.com/chrislyonsKY/tissot

Appreciate any feedback. This guide has been a great resource, and I'd love to contribute back to it.

[wildintellect]

Tagging some people that could offer ideas @gadomski @maxrjones

I would consider adding a block in each format showing validation rather than a separate cookbook. If you want a comprehensive how to validate various formats with this library that sounds like Tissot docs.

[chrislyonsKY]

Indeed, you raise a valid point. A standalone cookbook may be perceived as more akin to tool documentation rather than format guidance. The per-format validation approach would be more appropriate for this guide.

I would be delighted to contribute validation sections for individual format pages. A suitable approach would be to include a “Validating Your Output” block at the conclusion of each format’s page, which would encompass the following aspects:

• The necessary checks to be performed after conversion (presence of spatial index, inclusion of CRS metadata, application of compression)
• The decision-making process behind these choices (when a spatial index is relevant, when compression justifies the trade-off)
• The verification methods available, such as Tissot, ogrinfo, gdalinfo, or Python snippets

This approach ensures that the guidance is accessible to users who are already familiar with the format, while the tooling remains secondary to the underlying concepts.

Would it be advisable to initiate a pull request (PR) that adds a concise validation section to the FlatGeobuf and GeoParquet pages?

[gadomski]

Taking a quick look at https://github.com/chrislyonsKY/tissot, it looks like a mostly vibe-coded app? This is just from reading the commit history, which is pretty light and has checkpoints from a copilot session. I think anything that we include in the official CNG guide should be vetted first, e.g. by providing examples with real-world data (e.g. from government or commercial providers). The tissot documentation would be a good place for any such documentation.

There's also many other sources of "best practices" information to take into account, e.g. https://github.com/opengeospatial/geoparquet/blob/main/format-specs/distributing-geoparquet.md for GeoParquet, https://github.com/radiantearth/stac-best-practices/ for STAC, etc. We'd also want to consider existing tooling; for one example, https://cogeotiff.github.io/rio-cogeo/ is a go-to tool for validating COGs, and we'd want to either wrap or re-implement the checks there — validation tooling is tricky :-).

That being said, I think a single-use tool to help folks check whether their data is "Cloud-Native" has merit, thanks for opening the discussion!

[chrislyonsKY]

Fair points across the board.
The repo is currently scaffold and architecture — the commit history reflects that. The Rust implementation is underway and will look very different as the actual engine takes shape with tests against real data.
On the real-world data point: that’s exactly the plan. The tool needs to be validated against government datasets (TIGER, Kentucky Open Data, USGS) and common commercial formats before it belongs anywhere near a guide like this. I won’t PR anything here until that’s done.
Great callouts on existing best practices — rio-cogeo for COG validation, the GeoParquet distribution spec, and the STAC best practices repo are exactly the kind of prior art that should inform the validation checks rather than be reinvented. Wrapping or aligning with those existing tools rather than duplicating them is the right approach.
I’ll come back when there’s working code validated against real-world data. Appreciate the honest feedback.