I have a question concerning the Crop Type Classification. As far as i understand, it always runs the classification with a inner Buffer of 10m for every parcel.
Is there any way I can change that parameter using the Web User Interface?
That way we could try to get better results for small parcels or parcels with complex geometry that we are right now not able to assess.
Thank you!
Hello @Okke_Gerhard,
So, for the L4A crop type classification, the extraction of the markers (S1 and S2 derived values) for the classification is done as follows.
For S2:
- 5m inner buffer of the parcels shp (half of the 10m S2 L2A products resolution)
- rasterization (fixed on S2 grid) and for each parcel, selection of the pixels that have their centroid inside this buffer -> will be the pixels used for the markers extraction for that parcel
For S1: the same but with a 10m buffer given the S1 amplitude and coherence products 20m resolution.
This is the best way that we found to include as many parcels as possible for the markers extraction and to be sure that the extracted information concerns the parcel and not the surrounding. It is already quite permissive because it can happen that a small part of a pixel (a corner) is outside the parcel.
Then, by default, only the parcels that contain minimum 3 S2 pixels and 1 S1 pixel are classified. But there is one thing that we often do to increase the number of classified parcels:
- first, we perform the by default classification with S1 and S2 markers and with the minimum S2 pixels and S1 pixels parameters settled to 3 and 1, respectively
- secondly, we perform a classification with S2 markers only, and with the minimum S2 pixels and S1 pixels parameters settled to 3 and 0, respectively; this can be done using the custom jobs tab with the selection of the advanced parameters
- then, we merge the two results, using the results of the first classification when it exists, otherwise we use the results of the second classification
Did you try this already?
Best regards,
Philippe
Illustration of our approach for the buffering and markers extraction, for the L4A crop type processor
Hello @Philippe_Malcorps,
thank you for your advice. I did try to do the same processing but encountered some difficulties.
The default processing with minimum S2/3 and minimum S1/1 did work out. However, changing the processing to only the S2 markers did not change anything in the result. I received the exactly same results. I guess, I did some wrong configuration (I de-selected S1 in the Custom Jobs - L4A Crop Type - Filter Criteria for Input Types). I also tried to run another processing with S1 de-selected and minimum pixel changed to 0. But still got the same results.
For my understanding:
The minimum Pixel Number means, that a feature need to have for example at least 3 S2 pixel and 1 S1 pixel to be assesset or does one of both conditions need to be fullfilled (3 S2 pixel OR 1 S1 pixel)?
With best regards
Okke Gerhard
Hello Okke,
For your question, it is well an “AND” that the parcel needs to fulfill: at least 3 S2 pixels AND 1 S1 pixel.
If you want to increase the number of parcels by processing a classification with S2 markers only:
- you need to change the Mode to “s2-only” (as you did);
- but you need also to change the parameter Minimum number of S1 pixels to 0 -> for that you need to click on the Show advanced parameters button (up-right) and change this parameter.
Let me know if you encounter another difficulty.
Best regards,
Philippe
Hello Okke,
On top of what I said in my last message, you should obtain different results with both S1 and S2 markers, and with S2 markers only. In fact, we noticed a problem in the S1 markers extraction in the version 1.1 of the system which prevents their use. By moving the database to a dedicated container (one novelty of version 1.1), we decided to switch to the by-default version of GDAL from CENTOS (I think to be able to better integrate the continuous updates of GDAL, to confirm). But this GDAL version do not recognize the projection of the S1 preprocessed products. It was fixed in other parts of the system, but not in the L4A crop type processor. We are working and testing right now a solution and I will let you know when this will be ready.
Sorry for the inconvenience.
Philippe
Hello again,
I created a dedicated topic which explains how to update the L4A crop type processor with the corrections that we have been working on (new version of the crop-type-parcels.py script). By doing this update, the processor should work as it should be.
Best regards,
Philippe
Thank you,
i will be looking into it an see if your advice helps to achieve a better result.
Best Regards
Okke Gerhard