These address data are updated, typically by request, to City of San Marcos Planning and Development Services on a daily to weekly basis. Updates occur as new parcel plats are recorded, as building footprints change, when new service equipment such as cell towers and meters is installed, to bring existing address points into compliance with CAPCOG 911-Addressing guidelines, and as needed for various other circumstances.The 911 addresses (denoted in the Address911 field as “Y”) follow the CAPCOG (Capital Area Council of Governments) Addressing Guidelines (10-28-09) available here: http://www.capcog.org/divisions/emergency-communications/911-technology/(last accessed March 30, 2017).Non-911 addresses (denoted in the Address911 field as “N”) are maintained for location finding, public infrastructure inventory, and for various other circumstances. Location finding address points includes all intersection, 100 block numbers, and mile markers.There are two types of new addresses, In-fill and Subdivisions. In-fill addressing occurs in already developed areas that experience change. The Planning and Development Services Planning Technician updates and maintains the infill addresses, often in coordination with the City of San Marcos Fire Marshal’s office. Planning and Development Services 911 Address Coordinator creates new subdivision addressing. This feature exists in DevServices.sde. Field Information:OBJECTID- System-generated unique identifier for each record within the feature classMAXIMOID- unique identifier tie for public services asset management software; field is auto populated by IT GIS scriptMAXIMOIDPFX- unique identifier with prefix indicating (ADDR) feature tie for public services asset management software; field is auto populated by IT GIS scriptSAN- Site Address Number, assigned based on CAPCOG guidelines; alias: ADDRESSPRD- Prefix Directional (N, S, E, W); alias: PREFIX DIRECTIONSTN- Street Name; alias: STREET NAME; domain: ST_TYPESTS- Street Suffix; alias: STREET TYPEUNIT_NUM- FULLADDR- all caps concatenation of PRD + STN + STS (field calculate with this expression: ucase ([SAN] &" "& [PRD]&" "& [STN]&" "& [STS])UNIT TYPE*- values include: APT, ACSRY, BLDG, CLBHSE, CONDO, DUP, STE- these values , ; domain: ServUnitTypeZIP CODE- Zipcode- currently all 78666 COUNTY- Hays, Caldwell, Comal, or GuadalupeADDINFO*- used to add information about address, such as Business or Complex name or address type SF (single-family), intersection, etc.; alias DESCRIPTIONADDRESS911- yes or no value distinguishes 911 addresses from non-911 addresses; domain: YORNPOINT_X- Calculated geometry for “X Coordinate of Point” in PCS: NAD 1983 StatePlane Texas South Central FIPS 4204 Feet using Decimal DegreesPOINT_Y- Calculated geometry for “X Coordinate of Point” in PCS: NAD 1983 StatePlane Texas South Central FIPS 4204 Feet using Decimal DegreesCREATEDBY- system generated value based on log in ID CREATEDDATE- system generated value in UTMMODIFIEDBY- system generated value based on log in IDMODIFIEDDATE- system generated value in UTMSHAPE System-generated geometry type of the featureADDRESS_TYPE*- used to add information about addressGlobalID-System-generated unique identifier for each record that is required in replicated geodatabases*Indicate field is not consistent. The feature is under audit and overhaul in 2017 and 2018. Project will encompass and establish specific, consistent descriptors, update and add domains, compare and correct, as needed, consistency with these features: AptSteNum, Condo, Apartment, MFHousing, Parcel, Building, Centerline and Street address ranges

This street centerline lines feature class represents current right of way in the City of Los Angeles. It shows the official street names and is related to the official street name data. The Mapping and Land Records Division of the Bureau of Engineering, Department of Public Works provides the most current geographic information of the public right of way. The right of way information is available on NavigateLA, a website hosted by the Bureau of Engineering, Department of Public Works. Street Centerline layer was created in geographical information systems (GIS) software to display Dedicated street centerlines. The street centerline layer is a feature class in the LACityCenterlineData.gdb Geodatabase dataset. The layer consists of spatial data as a line feature class and attribute data for the features. City of LA District Offices use Street Centerline layer to determine dedication and street improvement requirements. Engineering street standards are followed to dedicate the street for development. The Bureau of Street Services tracks the location of existing streets, who need to maintain that road. Additional information was added to Street Centerline layer. Address range attributes were added make layer useful for geocoding. Section ID values from Bureau of Street Services were added to make layer useful for pavement management. Department of City Planning added street designation attributes taken from Community Plan maps. The street centerline relates to the Official Street Name table named EASIS, Engineering Automated Street Inventory System, which contains data describing the limits of the street segment. A street centerline segment should only be added to the Street Centerline layer if documentation exists, such as a Deed or a Plan approved by the City Council. Paper streets are street lines shown on a recorded plan but have not yet come into existence on the ground. These street centerline segments are in the Street Centerline layer because there is documentation such as a Deed or a Plan for the construction of that street. Previously, some street line features were added although documentation did not exist. Currently, a Deed, Tract, or a Plan must exist in order to add street line features. Many street line features were edited by viewing the Thomas Bros Map's Transportation layer, TRNL_037 coverage, back when the street centerline coverage was created. When TBM and BOE street centerline layers were compared visually, TBM's layer contained many valid streets that BOE layer did not contain. In addition to TBM streets, Planning Department requested adding street line segments they use for reference. Further, the street centerline layer features are split where the lines intersect. The intersection point is created and maintained in the Intersection layer. The intersection attributes are used in the Intersection search function on NavigateLA on BOE's web mapping application NavigateLA. The City of Los Angeles Municipal code states, all public right-of-ways (roads, alleys, etc) are streets, thus all of them have intersections. Note that there are named alleys in the BOE Street Centerline layer. Since the line features for named alleys are stored in the Street Centerline layer, there are no line features for named alleys in those areas that are geographically coincident in the Alley layer. For a named alley , the corresponding record contains the street designation field value of ST_DESIG = 20, and there is a name stored in the STNAME and STSFX fields.List of Fields:SHAPE: Feature geometry.OBJECTID: Internal feature number.STNAME_A: Street name Alias.ST_SUBTYPE: Street subtype.SV_STATUS: Status of street in service, whether the street is an accessible roadway. Values: • Y - Yes • N - NoTDIR: Street direction. Values: • S - South • N - North • E - East • W - WestADLF: From address range, left side.ZIP_R: Zip code right.ADRT: To address range, right side.INT_ID_TO: Street intersection identification number at the line segment's end node. The value relates to the intersection layer attribute table, to the CL_NODE_ID field. The values are assigned automatically and consecutively by the ArcGIS software first to the street centerline data layer and then the intersections data layer, during the creation of new intersection points. Each intersection identification number is a unique value.SECT_ID: Section ID used by the Bureau of Street Services. Values: • none - No Section ID value • private - Private street • closed - Street is closed from service • temp - Temporary • propose - Proposed construction of a street • walk - Street line is a walk or walkway • known as - • numeric value - A 7 digit numeric value for street resurfacing • outside - Street line segment is outside the City of Los Angeles boundary • pierce - Street segment type • alley - Named alleySTSFX_A: Street suffix Alias.SFXDIR: Street direction suffix Values: • N - North • E - East • W - West • S - SouthCRTN_DT: Creation date of the polygon feature.STNAME: Street name.ZIP_L: Zip code left.STSFX: Street suffix. Values: • BLVD - BoulevardADLT: To address range, left side.ID: Unique line segment identifierMAPSHEET: The alpha-numeric mapsheet number, which refers to a valid B-map or A-map number on the Cadastral tract index map. Values: • B, A, -5A - Any of these alpha-numeric combinations are used, whereas the underlined spaces are the numbers.STNUM: Street identification number. This field relates to the Official Street Name table named EASIS, to the corresponding STR_ID field.ASSETID: User-defined feature autonumber.TEMP: This attribute is no longer used. This attribute was used to enter 'R' for reference arc line segments that were added to the spatial data, in coverage format. Reference lines were temporary and not part of the final data layer. After editing the permanent line segments, the user would delete temporary lines given by this attribute.LST_MODF_DT: Last modification date of the polygon feature.REMARKS: This attribute is a combination of remarks about the street centerline. Values include a general remark, the Council File number, which refers the street status, or whether a private street is a private driveway. The Council File number can be researched on the City Clerk's website http://cityclerk.lacity.org/lacityclerkconnect/INT_ID_FROM: Street intersection identification number at the line segment's start node. The value relates to the intersection layer attribute table, to the CL_NODE_ID field. The values are assigned automatically and consecutively by the ArcGIS software first to the street centerline data layer and then the intersections data layer, during the creation of new intersection points. Each intersection identification number is a unique value.ADRF: From address range, right side.

This intersection points feature class represents current intersections in the City of Los Angeles. Few intersection points, named pseudo nodes, are used to split the street centerline at a point that is not a true intersection at the ground level. The Mapping and Land Records Division of the Bureau of Engineering, Department of Public Works provides the most current geographic information of the public right of way. The right of way information is available on NavigateLA, a website hosted by the Bureau of Engineering, Department of Public Works.Intersection layer was created in geographical information systems (GIS) software to display intersection points. Intersection points are placed where street line features join or cross each other and where freeway off- and on-ramp line features join street line features. The intersection points layer is a feature class in the LACityCenterlineData.gdb Geodatabase dataset. The layer consists of spatial data as a point feature class and attribute data for the features. The intersection points relates to the intersection attribute table, which contains data describing the limits of the street segment, by the CL_NODE_ID field. The layer shows the location of the intersection points on map products and web mapping applications, and the Department of Transportation, LADOT, uses the intersection points in their GIS system. The intersection attributes are used in the Intersection search function on BOE's web mapping application NavigateLA. The intersection spatial data and related attribute data are maintained in the Intersection layer using Street Centerline Editing application. The City of Los Angeles Municipal code states, all public right-of-ways (roads, alleys, etc) are streets, thus all of them have intersections. List of Fields:Y: This field captures the georeferenced location along the vertical plane of the point in the data layer that is projected in Stateplane Coordinate System NAD83. For example, Y = in the record of a point, while the X = .CL_NODE_ID: This field value is entered as new point features are added to the edit layer, during Street Centerline application editing process. The values are assigned automatically and consecutively by the ArcGIS software first to the street centerline spatial data layer, then the intersections point spatial data layer, and then the intersections point attribute data during the creation of new intersection points. Each intersection identification number is a unique value. The value relates to the street centerline layer attributes, to the INT_ID_FROM and INT_ID_TO fields. One or more street centerline features intersect the intersection point feature. For example, if a street centerline segment ends at a cul-de-sac, then the point feature intersects only one street centerline segment.X: This field captures the georeferenced location along the horizontal plane of the point in the data layer that is projected in Stateplane Coordinate System NAD83. For example, X = in the record of a point, while the Y = .ASSETID: User-defined feature autonumber.USER_ID: The name of the user carrying out the edits.SHAPE: Feature geometry.LST_MODF_DT: Last modification date of the polygon feature.LAT: This field captures the Latitude in deciaml degrees units of the point in the data layer that is projected in Geographic Coordinate System GCS_North_American_1983.OBJECTID: Internal feature number.CRTN_DT: Creation date of the polygon feature.TYPE: This field captures a value for intersection point features that are psuedo nodes or outside of the City. A pseudo node, or point, does not signify a true intersection of two or more different street centerline features. The point is there to split the line feature into two segments. A pseudo node may be needed if for example, the Bureau of Street Services (BSS) has assigned different SECT_ID values for those segments. Values: • S - Feature is a pseudo node and not a true intersection. • null - Feature is an intersection point. • O - Intersection point is outside of the City of LA boundary.LON: This field captures the Longitude in deciaml degrees units of the point in the data layer that is projected in Geographic Coordinate System GCS_North_American_1983.

The accompanying data cover all MPD stops including vehicle, pedestrian, bicycle, and harbor stops for the period from January 1, 2023 – December 31, 2024. A stop may involve a ticket (actual or warning), investigatory stop, protective pat down, search, or arrest. If the final outcome of a stop results in an actual or warning ticket, the ticket serves as the official documentation for the stop. The information provided in the ticket include the subject’s name, race, gender, reason for the stop, and duration. All stops resulting in additional law enforcement actions (e.g., pat down, search, or arrest) are documented in MPD’s Record Management System (RMS). This dataset includes records pulled from both the ticket (District of Columbia Department of Motor Vehicles [DMV]) and RMS sources. Data variables not applicable to a particular stop are indicated as “NULL.” For example, if the stop type (“stop_type” field) is a “ticket stop,” then the fields: “stop_reason_nonticket” and “stop_reason_harbor” will be “NULL.” Each row in the data represents an individual stop of a single person, and that row reveals any and all recorded outcomes of that stop (including information about any actual or warning tickets issued, searches conducted, arrests made, etc.). A single traffic stop may generate multiple tickets, including actual, warning, and/or voided tickets. Additionally, an individual who is stopped and receives a traffic ticket may also be stopped for investigatory purposes, patted down, searched, and/or arrested. If any of these situations occur, the “stop_type” field would be labeled “Ticket and Non-Ticket Stop.” If an individual is searched, MPD differentiates between person and property searches. Please note that the term property in this context refers to a person’s belongings and not a physical building. The “stop_location_block” field represents the block-level location of the stop and/or a street name. The age of the person being stopped is calculated based on the time between the person’s date of birth and the date of the stop. There are certain locations that have a high prevalence of non-ticket stops. These can be attributed to some centralized processing locations. Additionally, there is a time lag for data on some ticket stops as roughly 20 percent of tickets are handwritten. In these instances, the handwritten traffic tickets are delivered by MPD to the DMV, and then entered into data systems by DMV contractors. On August 1, 2021, MPD transitioned to a new version of its current records management system, Mark43 RMS. Beginning January 1, 2023, fields pertaining to the bureau, division, unit, and PSA (if applicable) of the officers involved in events where a stop was conducted were added to the dataset. MPD’s Records Management System (RMS) captures all members associated with the event but cannot isolate which officer (if multiple) conducted the stop itself. Assignments are captured by cross-referencing officers’ CAD ID with MPD’s Timesheet Manager Application. These fields reflect the assignment of the officer issuing the Notice of Infraction (NOIs) and/or the responding officer(s), assisting officer(s), and/or arresting officer(s) (if an investigative stop) as of the end of the two-week pay period for January 1 – June 30, 2023 and as of the date of the stop for July 1, 2023 and forward. The values are comma-separated if multiple officers were listed in the report. For Stop Type = Harbor and Stop Type = Ticket Only, the officer assignment information will be in the NOI_Officer fields. For Stop Type = Ticket and Non-Ticket the officer assignments will be in both NOI Officer (for the officer that issued the NOI) and RMS_Officer fields (for any other officer involved in the event, which may also be the officer who issued the NOI). For Stop Type = Non-Ticket, the officer assignment information will be in the RMS_Officer fields. Null values in officer assignment fields reflect either Reserve Corps members, who’s assignments are not captured in the Timesheet Manager Application, or members who separated from MPD between the time of the stop and the time of the data extraction. Finally, MPD is conducting on-going data audits on all data for thorough and complete information. Figures are subject to change due to delayed reporting, on-going data quality audits, and data improvement processes.

This layer presents detectable thermal activity from MODIS satellites for the last 7 days. MODIS Global Fires is a product of NASA’s Earth Observing System Data and Information System (EOSDIS), part of NASA's Earth Science Data. EOSDIS integrates remote sensing and GIS technologies to deliver global MODIS hotspot/fire locations to natural resource managers and other stakeholders around the World.

Area Covered: World

What can I do with this layer?
The MODIS thermal activity layer can be used to visualize and assess wildfires worldwide. However, it should be noted that this dataset contains many “false positives” (e.g., oil/natural gas wells or volcanoes) since the satellite will detect any large thermal signal.


It takes approximately 2 – 4 hours after satellite overpass for MODIS Rapid Response to process the data, and for the Fire Information for Resource Management System (FIRMS) to update the website. Occasionally, hardware errors can result in processing delays beyond the 2-4 hour range. Additional information on the MODIS system status can be found at MODIS Rapid Response.

Attribute Information

• Latitude and Longitude: The center point location of the 1km (approx.) pixel flagged as containing one or more fires/hotspots (fire size is not 1km, but variable). Stored by Point Geometry. See What does a hotspot/fire detection mean on the ground?
• Brightness: The brightness temperature measured (in Kelvin) using the MODIS channels 21/22 and channel 31.
• Scan and Track: The actual spatial resolution of the scanned pixel. Although the algorithm works at 1km resolution, the MODIS pixels get bigger toward the edge of the scan. See What does scan and track mean?
• Date and Time: Acquisition date of the hotspot/active fire pixel and time of satellite overpass in UTC (client presentation in local time). Stored by Acquisition Date.
  
• Acquisition Date: Derived Date/Time field combining Date and Time attributes.
• Satellite: Whether the detection was picked up by the Terra or Aqua satellite.
• Confidence: The detection confidence is a quality flag of the individual hotspot/active fire pixel.
• Version: Version refers to the processing collection and source of data. The number before the decimal refers to the collection (e.g. MODIS Collection 6). The number after the decimal indicates the source of Level 1B data; data processed in near-real time by MODIS Rapid Response will have the source code “CollectionNumber.0”. Data sourced from MODAPS (with a 2-month lag) and processed by FIRMS using the standard MOD14/MYD14 Thermal Anomalies algorithm will have a source code “CollectionNumber.x”. For example, data with the version listed as 5.0 is collection 5, processed by MRR, data with the version listed as 5.1 is collection 5 data processed by FIRMS using Level 1B data from MODAPS.
• Bright.T31: Channel 31 brightness temperature (in Kelvins) of the hotspot/active fire pixel.
• FRP: Fire Radiative Power. Depicts the pixel-integrated fire radiative power in MW (MegaWatts). FRP provides information on the measured radiant heat output of detected fires. The amount of radiant heat energy liberated per unit time (the Fire Radiative Power) is thought to be related to the rate at which fuel is being consumed (Wooster et. al. (2005)).
• DayNight: The standard processing algorithm uses the solar zenith angle (SZA) to threshold the day/night value; if the SZA exceeds 85 degrees it is assigned a night value. SZA values less than 85 degrees are assigned a day time value. For the NRT algorithm the day/night flag is assigned by ascending (day) vs descending (night) observation. It is expected that the NRT assignment of the day/night flag will be amended to be consistent with the standard processing.
• Hours Old: Derived field that provides age of record in hours between Acquisition date/time and latest update date/time. 0 = less than 1 hour ago, 1 = less than 2 hours ago, 2 = less than 3 hours ago, and so on.

This map is provided for informational purposes and is not monitored 24/7 for accuracy and

Road segments representing centerlines of all roadways or carriageways in a local government. Typically, this information is compiled from orthoimagery or other aerial photography sources. This representation of the road centerlines support address geocoding and mapping. It also serves as a source for public works and other agencies that are responsible for the active management of the road network. (From ESRI Local Government Model "RoadCenterline" Feature)**This dataset was significantly revised in August of 2014 to correct for street segments that were not properly split at intersections. There may be issues with using data based off of the original centerline file. ** The column Speed Limit was updated in November 2014 by the Transportation Intern and is believed to be accurate** The column One Way was updated in November of 2014 by core GIS and is believed to be accurate.[MAXIMOID] A unique id field used in a work order management software called Maximo by IBM. Maximo uses GIS CL data to assign locations to work orders using this field. This field is maintained by the Transportation GIS specialists and is auto incremented when new streets are digitized. For example, if the latest digitized street segment MAXIMOID = 999, the next digitized line will receive MAXIMOID = 1000, and so on. STREET NAMING IS BROKEN INTO THREE FIELDS FOR GEOCODING:PREFIX This field is attributed if a street name has a prefix such as W, N, E, or S.NAME Domain with all street names. The name of the street without prefix or suffix.ROAD_TYPE (Text,4) Describes the type of road aka suffix, if applicable. CAPCOG Addressing Guidelines Sec 504 U. states, “Every road shall have corresponding standard street suffix…” standard street suffix abbreviations comply with USPS Pub 28 Appendix C Street Abbreviations. Examples include, but are not limited to, Rd, Dr, St, Trl, Ln, Gln, Lp, CT. LEFT_LOW The minimum numeric address on the left side of the CL segment. Left side of CL is defined as the left side of the line segment in the From-To direction. For example, if a line has addresses starting at 101 and ending at 201 on its left side, this column will be attributed 101.LEFT_HIGH The largest numeric address on the left side of the CL segment. Left side of CL is defined as the left side of the line segment in the From-To direction. For example, if a line has addresses starting at 101 and ending at 201 on its left side, this column will be attributed 201.LOW The minimum numeric address on the RIGHT side of the CL segment. Right side of CL is defined as the right side of the line segment in the From-To direction. For example, if a line has addresses starting at 100 and ending at 200 on its right side, this column will be attributed 100.HIGHThe maximum numeric address on the RIGHT side of the CL segment. Right side of CL is defined as the right side of the line segment in the From-To direction. For example, if a line has addresses starting at 100 and ending at 200 on its right side, this column will be attributed 200.ALIAS Alternative names for roads if known. This field is useful for geocode re-matching. CLASSThe functional classification of the centerline. For example, Minor (Minor Arterial), Major (Major Arterial). THIS FIELD IS NOT CONSISTENTLY FILLED OUT, NEEDS AN AUDIT. FULLSTREET The full name of the street concatenating the [PREFIX], [NAME], and [SUFFIX] fields. For example, "W San Antonio St."ROWWIDTH Width of right-of-way along the CL segment. Data entry from Plat by Planning GIS Or from Engineering PICPs/ CIPs.NUMLANES Number of striped vehicular driving lanes, including turn lanes if present along majority of segment. Does not inlcude bicycle lanes. LANEMILES Describes the total length of lanes for that segment in miles. It is manually field calculated as follows (( [ShapeLength] / 5280) * [NUMLANES]) and maintained by Transportation GIS.SPEEDLIMIT Speed limit of CL segment if known. If not, assume 30 mph for local and minor arterial streets. If speed limit changes are enacted by city council they will be recorded in the Traffic Register dataset, and this field will be updating accordingly. Initial data entry made by CIP/Planning GIS and maintained by Transportation GIS.[YRBUILT] replaced by [DateBuilt] See below. Will be deleted. 4/21/2017LASTYRRECON (Text,10) Is the last four-digit year a major reconstruction occurred. Most streets have not been reconstructed since orignal construction, and will have values. The Transportation GIS Specialist will update this field. OWNER Describes the governing body or private entity that owns/maintains the CL. It is possible that some streets are owned by other entities but maintained by CoSM. Possible attributes include, CoSM, Hays Owned/City Maintained, TxDOT Owned/City Maintained, TxDOT, one of four counties (Hays, Caldwell, Guadalupe, and Comal), TxState, and Private.ST_FROM Centerline segments are split at their intersections with other CL segments. This field names the nearest cross-street in the From- direction. Should be edited when new CL segments that cause splits are added. ST_TO Centerline segments are split at their intersections with other CL segments. This field names the nearest cross-street in the To- direction. Should be edited when new CL segments that cause splits are added. PAV_WID Pavement width of street in feet from back-of-curb to back-of-curb. This data is entered from as-built by CIP GIS. In January 2017 Transportation Dept. field staff surveyed all streets and measured width from face-of-curb to face-of-curb where curb was present, and edge of pavement to edge of pavement where it was not. This data was used to field calculate pavement width where we had values. A value of 1 foot was added to the field calculation if curb and gutter or stand up curb were present (the face-of-curb to back-of-curb is 6 in, multiple that by 2 to find 1 foot). If no curb was present, the value enter in by the field staff was directly copied over. If values were already present, and entered from asbuilt, they were left alone. ONEWAY Field describes direction of travel along CL in relation to digitized direction. If a street allows bi-directional travel it is attributed "B", a street that is one-way in the From_To direction is attributed "F", a street that is one-way in the To_From direction is attributed "T", and a street that does not allow travel in any direction is attibuted "N". ROADLEVEL Field will be aliased to [MINUTES] and be used to calculate travel time along CL segments in minutes using shape length and [SPEEDLIMIT]. Field calculate using the following expression: [MINUTES] = ( ([SHAPE_LENGTH] / 5280) / ( [SPEEDLIMIT] / 60 ))ROWSTATUS Values include "Open" or "Closed". Describes whether a right-of-way is open or closed. If a street is constructed within ROW it is "Open". If a street has not yet been constructed, and there is ROW, it is "Cosed". UPDATE: This feature class only has CL geometries for "Open" rights-of-way. This field should be deleted or re-purposed. ASBUILT field used to hyper link as-built documents detailing construction of the CL. Field was added in Dec. 2016. DateBuilt Date field used to record month and year a road was constructed from Asbuilt. Data was collected previously without month information. Data without a known month is entered as "1/1/YYYY". When month and year are known enter as "M/1/YYYY". Month and Year from asbuilt. Added by Engineering/CIP. ACCEPTED Date field used to record the month, day, and year that a roadway was officially accepted by the City of San Marcos. Engineering signs off on acceptance letters and stores these documents. This field was added in May of 2018. Due to a lack of data, the date built field was copied into this field for older roadways. Going forward, all new roadways will have this date. . This field will typically be populated well after a road has been drawn into GIS. Entered by Engineering/CIP. ****In an effort to make summarizing the data more efficient in Operations Dashboard, a generic date of "1/1/1900" was assigned to all COSM owned or maintained roads that had NULL values. These were roads that either have not been accepted yet, or roads that were expcepted a long time ago and their accepted date is not known. WARRANTY_EXP Date field used to record the expiration date of a newly accepted roadway. Typically this is one year from acceptance date, but can be greater. This field was added in May of 2018, so only roadways that have been excepted since and older roadways with valid warranty dates within this time frame have been populated.

This layer presents detectable thermal activity from MODIS satellites for the last 7 days. MODIS Global Fires is a product of NASA’s Earth Observing System Data and Information System (EOSDIS), part of NASA's Earth Science Data. EOSDIS integrates remote sensing and GIS technologies to deliver global MODIS hotspot/fire locations to natural resource managers and other stakeholders around the World.Consumption Best Practices:

As a service that is subject to very high usage, ensure peak performance and accessibility of your maps and apps by avoiding the use of non-cacheable relative Date/Time field filters. To accommodate filtering events by Date/Time, we suggest using the included "Age" fields that maintain the number of days or hours since a record was created or last modified, compared to the last service update. These queries fully support the ability to cache a response, allowing common query results to be efficiently provided to users in a high demand service environment.When ingesting this service in your applications, avoid using POST requests whenever possible. These requests can compromise performance and scalability during periods of high usage because they too are not cacheable.Source: NASA FIRMS - Active Fire Data - for WorldScale/Resolution: 1kmUpdate Frequency: 1/2 Hour (every 30 minutes) using the Aggregated Live Feed MethodologyArea Covered: WorldWhat can I do with this layer?The MODIS thermal activity layer can be used to visualize and assess wildfires worldwide. However, it should be noted that this dataset contains many “false positives” (e.g., oil/natural gas wells or volcanoes) since the satellite will detect any large thermal signal.Additional InformationMODIS stands for MODerate resolution Imaging Spectroradiometer. The MODIS instrument is on board NASA’s Earth Observing System (EOS) Terra (EOS AM) and Aqua (EOS PM) satellites. The orbit of the Terra satellite goes from north to south across the equator in the morning and Aqua passes south to north over the equator in the afternoon resulting in global coverage every 1 to 2 days. The EOS satellites have a ±55 degree scanning pattern and orbit at 705 km with a 2,330 km swath width.It takes approximately 2 – 4 hours after satellite overpass for MODIS Rapid Response to process the data, and for the Fire Information for Resource Management System (FIRMS) to update the website. Occasionally, hardware errors can result in processing delays beyond the 2-4 hour range. Additional information on the MODIS system status can be found at MODIS Rapid Response.Attribute InformationLatitude and Longitude: The center point location of the 1km (approx.) pixel flagged as containing one or more fires/hotspots (fire size is not 1km, but variable). Stored by Point Geometry. See What does a hotspot/fire detection mean on the ground?Brightness: The brightness temperature measured (in Kelvin) using the MODIS channels 21/22 and channel 31.Scan and Track: The actual spatial resolution of the scanned pixel. Although the algorithm works at 1km resolution, the MODIS pixels get bigger toward the edge of the scan. See What does scan and track mean?Date and Time: Acquisition date of the hotspot/active fire pixel and time of satellite overpass in UTC (client presentation in local time). Stored by Acquisition Date.Acquisition Date: Derived Date/Time field combining Date and Time attributes.Satellite: Whether the detection was picked up by the Terra or Aqua satellite.Confidence: The detection confidence is a quality flag of the individual hotspot/active fire pixel.Version: Version refers to the processing collection and source of data. The number before the decimal refers to the collection (e.g. MODIS Collection 6). The number after the decimal indicates the source of Level 1B data; data processed in near-real time by MODIS Rapid Response will have the source code “CollectionNumber.0”. Data sourced from MODAPS (with a 2-month lag) and processed by FIRMS using the standard MOD14/MYD14 Thermal Anomalies algorithm will have a source code “CollectionNumber.x”. For example, data with the version listed as 5.0 is collection 5, processed by MRR, data with the version listed as 5.1 is collection 5 data processed by FIRMS using Level 1B data from MODAPS.Bright.T31: Channel 31 brightness temperature (in Kelvins) of the hotspot/active fire pixel.FRP: Fire Radiative Power. Depicts the pixel-integrated fire radiative power in MW (MegaWatts). FRP provides information on the measured radiant heat output of detected fires. The amount of radiant heat energy liberated per unit time (the Fire Radiative Power) is thought to be related to the rate at which fuel is being consumed (Wooster et. al. (2005)).DayNight: The standard processing algorithm uses the solar zenith angle (SZA) to threshold the day/night value; if the SZA exceeds 85 degrees it is assigned a night value. SZA values less than 85 degrees are assigned a day time value. For the NRT algorithm the day/night flag is assigned by ascending (day) vs descending (night) observation. It is expected that the NRT assignment of the day/night flag will be amended to be consistent with the standard processing.Hours Old: Derived field that provides age of record in hours between Acquisition date/time and latest update date/time. 0 = less than 1 hour ago, 1 = less than 2 hours ago, 2 = less than 3 hours ago, and so on.RevisionsJune 22, 2022: Added 'HOURS_OLD' field to enhance Filtering data. Added 'Last 7 days' Layer to extend data to match time range of VIIRS offering. Added Field level descriptions.This map is provided for informational purposes and is not monitored 24/7 for accuracy and currency.If you would like to be alerted to potential issues or simply see when this Service will update next, please visit our Live Feed Status Page!

This alley feature class represents current street centerline lines in the City of Los Angeles. The Mapping and Land Records Division of the Bureau of Engineering, Department of Public Works provides the most current geographic information of the public right of way. The right of way information is available on NavigateLA, a website hosted by the Bureau of Engineering, Department of Public Works. Alley Centerline layer was created in geographical information systems (GIS) software to display alley centerlines. The purpose of the layer is to show the location of the alleys on map products and web mapping applications. The Bureau of Street Services tracks the location of existing alleys that they maintain. Alleys are not dedicated streets, and the use of the road is determined by the Planning Department. Street features in the Street Centerline layer are dedicated. In the Alley Centerline layer, there is no naming convention stored in the corresponding records to identify the names of the alleys. Department of Transportation, LADOT, is working on a naming standard. Note there are Alleys features in the Street Centerline layer are Named Alleys. Since the line features for named alleys are stored in the Street Centerline layer, there are no line features for named alleys in those areas that are geographically coincident in the Alley layer. For a named alley line feature in the Street Centerline layer, the corresponding record contains the street designation field value of ST_DESIG = 20, and there is a name for the alley stored in the STNAME and STSFX fields. Currently the Alley line features in Alley layer do not split the street centerline layer features where they intersect, so there is no intersection point created or maintained in the Intersection layer.List of Fields:ZIP_R: Zip code right.ID: A unique numeric identifier of the line feature. This unique identifier is no longer used and ASSETID is used now instead.AL_DESIG: This value is currently not being used.MAPSHEET: The alpha-numeric mapsheet number, which refers to a valid B-map or A-map number on the Cadastral tract index map. Values: • B, A, -5A - Any of these alpha-numeric combinations are used, whereas the underlined spaces are the numbers.SHAPE: Feature geometry.USER_ID: The name of the user carrying out the edits.CRTN_DT: Creation date of the polygon feature.LST_MODF_DT: Last modification date of the feature.ZIP_L: Zip code left.STNUM: Street identification number. This field is currently not being used.OBJECTID: Internal feature number.LINE_ID: This value is currently not being edited. This used to be an automatically assigned unique ID of the alley centerline line segments.ASSETID: User-defined feature autonumber.AL_ID: This value is the ID of the alley as assigned by Bureau of Street Services, Department of Public Works. This is unique for each alley, but not unique for each alley line segment. This field has not been updated.SHAPE.LEN

This parcel lines feature class represents the current city parcel lines within the City of Los Angeles. It shares topology with the Landbase Parcel_polygons feature class. The Mapping and Land Records Division of the Bureau of Engineering, Department of Public Works provides the most current geographic information of the public right of way, ownership and land record information. The legal boundaries are determined on the ground by license surveyors in the State of California, and by recorded documents from the Los Angeles County Recorder's office and the City Clerk's office of the City of Los Angeles. Parcel and ownership information are available on NavigateLA, a website hosted by the Bureau of Engineering, Department of Public Works.Associated information about the landbase parcel lines is entered into attributes. Principal attributes include:CV_LAYER: is the principal field that describes the various types of lines like street and freeway right-of-ways, tract, lots, government property and easements lines, private street lines, utility right-of-ways, and ownership lines. For a complete list of attribute values, please refer to Landbase_parcel_lines_data_dictionary.Landbase parcels lines layer was created in geographical information systems (GIS) software to display the location of parcel lots. The parcels lines layer is a feature class in the LACityLandbaseData.gdb Geodatabase dataset. The layer consists of spatial data as a line feature class and attribute data for the features. The lines are derived from the polygon feature class in the landbase parcels layer, and information about the lines is entered into attributes. The CV_LAYER field values describe the various types of lines. The right-of-way, row, line features consist of CV_LAYER = 6, CV_LAYER = 106, and portions of CV_LAYER = 1 where that line is both the city boundary and the parcel line. In some cases, a parcel line will share two different type descriptions. Refer to CV_LAYER field metadata for further explantion. Parcel information should only be added to the Landbase Parcels layer if documentation exists, such as a Deed or a Plan approved by the City Council. When seeking the definitive description of real property, consult the recorded Deed or Plan.List of Fields:ASSETIDCV_LAYER: This value is a number representing a different type of user-assigned layer. Each of the line segments in the landbase parcels lines are assigned one of the CV_LAYER numbers, representing a different type of line work, described below. In some cases, a parcel line will share two different type descriptions. Such as, a parcel line may have CV_LAYER = 1 City Boundary line, and it is a CV_LAYER = 8 Tract line. The Tract line description is used first, and the City Boundary line description is used second. When selecting City Boundary line using CV_LAYER = 1, then (special way to select data...). The right-of-way, row, line features consist of CV_LAYER = 6, CV_LAYER = 106, and portions of CV_LAYER = 1 where that line is both the city boundary and the parcel line. Values: • 50 - Lot cut linework. • 38 - Freeway ease as easement lines. • 108 - Tract lines that are private street lines. • 8 - Tract lines, Rancho lines, Freeway (Fwy), and Right of way lines. • 30 - Former city boundary lines; other city or county boundary line. • 34 - Overlap lines. • 6 - Right of way (R/W) sidelines. • 19 - LA City easement lines. • 21 - All governmental lines (Fee). • 37 - APN (BPP) lines shown on tax assessors map (PCL maps); but no new PIN is created for the parcels polygon feature. • 48 - Subdivision title anno shown for ownership purpose (lot cut). • 10 - Lot lines. • 68 - SBBM (San Bernardino Base Meridian) section lines. • 1 - Boundary lines (existing). • 110 - Lot lines that are private street lines. • 18 - All governmental easement lines (except LA City and State freeway ease right of way lines). • 106 - Fwy traveled roadway lines; Dash right of way lines; Railroad and transmission lines. • 0 - Cadastral format.SHAPE: Feature geometry.OBJECTID: Internal feature number.ID: A unique numeric identifier of the polygon. The ID value is the last part of the PIN field value.MAPSHEET: The alpha-numeric mapsheet number, which refers to a valid B-map or A-map number on the Cadastral tract index map. Values: • B, A, -5A - Any of these alpha-numeric combinations are used, whereas the underlined spaces are the numbers.

Light Poles is a Point FeatureClass representing light posts distributed throughout the city. It is primarily used for identifying and tracking assets and necessary maintenance and repairs. The layer is updated as needed by the GIS division and by field staff. Light Poles has the following fields:

AssetID: Cupertino maintained GIS primary key type: String, length: 20, domain: none

Location: Further description of the location type: String, length: 50, domain: none

Status: The active or construction status of the asset in the field type: String, length: 20, domain: pwStatus domain values:['Abandoned', 'Proposed', 'Auction', 'Denied', 'Active', 'Removed', 'Not Connected']

OwnedBy: Organization which owns the asset type: String, length: 50, domain: shdOwnedBy domain values:['Cupertino', 'San Jose Water', 'CalTrans', 'PGE', 'Los Altos', 'Santa Clara', 'Private HOA', 'Saratoga', 'Other Public', 'Santa Clara County', 'San Jose', 'Santa Clara Valley Water District', 'Private', 'California Water Service', 'State Parks', 'Sunnyvale', 'Cupertino Sanitary District', 'CWA']

MaintainedBy: Organization who is responsible for maintenance of asset type: String, length: 50, domain: shdOwnedBy domain values:['Cupertino', 'San Jose Water', 'CalTrans', 'PGE', 'Los Altos', 'Santa Clara', 'Private HOA', 'Saratoga', 'Other Public', 'Santa Clara County', 'San Jose', 'Santa Clara Valley Water District', 'Private', 'California Water Service', 'State Parks', 'Sunnyvale', 'Cupertino Sanitary District', 'CWA']

CreateDate: The date the database row was initially created type: Date, length: 8, domain: none

UpdateDate: The date the database row was last updated type: Date, length: 8, domain: none

Rotation: Field used for assigning rotation degree in Maplex Labeling Engine type: Double, length: 8, domain: none

BadgeNumber: The badge number assigned to the light pole type: String, length: 6, domain: none

ServiceID: Service identification number type: String, length: 20, domain: none

PoleType: Field describing the type of pole found at the location type: String, length: 20, domain: utilLightPoleType domain values:['Mast Arm Pole', 'Taper 4 Bolt', '33', 'PBP Pole', 'Taper 3 Bolt', '1A', 'Type15', '1B', 'Taper 1 Bolt', 'Top Mount', 'Flute 1 Bolt', 'Taper 2 Bolt']

PoleMaterial: Field indicating what material the pole is made of type: String, length: 20, domain: utilLightPoleMaterial domain values:['Steel', 'Concrete', 'Aluminium', 'Galvanized', 'Wood']

PoleHeight: The height of the light pole type: SmallInteger, length: 2, domain: none

ArmLength: The length of the light pole arm - in feet type: SmallInteger, length: 2, domain: utilLightArmLength domain values:["65'", "3'", "6'", "8'", "10'", "12'", "45'", "15'", "40'", "50'", "35'", "20'", "55'", "25'", "60'", "30'"]

LightFunction: Field indicating the function of the light pole type: String, length: 20, domain: utilLightFunction domain values:['Street Light', 'Tennis Court Light', 'Parking Lot Light', 'Park Light', 'Flood Light', 'Safety Light']

NumberOfHeads: Field indicating the number of heads on the light pole type: SmallInteger, length: 2, domain: utilLampNumberOf domain values:['1', '2', '3', '4']

LampType: Field identifying the type of lamp used in the light pole type: String, length: 10, domain: utilLampType domain values:['High Pressure Sodium', 'Mercury Vapor', 'LED', 'Metal Halide', 'Inductive']

Wattage: Field indicating the number of watts type: SmallInteger, length: 2, domain: none

Volts: Field indicating the number of volts type: SmallInteger, length: 2, domain: utilLampVoltage domain values:['120V', '240V', '480V', '277V']

Base: Field indicating the type of base that light pole uses type: String, length: 10, domain: utilLightBase domain values:['Anchor', 'Buried']

Fixture: Field indicating which type of fixture style the light pole has type: String, length: 20, domain: utilLightFixture domain values:['Park Dome', 'Ornamental', 'Cobra', 'Shoe Box']

ControlType: Field indicating what type of control method is used type: String, length: 20, domain: utilLightControlType domain values:['Time Clock', 'Photo Electronic Control']

HasBeacon: Field indicating whether or not the light pole has a beacon type: String, length: 4, domain: shdBooleanYesNo domain values:['Yes', 'No']

IsFused: Field indicating whether or not the light pole is fused type: String, length: 3, domain: shdBooleanYesNo domain values:['Yes', 'No']

IsUnderground: Field indicating if the light pole is secured underground type: String, length: 4, domain: shdBooleanYesNo domain values:['Yes', 'No']

IsMetered: Field indicating whether or not the light pole is metered type: String, length: 4, domain: shdBooleanYesNo domain values:['Yes', 'No']

HasStencil: Field indicating whether or not the light pole has a stencil type: String, length: 4, domain: shdBooleanYesNo domain values:['Yes', 'No']

HasSticker: Field indicating whether or not the light pole has a sticker type: String, length: 4, domain: shdBooleanYesNo domain values:['Yes', 'No']

RateSchedule:

type: String, length: 10, domain: utilLightRateSchedule domain values:['LS1-F1', 'LS1-F', 'LS1-E', 'LS1-B', 'LS1-C', 'LS1-A', 'LS2-A']

GlobalID: Unique identifier automatically generated for features in enterprise database type: GlobalID, length: 38, domain: none

POINT_X: The X coordinate of the light pole type: Double, length: 8, domain: none

POINT_Y: The Y coordinate of the light pole type: Double, length: 8, domain: none

NoVehicleHds: Field indicating the number of vehicle heads on the light pole type: SmallInteger, length: 2, domain: trafNoOfVehHeads NoPedHds: Field indicating the number of pedestrian heads on the light pole type: SmallInteger, length: 2, domain: trafNoOfPedHeads domain values:['0', '1', '2']

NoPedButtons: Field indicating the number of pedestrian buttons on the light pole type: SmallInteger, length: 2, domain: trafNoOfPedButtons domain values:['0', '1', '2', '3']

Shape: Field that stores geographic coordinates associated with feature type: Geometry, length: 4, domain: none

IsTrafficSignal: Field indicating whether or not the light pole is used as a traffic signal type: String, length: 3, domain: shd_BooleanYesNo domain values:['Yes', 'No']

hasHandPoleCover: Field indicating whether or not the light pole has a hand pole cover type: String, length: 3, domain: shdBooleanYesNo domain values:['Yes', 'No']

isStreetlight: Field indicating whether or not the light pole is designated as a streetlight type: String, length: 3, domain: shdBooleanYesNo domain values:['Yes', 'No']

isSmallCell: Field indicating whether or not the light pole has a small cell attatched type: String, length: 3, domain: shdBooleanYesNo domain values:['Yes', 'No']

SmallCellCarrier: Carrier associated with the small cell type: String, length: 50, domain: utilSmallCellCarrier domain values:['Mobilitie', 'ATT', 'Crown Castle', 'Verizon']

hasFlagHolder: Field indicating whether or not the light pole has a flag holder type: String, length: 3, domain: shdBooleanYesNo domain values:['Yes', 'No']

FlagHolderInstallDate: The date when the flag holder was installed type: Date, length: 8, domain: none

hasSafeRouteBanner: Field indicating whether or not the light pole has a Safe Routes 2 School banner type: String, length: 3, domain: shdBooleanYesNo domain values:['Yes', 'No']

Traffic Poles is a Point FeatureClass representing traffic poles in the City of Cupertino. It is primarily used as an inventory layer in Cityworks and as a reference layer. The layer is updated as needed by the Public Works Department and the GIS Division. Traffic Poles has the following fields: OBJECTID: Unique identifier automatically generated by Esri type: OID, length: 4, domain: none

AssetID: Cupertino maintained GIS primary key type: String, length: 20, domain: none

Location: Further description of the location type: String, length: 50, domain: none

Status: The active or construction status of the asset in the field type: String, length: 20, domain: pwStatus domain values:['Abandoned', 'Proposed', 'Auction', 'Denied', 'Active', 'Removed', 'Not Connected']

OwnedBy: Organization which owns the asset type: String, length: 50, domain: shdOwnedBy domain values:['Cupertino', 'San Jose Water', 'CalTrans', 'PGE', 'Los Altos', 'Santa Clara', 'Private HOA', 'Saratoga', 'Other Public', 'Santa Clara County', 'San Jose', 'Santa Clara Valley Water District', 'Private', 'California Water Service', 'State Parks', 'Sunnyvale', 'Cupertino Sanitary District', 'CWA']

MaintainedBy: Organization who is responsible for maintenance of asset type: String, length: 50, domain: shdOwnedBy domain values:['Cupertino', 'San Jose Water', 'CalTrans', 'PGE', 'Los Altos', 'Santa Clara', 'Private HOA', 'Saratoga', 'Other Public', 'Santa Clara County', 'San Jose', 'Santa Clara Valley Water District', 'Private', 'California Water Service', 'State Parks', 'Sunnyvale', 'Cupertino Sanitary District', 'CWA'] AsbuiltDate:

The completion date listed on the plans type: Date, length: 8, domain: none

Date Install:

The date of the most recent maintenance on this asset type: Date, length: 8, domain: none

CreateDate: The date the database row was initially created type: Date, length: 8, domain: none

UpdateDate: The date the database row was last updated type: Date, length: 8, domain: none

Rotation: Field used for assigning rotation degree in Maplex Labeling Engine type: Double, length: 8, domain: none

BadgeNumber: The badge number assigned to the traffic pole type: String, length: 6, domain: none

ServiceID: Service identification number type: String, length: 20, domain: none

PoleType: Field describing the type of pole found at the location type: String, length: 20, domain: utilLightPoleType domain values:['Mast Arm Pole', 'Taper 4 Bolt', '33', 'PBP Pole', 'Taper 3 Bolt', '1A', 'Type15', '1B', 'Taper 1 Bolt', 'Top Mount', 'Flute 1 Bolt', 'Taper 2 Bolt']

PoleMaterial: Field indicating what material the pole is made of type: String, length: 20, domain: utilLightPoleMaterial domain values:['Steel', 'Concrete', 'Aluminium', 'Galvanized', 'Wood']

PoleHeight: Field indicating the height of the pole type: SmallInteger, length: 2, domain: none

ArmLength: The length of the traffic pole arm - in feet type: SmallInteger, length: 2, domain: utilLightArmLength domain values:["65'", "3'", "6'", "8'", "10'", "12'", "45'", "15'", "40'", "50'", "35'", "20'", "55'", "25'", "60'", "30'"]

LightFunction: Field indicating the function of the light on the pole type: String, length: 20, domain: utilLightFunction domain values:['Street Light', 'Tennis Court Light', 'Parking Lot Light', 'Park Light', 'Flood Light', 'Safety Light']

NumberofHeads: Field indicating the number of heads on the pole type: SmallInteger, length: 2, domain: utilLampNumberOf domain values:['1', '2', '3', '4']

LampType: Field identifying the type of lamp used in the light on pole type: String, length: 10, domain: utilLampType domain values:['High Pressure Sodium', 'Mercury Vapor', 'LED', 'Metal Halide', 'Inductive']

Wattage: Field indicating the number of watts type: SmallInteger, length: 2, domain: none

Volts: Field indicating the number of volts type: SmallInteger, length: 2, domain: utilLampVoltage domain values:['120V', '240V', '480V', '277V']

Base: Field indicating the type of base that pole uses type: String, length: 10, domain: utilLightBase domain values:['Anchor', 'Buried']

Fixture: Field indicating which type of fixture style the pole has type: String, length: 20, domain: utilLightFixture domain values:['Park Dome', 'Ornamental', 'Cobra', 'Shoe Box']

ControlType: Field indicating what type of control method is used type: String, length: 20, domain: utilLightControlType domain values:['Time Clock', 'Photo Electronic Control']

HasBeacon: Field indicating whether or not the pole has a beacon type: String, length: 4, domain: shdBooleanYesNo domain values:['Yes', 'No']

IsFused: Field indicating whether or not the pole is fused type: String, length: 3, domain: shdBooleanYesNo domain values:['Yes', 'No']

IsUnderground: Field indicating if the pole is secured underground type: String, length: 4, domain: shdBooleanYesNo domain values:['Yes', 'No']

IsMetered: Field indicating whether or not the pole is metered type: String, length: 4, domain: shdBooleanYesNo domain values:['Yes', 'No']

HasStencil: Field indicating whether or not the pipe has a stencil type: String, length: 4, domain: shdBooleanYesNo domain values:['Yes', 'No']

HasSticker: Field indicating whether or not the pole has a sticker type: String, length: 4, domain: shdBooleanYesNo domain values:['Yes', 'No']

RateSchedule:

type: String, length: 10, domain: utilLightRateSchedule domain values:['LS1-F1', 'LS1-F', 'LS1-E', 'LS1-B', 'LS1-C', 'LS1-A', 'LS2-A']

GlobalID: Unique identifier automatically generated for features in enterprise database type: GlobalID, length: 38, domain: none

POINT_X: The X coordinate of the traffic pole type: Double, length: 8, domain: none

POINT_Y: The Y coordinate of the traffic pole type: Double, length: 8, domain: none

NoVehicleHds: Field indicating the number of vehicle heads on the pole type: SmallInteger, length: 2, domain: trafNoOfVehHeads NoPedHds: Field indicating the number of pedestrian heads on the pole type: SmallInteger, length: 2, domain: trafNoOfPedHeads domain values:['0', '1', '2']

NoPedButtons: Field indicating the number of pedestrian buttons on the pole type: SmallInteger, length: 2, domain: trafNoOfPedButtons domain values:['0', '1', '2', '3']

Shape: Field that stores geographic coordinates associated with feature type: Geometry, length: 4, domain: none

IsTrafficSignal: Field indicating whether or not the pole is used as a traffic signal type: String, length: 3, domain: shd_BooleanYesNo domain values:['Yes', 'No']

hasHandPoleCover: Field indicating whether or not the pole has a hand pole cover type: String, length: 3, domain: shdBooleanYesNo domain values:['Yes', 'No']

isStreetlight: Field indicating whether or not the pole is designated as a streetlight type: String, length: 3, domain: shdBooleanYesNo domain values:['Yes', 'No']

isSmallCell: Field indicating whether or not the pole has a small cell attatched type: String, length: 3, domain: shdBooleanYesNo domain values:['Yes', 'No']

SmallCellCarrier: Carrier associated with the small cell type: String, length: 50, domain: utilSmallCellCarrier domain values:['Mobilitie', 'ATT', 'Crown Castle', 'Verizon']

hasFlagHolder: Field indicating whether or not the pole has a flag holder type: String, length: 3, domain: shdBooleanYesNo domain values:['Yes', 'No']

FlagHolderInstallDate: The date when the flag holder was installed type: Date, length: 8, domain: none

hasSafeRouteBanner: Field indicating whether or not the pole has a Safe Routes 2 School banner type: String, length: 3, domain: shdBooleanYesNo domain values:['Yes', 'No']

Generalized attribute values -- From the parcel data (Aquinnah FY22, Chilmark FY23, Edgartown FY23, Gosnold FY21, Oak Bluffs FY22, Tisbury FY22, West Tisbury FY23) the Assess Table was summarized based on unique Loc_ID for the 'first' owner zip code, the 'first' use code, the minimum year built, and the maximum year built. The summarized table for each town was joined to the building centroid points based on Loc_ID. For the field [YrRnd] a value of "S" (seasonal) was assigned to those buildings where the first owner zip code was NOT an MV or Gosnold zip code; all other building centroid points received a value of "YR" for year-round. This is a gross assumption.For the field [Res] a value of "R" (residential) was assigned to those buildings where the first use code began with a value of 1. All other building centroid points received a value of "NR" for non-residential. NOTE: Some 'residential' properties may be vacant but developable or undevelopable per the assessor.The field of [MinYrBlt] is based on the minimum year built for all records associated with that parcel in the Assess table in the parcel file geodatabase. This minimum year built value from the Assess table was copied into this Build Structure Points feature class based on the join field of [Loc_ID]. If there are multiple structures on a parcel, they all received the same Minimum Year Built.A similar process, as [MaxYrBlt], was followed to populate [MaxYrBlt].The Min & Max year built are provided for a quick & dirty/general gist/approximation as to when that structure was developed. You are encouraged to do more research if you are doing site specific analysis regarding development. A NOTE about the Assess Table that's in the Level 3 Parcel Geodatabases: The assess table will have multiple entries for each parcel only if there are multiple owners (such as a parcel containing condos). The assess table does NOT have multiple records if the parcel contains multiple buildings. The Year Built included in the Assess Table might be for the first structure developed on the property or maybe it's for the primary/largest structure on the parcel ...basically, it's anyone's best guess. Aside from reviewing the detailed property cards for every property, it's impossible to know which specific structure on the property the Year Built corresponds to. Regarding Use Code, it is possible that the use will vary based on the owner (doesn't happen often - but it happens). Simply extracting the 'first' use code where there are multiple records/owners for a parcel, this is just a quick & easy way to assign a plausible use to each structure on the parcel.A NOTE about the Structures: -- These could be a main house, a guest house, or a barn or shed or garage, etc. Any and All structures are included in this dataset.This dataset consists of 2-dimensional roof outlines ("roofprints") for all buildings larger than 150 square feet, as initially interpreted by a contractor (Rolta) for the whole area of the Commonwealth using DigitalGlobe ortho images obtained in 2011 and 2012, supplemented with LiDAR (Light Detection And Ranging) data collected from 2002 to 2011 for the eastern half of the state.The roofprints as delivered by Rolta were enhanced by MassGIS using Normalized Digital Surface Models (NDSMs) derived from the same LiDAR data. Other layers were used, including the Standardized Parcels, to aid in review, especially where LiDAR data were not available.In 2019, MassGIS refreshed the data to a baseline of 2016 and continues to update features using newer aerial imagery that allows MassGIS staff to remove, modify and add structures to keep up with more current ground conditions. Structures from the original compilation that are removed are stored in an "archive" feature class for edit tracking and historical purposes. Also in 2019, MassGIS replaced the polygons in Boston with data from the city. In March 2021, the layer was updated with 2017 and 2018 structure review edits along with the first data edits compiled atop spring 2019 imagery. In July 2021, MassGIS completed the statewide update based on 2019 imagery. In September 2022, MassGIS completed the statewide update based on 2021 imagery.Last updated on 9/19/2022.In ArcSDE the layer is named STRUCTURES_POLY.

Road segments representing centerlines of all roadways or carriageways in a local government. Typically, this information is compiled from orthoimagery or other aerial photography sources. This representation of the road centerlines support address geocoding and mapping. It also serves as a source for public works and other agencies that are responsible for the active management of the road network. (From ESRI Local Government Model "RoadCenterline" Feature)**This dataset was significantly revised in August of 2014 to correct for street segments that were not properly split at intersections. There may be issues with using data based off of the original centerline file. ** The column Speed Limit was updated in November 2014 by the Transportation Intern and is believed to be accurate** The column One Way was updated in November of 2014 by core GIS and is believed to be accurate.[MAXIMOID] A unique id field used in a work order management software called Maximo by IBM. Maximo uses GIS CL data to assign locations to work orders using this field. This field is maintained by the Transportation GIS specialists and is auto incremented when new streets are digitized. For example, if the latest digitized street segment MAXIMOID = 999, the next digitized line will receive MAXIMOID = 1000, and so on. STREET NAMING IS BROKEN INTO THREE FIELDS FOR GEOCODING:PREFIX This field is attributed if a street name has a prefix such as W, N, E, or S.NAME Domain with all street names. The name of the street without prefix or suffix.ROAD_TYPE (Text,4) Describes the type of road aka suffix, if applicable. CAPCOG Addressing Guidelines Sec 504 U. states, “Every road shall have corresponding standard street suffix…” standard street suffix abbreviations comply with USPS Pub 28 Appendix C Street Abbreviations. Examples include, but are not limited to, Rd, Dr, St, Trl, Ln, Gln, Lp, CT. LEFT_LOW The minimum numeric address on the left side of the CL segment. Left side of CL is defined as the left side of the line segment in the From-To direction. For example, if a line has addresses starting at 101 and ending at 201 on its left side, this column will be attributed 101.LEFT_HIGH The largest numeric address on the left side of the CL segment. Left side of CL is defined as the left side of the line segment in the From-To direction. For example, if a line has addresses starting at 101 and ending at 201 on its left side, this column will be attributed 201.LOW The minimum numeric address on the RIGHT side of the CL segment. Right side of CL is defined as the right side of the line segment in the From-To direction. For example, if a line has addresses starting at 100 and ending at 200 on its right side, this column will be attributed 100.HIGHThe maximum numeric address on the RIGHT side of the CL segment. Right side of CL is defined as the right side of the line segment in the From-To direction. For example, if a line has addresses starting at 100 and ending at 200 on its right side, this column will be attributed 200.ALIAS Alternative names for roads if known. This field is useful for geocode re-matching. CLASSThe functional classification of the centerline. For example, Minor (Minor Arterial), Major (Major Arterial). THIS FIELD IS NOT CONSISTENTLY FILLED OUT, NEEDS AN AUDIT. FULLSTREET The full name of the street concatenating the [PREFIX], [NAME], and [SUFFIX] fields. For example, "W San Antonio St."ROWWIDTH Width of right-of-way along the CL segment. Data entry from Plat by Planning GIS Or from Engineering PICPs/ CIPs.NUMLANES Number of striped vehicular driving lanes, including turn lanes if present along majority of segment. Does not inlcude bicycle lanes. LANEMILES Describes the total length of lanes for that segment in miles. It is manually field calculated as follows (( [ShapeLength] / 5280) * [NUMLANES]) and maintained by Transportation GIS.SPEEDLIMIT Speed limit of CL segment if known. If not, assume 30 mph for local and minor arterial streets. If speed limit changes are enacted by city council they will be recorded in the Traffic Register dataset, and this field will be updating accordingly. Initial data entry made by CIP/Planning GIS and maintained by Transportation GIS.[YRBUILT] replaced by [DateBuilt] See below. Will be deleted. 4/21/2017LASTYRRECON (Text,10) Is the last four-digit year a major reconstruction occurred. Most streets have not been reconstructed since orignal construction, and will have values. The Transportation GIS Specialist will update this field. OWNER Describes the governing body or private entity that owns/maintains the CL. It is possible that some streets are owned by other entities but maintained by CoSM. Possible attributes include, CoSM, Hays Owned/City Maintained, TxDOT Owned/City Maintained, TxDOT, one of four counties (Hays, Caldwell, Guadalupe, and Comal), TxState, and Private.ST_FROM Centerline segments are split at their intersections with other CL segments. This field names the nearest cross-street in the From- direction. Should be edited when new CL segments that cause splits are added. ST_TO Centerline segments are split at their intersections with other CL segments. This field names the nearest cross-street in the To- direction. Should be edited when new CL segments that cause splits are added. PAV_WID Pavement width of street in feet from back-of-curb to back-of-curb. This data is entered from as-built by CIP GIS. In January 2017 Transportation Dept. field staff surveyed all streets and measured width from face-of-curb to face-of-curb where curb was present, and edge of pavement to edge of pavement where it was not. This data was used to field calculate pavement width where we had values. A value of 1 foot was added to the field calculation if curb and gutter or stand up curb were present (the face-of-curb to back-of-curb is 6 in, multiple that by 2 to find 1 foot). If no curb was present, the value enter in by the field staff was directly copied over. If values were already present, and entered from asbuilt, they were left alone. ONEWAY Field describes direction of travel along CL in relation to digitized direction. If a street allows bi-directional travel it is attributed "B", a street that is one-way in the From_To direction is attributed "F", a street that is one-way in the To_From direction is attributed "T", and a street that does not allow travel in any direction is attibuted "N". ROADLEVEL Field will be aliased to [MINUTES] and be used to calculate travel time along CL segments in minutes using shape length and [SPEEDLIMIT]. Field calculate using the following expression: [MINUTES] = ( ([SHAPE_LENGTH] / 5280) / ( [SPEEDLIMIT] / 60 ))ROWSTATUS Values include "Open" or "Closed". Describes whether a right-of-way is open or closed. If a street is constructed within ROW it is "Open". If a street has not yet been constructed, and there is ROW, it is "Cosed". UPDATE: This feature class only has CL geometries for "Open" rights-of-way. This field should be deleted or re-purposed. ASBUILT field used to hyper link as-built documents detailing construction of the CL. Field was added in Dec. 2016. DateBuilt Date field used to record month and year a road was constructed from Asbuilt. Data was collected previously without month information. Data without a known month is entered as "1/1/YYYY". When month and year are known enter as "M/1/YYYY". Month and Year from asbuilt. Added by Engineering/CIP. ACCEPTED Date field used to record the month, day, and year that a roadway was officially accepted by the City of San Marcos. Engineering signs off on acceptance letters and stores these documents. This field was added in May of 2018. Due to a lack of data, the date built field was copied into this field for older roadways. Going forward, all new roadways will have this date. . This field will typically be populated well after a road has been drawn into GIS. Entered by Engineering/CIP. ****In an effort to make summarizing the data more efficient in Operations Dashboard, a generic date of "1/1/1900" was assigned to all COSM owned or maintained roads that had NULL values. These were roads that either have not been accepted yet, or roads that were expcepted a long time ago and their accepted date is not known. WARRANTY_EXP Date field used to record the expiration date of a newly accepted roadway. Typically this is one year from acceptance date, but can be greater. This field was added in May of 2018, so only roadways that have been excepted since and older roadways with valid warranty dates within this time frame have been populated.

Reason for Selection Large areas of intact natural habitat are favorable for conservation of numerous species, including reptiles and amphibians, birds, and large mammals. The Esri Green Infrastructure data covers the entire United States and has been used in other broad-scale conservation planning efforts, so using this existing data helps align the Blueprint with other conservation efforts and reduce duplication of effort. We chose to use “Core Size (acres)” as the metric for this indicator. Other evaluation attributes included in this index, such as the default “Core Score”, were less suitable because they were calculated using inputs that are duplicative of other indicators.Input Data2021 National Land Cover Database (NLCD)Southeast Blueprint 2024 extentEsri’s Intact Habitat Cores 2023, accessed 2-16-2024: Core Size (Acres); to download, select “Open in ArcGIS Desktop” and make a local copy. According to Esri’s data description for the 2023 intact habitat cores update: “This layer represents modeled Intact Habitat Cores, or minimally disturbed natural areas at least 100 acres in size and greater than 200 meters wide. Esri created these data following a methodology outlined by the Green Infrastructure Center Inc. These data were generated using 2019 National Land Cover Data. Cores were derived from all “natural” landcover classes and excluded all “developed” and “agricultural” classes including crop, hay and pasture lands. The resulting cores were tested for size and width requirements (at least 100 acres in size and greater than 200 meters wide) and then converted into unique polygons.”Mapping StepsConvert the Esri Intact Habitat Cores 2023 polygons to a 30 m raster using the values in the “Acres” field. We used the feature layer map service as the input in the Polygon to Raster function in the code.Reclassify the above raster into 4 classes, seen in the final indicator values below.Use NLCD to remove zero values in deep marine areas, which are outside the scope of this terrestrial indicator. Use a conditional statement to assign NoData to any area with a pixel value >0 in the NLCD.As a final step, clip to the spatial extent of Southeast Blueprint 2024. Note: For more details on the mapping steps, code used to create this layer is available in the Southeast Blueprint Data Download under > 6_Code. Final indicator valuesIndicator values are assigned as follows:3 = Large core (>10,000 acres)2 = Medium core (>1,000-10,000 acres)1 = Small core (>100–1,000 acres) 0 = Not a coreKnown IssuesThe core analysis for this indicator is based on the 2019 NLCD, not the more recent 2021 NLCD. Esri has shared the scripts and input data used to create this layer, which may also help update this indicator in the future.Even small dirt roads serve as hard boundaries for habitat cores. While this makes sense for some species, this indicator likely underestimates the effective size of the patch for some more mobile animals.Waterbodies like reservoirs are also considered part of habitat cores, so this layer likely overestimates the effective size of the habitat core for most species.Many intact habitat cores have a speckling of small altered areas inside of them. In some cases, like in areas of west TX with concentrated oil wells, there can be many alterations in a gridded pattern across the entire core. This indicator underestimates the cumulative impacts of interior alterations—especially when the small altered footprints are densely packed in a grid within a habitat core.Disclaimer: Comparing with Older Indicator Versions There are numerous problems with using Southeast Blueprint indicators for change analysis. Please consult Blueprint staff if you would like to do this (email hilary_morris@fws.gov).Literature CitedEsri Green Infrastructure Center. Data Description: Detailed Description and Methodology for Intact Habitat Cores. PDF. Last updated June 30, 2023. [https://nation.maps.arcgis.com/home/item.html?id=047d9b05e0c842b1b126bc0767acfd5e]. Esri Green Infrastructure Center, Inc. 2023. Intact Habitat Cores (2023). [https://www.arcgis.com/home/item.html?id=b404b86a079a48049cb50272df23267a].

This pipe feature class represents current wastewater information of the mainline sewer in the City of Los Angeles. The Mapping and Land Records Division of the Bureau of Engineering, Department of Public Works provides the most rigorous geographic information of the storm drain system using a geometric network model, to ensure that its storm drains reflect current ground conditions. The conduits and inlets represent the storm drain infrastructure in the City of Los Angeles. Storm drain information is available on NavigateLA, a website hosted by the Bureau of Engineering, Department of Public Works.Associated information about the wastewater Pipe is entered into attributes. Principal attributes include:PIPE_SUBTYPE: pipe subtype is the principal field that describes various types of lines as either Airline, Force Main, Gravity, Siphon, or Special Lateral.For a complete list of attribute values, please refer to (TBA Wastewater data dictionary). Wastewater pipe lines layer was created in geographical information systems (GIS) software to display the location of sewer pipes. The pipe lines layer is a feature class in the LACityWastewaterData.gdb Geodatabase dataset. The layer consists of spatial data as a line feature class and attribute data for the features. The lines are entered manually based on wastewater sewer maps and BOE standard plans, and information about the lines is entered into attributes. The pipe lines are the main sewers constructed within the public right-of-way in the City of Los Angeles. The ends of line segments, of the pipe lines data, are coincident with the wastewater connectivity nodes, cleanout nodes, non-structures, and physical structures points data. Refer to those layers for more information. The wastewater pipe lines are inherited from a sewer spatial database originally created by the City's Wastewater program. The database was known as SIMMS, Sewer Inventory and Maintenance Management System. For the historical information of the wastewater pipe lines layer, refer to the metadata nested under the sections Data Quality Information, Lineage, Process Step section. Pipe information should only be added to the Wastewater Pipes layer if documentation exists, such as a wastewater map approved by the City Engineer. Sewers plans and specifications proposed under private development are reviewed and approved by Bureau of Engineering. The Department of Public Works, Bureau of Engineering's, Brown Book (current as of 2010) outlines standard specifications for public works construction. For more information on sewer materials and structures, look at the Bureau of Engineering Manual, Part F, Sewer Design, F 400 Sewer Materials and Structures section, and a copy can be viewed at http://eng.lacity.org/techdocs/sewer-ma/f400.pdf.List of Fields:STREET: This is the street name and street suffix on which the pipe is located.PIPE_LABEL: This attribute identifies the arc segment between two nodes, which represents the pipe segment. There could be any number of pipes between the same two maintenance holes and at least one. If there is more than one pipe between the same two maintenance holes, then a value other than 'A' is assigned to each pipe, such as the value 'B', 'C', and so on consecutively. Also, when a new pipe is constructed, some old pipes are not removed from the ground and the new pipe is added around the existing pipe. In this case, if the original pipe was assigned an 'A', the new pipe is assigned a 'B'.C_UP_INV: This is the calculated pipe upstream invert elevation value.PIPE_MAT: The value signifies the various materials that define LA City's sewer system. Values: • TCP - Terra Cotta pipe. • CMP - Corrugated metal pipe. • RCP - Reinforced concrete pipe. Used for sewers larger than 42inch, with exceptions. • PCT - Polymer concrete pipe. • CON - Concrete or cement. • DIP - Ductile iron pipe. • ABS - Acrylonitrile butadiene styrene. • STL - Steel. • UNK - Unknown. • ACP - Asbestos cement pipe. • RCL - Reinforced concrete pipe lined. • OTH - Other or unknown. • VCP - Vitrified clay pipe. • TRS - Truss pipe. • CIP - Cast iron pipe. • PVC - Polyvinyl chloride. • BRK - Brick. • RCPL - Lined Reinforced concrete pipe. Used for sewers larger than 42inch, with exceptions. • B/C - Concrete brick pipe. • FRP - Centrifugally cast fiberglass reinforced plastic mortar pipe.DN_INV: This is the downstream invert elevation value.PIPE_WIDTH: This value is the pipe dimension for shapes other than round.C_SLOPE: This is the calculated slope.ENABLED: Internal feature number.DN_STRUCT: This attribute identifies a number at one of two end points of the line segment that represents a sewer pipe. A sewer pipe line has a value for the UP_STRUCT and DN_STRUCT fields. This point is the downstream structure that may be a maintenance hole, pump station, junction, etc. Each of these structures is assigned an identifying number that corresponds to a Sewer Wye data record. The 8 digit value is based on an S-Map index map using a standardized numbering scheme. The S-Map is divided into 16 grids, each numbered sequentially from west to east and north to south. The first three digits represent the S-Map number, the following two digits represent the grid number, and the last three digits represent the structure number within the grid. This field also relates to the (name of table or layer) node attribute table.PIPE_SIZE: This value is the inside pipe diameter in inches.MON_INST: This is the month of the pipe installation.PIPE_ID: The value is a combination of the values in the UP_STRUCT, DN_STRUCT, and PIPE_LABEL fields. This is the 17 digit identifier of each pipe segment and is a key attribute of the pipe line data layer. This field named PIPE_ID relates to the field in the Annotation Pipe feature class and to the field in the Wye line feature class data layers.REMARKS: This attribute contains additional comments regarding the pipe line segment.DN_STA_PLS: This is the tens value of the downstream stationing.EASEMENT: This value denotes whether or not the pipe is within an easement.DN_STA_100: This is the hundreds value of the downstream stationing.PIPE_SHAPE: The value signifies the shape of the pipe cross section. Values: • SE - Semi-Elliptical. • O1 - Semi-Elliptical. • UNK - Unknown. • BM - Burns and McDonald. • S2 - Semi-Elliptical. • EL - Elliptical. • O2 - Semi-Elliptical. • CIR - Circular. • Box - Box (Rectangular).PIPE_STATUS: This attribute contains the pipe status. Values: • U - Unknown. • P - Proposed. • T - Abandoned. • F - As Built. • S - Siphon. • L - Lateral. • A - As Bid. • N - Non-City. • R - Airline.ENG_DIST: LA City Engineering District. The boundaries are displayed in the Engineering Districts index map. Values: • O - Out LA. • V - Valley Engineering District. • W - West LA Engineering District. • H - Harbor Engineering District. • C - Central Engineering District.C_PIPE_LEN: This is the calculated pipe length.OWNER: This value is the agency or municipality that constructed the pipe. Values: • PVT - Private. • CTY - City of LA. • FED - Federal Facilities. • COSA - LA County Sanitation. • OUTLA - Adjoining cities.CRTN_DT: Creation date of the line feature.TRTMNT_LOC: This value is the treatment plant used to treat the pipe wastewater.PCT_ENTRY2: This is the flag determining if the second slope value, in SLOPE2 field, was entered in percent as opposed to a decimal. Values: • Y - The value is expressed as a percent. • N - The value is not expressed as a percent.UP_STA_100: This is the hundreds value of the upstream stationing.DN_MH: The value is the ID of the structure. This point is the structure that may be a maintenance hole, pump station, junction, etc. The field name DN_MH signifies the structure is the point at the downstream end of the pipe line segment. The field DN_MH is a key attribute to relate the pipe lines feature class to the STRUCTURE_ID field in the physical structures feature class.SAN_PIPE_IDUSER_ID: The name of the user carrying out the edits of the pipe data.WYE_MAT: This is the pipe material as shown on the wye card.WYE_DIAM: This is the pipe diameter as shown on the wye card.SLOPE2: This is the second slope value used for pipe segments with a vertical curve.EST_YR_LEV: This value is the year installed level.EST_MATL: This is the flag determining if the pipe material was estimated.LINER_DATE: This value is the year that the pipe was re-lined.LAST_UPDATE: Date of last update of the line feature.SHAPE: Feature geometry.EST_YEAR: This is the flag indicating if the year if installation was estimated.EST_UPINV: This is the flag determining if the pipe upstream elevation value was estimated.WYE_UPDATE: This value indicates whether the wye card was updated.PCT_ENTRY: This is the flag determining if the slope was entered in percent as opposed to a decimal. Values: • N - The value is not expressed as a percent. • Y - The value is expressed as a percent.PROF: This is the profile drawing number.PLAN1: This is the improvement plan drawing number.PLAN2: This is the supplementary improvement plan drawing number.EST_DNINV: This is the flag determining if the pipe downstream elevation value was estimated.UP_STRUCT: This attribute identifies a number at one of two end points of the line segment that represents a sewer pipe. A sewer pipe line has a value for the UP_STRUCT and DN_STRUCT fields. This point is the upstream structure that may be a maintenance hole, pump station, junction, etc. Each of these structures is assigned an identifying number that corresponds to a Sewer Wye data record. The 8 digit value is based on an S-Map index map

FEMA Historical Geospatial Damage Assessment DatabaseMethodologyFor visual damage assessments using post-event imagery:Destroyed structures are classified based on a visual post-event imagery review that the structure was collapsed. Affected structures were classified based on a visual post-event imagery review indicating there were missing roof segments, failure of structural elements, and visible damage. Visual imagery assessments are primarily completed using nadir “looking straight down” imagery so damages to the sides of buildings were not included in the visual assessments. Often, imagery was not acquired during peak flood crests on rivers or surge inundation along the coast and as a result, the visual assessments may focus on resulting wind damages, not flood impacts. There may be damages visible on-the-ground that were not assessed using the imagery.For modeled damage assessments using depth grids:Damage categories (Affected, Minor, Major, Destroyed) are derived from flood depths at the structure as characterized by the best-available flood depth grid at the time of the damage assessment.Data DictionaryDamage Level:The damage category assigned to the structure based on modeled or visual assessment.No DamageAffectedMinorMajorDestroyedDamage Type:The type of event that created the damage. Multi-event: more than one type of event created damage.Assessment Type:The method for assigning a damage category:Field Assessed: damage category validated in the fieldModeled: damage category predicted based on modeled wind, flood or surge dataOther type: damage category predicted based on other type of geospatial analysisRemote Sensing: damage category assigned using image processing and image validationUnknown: damage category predicted based on unknown type of analysisInundation Depth:Depth of flooding in feet. Predicted/modeled or measured/observed.Wind Exposure Level:Severity of wind impact the structure experienced based on the Saffir-Simpson Hurricane Wind Scale or the Enhanced Fujita Rating for Tornados.Peak Ground Acceleration:PGA experienced by the structure during an earthquake based on USGS ShakeMap GIS data.Accessible:Indicates whether the structure is accessible or inaccessible due to debris, flooding, damage or other reason.Production Date:Date when the damage category was assigned.Imagery Date:Acquisition date of the image that was used to assign structural damage categories.Event Name:Name of the natural disaster that caused the damage.Event Date:The date of the event or natural disaster.Data Producer:Organization that created the damage assessment data.Disaster Number:Unique ID value assigned for natural disaster events.USNG:The USNG grid ID that the structural damage lies within.Access & Use InformationPublic: This dataset is intended for public access and use.