Attributing L2A to multiple sites


I was wondering if there’s any downside to attributing L2A products to multiple sites - I’m planning to split a site into multiple sub sites, and instead of looking which already processed products belong to which sub-site, I’d rather attribute to all of them.

I assume the obvious problem would be with higher level processing, that all data is used which is listed for a site in the database table, so in this case there would be redundant processing. Am I correct? Any easy workarounds or tips?

Many thanks.

Sorry, I’m not sure I understand. Right now a product (L2A or otherwise) can only belong to a single site. To have a single product for multiple sites you’d have to insert more than one row in that database table pointing to the same disk location.

If you do that – as you suspected – all L2As will be used for all of the sub-sites. So instead you should properly assign them to the sub-sites. The simplest way to do that is to use the tile list that’s already stored in the database for each product. This query, for example, will return the products containing one of the 29PNP and 29PRP tiles:

select * from product
where processor_id = 1
  and site_id = 73
  and tiles :: text[] @> array['29PNP', '29PRP'];

I was referring to the script. In the FAQs there’s this example:

# import one L2A product to the Sudan site
# use the short name from the web interface -s sudan -p l2a -t l2a -d product_path

So I assumed if you run this with a L2 product which already belongs to a site, it will be attributed for 2 sites. But now I see that’s not possible.

My problem is that I’ve processed already products (mostly Landsat) for a site (country scale), but now I want to split said site into multiple sub-sites. I was hoping there would be an easy way to attribute the already processed L2s to the corresponding sub-sites without having to manually check which products intersect which sites and manually changing the site_id in the product table.

There is, using a variant of the SQL query I shown above. But that’s right, it’s a manual process.

So if I understand correctly, I need to know the tile IDs or paths/rows beforehand for each site.

So if I understand correctly, I need to know the tile IDs or paths/rows beforehand for each site.

Assuming you’ve already created the sub-sites, you can easily find those out:

select * from sp_get_site_tiles(73 :: smallint, 2 :: smallint); -- site_id, satellite_id

Excellent! Is this info available instantly (i.e. after creation of the site and before the data download) or will it be gradually inserted into the db with every new tile downloaded?

And a related question:

If a tile is already downloaded/processed for another site, it doesn’t have any influence on the new site? Meaning if I happen to have 2 distinct sites where for instance 1 S2 tile intersects, the acquisitions of that tile will be downloaded and processed for each site independently even though it might already be available processed on disk one of them?

The tiles for a site are available right from the start. There’s also a way to manually set them, as you’ll probably get some neighbouring ones otherwise. But oof course, the tiles in each product are only filled in when the product is inserted into the database.


1 Like