Planetscope data ordering feedback

I have successfully ordered and visualised some PlanetScope data using the new system.

Some feedback/questions so far:

1a. Ordering is a 2 step process, creating the order, then confirming it. It is useful to create it to check the km2 usage before confirming, and I did that many times to test and understand the system. However, a new BYOC collection is created each time an order is created, not when it is confirmed, so I had (and had to manually delete) many empty collections. It might make sense to only create the collection when the order has been confirmed to avoid this.
1b. As a result of 1a, if one deletes a collection before the order has been confirmed, the order fails. I guess this shouldn’t be a common problem though - just an observation.

  1. Do I understand correctly that the “analytic” product doesn’t include a cloud mask, and that the “basic_udm” or “basic_udm2” products/assets are not available? This limits the usefulness of the data…

Thank you for this feedback. It very much appreciated!

For 1 - very good points, have to consider how to address them most efficiently.
For 2 - this is correct, but just for the short-term. We have had to limit the features for the first iteration in order to actually put it out there. But certainly in our plans. Cloud mask (or rather “useful pixels mask”) is first in the priority, but we will look in other assets as well!


Glad to hear that cloud masks, or useful pixel masks etc. are in mind. This is really key.

Next questions:
3. How can I tell how much area I have left in a package?
4. Is there a way of merging BYOC collections? For example, if I make separate orders for a number of different AOIs, then I get a different ID for each, and need to set up a different configuration layer for each. Is there a way of merging them so I can set up a single layer which returns data for any of a large number of orders?

You will get a response along the lines:

    "data": [
            "id": "<USER_ID>",
            "quotaSqkm": <YOUR_ALLOCATED_QUOTA>,
            "quotaUsed": 0.0,
            "datasetId": "AIRBUS_PLEIADES"
            "id": "<USER_ID>",
            "quotaSqkm": <YOUR_ALLOCATED_QUOTA>,
            "quotaUsed": <YOUR_QUOTA_USED),
            "datasetId": "PLANET_SCOPE"

AT2: Best way is to provide an existing collection ID at the time of the order, e.g.:

    "name": "planet products",
    "collectionId": "f4a28a33-<MASKED>",
    "input": {
        "provider": "PLANET",

If you are passed this step, we can merge collections for you, assuming they are composed from the same data source. There is no tool yet available for you to do that, which is why we are happy to do this for you.

Alternative option woudl be to use data fusion option of the process API, but I think this would be an overkill in terms of complexity.

Re quotas:
That worked, but it looks like quota was used up even for the failed order (see 1b above - my own silly fault though).
My orders so far:
[(‘CREATED’, ‘5.76km2’),
(‘FAILED’, ‘6.2km2’),
(‘DONE’, ‘6.2km2’),
(‘CREATED’, ‘0.94km2’),
(‘CREATED’, ‘21.34km2’),
(‘CREATED’, ‘5.98km2’),
(‘CREATED’, ‘0.11km2’),
(‘CREATED’, ‘21.34km2’)]

My Planet Scope quota:
{‘id’: xxxxxx,
‘quotaSqkm’: 100.0,
‘quotaUsed’: 12.405376482889988,
‘datasetId’: ‘PLANET_SCOPE’}

Re merging collections: Thanks for the offer, but fortunately I didn’t yet make more than one order, so thanks for the future solution.

  1. If I access the data using e.g. the OGC api, can I filter by cloud cover (like I can for the data order) as for sentinel data, or only by date?

Oh dear, this seems to be a bug on our side. If you do not mind, I would leave it for a while as it is on your account, so that we can debug it. But in case you come close to the upper limit, please let us know so that we compensate you immediately.

For the moment, BYOC datasets (which is what we are using for PlanetScope and Pleiades as well) only allow filtering per date. It’s a good idea though!

No problem, I’ll let you know when I get close to the upper limit.