Clarify which ISRM was used for CARB report

dholstius commented 2 years ago

Question for the UW team:

Q. Which ISRM was used to generate the results in the CARB report? Was it:

a. The contiguous-US ISRM hosted on Zenodo; or b. The California-specific ISRM shared via Google Drive ?

The former ISRM has 51k cells, ~9k of which are “California”. We’ve received polygons corresponding to that ISRM for the whole US, and that’s great. The former is also the basis for the iF calculations in issue #1.

The latter ISRM has 21k cells. I'm not sure we’ve received corresponding geometries for it (?) The latter also seems to be the basis for the CARB report; p. 11 says there are 21k "emission locations."

And, if I map the Bay Area based on the polygons we've received to date (i.e., those for the contiguous-US ISRM), it seems like the map is not quite right. Compare, for example, the same areas (circled in red) on the two maps below. The smallest cells are always ~1 km², but it seems like there are more cells in the CARB-report map. So it's not really "higher-res" — but there are more 1 km² cells.

Map based on polygons received (as of 2022-04-22):

Map found in CARB report (p. 11)

Related Issues

1
3

dholstius commented 2 years ago

It seems like we should only comparing the "Richmond iF example" (p. 20 of CARB report) to issue #1 if they share the same basis (i.e., ISRM).

dholstius commented 2 years ago

I think most of the content we've been talking about for the "demo handoff" has been based on the US ISRM, rather than the CA ISRM.

joshapte commented 2 years ago

The CARB report you reference (and the Richmond example) uses the 21k cell ISRM matrix we developed for this project.

bujinb commented 2 years ago

Yes, the demo was done using the US ISRM which has ~9000 grid cells for California.

joshapte commented 2 years ago

I would be surprised if the two different ISRMs gave meaningfully different iF results, but that's worth looking into to eliminate this possibility.

dholstius commented 2 years ago

@bujinb, can you share the CA ISRM cell polygons? Via Dropbox is fine, or you can upload them here, if that's easier. Thank you!

bujinb commented 2 years ago

I'm asking for the CA ISRM polygons from Sara Chambliss, will upload in a day or two @dholstius Also currently working on the IF map, will share it by Wednesday.

joshapte commented 2 years ago

I think Libby may have the shapefile or other associated spatial data for this inmap dataset. On Apr 25, 2022, 12:02 PM -0700, bujinb @.***>, wrote:

I'm asking for the CA ISRM polygons from Sara Chambliss, will upload in a day or two @dholstius Also currently working on the IF map, will share it by Wednesday. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

bujinb commented 2 years ago

Hi! The shape file for CA ISRM is in the dropbox @dholstius

https://www.dropbox.com/home/Bay%20Area%20ISRM/Data/CA%20ISRM

Thank you @joshapte

dholstius commented 2 years ago

Thanks all! I see a couple of things and would like to make a friendly suggestion about process ...

@bujinb has uploaded a shapefile InMAP_gridCells to Dropbox.
Libby (GitHub ID?) has also uploaded a shapefile InMAP_gridCells, but to a new Google Drive folder.
Libby has uploaded a netCDF file ca_isrm.nc to the same Google Drive folder folder.
Previously we got a link to a different ("older") Google drive folder, also containing a file named ca_isrm.nc.

There aren't any version identifiers (like foo-v1.2.1.nc) embedded in these, and there's no accompanying README for any of them. So it's not immediately clear whether they're duplicates. I could check to see if the md5s match, but I'm left with another question — the shapefile from Libby contains a single field, JoinID. Is this the CA ISRM cell ID?

I think investment in version identifiers and READMEs will pay off with less net confusion and more efficient use of time, so I'd like to encourage the use of those. Here are two examples; the latter has tips, and they can be very brief!

In my experience, it's been best to give this sort of feedback early in a project, before things really pile up, even though it might seem pedantic right now. It's good to build habits!

Where I'm coming from: I grew up with RPP culture, and I also endorse the CRAPL and blameless development. It may seem like overhead for "can you send me that" requests, and there are RPP limits, but my 2¢ is that it'll help to proactively nudge our practice a little bit from where we are now.

Thoughts? Concerns? Suggestions?

pmartien commented 2 years ago

Hi all! Thanks @dholstius for the gentle nudge. Many of the tasks in our BAAQMD InMAP project are, at their core, handoff tasks:

sharing files,
sharing code, or
sharing analysis products.

In my experience handoffs are always a challenge, especially, if there are changes along the way, which is the norm.

Handoffs are certainly a struggle within BAAQMD, even within closely aligned teams. To maintain sanity, we're working on developing more of a README culture. It's definitely a work in progress, but the idea is that every shared data file should be accompanied by a README, or be described in an existing README.

It definitely requires some overhead but it pays off, especially for longer projects when memory fades about what happened earlier. It also often makes documentation a lot easier and reduces the anxiety of working with multiple shared files.

I'm super excited to see the great issues discussion we've been having on GitHub. It gives me confidence that we're resolve our blockers. Adopting READMEs for data files may help too.

Sorry for the soapbox! PS: I'm one of our team's worst offenders for forgetting READMEs, but am increasingly reminded.

BAAQMD / InMAP-SFAB