You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After doing some more fine grained testing, I've found using the mean area only for area calculation is sometimes too inaccurate.
Usually it evens out across the entire AOI, but for more granular calculations that might only look at the northern or southern end of the AOI, it can get off. For example, if you want to get loss in a specific protected area in the AOI, but the protected area is only overlapping the top of the AOI.
Doing the full calculation with area for each pixel latitude was too performance intensive last time. Going to experiment with some faster ways to get a close approximation.
The text was updated successfully, but these errors were encountered:
Update: tried increasing area precision, but the area was still off in the same way. I think the issue isn't precision in the area calculation, which only makes it a fraction of a percent more accurate, but the counting.
The issue only seems to be noticeable (i.e. more than 1% off) for very smaller areas, and the difference in area only ends up being equivalent to 3 or 4 pixels. My guess is that issues occurs during rasterization of the geometry: some pixels on the edge might count as part of the geometry in one algorithm but not another. The lambda is using Shapely but Geotrellis is using JTS.
So the whole thing might actually be a few pixels off, it's just only a noticeable difference for smaller geometry. It's still less than 2% difference for those geometries. It should be fine for now, and I'll do a deep dive later into what the different might be.
After doing some more fine grained testing, I've found using the mean area only for area calculation is sometimes too inaccurate.
Usually it evens out across the entire AOI, but for more granular calculations that might only look at the northern or southern end of the AOI, it can get off. For example, if you want to get loss in a specific protected area in the AOI, but the protected area is only overlapping the top of the AOI.
Doing the full calculation with area for each pixel latitude was too performance intensive last time. Going to experiment with some faster ways to get a close approximation.
The text was updated successfully, but these errors were encountered: