|Download this layer||View in an online map|
MassGIS' Level 3 Assessors’ Parcel Mapping data set, containing property (land lot) boundaries and database information from each community's assessor, was developed through a competitive procurement funded by MassGIS. Each community in the Commonwealth was bid on by one or more vendors and the unit of work awarded was a city or town. The specification for this work was Level 3 of the MassGIS Digital Parcel Standard. As of October 30, 2013, standardization of assessor parcel mapping for 350 of Massachusetts' 351 cities and towns has been completed (data for Boston is not part of this project and will be processed separately). MassGIS is continuing the project, updating parcel data provided by municipalities.
This layer replaces the legacy Level 0 and Level II parcels.
MassGIS has assembled information and resources for those interested in maintaining standardized parcel mapping.
Digital Parcel Standard, Level 3
The standard establishes requirements for how parcel boundaries are compiled. It also requires creating a few attributes in the TaxPar and OthLeg feature class polygons that are unique to the standard. In addition, the standard requires that a minimum selection of information from the assessor's database be included in a separate database table that can be linked to the parcel polygons. Finally, the standard establishes very high percentage requirements for what percentage of parcels link to an assessor tax list record and vice versa.
One of the primary objectives in developing Level 3 in Version 2.0 of the digital parcel standard was revising the data model to eliminate situations in which one tax listing links to more than one polygon on the assessor’s map. Sustaining this approach will, ultimately, depend on embedding a unique parcel identifier from the standard (the LOC_ID attribute) directly in the assessor tax list database. Conversations with the four primary assessing database software vendors in Massachusetts indicate that embedding the LOC_ID in this manner can be accommodated in their existing database structures. It always has been necessary to link multiple tax listings with one polygon (the most common example being condominiums), and the standard continues to model that relationship.
The standard calls for data stored in an ESRI file geodatabase (fGDB) with three feature classes, a database table, and two look-up tables. These are all briefly described below and full details can be found in the standard. The components of the Level 3 fGDB are:
TaxPar Feature Class (“tax” parcels) – this feature class comprises polygons or multi-part polygons, each of which links to one or more assessor tax records (unless it is a feature for which a tax record has not been established, i.e. public right-of-way, most water, etc…). In situations where two or more contiguous parcels have common ownership, the internal boundaries of these parcels have been removed, creating a single polygon corresponding to the tax listing that it represents. Where two or more non-contiguous parcel polygons share common ownership, they have been converted to a multi-part polygon; each multi-part polygon links to one or more assessor tax listings.
OthLeg Feature Class - this feature class contains polygons representing other legal interests in land. These other legal interests include representations of the “fee simple” property parcels that comprise the combined parcel polygons described above in the TaxPar feature class. In addition, other legal interests in this feature class include various types of easements.
Misc Feature Class– this feature class contains map features from the assessor parcel maps needed to produce that tax map with the content that the assessor is used to seeing, such as water, wetlands, traffic islands, etc.
Assess Database Table – this is a standard extract from the assessor database containing about 25 elements including property valuation, site address, state use code, owner, owner address, and a selection of information about the structure. This table includes the FY (fiscal year) field, which stores the vintage of the assessed value of the parcel.
LUT Look Up Table – this is a look-up table for the MISC_TYPE attribute of the Misc feature class and the LEGAL_TYPE attribute of the OthLeg feature class.
UC_LUT Look Up Table – this is a look-up table for state use codes found in the assessing extract.
In ArcSDE, MassGIS stores the components of this data layer as follows:
- TaxPar feature class: L3_TAXPAR_POLY
- OthLeg feature class: L3_OTHLEG_POLY
- Misc feature class: L3_MISC_POLY
- The assessor data extract: L3_ASSESS
- The two look-up tables are L3_LUT and L3_UC_LUT
- A relationship class has been built to link the TaxPar feature class polygons to the assessing extract database table, named L3_TAXPAR_POLY_RC_ASSESS.
- A spatial view was created that links the assessor records to the the TAXPAR polygons, named L3_TAXPAR_POLY_ASSESS. An export of this view includes "stacked" polygons for features that link to multiple assessor records (such as condominiums) and does not include features that have no associated ASSESS records. A similar spatial view, L3_TAXPAR_POLY_ASSESS_MM, contains all features, except road rights-of-way and water bodies, even if they do not have associated ASSESS records, and is used in Municipal Mapper and the Tax Parcels cached basemap tileset.
Complying with Level 3 of the Standard
Assessor’s parcel mapping is a representation of property boundaries, not an authoritative source. The authoritative record of property boundaries is recorded at the registries of deeds and a legally authoritative map of property boundaries can only be produced by a professional land surveyor.
Representation of Parcel Boundaries - Users of parcel data, which MassGIS has approved as meeting the requirements for Level 3 of its standard, may find places where the boundaries conflict with visible features on orthoimagery. This is common and reflects a variety of circumstances. Often the discrepancy between the tax map and the visible road right-of-way on the orthoimagery base map is correct, as roads are not always constructed the way they were shown on the original plan. Other factors accounting for discrepancies between the boundaries and visible features on the orthoimagery are buildings that may “lean” in the imagery because of camera angle, making them appear as if they are crossing parcel lot lines. Also, while rights-of-way ordinarily have a standard width, that is not always true. In fact, we have seen countless instances where right-of-way widths are irregular. Similarly, the fence, wall, or shrub line visible on the orthoimagery is not necessarily the property boundary. In some cases, houses are built so that they straddle lot lines. Also, while MassGIS' quality assurance process is extensive and rigorous, it is not perfect and it is possible that we have missed some boundary compilation or other errors.
Municipal Boundaries - The standard requires that MassGIS’ representation of the official municipal boundaries be incorporated into the standardized assessor mapping. Checking for that is part of our QA process. However, there are discrepancies between municipalities where they share a boundary that follows a stream channel; without engaging the services of a surveyor, there is no way to determine where those boundaries are and we did not require that MassGIS’ mapping of that boundary supersede the boundary from the tax mapping. Also, MassGIS has allowed communities to represent the coastline as it is in their tax mapping. Finally, this requirement from the standard uncovered numerous discrepancies in municipal boundary lines that will require further discussion with the communities involved. Known outstanding boundary discrepancies include portions of the boundaries between the following communities: Andover-Lawrence, Lawrence-Methuen, Cohasset-Scituate, Attleboro-Rehoboth, Avon-Stoughton; Easton-Stoughton, and Dracut-Methuen.
Assessing Data Extract - The assessing data extract is an “as is” copy of the records maintained by each assessor. There are errors and discrepancies.
Assessing Data Match Rates - The standard sets very high requirements for the percentage of parcels that must match to an assessing record, as well as vice-versa. Full details are in the standard. However, these match rates were not always achievable. In some communities, assessors do not know who owns some properties. These are almost always small fragments of land with no structure or small lots in wetland or forested areas. The NO_MATCH attribute of the TaxPar feature class has been used to track these circumstances. Although much less common, there are also occasionally records from the assessing extract beyond the allowed percentage that do not match to a parcel polygon.
For each community, vendors delivered an ESRI file geodatabase to MassGIS. MassGIS staff reviewed the parcel boundary mapping, identifying potential errors. Situations that were commonly called out in the boundary QA included lot lines running through structures, inconsistent right-of-way widths (unless the mapping was known to have been compiled from deeds and plans), discrepancies compared to visible features on the orthoimagery, and discrepancies relative to the official representation of the municipal boundaries maintained by MassGIS. Additional checks include: attribute names and domain values, consistency between “TAX” and “FEE” polygons included in the TaxPar and OthLeg feature classes, linking percentages from the parcel map polygons to the assessing data extract and vice versa, and review of situations where multiple tax records link to a single parcel and one or more of the tax records is not a condominium.
Complete descriptions of the attributes for the Level 3 feature classes, database table, and the look-up tables are found in the parcel standard. Attribute table fields and domains (valid values) and selected definitions are listed here:
Field Name Type Size Dec. Places Valid Values Null Required Tax Parcel Attributes MAP_PAR_ID C 26 Parcel ID appearing on the original assessor's map YES LOC_ID C 18 M_<X>_<Y>(for meters), F_<X>_<Y> (for US Survey Feet) YES POLY_TYPE C 15 FEE, TAX, ROW, WATER, PRIV_ROW, RAIL_ROW YES MAP_NO C 4 Assessor's original map sheet number SOURCE C 15 ASSESS, SUBDIV, ROAD_LAYOUT, ANR, OTHER NO YES(1) PLAN_ID C 40 Identifying information for plan used to update the digital file YES(1) LAST_EDIT N 8 Format YYYYMMDD NO BND_CHK C 2 null value, CC, NR, OK NO_MATCH C 1 Y, N NO TOWN_ID N 3 MassGIS town identifier (1-351) NO YES Other Legal Interests Attributes MAP_PAR_ID C 26 Parcel ID appearing on the original assessor's map YES LEGAL_TYPE C 15 FEE, PRIV_ROW, RAIL_OVER, RAIL_ROW, ROW_OVER, EASE, CR, APR, CRX, APRX, OTHER YES LS_BOOK C 16 Registry of Deeds book for last sale YES(1) LS_PAGE C 14 Registry of Deeds page for last sale YES(1) REG_ID C 15 The equivalent to Registry of Deeds book and page information but for registered or probate land. YES(2) TOWN_ID N 3 MassGIS town identifier (1-351) NO YES TAXPAR_ID C 18 Miscellaneous Features Attributes MISC_TYPE C 15 WETLAND, ISLAND, TRAFFIC_ISLAND, WATER, OUTSIDE, BLDG YES TOWN_ID N 3 MassGIS town identifier (1-351) NO YES Extract from Assessor PROP_ID C 30 Unlike the items below, this attribute may not come directly from the assessor’s database. It may sometimes be constructed from information typically found in multiple columns in the assessor’s database (see definition for more information). It must be unique within the city or town NO YES LOC_ID C 18 M_<X>_<Y> (meters), F_<X>_<Y> (US Survey Feet); use to join to parcel polygons NO YES BLDG_VAL N 9 Current assessed value for the main building(s) on the property YES LAND_VAL N 9 Current assessed value for land YES OTHER_VAL N 9 Other structures or physical improvements that are separately valued YES TOTAL_VAL N 9 Current total assessed value for land and structures. Because some databases include other categories of valuation not included above, this may not represent the total of the fields above YES FY N 4 Fiscal year of assessed value formatted as YYYY (number, 4; cannot be null). NO YES LOT_SIZE N 11 2 Deed area in EITHER square feet OR acres, but not both YES LS_DATE C 8 Last sale date formatted as YYYYMMDD YES LS_PRICE N 9 Last sale price YES USE_CODE C 4 Land use code as set by Dept. of Revenue NO YES SITE_ADDR C 80 This field will contain the complete original site address as listed in the tax record YES ADDR_NUM C 12 This field will contain address number information, either a single house number with suffix (e.g., 25, 103 ½ or 12A) or a range of numbers (e.g., 12-16 or 12A–12B). YES(2) FULL_STR C 60 This field will contain the full street name, which may be stored in separate fields in the assessor database. YES(2) LOCATION C 60 This is the place to put secondary location information. Frequently, descriptors such as “Side”, “South Side”, “Rear”, “Basement” as well as building and unit descriptors such as “#1” or “Unit A” are found in assessor data YES(2) CITY C 25 City or town where the property is located YES ZIP C 10 Zip code where the property is located, if available YES OWNER1 C 80 Name of first owner of record YES OWN_ADDR C 80 The complete owner mailing address, including the street number, name, etc. Where the tax bill is sent. YES OWN_CITY C 25 The city for the property owner’s address YES OWN_STATE C 2 For US addresses, the state where the property owner lives, using the postal service abbreviations for state YES(3) OWN_ZIP C 10 The zip code of the owner’s address YES OWN_CO C 30 The country where the owner lives YES LS_BOOK C 16 Last sale Registry of Deeds book YES(1) LS_PAGE C 14 Last sale Registry of Deeds page YES(1) REG_ID C 15 This is the equivalent to Registry of Deeds book and page information but for registered or probate land YES(2) ZONING C 8 This is the code to indicate the zoning district within which the property lies not including overlay zoning districts YES YEAR_BUILT N 4 format YYYY YES BLD_AREA N 9 Applies primarily to apartment buildings and commercial/industrial properties; assessor’s data is based on exterior building measurements. Building area may be recorded as gross square-feet, adjusted gross square-feet, or finished area. Basement area may or may not be included in finished area. Partial story-heights and attic areas may be treated differently by different CAMA systems. Gross area may include non-living areas such as porches and decks, or attached garages. YES(2) UNITS N 4 Either living units; single-family=1, three-family=3 or number of residential or commercial condominium units within a GIS parcel. YES(2) RES_AREA N 7 Applies primarily to 1, 2 & 3 family dwellings based on exterior building measurements or residential condominiums based on deeded unit areas. Building area may be recorded as gross square-feet, adjusted gross square-feet, or finished area. Basement area may or may not be included in finished area. Partial story-heights and attic areas may be treated differently by different CAMA systems. Gross area may include non-living areas such as porches and decks or attached garages. YES(2) STYLE C 20 Code indicating style of structure (“colonial”, “ranch” etc.) YES STORIES C 6 This is not the wall height. Story height is typically recorded as a full story for each floor, except under roof-line floors, which are adjusted by factors ranging from 10% to 90% of a full story depending on roof slope and wall height; examples include one-half stories and attics. Note that in the Patriot AssessPro database, letters (e.g. A, H) may be assigned to indicate partial story heights. YES NUM_ROOMS N 3 Total room count as determined by the assessor; primarily applied to residential properties. YES LOT_UNITS C 1 S (sq. ft.) or A (acres) (Added by vendor, not from assessor database) YES TOWN_ID N 3 MassGIS town identifier (1-351), added by MassGIS NO YES MA_PROP_ID C 60 Unique identifier for ASSESS record, added by MassGIS NO YES (1) Only required if information is available
(2) Only required if information needed is available in the assessor's database
(3) Not required for owners with non-US addresses unless needed
Display and Download in OLIVER
To download data for a single municipality when viewing the Level 3 parcel data in OLIVER, add the "Political / Administrative Boundaries > Assessors Parcels > Parcels Level 3 FTP Download Links by Town" layer. When you identify on a town, you will see hyperlinks in the SHAPE_LINK and FGDB_LINK fields, for the shapefile and file geodatabase downloads, respectively. Click on the hyperlink to download a zipped file containing all the data for that municipality. Adding the "Parcel Status" layer will display the level of parcel data for each town. This permalink will bring up OLIVER with these layers added. Click on the image at right for an illustration (PDF). (Note: the zip files you may download in this manner are the same files downloadable from the Level 3 Parcels download page.)
MassGIS is vigorously encouraging communities to maintain their standardized digital assessor parcel mapping in compliance with Level 3 of the digital parcel standard. From our discussions with companies that maintain assessor tax mapping for municipal clients, we know that maintaining Level 3 compliant data will be no more expensive than maintaining other forms of parcel mapping. We also have discussed the standard with the Department of Revenue’s Bureau of Local Assessment and expect the Bureau will recommend that assessors maintain their mapping in compliance with Level 3 of the standard.
MassGIS has assembled information and resources for those interested in maintaining standardized parcel mapping.
In August 2014 the first updates were released, for the following municipalities: Amesbury, Belmont, Boxford, Carver, Dunstable, Eastham, Georgetown, Great Barrington, Hawley, Ludlow, Marion, Newbury, Newburyport, North Andover, Peabody, Rowley, Townsend and West Newbury.
Last Updated 8/22/2014