This point layer contains start and end nodes for all of the street segments in Cambridge. It also contains street names for all intersections.Explore all our data on the Cambridge GIS Data Dictionary.Attributes NameType DetailsDescription NodeNumber type: Doublewidth: 8precision: 38 Node ID - relates to "FromNode" and "ToNode" of each street segment

Intersection type: Stringwidth: 75precision: 0 Intersecting street names separated by "&"

IntersectingStreetCount type: Integerwidth: 4precision: 10 Number of intersecting streets at the node

TurnRestriction type: Stringwidth: 10precision: 0 Vehicle turning restrictions at intersection

P_X type: Doublewidth: 8precision: 38 X coordinate of point

P_Y type: Doublewidth: 8precision: 38 Y coordinate of point

Street1 type: Stringwidth: 30precision: 0 Unpopulated

EditDate type: Stringwidth: 4precision: 0

Street2 type: Stringwidth: 30precision: 0 Unpopulated

created_date type: Datewidth: 8precision: 0

last_edited_date type: Datewidth: 8precision: 0

The top 200 locations where reported collisions occurred at intersections have been identified. The crash cluster analysis methodology for the top intersection clusters uses a fixed meter search distance of 25 meters (82 ft.) to merge crash clusters together. This analysis was based on crashes where a police officer specified one of the following junction types: Four way intersection, T-intersection, Y-intersection, five point or more. Furthermore, the methodology uses the Equivalent Property Damage Only (EPDO) weighting to rank the clusters. EPDO is based any type of injury crash (including fatal, incapacitating, non-incapacitating and possible) having a weighting of 21 compared to a property damage only crash (which has weighting of 1). The clusters were reviewed in descending EPDO order until 200 locations were obtained. The clustering analysis used crashes from the three year period from 2016-2018. The area encompassing the crash cluster may cover a larger area than just the intersection so it is critical to view these spatially.

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.

Monthly extracts of historic Traffic Data at Signalised derived by SCATS.

SCATS (Sydney Coordinated Adaptive Traffic System) is an intelligent transportation system that manages the dynamic timing of signal phases at traffic signals in real time. The system estimates the number of vehicles passing through the intersection and other information related to traffic signal timing. There is no guarantee this data is accurate or was used to make internal decisions in SCATS.

The data is provided by controller site. Each site has its own parquet file for the month, which contains SCATS data produced by that site. The files use the LM site number format (e.g. – Site 1 is LM00001).

Note that you are accessing the data provided by the links below pursuant to a Creative Commons (Attribution) Licence which has a disclaimer of warranties and limitation of liability. You accept that the data provided pursuant to the Licence is subject to changes and may have errors.

Pursuant to section 3 of the Licence you are provided with the following notice to be included when you Share the Licenced Material:- “The Commissioner of Main Roads is the creator and owner of the data and Licenced Material, which is accessed pursuant to a Creative Commons (Attribution) Licence, which has a disclaimer of warranties and limitation of liability.”

A data dictionary is provided at the document link.

Monthly data extracts are in parquet format.

The locations of the traffic signals are found at the link below.

https://portal-mainroads.opendata.arcgis.com/datasets/traffic-signal-sitesAvailable in JSON format below.gisservices.mainroads.wa.gov.au/arcgis/rest/services/Connect/MapServer/0/query?where=1%3D1&outFields=*&returnGeometry=true&f=pjson

The mapping of the detectors to the strategic approaches at an intersection is given at the link below.

https://mainroadsopendata.mainroads.wa.gov.au/swagger/ui/index#/LmSaDetector

Further information, including SCATS graphics, is available via the Traffic Signal information on Main Roads TrafficMap

trafficmap - Main Roads WA

The dataset contains locations and attributes of intersections created as part of the Master Address Repository (MAR) for the Office of the Chief Technology Officer (OCTO) and participating DC government agencies. The intersection points - MAR is primarily derived from DC Department of Transportation's (DDOT) intersection table in their Street Spatial Database (SSD). Regular at-grade intersections (TYPE = 'REGULAR') as well as overpasses (TYPE = 'OVERPASS'), underpasses (TYPE = 'UNDERPASS') and ramps (TYPE = 'RAMP') are included. The overpasses, underpasses, and ramps are based on street centerlines from DDOT. More information on the MAR can be found at https://opendata.dc.gov/pages/addressing-in-dc. The data dictionary is available: https://opendata.dc.gov/documents/2a4b3d59aade43188b6d18e3811f4fd3/explore. In the MAR 2, the IntersectionPt is called INTERSECTIONS_PT and is primarily based off of street data from DC Department of Transportation's Roads & Highways database. It also features additional useful information such as created date, last edited date, begin date, and more.

Point geometry with attributes displaying street intersections of all public and private named roads in East Baton Rouge Parish, Louisiana.

Intersection Approach Segments are short segments of the route that approach an intersection, in other words, a short section of the road leading up to an intersection.Roads and Highways manages intersections, however they are not singular points; RH creates a series of points - one for each intersecting road at that intersection. For DDOT, it is more useful to have a single intersection point representing the intersection. Through a custom DDOT script,the series of intersection points is reduced into a single representative point.For more information please visit DDOT's wiki page.

WARNING: This is a pre-release dataset and its fields names and data structures are subject to change. It should be considered pre-release until the end of 2024. Expected changes:

• Metadata is missing or incomplete for some layers at this time and will be continuously improved.
  
• We expect to update this layer roughly in line with CDTFA at some point, but will increase the update cadence over time as we are able to automate the final pieces of the process.

Purpose

County and incorporated place (city) boundaries along with third party identifiers used to join in external data. Boundaries are from the authoritative source the California Department of Tax and Fee Administration (CDTFA), altered to show the counties as one polygon. This layer displays the city polygons on top of the County polygons so the area isn"t interrupted. The GEOID attribute information is added from the US Census. GEOID is based on merged State and County FIPS codes for the Counties. Abbreviations for Counties and Cities were added from Caltrans Division of Local Assistance (DLA) data. Place Type was populated with information extracted from the Census. Names and IDs from the US Board on Geographic Names (BGN), the authoritative source of place names as published in the Geographic Name Information System (GNIS), are attached as well. Finally, the coastline is used to separate coastal buffers from the land-based portions of jurisdictions. This feature layer is for public use.

Related Layers

This dataset is part of a grouping of many datasets:

1. Cities: Only the city boundaries and attributes, without any unincorporated areas
   • With Coastal Buffers
   • Without Coastal Buffers
2. Counties: Full county boundaries and attributes, including all cities within as a single polygon
   • With Coastal Buffers
   • Without Coastal Buffers
3. Cities and Full Counties: A merge of the other two layers, so polygons overlap within city boundaries. Some customers require this behavior, so we provide it as a separate service.
   • With Coastal Buffers (this dataset)
   • Without Coastal Buffers
4. Place Abbreviations
5. Unincorporated Areas (Coming Soon)
6. Census Designated Places (Coming Soon)
   
7. Cartographic Coastline
   • Polygon
   • Line source (Coming Soon)

Point of Contact

California Department of Technology, Office of Digital Services, odsdataservices@state.ca.gov

Field and Abbreviation Definitions

• COPRI: county number followed by the 3-digit city primary number used in the Board of Equalization"s 6-digit tax rate area numbering system
• Place Name: CDTFA incorporated (city) or county name
• County: CDTFA county name. For counties, this will be the name of the polygon itself. For cities, it is the name of the county the city polygon is within.
• Legal Place Name: Board on Geographic Names authorized nomenclature for area names published in the Geographic Name Information System
• GNIS_ID: The numeric identifier from the Board on Geographic Names that can be used to join these boundaries to other datasets utilizing this identifier.
• GEOID: numeric geographic identifiers from the US Census Bureau Place Type: Board on Geographic Names authorized nomenclature for boundary type published in the Geographic Name Information System
• Place Abbr: CalTrans Division of Local Assistance abbreviations of incorporated area names
• CNTY Abbr: CalTrans Division of Local Assistance abbreviations of county names
• Area_SqMi: The area of the administrative unit (city or county) in square miles, calculated in EPSG 3310 California Teale Albers.
• COASTAL: Indicates if the polygon is a coastal buffer. Null for land polygons. Additional values include "ocean" and "bay".
• GlobalID: While all of the layers we provide in this dataset include a GlobalID field with unique values, we do not recommend you make any use of it. The GlobalID field exists to support offline sync, but is not persistent, so data keyed to it will be orphaned at our next update. Use one of the other persistent identifiers, such as GNIS_ID or GEOID instead.

Accuracy

CDTFA"s source data notes the following about accuracy:

City boundary changes and county boundary line adjustments filed with the Board of Equalization per Government Code 54900. This GIS layer contains the boundaries of the unincorporated county and incorporated cities within the state of California. The initial dataset was created in March of 2015 and was based on the State Board of Equalization tax rate area boundaries. As of April 1, 2024, the maintenance of this dataset is provided by the California Department of Tax and Fee Administration for the purpose of determining sales and use tax rates. The boundaries are continuously being revised to align with aerial imagery when areas of conflict are discovered between the original boundary provided by the California State Board of Equalization and the boundary made publicly available by local, state, and federal government. Some differences may occur between actual recorded boundaries and the boundaries used for sales and use tax purposes. The boundaries in this map are representations of taxing jurisdictions for the purpose of determining sales and use tax rates and should not be used to determine precise city or county boundary line locations. COUNTY = county name; CITY = city name or unincorporated

Roads and Highways manages intersections, however they are not singular points; RH creates a series of points - one for each intersecting road at that intersection. For DDOT, it is more useful to have a single intersection point representing the intersection. Through a custom DDOT script,the series of intersection points is reduced into a single representative point.For more information please visit DDOT's wiki page

Roads and Highways manages intersections, however they are not singular points; RH creates a series of points - one for each intersecting road at that intersection. For DDOT, it is more useful to have a single intersection point representing the intersection. Through a custom DDOT script,the series of intersection points is reduced into a single representative point.For more information please visit DDOT's wiki page.

This layer shows intersections on the road network stored in the Integrated Road Information System (IRIS). An intersection is a road junction where two or more roads either meet or cross at grade …Show full descriptionThis layer shows intersections on the road network stored in the Integrated Road Information System (IRIS). An intersection is a road junction where two or more roads either meet or cross at grade (they are at the same level).The layer also details the IRIS Intersection Number. This layer is provided for information only.Note that you are accessing this data pursuant to a Creative Commons (Attribution) Licence which has a disclaimer of warranties and limitation of liability. You accept that the data provided pursuant to the Licence is subject to changes.Pursuant to section 3 of the Licence you are provided with the following notice to be included when you Share the Licenced Material:- The Commissioner of Main Roads is the creator and owner of the data and Licenced Material, which is accessed pursuant to a Creative Commons (Attribution) Licence, which has a disclaimer of warranties and limitation of liability.Creative Commons CC BY 4.0 https://creativecommons.org/licenses/by/4.0/

A point feature layer with the locations and names of street intersections within Stark County, Ohio. This layer was initially developed so that police, fire, and EMS would be able to identify the closest street intersection for emergency calls. Within the attribute table, you will find the names for the intersecting streets; the primary and secondary streets are the only attributes that are populated. This data is a work in progress and will be updated periodically as new streets are added to our data. It is planned for each street intersection point to be eventually filled out for the whole county.

Street Intersections within the City of Phoenix

This dataset was created using the intersecting point of a controlled intersection and represents all Metro/State traffic control signal devices controlling a given intersection as maintained by Louisville Metro public works traffic engineering department. View detailed metadata.

The Statistics Canada street network for 2016 was used to derive street intersection counts within buffers of 100, 250, 300, 500, 750 and 1000 meters of each DMTI Spatial single link postal code for the year 2019. Only street intersections with more than one street segment joining were counted - no dead ends were included. A higher value indicates more intersections and a greater degree of connectivity enabling more direct travel between two points using existing streets. CANUE staff used ArcGIS and the Line and Junction Connectivity Toolbox (see supporting documentation) to create intersection counts and PostGres SQL to produce buffer counts.

Geographic Information System (GIS) analyses are an essential part of natural resource management and research. Calculating and summarizing data within intersecting GIS layers is common practice for analysts and researchers. However, the various tools and steps required to complete this process are slow and tedious, requiring many tools iterating over hundreds, or even thousands of datasets. USGS scientists will combine a series of ArcGIS geoprocessing capabilities with custom scripts to create tools that will calculate, summarize, and organize large amounts of data that can span many temporal and spatial scales with minimal user input. The tools work with polygons, lines, points, and rasters to calculate relevant summary data and combine them into a single output table that can be easily incorporated into statistical analyses. These tools are useful for anyone interested in using an automated script to quickly compile summary information within all areas of interest in a GIS dataset

Attention new flow URL carto.ain.fr becomes geodata.ain.fr

Last modification of the graph Nov 2023: decommissioning of the RD979 from Boulevard Charles de Gaulle to the roundabout of the Alagnier (urban part in the town of bourg) avenue Amédée Mercier

Roads are all represented by a single axis even in the case of separate pavements. At junctions / intersections, sections not participating in the main road are cut off at the outer edge of the junction (stop / cede the passage). To ensure the topology of the road graph pseudo roads have been added (categorie_admin=intersection) but do not participate in the linear of the RD.

For roundabouts, the calculation of the PR+abs follows the axis of the roundabout in the direction of the route (meaning of the PR) and thus travels part of the roundabout virtually while physically there is a discontinuity (PV_beginning / PV_end).

The field 'categorie_admin' allows to know its use. rd / intersection / junction_pn / roundabout. The total length of the network coming together as the sum of the cumulf-cumuld of the rd and giratoire.

Field determination rule: axis

the wording of the route is in the form of Dxx (e.g. D23)

For roads with name extensions (letter after the number of the RD), this extension is added afterwards with a minus (indent of 6) in separator (e.g.: D23-C).

For roundabouts an extension 'GIRxxx' is added next with an underscore (tiret of 8) as a separator.

ex D72-A_GIR_02_0262.

PR of the entry of the roundabout on 2 characters with 0 in prefix to complete 4-character abscissa of the roundabout entry with 0 prefixes to complete

Field determination rule: axis_cd01

Axes of the Departmental Routes of Ain (e.g. 01 D0117A).

Rules for naming roundabouts (in the process of being entered):

E.g.: GIR0117A_09_0611 GIR route type prefix RD number on 4 characters with 0 in prefix to complete Letter from RD with _ if no letter Separator _ PR of the entry of the roundabout on 2 characters with 0 in prefix to complete 4-character abscissa of the roundabout entry with 0 prefixes to complete

Intersection management scheme:

https://geodata.ain.fr/apps/external/img/GPR_schema_intersection.png" alt="Intersection Management Scheme">

Average Daily Traffic Counts of Roads and Intersections in San Joaquin County maintained by Transportation Engineering

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 dataset offers a detailed inventory of road intersections and their corresponding suburbs within Cape Town, meticulously curated to highlight instances of high pedestrian crash counts observed in "high-high" cluster and "high-low" outlier fishnet grid cells across the years 2017, 2018, 2019, and 2021. To enhance its utility, the dataset meticulously colour-codes each month associated with elevated crash occurrences, providing a nuanced perspective. Furthermore, the dataset categorises road intersections based on their placement within "high-high" clusters (marked with pink tabs) or "high-low" outlier cells (indicated by red tabs). For ease of navigation, the intersections are further organised alphabetically by suburb name, ensuring accessibility and clarity.Data SpecificsData Type: Geospatial-temporal categorical data with numeric attributesFile Format: Word document (.docx)Size: 255 KBNumber of Files: The dataset contains a total of 264 road intersection records (68 "high-high" clusters and 196 "high-low" outliers)Date Created: 21st May 2024MethodologyData Collection Method: The descriptive road traffic crash data per crash victim involved in the crashes was obtained from the City of Cape Town Network InformationSoftware: ArcGIS Pro, Open Refine, Python, SQLProcessing Steps: The raw road traffic crash data underwent a comprehensive refining process using Python software to ensure its accuracy and consistency. Following this, duplicates were eliminated to retain only one entry per crash incident. Subsequently, the data underwent further refinement with Open Refine software, focusing specifically on isolating unique crash descriptions for subsequent geocoding in ArcGIS Pro. Notably, during this process, only the road intersection crashes were retained, as they were the only incidents with spatial definitions.Once geocoded, road intersection crashes that involved a pedestrian were extracted so that subsequent spatio-temporal analyses would focus on these crashes only. The spatio-temporal analysis methods by which the pedestrian crashes were analysed included spatial autocorrelation, hotspot analysis, and cluster and outlier analysis. Leveraging these methods, road intersections involving pedestrian crashes identified as either "high-high" clusters or "high-low" outliers were extracted for inclusion in the dataset.Geospatial InformationSpatial Coverage:West Bounding Coordinate: 18°20'EEast Bounding Coordinate: 19°05'ENorth Bounding Coordinate: 33°25'SSouth Bounding Coordinate: 34°25'SCoordinate System: South African Reference System (Lo19) using the Universal Transverse Mercator projectionTemporal InformationTemporal Coverage:Start Date: 01/01/2017End Date: 31/12/2021 (2020 data omitted)