Specification

Requirements¶

PORTO-CORE-001¶

Severity: MUST · Enforcement: validator · Section: Core Structure

It MUST be a valid STAC catalog following STAC 1.1.0, with a root catalog.json always required, even for a single collection.

PORTO-CORE-002¶

Severity: MUST · Enforcement: validator · Section: Core Structure

catalogs and collections are internal nodes, items are leaves, and assets (data files) MUST sit at the collection or item level.

PORTO-CORE-003¶

Severity: MAY · Enforcement: validator · Section: Core Structure

Catalogs organize only and MAY nest into sub-catalogs;

PORTO-CORE-004¶

Severity: MUST · Enforcement: validator · Section: Core Structure

collections MUST be one level deep, containing only items or assets, never nested collections.

PORTO-CORE-005¶

Severity: MUST · Enforcement: validator · Section: Core Structure

Every catalog and sub-catalog MUST contain a catalog.json, an AGENTS.md, and a README.md; every collection MUST contain a collection.json, an AGENTS.md, and a README.md.

PORTO-CORE-006¶

Severity: MUST · Enforcement: validator · Section: Conformance and Versioning

Every catalog and collection MUST declare the versioned Portolan schema URI (e.g. https://schemas.portolan-sdi.org/portolan/v0.2.0/schema.json) in its stac_extensions array.

PORTO-CORE-007¶

Severity: MUST · Enforcement: validator · Section: Conformance and Versioning

The specification version MUST NOT be conflated with the dataset version.

PORTO-CORE-008¶

Severity: MUST · Enforcement: validator · Section: Conformance and Versioning

Dataset versioning, where used, MUST use the STAC version extension.

PORTO-CORE-009¶

Severity: SHOULD · Enforcement: validator · Section: Conformance and Versioning

All objects within a catalog SHOULD declare the same Portolan schema URI.

PORTO-CORE-010¶

Severity: MUST · Enforcement: validator · Section: Conformance and Versioning

A validator MUST flag any catalog or collection whose declared URI differs from the root catalog's; such a mismatch is a warning, not an error, and a mixed-version catalog remains valid.

PORTO-CORE-011¶

Severity: MUST · Enforcement: process · Section: Conformance and Versioning

The metadata passes MUST be executable without reading asset data; the data pass MAY be run independently.

PORTO-CORE-012¶

Severity: MAY · Enforcement: process · Section: Conformance and Versioning

versions.json is a tooling artifact and is NOT REQUIRED in a catalog for v0.1.

PORTO-CORE-013¶

Severity: MUST · Enforcement: validator · Section: Catalogs

The canonical entrypoint is a STAC catalog.json in the catalog root, which MUST be valid.

PORTO-CORE-014¶

Severity: MUST · Enforcement: validator · Section: Catalogs

Catalogs MAY use nested sub-catalogs for organization but MUST NOT use nested collections.

PORTO-CORE-015¶

Severity: MUST · Enforcement: validator · Section: Collections

A collection directory MUST contain a collection.json and holds one subdirectory per item.

PORTO-CORE-016¶

Severity: SHOULD · Enforcement: validator · Section: Collections

Collection IDs SHOULD contain only lowercase letters, numbers, hyphens, and underscores, start with a letter, and be unique within the catalog.

PORTO-CORE-017¶

Severity: MUST · Enforcement: validator · Section: Single-File Collections

When a collection holds a single data file (e.g. one GeoParquet file), that data MUST be represented as a collection-level asset — no item directory or item JSON is needed (see Vector).

PORTO-CORE-071¶

Severity: MUST · Enforcement: validator · Section: Raster Collections

A collection holding multiple raster scenes MUST model each scene as an item carrying its COG as an item-level asset; scene COGs MUST NOT be listed as collection-level assets.

PORTO-CORE-072¶

Severity: MUST · Enforcement: validator · Section: Raster Collections

A collection holding a single COG follows the single-file rule above: it MUST expose that COG as a collection-level asset with no item directory (see Raster).

PORTO-CORE-018¶

Severity: MUST · Enforcement: validator · Section: Nested Catalogs, Flat Collections

A collection MUST NOT contain a child collection.

PORTO-CORE-078¶

Severity: SHOULD · Enforcement: validator · Section: Nested Catalogs, Flat Collections

A catalog or collection with twenty or more children SHOULD organize them into subcatalogs, thematic or otherwise, so users can browse the data.

PORTO-CORE-019¶

Severity: MUST · Enforcement: validator · Section: Items

an item MUST be a valid STAC item, carrying an id, a geometry and bbox (or null geometry for non-spatial data), a datetime or a start_datetime/end_datetime interval, its assets, and the structural links defined under Links.

PORTO-CORE-020¶

Severity: MUST · Enforcement: process · Section: Items

Item-level detail that other extensions already cover — file, raster, vector — MUST use those extensions rather than being re-specified here.

PORTO-CORE-021¶

Severity: MAY · Enforcement: validator · Section: Items

A partitioned collection MAY represent each partition as an item, but this is not required — see Partitioned Collections for when it is worthwhile.

PORTO-CORE-022¶

Severity: MUST · Enforcement: validator · Section: Assets

Every asset MUST include an href, the URI to the data, with relative or absolute both allowed for now.

PORTO-CORE-023¶

Severity: MUST · Enforcement: validator · Section: Assets

Where an asset href is absolute, it MUST use https rather than s3, since browsers cannot fetch s3 URLs directly.

PORTO-CORE-024¶

Severity: SHOULD · Enforcement: process · Section: Assets

An asset SHOULD also provide s3 or other cloud-native URLs through the alternate extension, so tools that prefer direct bucket access can use them.

PORTO-CORE-025¶

Severity: MUST · Enforcement: validator · Section: Assets

Portolan additionally requires a type, meaning the media type, and at least one role on every asset.

PORTO-CORE-026¶

Severity: MUST · Enforcement: validator · Section: Assets

The required media type for each core format is: | Format | Media type | |--------|------------| | GeoParquet and plain Parquet | application/vnd.apache.parquet | | COG | image/tiff; application=geotiff; profile=cloud-optimized | | PMTiles | application/vnd.pmtiles | | COPC | application/vnd.laszip+copc | | Thumbnail | image/png, image/jpeg, or image/webp |

PORTO-CORE-027¶

Severity: MUST · Enforcement: validator · Section: Assets

Portolan uses the standard STAC role names wherever they fit and requires at least one per asset: data for the primary GeoParquet, COG, or Parquet; visual for the PMTiles rendering derivative; thumbnail for the preview image; metadata for sidecar metadata, with iso-19115 used specifically for an ISO 19115 file.

PORTO-CORE-028¶

Severity: SHOULD · Enforcement: validator · Section: Assets

Assets SHOULD carry file:size and file:checksum from the file extension.

PORTO-CORE-029¶

Severity: MUST · Enforcement: validator · Section: Assets

A file:checksum MUST use multihash encoding, not a raw sha256 string.

PORTO-CORE-030¶

Severity: MUST · Enforcement: validator · Section: Assets

Any file:size and file:checksum an asset carries MUST match the bytes its href resolves to.

PORTO-CORE-031¶

Severity: MAY · Enforcement: validator · Section: Assets

A non-cloud-native representation MAY be included as an alternate asset as long as an equivalent cloud-native primary asset exists (e.g. a GeoJSON alongside the required GeoParquet).

PORTO-CORE-032¶

Severity: MUST · Enforcement: validator · Section: Links

Every catalog, collection, and item MUST include the structural links that make the tree navigable: a catalog or collection MUST include root and parent links (except the root catalog, which has no parent) and a child or item link for every object it contains; an item MUST include root, parent, and collection links.

PORTO-CORE-033¶

Severity: MUST · Enforcement: validator · Section: Links

Every structural link MUST carry a type of application/json (or application/geo+json for links to items).

PORTO-CORE-081¶

Severity: SHOULD · Enforcement: process · Section: Links

A catalog served over the internet from a single fixed URL SHOULD carry an absolute self link on its root catalog.

PORTO-CORE-035¶

Severity: MUST · Enforcement: validator · Section: Links

Every link in a catalog MUST resolve.

PORTO-CORE-036¶

Severity: MUST · Enforcement: validator · Section: Links

A validator MUST resolve each relative link against the catalog's own file tree, whether on a local filesystem or on object storage, and confirm the referenced file is present and is the correct object, rather than merely checking that the href is present or well-formed. A link that fails to resolve, or resolves to the wrong object, is a conformance failure.

PORTO-CORE-079¶

Severity: MAY · Enforcement: validator · Section: Alternate-Language Trees

A catalog MAY publish one STAC object tree for each language. The root catalog links to each translated root with an alternate link, as defined by the STAC Language extension.

PORTO-CORE-080¶

Severity: MUST · Enforcement: validator · Section: Alternate-Language Trees

A translated tree represents the same catalog in another language. It is not part of the containment tree. A catalog MUST NOT link to a translated root with child or item. Each language tree has its own root catalog. That root has no parent link. Every root link in the tree points to that root catalog. Equivalent objects keep the same ID across language trees. A validator MUST treat a translated root as the start of a separate language tree. It MUST NOT report missing containment links or duplicate IDs between language trees.

PORTO-CORE-037¶

Severity: MUST · Enforcement: validator · Section: Human-Readable Titles

every catalog.json and collection.json MUST have a non-empty title and description;

PORTO-CORE-038¶

Severity: MUST · Enforcement: validator · Section: Human-Readable Titles

titles MUST be human-readable, so a raw slug (snake_case) or a technical namespace prefix (ns:LayerName) is not acceptable;

PORTO-CORE-039¶

Severity: MUST · Enforcement: validator · Section: Human-Readable Titles

and every child and item link MUST include a title.

PORTO-CORE-040¶

Severity: MUST · Enforcement: validator · Section: Human-Readable Titles

A validator checks readability heuristically; it MUST flag a title that fails the check, and because heuristics misfire, the finding is a warning, not an error.

PORTO-CORE-041¶

Severity: MUST · Enforcement: validator · Section: Bounding Boxes and Spatial Extent

So every bbox — catalog extent, collection extent, and item — MUST: - contain no NaN or infinite values (including 3D elevation coordinates); - contain no sentinel "effectively infinite" values (e.g. ±1.79e308); - use only WGS84 coordinates in range (longitude -180 to 180, latitude -90 to 90) with south ≤ north; and - in a 3D bbox, order the vertical axis with minimum elevation ≤ maximum elevation.

PORTO-CORE-042¶

Severity: SHOULD · Enforcement: validator · Section: Temporal Metadata

Items SHOULD carry an explicit datetime (or a start_datetime / end_datetime interval) describing when the data applies.

PORTO-CORE-043¶

Severity: MUST · Enforcement: validator · Section: Data Storage

A server hosting the catalog's cloud-native assets MUST support range requests: honor the Range header, return 206 Partial Content, and advertise Accept-Ranges: bytes; HEAD requests MUST return an accurate Content-Length.

PORTO-CORE-044¶

Severity: MUST · Enforcement: process · Section: Data Storage

The server MUST support HTTP/1.1 or greater; HTTP/2 or /3 is RECOMMENDED.

PORTO-CORE-045¶

Severity: MUST · Enforcement: validator · Section: Data Storage

To let browser clients read data directly, a server hosting the catalog's cloud-native assets MUST also enable CORS on all metadata and asset files: Access-Control-Allow-Origin: * (or an equivalent read-permitting policy), allowed methods including GET and HEAD, allowed request headers including Range, If-Match, If-Modified-Since, If-None-Match, and If-Unmodified-Since (via Access-Control-Allow-Headers), and exposed response headers including Content-Type, Content-Length, Content-Range, Accept-Ranges, and ETag (via Access-Control-Expose-Headers).

PORTO-CORE-073¶

Severity: MUST · Enforcement: validator · Section: Data Storage

A validator MUST probe the servers hosting the catalog's own cloud-native assets and MUST NOT require upstream servers to satisfy these requirements.

PORTO-CORE-046¶

Severity: MUST · Enforcement: validator · Section: Providers

Every collection MUST identify the parties responsible for its data through the STAC providers field.

PORTO-CORE-047¶

Severity: MUST · Enforcement: validator · Section: Providers

The list MUST include at least one provider with the producer role, the organization that originally captured or created the data, and exactly one provider with the host role, listed as the last element.

PORTO-CORE-048¶

Severity: SHOULD · Enforcement: process · Section: Providers

Providers with the processor and licensor roles SHOULD be included where they apply.

PORTO-CORE-049¶

Severity: MAY · Enforcement: validator · Section: Providers

A single organization MAY hold multiple roles; a self-published dataset will typically list one provider as both producer and host.

PORTO-CORE-050¶

Severity: MAY · Enforcement: validator · Section: Providers

Catalogs MAY also declare providers, but the collection-level declaration is authoritative.

PORTO-CORE-051¶

Severity: MUST · Enforcement: validator · Section: Providers

The host provider MUST include contact information: a url pointing to a page where the maintainer can be reached, or an email field with a maintainer address.

PORTO-CORE-052¶

Severity: MAY · Enforcement: validator · Section: Providers

A collection MAY additionally use the contacts extension for richer contact information, but doing so does not replace the url-or-email requirement on the host provider.

PORTO-CORE-053¶

Severity: MUST · Enforcement: validator · Section: Source Provenance

A mirror MUST include a via link (type text/html) pointing to the original source.

PORTO-CORE-054¶

Severity: MUST · Enforcement: process · Section: Source Provenance

When that source publishes its own STAC catalog, the mirror MUST also include a canonical link pointing to the source's STAC, so consumers and agents can follow the chain to the authoritative metadata, not just a landing page.

PORTO-CORE-055¶

Severity: MAY · Enforcement: validator · Section: Source Provenance

Whether the source publishes a STAC catalog cannot be determined from the mirror's metadata alone, so a validator MAY surface a mirror without a canonical link as informational, never as a failure.

PORTO-CORE-056¶

Severity: MAY · Enforcement: validator · Section: Source Provenance

The via and canonical links MAY both be present and point at different targets (a human page and a STAC root).

PORTO-CORE-057¶

Severity: MUST · Enforcement: validator · Section: Source Provenance

A mirror MUST record when it was last synced from its source by setting the top-level updated field (RFC 3339) at each synced catalog and collection to the time of the sync.

PORTO-CORE-058¶

Severity: MUST · Enforcement: validator · Section: License

Every collection MUST declare a license in its collection.json.

PORTO-CORE-059¶

Severity: MUST · Enforcement: validator · Section: License

The value MUST be an SPDX license identifier (e.g. CC-BY-4.0, Apache-2.0), or the STAC value other when no SPDX identifier fits, in which case the collection MUST include a license link (rel: license) pointing to the license text.

PORTO-CORE-060¶

Severity: MUST · Enforcement: validator · Section: License

The deprecated STAC 1.1 value proprietary MUST NOT be used.

PORTO-CORE-061¶

Severity: MUST · Enforcement: validator · Section: AGENTS.md

Every catalog and collection MUST include an AGENTS.md in Markdown, referenced in the STAC links array (rel: "agents", type: text/markdown).

PORTO-CORE-062¶

Severity: MUST · Enforcement: validator · Section: README.md

Every catalog and collection MUST have a README.md in Markdown, referenced in the STAC links array (rel: "describedby", type: text/markdown).

PORTO-CORE-063¶

Severity: MUST · Enforcement: validator · Section: README.md

The README.md MUST contain at minimum a title, description, license, and data provenance.

PORTO-CORE-074¶

Severity: MAY · Enforcement: process · Section: Catalog Logo

The root catalog MAY publish a logo as a link with rel: "icon".

PORTO-CORE-075¶

Severity: MUST · Enforcement: validator · Section: Catalog Logo

An icon link MUST declare a type, and that type MUST be one of image/apng, image/avif, image/gif, image/jpeg, image/png, image/svg+xml, or image/webp.

PORTO-CORE-076¶

Severity: SHOULD · Enforcement: validator · Section: Catalog Logo

An icon link SHOULD carry a title.

PORTO-CORE-077¶

Severity: SHOULD · Enforcement: validator · Section: Catalog Logo

The href SHOULD be relative, which keeps the catalog portable for the reason Links gives.

PORTO-CORE-064¶

Severity: SHOULD · Enforcement: process · Section: Metadata

Collections SHOULD include machine-readable metadata (e.g. Apache Ossie) when they have many coded or categorical variables or complex classification schemes, and SHOULD include column descriptions, which will likely become a requirement as tooling matures.

PORTO-CORE-065¶

Severity: MUST · Enforcement: process · Section: Visualization

Every geospatial collection MUST provide a way to render its data with zero infrastructure, either by: - rendering from source — the data asset is small and simple enough for clients to draw directly (e.g. a small GeoParquet, or a COG that is already display-ready, whether through an embedded color table or as a continuous raster colorized at draw time via the render extension and the required min/max statistics); or - a visualization derivative — an additional cloud-native product optimized for rendering, published as a collection-level asset with roles: ["visual"]; PMTiles is the recommended vector format today.

PORTO-CORE-066¶

Severity: MAY · Enforcement: validator · Section: Visualization

Whether an asset is small and simple enough to render from source is not decidable from metadata, so a validator cannot enforce this requirement directly; it MAY advise, as informational, when a large vector collection lacks a visual derivative.

PORTO-CORE-067¶

Severity: MUST · Enforcement: validator · Section: Visualization

Collections MUST include a thumbnail generated from default styling and MUST provide visualization styles as standalone STAC assets appropriate to the render path, except where the render path is self-rendering (a display-ready COG or a small GeoParquet drawn directly), which needs no separate style file.

PORTO-CORE-068¶

Severity: MUST · Enforcement: validator · Section: Visualization Styles

When a collection provides a render path it MUST provide at least one style telling clients how to draw it, in a format appropriate to that render path.

PORTO-CORE-069¶

Severity: MUST · Enforcement: validator · Section: Visualization Styles

Style files are STAC assets: each style MUST be registered as a collection-level asset carrying the style role, alongside the data and thumbnail.

PORTO-CORE-070¶

Severity: MUST · Enforcement: validator · Section: Visualization Styles

when a collection provides more than one style, exactly one style asset MUST carry both style and default in its roles.

PORTO-FMT-001¶

Severity: MUST · Enforcement: validator · Section: Portolan Specification — Formats

STAC allows assets in any format, but Portolan requires that every collection and item is available in a cloud-optimized format, and adds requirements on specific ones: in general GeoParquet and PMTiles for vector, COG for raster, COPC for point clouds, and Parquet for non-spatial data.

PORTO-FMT-002¶

Severity: SHOULD · Enforcement: process · Section: Portolan Specification — Formats

A mirror SHOULD also include the original data as an asset when it is directly downloadable (not just an API).

PORTO-FMT-003¶

Severity: SHOULD · Enforcement: process · Section: Portolan Specification — Formats

Catalogs SHOULD reference alternate formats of data and metadata — for example an existing ISO 19115 file referenced as an asset with the metadata role — though new catalogs need not pre-produce them, since tooling should make translation easy.

PORTO-FMT-045¶

Severity: MUST · Enforcement: validator · Section: Portolan Specification — Formats

A validator MUST apply the format requirements in this document to the catalog's own cloud-native assets and MUST NOT fail an asset for its format because it carries the source role.

PORTO-FMT-004¶

Severity: MUST · Enforcement: validator · Section: GeoParquet

Data MUST be provided in GeoParquet 1.1 or 2.0, following the Best Practices for Distributing GeoParquet so it can be queried without a server.

PORTO-FMT-005¶

Severity: SHOULD · Enforcement: process · Section: GeoParquet

Files SHOULD be compressed to stay small, with zstd RECOMMENDED.

PORTO-FMT-006¶

Severity: MUST · Enforcement: validator · Section: GeoParquet

Rows MUST be spatially ordered so nearby features are nearby in the file. This rule applies to every file, no matter how many row groups it has. A validator checks it by looking at the rows themselves. It splits them into the groups a conforming writer would have produced, then checks that each of those groups covers a small part of the file. A file with five or more row groups gets a second check, using the row groups it actually has. A reader can run this one from the file footer alone, without reading any data. The file passes if either of these is true: - low overlap — fewer than 30% of consecutive row-group pairs have bounding boxes that overlap on their interiors; or - high locality — row-group bounding boxes cover, on average, less than about 30% of the file's total extent.

PORTO-FMT-044¶

Severity: MUST · Enforcement: validator · Section: GeoParquet

A validator MUST NOT fail a file for missing a threshold that its row-group count puts out of reach. Row ordering is a separate rule and is not waived here, so a file with fewer than five row groups is still checked on its rows.

PORTO-FMT-007¶

Severity: MUST · Enforcement: validator · Section: GeoParquet

Files MUST provide per-row-group spatial statistics so readers can skip row groups from metadata alone — either: - a GeoParquet 1.1 bbox covering column with Parquet min/max statistics on its leaf fields (a bbox column without statistics does not qualify); or - for GeoParquet 2.x / Parquet GEOMETRY, native GeospatialStatistics per geometry column chunk.

PORTO-FMT-008¶

Severity: SHOULD · Enforcement: validator · Section: GeoParquet

For 2.x, a covering column remains RECOMMENDED even where native statistics exist, since it adds page-level min/max stats that enable finer-grained pruning.

PORTO-FMT-009¶

Severity: MUST · Enforcement: validator · Section: GeoParquet

Row groups MUST hold no more than 150,000 rows.

PORTO-FMT-010¶

Severity: SHOULD · Enforcement: process · Section: PMTiles

A PMTiles file SHOULD be provided as the visualization derivative, web-map-optimized and range-request friendly.

PORTO-FMT-011¶

Severity: MUST · Enforcement: validator · Section: PMTiles

It MUST be registered through a collection-level rel: "pmtiles" link per the web-map-links extension (v1.3.0): type application/vnd.pmtiles, a pmtiles:layers array of default-visible layers, with the extension's v1.3.0 schema declared in stac_extensions.

PORTO-FMT-012¶

Severity: MUST · Enforcement: validator · Section: PMTiles

The pmtiles:layers array MUST be non-empty; an empty list leaves a client with nothing to display.

PORTO-FMT-013¶

Severity: MAY · Enforcement: validator · Section: PMTiles

when a provider intends the PMTiles file as a genuine distribution format of the data, it MAY additionally be registered as a collection-level asset, and the link and the asset then coexist.

PORTO-FMT-014¶

Severity: MUST · Enforcement: validator · Section: PMTiles

When PMTiles are provided, the collection MUST include at least one visualization style as a standalone STAC asset with the ["style"] role, registered per Visualization Styles.

PORTO-FMT-015¶

Severity: MUST · Enforcement: validator · Section: PMTiles

For PMTiles the style is a MapLibre GL style file (MapLibre GL style spec v8) in a styles/ subdirectory, with media type application/vnd.mapbox.style+json, a complete, self-contained JSON loadable directly by MapLibre GL JS.

PORTO-FMT-016¶

Severity: MAY · Enforcement: validator · Section: Partitioned Collections

Large files MAY be partitioned.

PORTO-FMT-017¶

Severity: MUST · Enforcement: validator · Section: Partitioned Collections

Partitioning MUST be described per the partition extension (v1.0.0), with its schema declared in stac_extensions and its required fields carried — partition:scheme, partition:keys, and partition:glob.

PORTO-FMT-018¶

Severity: MUST · Enforcement: process · Section: Partitioned Collections

The scheme's path structure MUST reflect spatial extent so readers can prune files without reading metadata.

PORTO-FMT-019¶

Severity: SHOULD · Enforcement: process · Section: Partitioned Collections

partition:glob is the normative bulk-access path; the collection description SHOULD also mention the glob for human readers, but validators read only the field.

PORTO-FMT-020¶

Severity: MAY · Enforcement: validator · Section: Partitioned Collections

The https-only rule for absolute asset hrefs does not extend to the glob: globs are consumed by partition-aware readers rather than browsers, and bucket-native schemes (s3://, gs://) MAY be used where those readers need them (glob expansion requires listing, which plain https does not provide).

PORTO-FMT-021¶

Severity: MUST · Enforcement: validator · Section: Partitioned Collections

Every partition file MUST share a single Parquet schema — the same columns, names, and types — so the glob can be queried as one table. This is validated by tooling reading file footers, not by JSON schema.

PORTO-FMT-022¶

Severity: SHOULD · Enforcement: process · Section: Partitioned Collections

Partition files MAY be represented as items when partitions are user-meaningful units (countries, regions); for opaque schemes (hilbert, s2, h3) or hundreds of partitions, items SHOULD NOT be created — the glob pattern is the access path.

PORTO-FMT-023¶

Severity: MUST · Enforcement: validator · Section: Raster

Raster data MUST be provided as Cloud Optimized GeoTIFF (COG) for efficient range-request access without full download.

PORTO-FMT-024¶

Severity: MUST · Enforcement: validator · Section: Raster

Beyond that baseline, a COG MUST conform to OGC 21-026's Optimized GeoTIFF requirements class (/req/optimized_geotiff), which adds three requirements:

PORTO-FMT-025¶

Severity: MUST · Enforcement: validator · Section: Raster

A raster larger than a single internal tile needs internal overviews so a reader can display it zoomed out without fetching full-resolution pixels; one that already fits within a tile is exempt, since it is its own overview. Base COG validators, including rio cogeo validate, treat missing overviews as a warning rather than a failure. Portolan raises this to a requirement.

PORTO-FMT-026¶

Severity: MUST · Enforcement: validator · Section: Raster

COGs MUST carry pixel statistics for rendering.

PORTO-FMT-027¶

Severity: MUST · Enforcement: validator · Section: Raster

Every band MUST carry an embedded minimum, maximum, mean, and standard deviation so a renderer can scale any data type without reading pixels.

PORTO-FMT-028¶

Severity: MUST · Enforcement: validator · Section: Raster

Statistics MUST be embedded in the file — an external .aux.xml (PAM) sidecar does not satisfy this —

PORTO-FMT-029¶

Severity: MUST · Enforcement: process · Section: Raster

and MUST be written at creation time (e.g. gdal_translate -of COG -stats), residing in the file's leading header block so they arrive in a reader's first range request.

PORTO-FMT-030¶

Severity: MUST · Enforcement: validator · Section: Raster

| Minimum, maximum, mean, standard deviation | MUST |

PORTO-FMT-031¶

Severity: SHOULD · Enforcement: validator · Section: Raster

| Valid percent | SHOULD (MUST when the band has a nodata value) |

PORTO-FMT-032¶

Severity: MUST · Enforcement: process · Section: Raster

| Approximate flag (STATISTICS_APPROXIMATE = YES) | MUST when estimated |

PORTO-FMT-033¶

Severity: MUST · Enforcement: process · Section: Tabular (Non-Geospatial)

A tabular collection MUST be distinguishable from a geospatial one so that validators and federation agents relax spatial requirements and route queries correctly.

PORTO-FMT-034¶

Severity: MUST · Enforcement: validator · Section: Tabular (Non-Geospatial)

Data MUST be provided as a Parquet file (application/vnd.apache.parquet) exposed as a collection-level asset with role ["data"], following the single-file collection pattern — no item directory or item JSON.

PORTO-FMT-035¶

Severity: MAY · Enforcement: validator · Section: Tabular (Non-Geospatial)

Where a source file is converted (e.g. a CSV), the original MAY be retained as an alternate asset under the primary-vs-alternate rule, with the Parquet as the primary.

PORTO-FMT-036¶

Severity: MUST · Enforcement: validator · Section: Tabular (Non-Geospatial)

STAC requires extent.spatial.bbox on every collection, so a tabular collection MUST still carry one, but it represents the area of interest the data pertains to, not a geometry footprint, and validators MUST treat it as informational.

PORTO-FMT-037¶

Severity: SHOULD · Enforcement: validator · Section: Tabular (Non-Geospatial)

Tabular collections SHOULD populate extent.temporal when the data has a time dimension, and SHOULD document their columns with the STAC table extension (table:columns with names, types, and descriptions).

PORTO-FMT-038¶

Severity: MUST · Enforcement: process · Section: Tabular (Non-Geospatial)

When geometry and attributes live in separate files (e.g. census geometries joined to a demographics table), the metadata MUST document the join columns explicitly in the README and MUST include a working code example showing how to join them.

PORTO-FMT-039¶

Severity: MUST · Enforcement: process · Section: Point Cloud

Point cloud support is not yet implemented; when complete, data MUST be provided as Cloud-Optimized Point Cloud (COPC).

PORTO-FMT-040¶

Severity: SHOULD · Enforcement: validator · Section: Raster

A raster collection that models scenes as items SHOULD also publish a stac-geoparquet item mirror at items.parquet in the collection root.

PORTO-FMT-041¶

Severity: MUST · Enforcement: validator · Section: Raster

A published item mirror MUST be registered as a collection-level asset carrying media type application/vnd.apache.parquet and the role collection-mirror

PORTO-FMT-042¶

Severity: MUST · Enforcement: validator · Section: Raster

An item mirror is a derived Parquet copy and MUST exactly reproduce the collection's items at publication time: one row per item, with every row containing that item's fields.

PORTO-FMT-043¶

Severity: MUST · Enforcement: validator · Section: Raster

The GeoParquet requirements above apply to item mirrors exactly as they apply to vector datasets. Rows MUST be spatially ordered, the file MUST include per-row-group spatial statistics, and row groups MUST contain no more than 150,000 rows.

PORTO-FMT-046¶

Severity: SHOULD · Enforcement: validator · Section: GeoParquet

A vector collection SHOULD document its columns with the STAC table extension, carrying table:columns with names, types, and descriptions on the collection itself.

PORTO-FMT-047¶

Severity: SHOULD · Enforcement: validator · Section: GeoParquet

An item that carries a GeoParquet data asset, as when partition files are modeled as items, SHOULD carry the same field in its properties.

PORTO-FMT-048¶

Severity: MAY · Enforcement: validator · Section: GeoParquet

A collection whose data assets describe differing schemas MAY declare table:columns per asset instead.