Regrid Matched Building Footprints FAQ

What is the source of the buildings data?

Our partners at EarthDefine use high-resolution National Agriculture Imagery Program (NAIP) imagery, as well as Light Detection and Ranging (Lidar) imagery. EarthDefine then applies their industry-leading AI models to the imagery to derive high-quality nationwide building footprints.

What is the geographic coverage of the data?

The buildings data covers the entire contiguous United States (the "lower 48") plus Hawaii, Puerto Rico, and the Virgin Islands. It includes all but 6 FIPS codes within Alaska, and has no coverage for the other territories.

What is the quality of the imagery?

NAIP provides 60cm or higher resolution color infrared imagery across the lower 48 States.

NAIP data is flown statewide by different contractors, so every state might have a different NAIP vendor, and there is some variability within the nationwide imagery.

The majority of Lidar data is sourced from the USGS as part of the 3D Elevation Program.

How accurate is the data?

In terms of spatial accuracy, the georectification standard of the NAIP imagery is  +/- 6 meters, and we have found it to be better in many places. This number is the 95% confidence level (CE95), meaning that "95% of well-defined points tested shall fall within 6 meters of true ground". The spatial accuracy of the derived buildings is at least +/- 6m, or at worst 6 meters.

To find the accuracy of the buildings themselves, we use a metric called Intersection over Union (IoU) to evaluate how well buildings line up with validation data. The current IoU for the buildings is over 0.94, which is quite good. For comparison, the Microsoft Buildings product has an IoU of 0.86.

This data goes through multiple rounds of quality control to ensure that discrepancies like shadows and, incorrect building edges are removed when classifying and obtaining footprints.

How often is the data updated?

You can expect multiple buildings data updates a year. Each update typically impacts different counties, and updates are delivered on a rolling basis as they are available.

The buildings data is mainly based on the currency of the NAIP imagery. Half of the country usually has NAIP imagery updates once per year, and many states do updates every year. The latest NAIP imagery is used by EarthDefine to update the data at least once a year.

Our partners at EarthDefine are continually updating and improving their algorithms to improve the quality of the data. These improvements are also released as updates throughout the year. We track the date of these updates in the buildings schema as ed_source_date, and on our data store as "Building Source Imagery Date."

Why do some geographies have older data?

Occasionally, NAIP imagery does not meet EarthDefine's quality standards or is of lower quality than the previous year’s imagery. In these cases, older imagery may be used to derive higher quality footprints.

How large does a structure need to be in order to be included in the buildings data?

Our partners at Earthdefine currently don’t capture any structure that is less than 3 square meters (32.29 square feet). The goal is to capture all the legitimate structures that exist and as such we may increase or decrease the lower limit at which we capture in the future as the processes of building capture are further refined.

What is the join file?

We provide a join file that matches parcels by ll_uuid to buildings by their ed_bld_uuid. One parcel may have multiple buildings on it, and one building may span multiple parcels. The Regrid Matched Building Footprints Join File accounts for this many-to-many relationship. We have tuned an algorithm that accounts for variance in the data to provide building to parcel matches that are more accurate than a typical spatial intersection query. More details about the join file structure are available here.

Do you provide the matched data via API?

We offer an upgraded API option that returns parcels + matched building footprints via the Regrid Parcel API, please review our Regrid Parcel API options page for more details.

Why are there two different “Matched Building Footprints schemas?

We have 2 schemas for Matched Building Footprints, one without building height, elevation, and associated vertical attributes, and one with these vertical component attributes.

Do I need both Matched Building Footprints schemas?

No, you do not need both, you only need the one that best fits your needs. If you don’t have need for building height and/or building elevation, you don’t need the ‘with Height’ version.

Is building square footage or height provided?

Building footprint square footage is provided as part of the Matched Building Footprints schema. Total building floor space is not currently included.

Height, number of stories, and total building square footage are included in the expanded Matched Building Footprints with Height schema.

How does a ed_str_uuid differ from a ed_bld_uuid?

We deliver the spatial data at the building level. Every shape in the buildings data has a ed_bld_uuid value. Because the individual building level is much more spatially precise, our join table makes use of the ed_bld_uuid and we expect most people to make use of the ed_bld_uuid in their workflows and code.

Buildings may be derived from a larger structure, identified by the ed_str_uuid. For example, a large row of homes may appear in imagery data as one large structure, but in reality it is many smaller buildings.

Because we divide up the larger structures by parcel boundaries, ed_str_uuid is not unique in our data. Multiple buildings my be derived from a larger structure, and they would all share the same ed_str_uuid. The building ID, ed_bld_uuid is expected to be unique in our data.

If a workflow requires or would benefit from the original full structures before dividing into individual buildings, you can use the ed_str_uuid to group the individual building records.

How large is the buildings dataset in a database?

In a database, the full buildings dataset plus useful indexes, plus the indexed join table, will typically use 200-250GB.

Actual size will vary depending on what fields you index, geometry simplification, including or not including specific fields, and other factors.