Skip to content

True CPC per pixel measures #64

@mdales

Description

@mdales

This was discussed at the meeting last week. Currently in our implementation of CPC we use a downsampling based method, where we just take the 30x30m per pixel resolution JRC data, filter per LUC we care about (there's only two), and from that we build a coarsened low resolution raster of 1200x1200m per pixel, by just taking 40x40 pixel square at JRC resolution and summing them up and dividing by the number of pixels used (this allows for the source raster not to be perfectly round to the nearest 40 pixels).

It turns out that in @swinersha's implementation he uses this style of raster for the first two uses of CPC, and then for the final pixel matching he uses a "true" CPC raster, which is where for each pixel at the JRC resolution you make a circle around that pixel of 1200m and then filter by LUC and average. This is more accurate, but more costly to calculate - I guess that's why it's only done at the end, because by this point you've got rid of a lot of data.

However, given it's a one time cost we could pre-calculate, we could in theory do this JRC scale "true" CPC raster once in our pipeline per JRC update. In the meeting on Friday it was agreed that the eventual aim would be to use "true" CPC for all three stages where CPC in needed in the methodology.

Thus there are the following tasks to do:

1: Write some code to generate "true" CPC rasters at JRC scale.
2: Start using those in Find Pairs to match Tom's current implementation.
3: Eventually replace all CPC usage with these new rasters.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions