ON THIS PAGE
A satellite-imagery enquiry can be technically simple and still be commercially clear. The buyer does not need to know the satellite name, product code or processing terminology. What matters is communicating the location, time requirement, intended use and expected output accurately enough for the imagery team to recommend the right route.
A weak request often begins with a product assumption. A strong request begins with the project.
1. Define the area of interest accurately
The AOI determines coverage, feasibility, scene selection and commercial sizing. The best format is a GIS boundary, but a first enquiry can begin with simpler information.
Useful AOI formats
- KML/KMZ;
- GeoJSON;
- zipped shapefile;
- coordinates;
- polygon drawn on a map;
- marked-up screenshot or PDF;
- place name plus description.
If the AOI contains several disconnected sites, provide them separately if possible.
Do not enlarge the AOI to guess a minimum order
Send the real operational AOI. SIME can confirm how applicable minimum-order rules affect the commercial footprint. Around 100 km² can be a useful planning reference for many high-resolution projects, but smaller requirements can still be reviewed depending on product and coverage.
2. Explain the time requirement
“Recent imagery” can mean very different things. To one project, imagery from the previous year is recent. To another, anything older than two weeks is unusable.
- Historical: imagery from a past year/date range;
- Latest available: most recent suitable archive scene;
- Future window: new collection during a defined period;
- Before/after: two dates around an event;
- Recurring: monthly, quarterly, seasonal or event-driven monitoring.
3. Describe the purpose in operational language
- confirm construction progress;
- update an urban-planning basemap;
- identify new buildings;
- monitor land clearing;
- assess a utility corridor;
- create a historical development timeline;
- support real-estate site assessment;
- provide current context for emergency planning.
4. State the smallest feature that matters
This is one of the best ways to guide resolution selection.
- Do we need to detect the feature?
- Do we need to classify it?
- Do we need to measure it?
- Will a human analyst interpret it?
- Will a computer-vision model use it?
5. Decide whether archive or new tasking is likely
If the project needs a historical date, archive search is the obvious route. If it requires current or future conditions and no suitable archive scene exists, new tasking may be evaluated.
6. Cloud tolerance should reflect the important AOI
A scene-level cloud percentage can hide local problems. Five percent cloud sounds low, but if the cloud sits directly over the project site the image may be unusable.
- must the full AOI be cloud-free?
- is cloud outside priority zones acceptable?
- can partial coverage be combined from several scenes?
- can the project wait for a clearer collection?
7. Consider viewing angle in dense urban areas
High off-nadir imagery can increase building lean and occlusion. If ground visibility between tall structures matters, mention it.
8. Define spectral requirements only when they matter
Many users need a high-quality natural-colour visual product. Others need multispectral data for vegetation, environmental or analytical workflows.
9. Describe the required processing level
- map-ready imagery;
- orthorectified imagery;
- pansharpened imagery;
- multispectral imagery;
- mosaicked coverage;
- colour-balanced basemap;
- elevation/3D data;
- streaming/subscription access.
10. Specify coordinate system if the project has one
GIS and engineering projects may require a particular projected CRS. Including this early avoids unnecessary reprojection and confusion.
11. Explain how imagery will be used and shared
- used by one internal project team;
- shared across an enterprise;
- provided to consultants;
- used in a client deliverable;
- published in a web portal;
- used in a public-facing application;
- used in analytical or AI workflows.
12. Decide whether files or platform access are appropriate
Traditional delivery may use download, cloud transfer or physical media. Recurring users may benefit from Vantor Hub or API access instead.
13. Give the project schedule, not only the desired image date
- archive search;
- tasking feasibility;
- collection;
- processing;
- quality control;
- delivery;
- internal review.
14. Explain whether monitoring will continue
A one-time order may be structured differently from a programme that repeats for several years. Recurring coverage may influence tasking strategy, subscription options, licensing and data-management design.
15. Include procurement constraints if known
- fixed budget periods;
- annual contracts;
- framework agreements;
- specific license language;
- required vendor documentation;
- security or data-handling conditions.
Common reasons imagery quotations are delayed
Supplier response becomes slower when the AOI is unclear, the date requirement is ambiguous or the intended use is missing. “Please quote imagery for Dubai” can trigger several rounds of clarification.
Do not combine unrelated AOIs without explanation
If a project contains multiple sites, identify them clearly and explain whether they belong to one programme. Separate AOIs can have different archive availability, tasking feasibility and commercial treatment.
Specify whether partial coverage is acceptable
Some projects can begin with partial archive coverage while remaining areas are tasked. Others require a complete uniform dataset before work can start.
Think about acceptance criteria before procurement
For larger programmes, define what constitutes an acceptable delivery: coverage completeness, date window, cloud over AOI, processing level, coordinate system, file integrity and metadata.
A strong request can still be short
We need current high-resolution imagery for a 180 km² development area in Abu Dhabi. The imagery will be used to review construction progress and update our enterprise GIS. We prefer imagery collected between October and December 2026, with low cloud over the development footprint. The data will be shared internally and with our planning consultant. Please advise whether suitable archive imagery exists or new tasking is recommended, and whether 30 cm native or 15 cm HD is more appropriate.
Imagery-request checklist
- AOI attached?
- Date/time requirement stated?
- Purpose explained?
- Smallest relevant feature described?
- Archive/tasking preference stated if known?
- Cloud tolerance stated?
- Processing requirements stated?
- Coordinate system stated?
- Usage/sharing model explained?
- Delivery/platform preference stated?
- Project deadline stated?
- Recurring monitoring identified?
What SIME does after receiving the request
SIME can review the AOI, search suitable archive options, assess new WorldView tasking where required, compare 30 cm native and 15 cm HD options, define processing and delivery, and confirm the applicable licensing and commercial route.
Start here: Request Satellite Imagery.
Include preferred delivery method when known
Large imagery datasets may be delivered by download, cloud transfer, physical media or through a subscription/service environment. If the client has network or security restrictions, state them early so the proposed delivery is practical.
Explain whether source imagery or only a final mosaic is required
Some organizations want only a processed basemap. Others need original scenes as well for analysis, audit or future reprocessing. The quotation and storage plan can differ depending on whether source products are included.
Request metadata explicitly
For long-term enterprise use, acquisition date, source product, processing level, coordinate system and license information should remain associated with the delivered imagery.
State whether imagery will feed an AI or automated workflow
Machine-learning applications may have requirements around consistency, spectral bands, bit depth, tiling and licensing. Mentioning the intended AI use during procurement can prevent rework later.
For recurring programmes, define cadence and trigger conditions
Monitoring may be calendar-based—monthly or quarterly—or event-driven, such as after a construction milestone, storm or regulatory trigger. Defining cadence helps determine whether repeated tasking or a subscription model is more appropriate.
Keep technical and commercial requirements connected
A very restrictive technical specification can reduce available imagery and increase cost. If a condition is preferred rather than mandatory, label it accordingly so the supplier can offer alternatives.
Provide a contact who understands the operational purpose
Technical procurement can move faster when the imagery supplier can clarify questions with someone who understands the project objective. A procurement contact alone may not know whether date flexibility, cloud tolerance or partial coverage is acceptable.
Separate mandatory requirements from preferences
If every criterion is written as mandatory, a supplier may have no compliant option even when a very useful alternative exists. Distinguish “must have” from “preferred” for date, angle, cloud, resolution and delivery.
For historical studies, list all required epochs
Do not request “historical imagery” generically. List target years or event windows. This allows archive search to focus on meaningful periods and helps identify where exact dates are unavailable.
For monitoring programmes, define how results will be compared
If imagery will support change detection, state whether the comparison is manual, GIS-based or automated. Automated comparison may require stricter co-registration and radiometric consistency than visual review.
Clarify who will process the imagery
If the client has an internal remote-sensing team, source or minimally processed data may be appropriate. If the client expects a ready-to-use basemap, additional orthorectification, mosaicking and colour balancing may be required.
