What you will learn
- How raw satellite data becomes calibrated, usable imagery
- What processing pipelines, tasking, and quality checks involve
- How imagery catalogues and search work for customers
- What delivery formats and licensing controls customers need
- How to phase a platform from one sensor to several
What a satellite imagery processing platform is
An imagery platform is the factory between a satellite's sensor and its customers. Raw data arrives from downlinks, is calibrated and corrected, processed into imagery products at defined levels, catalogued with metadata, and delivered to customers through search and ordering. The platform's value is throughput and consistency: customers receive comparable products on a predictable schedule, not hand-processed files.
Metadata is what makes the catalogue useful. Acquisition time, location, cloud cover, sensor, and processing level let customers find the imagery they need without opening every file. A platform that stores imagery without rich metadata is a hard drive, not a catalogue.
Core features
Pipeline reliability and catalogue search define the product.
- Raw data ingestion from downlinks and partner sources
- Calibration and correction pipelines with quality checks
- Product levels from raw data to analysis-ready imagery
- Catalogue with spatial, temporal, and cloud-cover search
- Ordering and delivery with format and licensing controls
- Processing monitoring, failure handling, and reprocessing workflows
How it is built
Start with one sensor's pipeline and catalogue, then add sensors and customers.
- Ingestion: raw data intake, validation, and storage for one sensor
- Pipeline: calibration, correction, and product generation with quality checks
- Catalogue: metadata, search, and ordering for the first products
- Delivery: formats, licensing, and customer access
- Scale: more sensors, tasking integration, and customer tiers
Technology choices
Processing pipelines should be built as repeatable, versioned steps, so a product can be regenerated when calibration improves or a defect is found. Ad-hoc processing scripts that cannot be rerun consistently will not survive operational use.
Storage and compute planning matter early. Imagery volumes are large, and processing is compute-heavy; cloud or on-premise choices should be made from measured data rates, not assumed ones.
Challenges to plan for
Quality control is the bottleneck. Automated checks catch gross errors, but subtle calibration or geolocation issues need human review and sample inspection, and the pipeline should route suspect products to review rather than delivering them.
Licensing and access control need care. Imagery may carry distribution restrictions, and the delivery layer should enforce per-customer licensing rather than relying on customers to respect terms.
Who it is for, and its limits
Imagery platforms fit Earth observation operators, satellite companies selling data, and organisations processing imagery for agriculture, mapping, or monitoring. They fit any operator whose data volume exceeds manual processing.
Processing does not interpret imagery. Analysis — crop health, change detection, mapping — is a customer or downstream application; the platform delivers consistent imagery products for that analysis.
What a first release looks like
A first release should process one sensor's data into one product level, with a catalogue searchable by location, time, and cloud cover, and delivery to the first customers. Additional sensors and product levels come later, once the pipeline has run operationally for a month, including a failed product that was detected by quality checks and reprocessed. The catalogue must be proven searchable by customers who did not build it, because a catalogue only its builders can search is a storage system.
The test case is a customer needing recent imagery of a farming region with less than twenty percent cloud cover. The customer searches by area and date, finds three candidate scenes with cloud figures and acquisition times, orders one, and receives it in the requested format with a licence attached. Meanwhile a processing failure on another scene is caught by quality checks, flagged for reprocessing, and never delivered as a defective product. If customers must ask staff to find imagery, the catalogue has failed.
A mistake worth avoiding
The mistake worth avoiding is delivering imagery without automated quality control, trusting that customers will report defects. Customers often do not report subtle defects — a geolocation shift, a calibration drift, a cloud mask error — they simply stop trusting the data and stop ordering, without telling the operator why revenue fell. The discipline is gate-based quality control: automated checks on geometry, radiometry, and metadata before delivery, with suspect products routed to human review and never delivered silently. A defective product delivered once costs more in lost trust than the reprocessing delay it would have taken to catch it.
Frequently asked questions
What are product levels?
Stages of processing from raw sensor data to calibrated, corrected, analysis-ready imagery. Each level adds correction and usability, and customers order the level their work needs.
Why does metadata matter?
Because search depends on it: location, time, cloud cover, sensor, and processing level let customers find suitable imagery without opening files.
How are processing failures handled?
Through monitoring, alerting, and reprocessing workflows, so a failed product is regenerated rather than silently missing.
Can customers task the satellite?
Tasking can be integrated, so orders for future acquisitions flow into mission planning, subject to feasibility and priority.
How much does it cost to build?
Cost depends on sensor count, data volume, product levels, and customer tiers. One sensor's pipeline is far smaller than a multi-sensor commercial platform, so confirm with a scoped quote.