openEDI / documentation

OEDI Public Dataset Documentation
55 stars 19 forks source link

Data dictionary for PV Rooftops dataset? #6

Closed jefffriesen closed 11 months ago

jefffriesen commented 4 years ago

I am trying to work with the PV Rooftops data. The goal is to understand the PV potential for every rooftop plane for a given building in a city. I'm working specifically with the Boulder data set, but will need to use others.

At risk of overloading a single github issue, I'm going to bring up several issues. I think a data dictionary would resolve my questions, so that's the main goal of this post.

  1. What is bldg_fid? Is that a unique building id? I noticed the same bldg_fid has multiple slopearea_m2 but different aspects. I interpret this as different roof directions.

  2. I'm assuming slopearea_m2 is the area we would want to use to estimate how many panels can be added to that roof plane. But in the paper https://www.nrel.gov/docs/fy16osti/65298.pdf it says that you filtered out all planes that are less than 10 square meters. But in the data for Boulder I pulled, there are a lot of slopearea_m2 less than 10 square meters. (see screenshot). To find the area of the plane we can place panels on, would I add up slopearea_m2 per plane?

  3. I loaded the_geom_4326 and overlayed them on Open Street Map buildings. There are many tiny polygons, which matches up with the data where I see a lot of slopearea_m2 less than 10 square meters. (see screenshot). Why so many polygons? Is this all raw data and we filter them out?

  4. I'm not sure what the_geom_96703 is. I assumed that was a local CRS, but couldn't find it as an option in QGIS. What is that?

We have the schema from your documentation, but I think a data dictionary would clear up a lot. But the issue of many tiny polygons is still confusing.

Thank you

jefffriesen commented 4 years ago

I just realized I forgot the screenshots:

nrel_rooftop_pv_1 nrel_rooftop_pv_4
MRossol commented 4 years ago

@jefffriesen Thanks for the comments, we fully agree and are working on re-vamping this documentation as well as providing some clearer examples. Our goal is to do so by the end of the summer.

jefffriesen commented 4 years ago

@MRossol Ok, thanks for the update. I'm happy to look at the documentation and give feedback however I can.

mooneyme commented 4 years ago

Hi @jefffriesen. While we work on the documentation, I can answer some of your questions directly.

  1. Yes, the bldg_fid is the building feature ID for a given building. The data is published as the building's developable plane resolution; this is a sub-building resolution. Developable planes are contiguous areas on a rooftop with the same orientation characteristics that are suitable for solar. So yes, you are correct, a building can have multiple entries due to it having multiple planes. Sometimes these are different tilts/azimuths, or two different planes can be oriented the same way but divided by a chimney or other obstructing feature (i.e, not contiguous).
  2. Correct, you can use slopearea_m2 to determine the number of panels that can fit on a given plane. The data is of raw outputs and does not include some of the filtering performed for the national technical potential (Gagnon et al. 2012). So you should absolutely perform some minimum area filtering. Recently, we have been applying a minimum area filter of 1.62 m2, which is roughly the area required to fit a single panel.
  3. Yep, that is correct. Remove tiny polygons in your screening.
  4. The 96703 in the_geom_96703 does refer to the CRS, however, it is a bit misleading because its a postgres legacy naming convention to add a leading 9 for user generated CRSs. So really, the SRID here is 6703: https://spatialreference.org/ref/sr-org/6703/

Hope that helps!

jefffriesen commented 4 years ago

@mooneyme This is really helpful. Thanks for this information.

Should I wait until more documentation is added to close this ticket or close it now?