Planet integration: Initial database schema #113

New issue

Closed

opened 2026-07-15 19:21:29 +00:00 by eliribble · 1 comment

eliribble commented

2026-07-15 19:21:29 +00:00

Owner

With the completion of #111 we should now have the ability to talk to Planet. We need to go from there to beginning to populate the database with information about the satellite images we have purchased. I'd like you to look at the data that is available from the planet API and propose a database schema in nidus-sync. The schema can just be called planet. We need to keep track of the metadata about an image like when it was created, time of day, the source sensors, how many bands it has, the geographic area covered (use PostGIS types for this), the external identifiers, and any other data you think may be useful. You can look at the go-planet submodule to get ideas about what information is available. It's probably a good idea to reference the Nidus Reveal design and implementation in doc/nidus-reveal to make sure we have all the data we'll need.

With the completion of #111 we should now have the ability to talk to Planet. We need to go from there to beginning to populate the database with information about the satellite images we have purchased. I'd like you to look at the data that is available from the planet API and propose a database schema in nidus-sync. The schema can just be called `planet`. We need to keep track of the metadata about an image like when it was created, time of day, the source sensors, how many bands it has, the geographic area covered (use PostGIS types for this), the external identifiers, and any other data you think may be useful. You can look at the go-planet submodule to get ideas about what information is available. It's probably a good idea to reference the Nidus Reveal design and implementation in doc/nidus-reveal to make sure we have all the data we'll need.

ned was assigned by eliribble

2026-07-15 19:21:29 +00:00

ned referenced this issue from a pull request that will close it,

2026-07-15 19:24:03 +00:00

Add Planet initial database schema #114

ned commented

2026-07-15 19:24:10 +00:00

Member

#114 is up with the proposed planet schema.

What I found in go-planet

After digging through the go-planet submodule, the Planet API provides these data categories for each image item:

Identity: item ID, item type (PSScene, SkySatScene, etc.), satellite ID, strip ID, provider
Acquisition: acquired timestamp, published/updated timestamps, ground control flag
Geometry: GeoJSON footprint of the scene
Quality: cloud cover, cloud percent, clear percent, haze, shadow, snow/ice, visible percent
Sensor angles: view angle (off-nadir), satellite azimuth, sun azimuth, sun elevation
Resolution: GSD (ground sample distance), pixel resolution
Assets: array of available asset type identifiers (analytic_sr, ortho_analytic_4b_sr, etc.)
Permissions: download permission strings
Orders: order ID, name, source type, state, bundles, delivery/hosting config

Schema design

Five tables in the planet schema:

Table	Purpose
`planet.item`	Individual satellite image metadata — the core table. PostGIS geometry, all quality metrics, sun/sensor angles, available assets, permissions, generated capture_date/capture_hour columns
`planet.sensor`	Normalized sensor/satellite catalog with band info and GSD range
`planet.item_asset`	Per-item purchased asset tracking (download status, URLs)
`planet.order`	Planet Orders API purchase records with delivery/hosting config
`planet.order_item`	Junction linking items to orders with bundle type and download tracking

Nidus Reveal alignment

The schema captures all the metadata the nidus-reveal design doc calls out (§10.3): solar_azimuth, solar_elevation, view_angle (off-nadir), cloud_cover. The PostGIS geometry and GSD fields enable the high-res / medium-res layer classification.

#114 is up with the proposed `planet` schema. ## What I found in go-planet After digging through the go-planet submodule, the Planet API provides these data categories for each image item: - **Identity**: item ID, item type (PSScene, SkySatScene, etc.), satellite ID, strip ID, provider - **Acquisition**: acquired timestamp, published/updated timestamps, ground control flag - **Geometry**: GeoJSON footprint of the scene - **Quality**: cloud cover, cloud percent, clear percent, haze, shadow, snow/ice, visible percent - **Sensor angles**: view angle (off-nadir), satellite azimuth, sun azimuth, sun elevation - **Resolution**: GSD (ground sample distance), pixel resolution - **Assets**: array of available asset type identifiers (analytic_sr, ortho_analytic_4b_sr, etc.) - **Permissions**: download permission strings - **Orders**: order ID, name, source type, state, bundles, delivery/hosting config ## Schema design Five tables in the `planet` schema: | Table | Purpose | |---|---| | `planet.item` | Individual satellite image metadata — the core table. PostGIS geometry, all quality metrics, sun/sensor angles, available assets, permissions, generated capture_date/capture_hour columns | | `planet.sensor` | Normalized sensor/satellite catalog with band info and GSD range | | `planet.item_asset` | Per-item purchased asset tracking (download status, URLs) | | `planet.order` | Planet Orders API purchase records with delivery/hosting config | | `planet.order_item` | Junction linking items to orders with bundle type and download tracking | ## Nidus Reveal alignment The schema captures all the metadata the nidus-reveal design doc calls out (§10.3): solar_azimuth, solar_elevation, view_angle (off-nadir), cloud_cover. The PostGIS geometry and GSD fields enable the high-res / medium-res layer classification.

ned closed this issue

2026-07-15 19:25:08 +00:00