Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

True CPC per pixel measures #64

Open
mdales opened this issue Oct 9, 2023 · 3 comments
Open

True CPC per pixel measures #64

mdales opened this issue Oct 9, 2023 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@mdales
Copy link
Contributor

mdales commented Oct 9, 2023

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.

@mdales mdales added the enhancement New feature or request label Oct 9, 2023
@swinersha
Copy link
Collaborator

swinersha commented Oct 10, 2023

Michael. Thanks for summarising the issue. That sounds correct to me.

The only thing to not is that it would be good to run some sensitivity tests on what size neighbour hood to use. So at some point we might need to compute a few versions using different neighbourhood sizes.

@robinmessage robinmessage self-assigned this Oct 10, 2023
@robinmessage
Copy link
Collaborator

@swinersha @mdales I just wanted to note that an (approximate) gaussian blur would be much quicker to calculate, so we could do that if it would be better. No worries if not, at least we only have to do this once.

@mdales
Copy link
Contributor Author

mdales commented Oct 10, 2023

Given the process we've been through thus far in testing, I suspect the first step would be to implement something basic and then check It matches Tom's GEE data, assuming we can extract it, and then improve from there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants