BUG: Fix multi-tile Planet data

[remi-braun]

Some PlanetScope data may come as a bundle of several tiles:

For now, only the first one is processed, so add a mosaicing process before anything (create VRT of the stacks)

Maybe it can be difficult to manage the metadata (name etc.) -> create synthetic metadata? How to manage cloud cover ?

[remi-braun]

Same issue for:

• SkySat Scene
• PlanetScope L3A (Ortho tiles)
• PlanetScope L3B (PS Scene)

[remi-braun]

This is a complicated issue.

• EOReader rule is (for now ?) to handle only single products
• Those products are like several products in only one, with several metadata BUT they have been ordered and distributed like if they were merged

How to handle that? 1️⃣ Create a VRT, but how do we merge the metadata ? (seems the most natural) ✔️ 2️⃣ Create several products but this needs a global change in the Reader().open() function (outputs a list of products instead of one product) ❌ 3️⃣ Only manage the first sub-product (with a warning) ❌ (this is the current and wrong behaviour)

So there is a question of how to merge the metadata

• the metadata handled by EOReader should be quite easy
• the synthetic XML metadata may be a bit harder

Here is the difference between two metadata files for two subproducts of the same product (PSScene) : https://diffonline.net/Qndq9IrvW6 Workaround for the changes:

• identifier: 20210902_093940_06_245d_3B_AnalyticMS_8b vs 20210902_093942_54_245d_3B_AnalyticMS_8b
  ✔️ Choose the latest for the datetime and set XX for satellite_id
  Idem for fileName
• acquisitionDate: 2021-09-02T09:39:40+00:00 vs 2021-09-02T09:39:42+00:00
  ✔️ Choose the latest
  Idem for archivingDate, beginPosition, endPosition, acquisitionDateTime
• incidenceAngle: 4.338212e+00 vs 4.334479e+00
  ✔️ Round to 10-1
  Idem for illuminationAzimuthAngle, illuminationElevationAngle, azimuthAngle, spaceCraftViewAngle
• coordinates
  ✔️ Create a new extent grouping all others
• pos, topLeft, topRight, bottomRight and bottomLeft lat/lon
  ✔️ From new extent
• numRows and numColumns ✔️ Compute from VRT
• reflectanceCoefficient are product dependant ❓ Add them in the VRT file (if possible)

Solution

:one: Create VRT with the corresponding reflectance coefficients, remove stats and coefficients and set the bands in Float32 :two: Take the latest acquired subproduct metadata file :three: Apply the described changes on this XML

[remi-braun]

Same work for SkySatScene : https://diffonline.net/Qndq9IrvW6 Workaround for the changes:

• coordinates
  ✔️ Compute from the VRT
• id: 20220706_060910_ssc19d1_0005 vs 20220706_060910_ssc19d1_0006
  ✔️ set X (or 0) for scene_id
• clear_confidence_percent
  ✔️ Keep the lowest
• clear_percent, satellite_azimuth shadow_percent, view_angle
  ✔️ Compute the mean

[remi-braun]

Same work for PSOrthoTile : https://diffonline.net/5nJ6eavnA9 Workaround for the changes:

• identifier: 5876232_3261410_2022-08-23_2233_BGREN_Analytic vs 5876232_3261411_2022-08-23_2233_BGREN_Analytic ✔️ Choose the latest for the datetime Idem for acquisitionDate and fileName
• tileId: 3261410 vs 3261411
  ❓ Choose what ? Empty the field ?
• incidenceAngle: 4.338212e+00 vs 4.334479e+00
  ✔️ Round to 10-1
• coordinates
  ✔️ Create a new extent grouping all others
• pos, topLeft, topRight, bottomRight and bottomLeft lat/lon
  ✔️ From new extent
• numRows and numColumns ✔️ Compute from VRT