- Print
- DarkLight
- PDF
Assessments FAQ
- Print
- DarkLight
- PDF
Q: How are Condos modeled in SmartFabic?
A: Condos typically have a one-to-many relationship between parcel boundaries and property attributes. Condominiums typically have a master parcel, but each condo unit will have a unique tax assessment record. When condominium units are linked to a parcel this creates a parcel “stack”. Since each unit is a unique entity, each parcel in the resulting stack will share the same Parcel LightBox ID, but will retain a unique tax assessor ID value.
This model also occurs with property types:
- Time-share's
- Mobile Home Parks
- Some commercial properties
- And new co-ownership real estate owned models
Additional Information:
Q: What are the BLDG_AREA_1 to BLDG_AREA_7 variables as well as the BLDG_AREA_INDICATOR?
A: These fields indicate the different areas in the building (where available) on a property. BLDG_AREA_1 indicates the number of square feet and the BLDG_AREA_INDICATOR refers to a code that describes that part of the building. Based on the code returned they indicate a floor/level of the building and its status (finished, unfinished, office area, mezzanine, etc.).
Q: What are Orphan Assessments in my delivery?
A: Orphan Assessments are assessment records that we were not able to link to parcel boundaries.
Please see the below for more information:
Q: Are the BLDG_NUMBER column in the Assessments table and the ASSOCIATED_ASSESSMENT_COUNT variable in the Parcels table coming from the same source?
A: Answer
- The BLDG_NUMBER is the total number of buildings or structures on a single parcel as reported on the assessment roll.
- The ASSOCIATED_ASSESSMENT_COUNT comes from the spatial processing of the parcel polygon in relation to the location of an assessment record.
- A condo would be an example of these 2 fields differing. There may be one building on the parcel. However, there may be hundreds of taxable records associated with that parcel that we have identified by doing a spatial analysis (e.g. condo units).
Q: What is GEOMETRY_SOURCE indicating?
A: The GEOMETRY_SOURCE field indicates the method used to geocode property point locations. We start with a separate parcel polygon and assessment record. We then process assessment record addresses and match them to a parcel. Typically when we match an assessment record to a parcel we move the latitude/longitude of that assessment record to the center of that parcel. This will be indicated by the value ‘Parcel’ in this field. Other possible values are ‘STREET_CENTERLINE’ OR ‘COUNTY_CENTROID’.
For example, an instance where an assessment record was unable to be successfully matched to a parcel. Alternatively, the location of that point was interpolated using a waterfall method where the correct street could be deduced, and a point could be placed on that street. If this method does not work, we fall back to a postal code centroid, then a county centroid.
Q: What is the purpose of UNIQUE_TAXAPN? It seems to be the combination of two other variables (TAXAPN + DUPE_TAXAPN_SEQ).
A: The UNIQUE_TAXAPN is Property APN/ID as inventoried by the tax assessor (TAXAPN) + duplicate APNsequence number (DUPE_TAXAPN_SEQ) if populated. Ex: 07-08-34.001 01.
The DUPE_TAXAPN_SEQ provides additional sequence numbers that can distinguish between the primary or master parcel and subsequent taxable entities. (EX: 01, 02, 03 etc).
A condominium could be a good example of the DUPE_TAXAPN_SEQ being populated where the APN or parcel is technically the same for each taxable entity but there are several unique taxable properties on that parcel. The sequence is a unique number that can be appended to the APN to create a unique tax APN.
Q: Where is the information in the CAL_ACREAGE variable coming from? How is this different from ACCREAGE?
A: CAL_ACREAGE is calculated by spatially processing the parcel geometry from the source (I.e. county GIS) whereas the ACREAGE is an acreage value recorded by the assessor. It is not uncommon to see the 2 differ. For spatial accuracy we recommend CAL_ACREAGE.
For example, if a developer was looking at a parcel that the assessor says is 9 acres but the CAL_ACREAGE says is 11 acres we’d recommend using the CAL_ACREAGE as the more accurate number. As with all data, there are nuances but that’s the idea.
Q: What is the source of the CENSUS_BLOCK_GROUP, variable?
A: This attribute is derived using a Spatial Overlap operation using the assessment point location to the census block group data set.
Q: What is the difference between LAST_SALE, LAST_MARKET_SALE, PRIOR_MARKET_SALE, and PRIOR_SALE?
A: Answer
- LAST_SALE may reflect a market sale or non-market sale that resulted in the current owner taking possession of the property.
- LAST_MARKET_SALE is specifically a sale that occurred on the market
- PRIOR_SALE may reflect a market sale or non-market sale that resulted in the previous owner taking possession of the property.
- PRIOR_MARKET_SALE is specifically a sale that occurred on the market before the most recent market sale.
Q: How does Lightbox impose an MSA_CODE on a property? Is it based on MSA shapefiles?
A: This is a LightBox-created field, derived from spatial relationship with census data.
Q: What are NEIGHBORHOOD_CODEs? What is the source of this data?
A: This is a county-provided code indicating the neighborhood or geographic area of the parcel/assessment.
Q: What does YR_BLT_EFFECT represent?
A: The year the property was renovated or recognized as a taxable entity in its current form.
Q: What are the RANGE and SECTION variables indicating?
A: Answer
- The "range" portion of geographical coordinates based on local surveys. Ranges typically run east or west of a pre-determined "meridian" in six-mile intervals.
- The "section" portion of geographical coordinates is based on local surveys. Sections are 1 square mile (2.6 square kilometers), containing 640 acres (260 hectares). There are 36 sections making up one survey township on a rectangular grid.
Q: What is the source of the BUILDING_CONDITION variable? How often is it updated?
A: This provides additional information regarding a parcel. This information may come from a comments field provided by the county or can be information added by the analyst. If Duplicate parcels are present, this field contains a summary of multiple building records and should contain the improvement # and any available physical characteristics. Refer to the BUILDING_CONDITION_DESC field for the corresponding description. Updated annually as part of the tax roll if applicable.
Q: How is BUILDING_CONDITION populated?
A: The Building Condition typically grades the current state of the structure. There is no national standard definition for how each county/jurisdiction defines the condition, in general, each county/jurisdiction will provide a descriptive value matching to LightBox code rating from highest to lowest: E – Excellent, G – Good, V – Average, F – Fair, P – Poor, U - Unsound. In the cases where the county provides a value that doesn’t match to descriptive value of one of our codes, we will map to the appropriate LightBox code after researching and validating with the county.
Q: How does BUILDING_QUALITY relate to BUILDING_CONDITION?
A: The Building Quality and Building Condition values normally go hand in hand but there are exceptions such as an older run-down marble structure would have a high Building Quality but rated low on Building Condition. Similarly, a brand-new mobile home is made of plywood and other cheap materials and would have a low Building Quality value but since it is new the Building Condition higher value.
Q: What is the source of the BUILDING_QUALITY field? How often is it updated?
A: This is a code reflecting the quality of a building. It usually comes as a grade from the county and is updated annually as part of the tax roll if applicable.
Both the Building Quality and Building Condition fields are populated with the value provided by the county/source provider. Majority of the time it is a straight move directly from what is provided in the source. LightBox does not leverage other values or logic in determining the Building Quality and/or Building Condition beyond the data that is provided by the county/source provider. In some cases, LightBox may have to map the county/source’s values to our standard codes for those fields.
Q: How is CONSTRUCTION_TYPE populated?
A: CONSTRUCTION_TYPE is populated with the code corresponding to the dominant building material if provided in the source.
Q: What is the source of LENDER_CODE_1?
A: Code indicating the type of lender associated with the last market sale of the property. Refer to the LENDER_CODE_1_DESC field for the corresponding description. Sourced via the transactions data that’s coming from the office of the recorder.
Q: How is LOAN_TYPE_1 determined?
A: If we can determine from the recorded deed document or mortgage, we will include this field. Refer to LOAN_TYPE_1_DESC field for the corresponding description.
Q: If all addresses are in the Address table, why does the Assessment table also include addresses?
A: This represents addresses that come directly from the assessor and are considered the SITUS address, which the tax authority recognizes when describing a parcel. A parcel might have several addresses but can only be on SITUS for taxation purposes.
See: Situs vs Secondary Addresses
Q: What is the difference between ASSESSMENT_LID and PRIMARY_ASSESSMENT_LID?
A: If the primary assessment record is not flagged from the county data we take the lowest alphanumeric APN and assign that the primary assessment record. In some cases, a specific assessment record is flagged by the county as the ‘primary’ but outside of these cases, we use the above methodology.
Q: Situs address in Assessment - is it straight pass through from the county or does LightBox standardize?
A: The address information in our assessor data that is linked to parcel data becomes an input into our address universe and, as such, runs through our address validation/standardization process.
Q: How do I find all the properties that an owner owns?
A: For data delivery options, create a field index on the owner address and owner postal code. You can then query all the data that has the same value as your subject property.
Q: Can I find all the properties that an owner owns through the API?
A: Yes, we have an endpoint called ownerportfolio on the assessment API. Pass in your subject assessment record identified by the LightBox ID and the API will return all the records that are owned by the owner of the target assessment record.
Q: Why at the beginning of 2024 is there still 2022 assessment year included in our data? Shouldn't we have all of 2023 assessment year by this time?
A: Many counties, most notably in Illinois, assess in arrears. This means we will not receive a certified Assessor Roll for Assessment Year 2023 until sometime in 2024. For these counties, the data we’re showing with Assessment Year 2022 is current. For other counties, such as GA and LA, we are currently working on programming the Assessment Year 2023 data
Q: Why in some records do we have a tax year that is greater than the assessment year or vice versa?
A: In the majority of counties, both the Assessment Year data and Tax Year data would be updated more or less simultaneously each year. However, in many counties/states, the Tax department publishes new Tax amounts at a different time of year than the Assessment Roll is available in public records. An example is in Michigan, where nearly all counties will have 2024 Assessment Values available during the April to July timeframe, however, tax data for Tax Year 2024 will not be published for any county until this December.