State of SpatioTemporal Asset Catalogs (STAC)

2019

Why STAC?

2

Make geospatial specs differently

• Start with a core set of principles to collaborate
• Embrace open source tools & practices - all work on spec on GitHub
• JSON/REST/HTTP at the core
• Small reusable pieces loosely coupled
• Focus on the developer & implementor - practical & easy to implement
• “we believe in rough consensus and running code”

​

​

5

What is it?

• SpatioTemporal Asset Catalogs
• Language for geospatial catalogs and assets
• Focus on search and discovery
• Simple + Extensible
• Static catalogs and HTTP APIs
• More details in Matt’s talk

​

​

6

What is not?

• Full-fledged metadata standard
• Single source of truth
• Covering all kind of datasets
• Replacement for ISO 19115, OGC CSW, …

7

Who?

• 29 contributors on github
• 10 with 10+ contributions

8

1 Year of STAC

What’s happened since the last ARD conference?

9

1

6 Releases!

• 0.6.0 added Collections
• 0.6.2 SAR / Point Cloud / Data Cube
• 0.7.0 Various Refinements
• 0.8.0(-rc1) coming by end of August! 🤞

​

10

Over 700 Commits

(recent activity is on dev branch and not merged to master yet)

11

12

Sprint at Planet

• 23 in person and ~10 remote participants
• 3 days, our longest yet
• Focus on ecosystem tools
• Major decisions for 0.8.0 release

​

13

Our First Happy Hour!

• At Climate Corp
• 6 lightning talks
• ~50 participants
• Great outreach

14

15

Progress on Original API’s and Ecosystem Tools

• sat-api is up to 0.7.0 and innovating
• sat-utils growing
• Matt to talk about both later today
• Staccato (Java API started by Boundless) now open source!
• OpenEO / Google Earth Engine catalogs have advanced
• CBERS static catalog now has an API

​

16

17

18

19

20

21

22

23

L3Harris

0.7.0 STAC Catalog used internally. Powers:

• IntelliEarth geospatial data resale portal
• Jagwire datastore for Full Motion Video and raster data
• Amplify Utility Asset Management software

24

25

26

27

QGIS search results

28

29

30

Public STAC Catalogs

Landsat

CBERS

Sentinel 2 (S1 coming soon!)

Google Earth Engine (Collections Only)

Spacenet

ISERV

31

Internal / R+D Use

32

And many more!

(I just didn’t get approval to share)

STAC Future

What’s coming next?

33

1

34

35

36

ARD and STAC

• STAC + Cloud Optimized GeoTIFF’s should be ideal format to distribute ARD
• Maybe ARD Extension for STAC, or a set of other extensions
• Goal of some reference ARD catalogs to expose as STAC.

37

OGC and STAC

• STAC has always sought to align with WFS 3 (now called OGC API - Features)
• 0.8.0 will (mostly) harmonize with ‘Draft 2’ for core
• Further dialog on call and at next joint sprint in October
• Focus on ‘Query’, plus WFS extensions

38

Implementation Goals

• STAC Lint able to fully validate extensions
• All major geospatial software vendors implement clients and servers
• All satellite imagery is available in STAC catalogs
• Diverse libraries make it simple to build

39

Specification Goals

• Much better provenance tracking
• Any derived enhancements or analysis should be STAC and easily trace back to their source
• ‘PageRank for geospatial assets’. With ARD + derived data
• Vendor extension conventions
• Decentralized evolution of relevant fields, not just core.
• Stay small, but influence other specs

40

Path to 1.0

• Separate ‘core’ content from API spec
• Item, Catalog and Collection concepts stand on their own
• STAC API to fully align with WFS
• Will follow their speed, finalize after they do, and formalize all the extensions STAC needs
• Go to 1.0.0-beta sometime this winter
• 1.0.0 when extensions mature and more implementations

41

Updating the challenge

• Last year I was

hoping for a billion

STAC Records ‘online’

• Did not define it precisely enough, there are already single STAC instances with over 1 billion records.
• New goal is ‘publicly available’, as internal use has well exceeded the goal, but our goal is to make the commons of imagery accessible to all.

​

42

Thank You!

43

http://stacspec.org

44

45