Hello everybody,
we have already mentioned this problem before in the last webinar. At that point, we did not get an answer that explains what exactly is causing it nor how it can be solved. Hence I repeat this question here:
We saw in our LPIS product that many geometries that have a large spatial extend still have no S1 pixels nor S2 pixel and are hence excluded from the classifications.
Looking at a subset (about one quarter of all parcels) of geometries containing only parcels that have no S1/S2 pixels (in the LPIS product) with a GIS, the geometries include many narrow strips (which was expected). Still there are about one third, probably even more of those parcels that are quite large and have uncomplicated shapes. These parcels are also evenly distributed over the whole area.
As this results in quite a significant amount of parcels that are not classified, we would very much like to get a solution on this topic. Can someone (from the board) help us out here?
Is anyone else encountering this kind of problem?
Thank you
Cheers Jonathan
Hello Jonathan,
Can you share the dataset with us so that we could try it here?
Best regards,
Philippe
Hello Philippe,
I am not sure which dataset exactly you are referring to (LPIS-product or declarations or …?). For us it is not so easy to share data this way, as we are working with official data from our PA. If it is necessary for you to have the data to solve this issue we will have to sort out how we can manage this.
For us it would be more convenient to work on this issue in an alternative way.
Maybe there is someone else with a similar issue, who is prepared to share their data?
Cheers,
Jonathan
Hello Jonathan,
Yes, I understand that it is tricky to share. We would only need the limits of the parcels (no attribute).
But meanwhile, I thought about one possible explanation. Can you check if these parcels have the “Duplic” or “Overlap” flags = 1?
When the parcels are imported in the system, they are prepared using the /usr/bin/data-preparation.py. Two shp buffers are generated (-5m and -10m) and these shp buffers are rasterized to create tif layers aligned on S2 (10m resolution with centroid inside -5m buffer) and S1 (20m resolution with centroid inside -10m buffer) data, for each S2 tile extent. These tif layers are then used for ex. for the features extraction of the L4A crop type processor, which accelerate the process (they are generated once for all). And these tif layers are used for counting the number of S2 and S1 pixels used by parcel. So if two or more parcels overlap completely (“Duplic” flag = 1), the first one (or the last one, I should check) in the list will be contained in these tif layers, but not the other ones. So no pixel will be counted for these other ones. If two parcels overlap partly (“Overlap” flag = 1 if more than 10% of the surface parcel overlap another one), the first one (or the last one, I should check) in the list will be contained totally in these tif layers, and the other one will be contained only for the part which does not overlap this parcel. And again the pixels will be counted based on the tifs. In this sense, the system don’t handle the duplicate and overlapping parcels, which has to be removed/corrected before being imported in the system.
Philippe
Hello Philippe,
thanks for your understanding and clarification. Your idea is actually helping a lot. A quick look at the data revealed that indeed a very large portion of the subset with parcels flagged as 0S1 or 0S2 pixel are also flagged with either “Duplic” flag = 1 or “Overlap” flag = 1. Hence I need to get a closer look at those parcels, whether they were overlapping or duplicates in the first place and possibly fix it. If i need further Help, I will contact you here again.
Jonathan