| ArcGIS REST Services Directory |
| Home > services > EM_Hackathon_WCC_Layers (FeatureServer) > All Layers and Tables | | API Reference |
The regional modelling used an attenuation relationship to model the onshore and upstream runup of tsunami flow to derive the horizontal distances and vertical elevations. The relationship was based on and calibrated with observations of tsunami runup elevations from known events. The relationship is 0.5% height attenuation by distance (i.e. water gets 1.0 m shallower every 200 m inland). The relationship is different for flow over water and up rivers where height attenuation was set at 0.25% (i.e. water gets 1.0 m shallower every 400 m upstream). Only rivers with a width at the mouth over 10 m were modelled in this way. Two zones were modelled with this attenuation relationship; the orange zone and the yellow zone. The red zone was derived by orthophoto analysis, complemented with LiDAR data. The input data for the GIS modelling consisted of a digital elevation model in ArcINFO grid format derived from LiDAR data coverage for the western half of the region (Hutt, Wellington, Porirua, Kapiti) and an interpolated DEM from the 1:50000 LINZ topographic NZMS-260 series for the Wairarapa Coast. Individual grids were generated for significant river and lakes to model the attenuation rule over water and a sea polygon coverage was created from the coastline as an inundation source. The modelling was calibrated with probabilistic tsunami wave heights derived from previously recorded events that have affected the Wellington region and modelling tsunami from known source areas.
The second project was a more detailed hydrodynamic inundation modelling undertaken using the COMCOT tsunami model developed by GNS tsunami scientists. The area covered includes Wellington Harbour including Lower Hutt, Eastbourne and east Harbour Bays, Wellington City and south coast bays, Lyall, Houghton,Island and Owhiro Bay.
More detailed modelling was possible due to high-resolution topographic and bathymetric data becoming available of the area from projects co-funded by Greater Wellington Regional Council, advances in the understanding of tsunami flows within enclosed harbours and research undertaken by GNS Science on the rupture characteristics of the Hikurangi subduction zone – the offshore plate boundary of the Australian and Pacific tectonic plates.
The red zone, also known as the shore exclusion zone, can encompass wave heights up to 1.2 m in height with a 1% annual exceedance probability (i.e. 100 yr return period) from all sources (local, regional and distant). The red zone is to be used when a tsunami forecast suggests a marine threat or a threat only to beaches and coastal infrastructure and facilities.
The orange zone was defined using probabilistic wave heights with a 0.2% AEP (i.e. 500 yr return period) from regional (1-3 hr travel time away) and distant sources (>3 hr travel time away). For Wellington Harbour this encompasses tsunami waves heights up to 5.0 m. The orange zone is to be used when a forecast tsunami from a distant source is expected to cause some inundation, but not large enough to require evacuating the yellow zone.
The yellow zone was defined using probabilistic wave heights with a 0.04% AEP (i.e. 2500 yr return period) from all possible sources and corresponds to the maximum credible event for the region and up to a 6000 yr return period for Wellington Harbour based on a Mw 9.0 earthquake on the Hikurangi Subduction Zone. The yellow zone is primarily for self-evacuation in the event of a strongly-felt or long-duration earthquake, or when a forecast of a distant-source tsunami of above a specific threat level is issued.
Further information can be found in the reports:
Leonard, G.S., Power, W., Lukovic, B., Smith, W., Johnston, D. and Downes, G. (2008), Tsunami Evacuation Zones for Wellington and Horizons Regions Defined by a GIS-Calculated Attenuation Rule. GNS Science Report 2008/30, 22 p.
Mueller, C., Power, W.L. and Wang, X. (2015), Hydrodynamic Inundation Modelling and Delineation of Tsunami Evacuation Zones for Wellington Harbour. GNS Science Consultancy Report 2015/176, 30 p.
Abbreviations/Acronyms: N/A
Refresh Rate (Data only): Static
Data Security: Public
Ownership: GWRC
Stewardship: Corporate GIS
Custodianship: Corporate GIS
Authoritative Data Sources (Data only): N/A
Summary of Data Collection (Data only): N/A
Access transport sensor count data here:
Metadata info - https://gis-snowflake-opendata-public-wcc-arcgis-prod.s3.ap-southeast-2.amazonaws.com/transport_sen…
2023 - https://gis-snowflake-opendata-public-wcc-arcgis-prod.s3.ap-southeast-2.amazonaws.com/transport_sen…
2024 - https://gis-snowflake-opendata-public-wcc-arcgis-prod.s3.ap-southeast-2.amazonaws.com/transport_sen…
2025 - https://gis-snowflake-opendata-public-wcc-arcgis-prod.s3.ap-southeast-2.amazonaws.com/transport_sen…
File Listing - https://gis-snowflake-opendata-public-wcc-arcgis-prod.s3.ap-southeast-2.amazonaws.com/
Intended Purpose:
This data source is created to provide access to data from transport sensors installed in Wellington city, which measure transport counts and help analyse how people move around the city.
Abbreviations/Acronyms:
WCC: Wellington City Council
API: Application Programming Interface
Refresh Rate: The dataset will be refreshed no less than once per calendar month.
Data Security : Public
Ownership: Digital Innovation team, WCC. Please contact: digitalinnovation@wcc.govt.nz for questions or feedback about this data.
Custodianship: Corporate GIS team, WCC.
Stewardship: City Insights team, WCC.
Authoritative Data Source (Data only): The primary source of data is from VivaCity Labs, which provides a dashboard and application programming interface (API) for collected data.
Outling Limitations of Data:
This dataset provides valuable insights into transport activity over time, but there are a few limitations to keep in mind:
While sensors are designed to be highly accurate, they may still produce occasional discrepancies due to technical faults, environmental conditions, or other external factors. The data is best used to understand patterns and trends rather than precise counts.
Work is underway to improve how data accuracy is monitored, resolved, and presented on the Open Data Portal.
Temporary gaps may appear due to sensor outages or scheduled maintenance.
If data for one direction of a countline appears blank, it means that the countline is configured to count in only one direction.
In locations where multiple sensors or countlines are close together, a single commuter may be counted more than once as they pass through each countline. Users should refer to the spatial layout provided in this layer to interpret the data accurately.
Sensors vary in installation dates, resulting in different data collection start points.
Historic data collected from old or inactive sensors may be excluded from the historic datasets.
Data Dictionary:
1. Dimension/Look-Up Table
Countline Meta Info - This model processes and enriches countline metadata by calculating the bearing and direction of lines based on their start and end coordinates. It provides relevant compass directions for each line, which can be used for navigation or spatial analysis.
Fields:
countline_id - A unique identifier for each countline.
name - The name of the countline, indicating generic location of countline.
latitude_start_line - The latitude coordinate where the countline starts.
longitude_start_line - The longitude coordinate where the countline starts.
latitude_end_line - The latitude coordinate where the countline ends.
longitude_end_line - The longitude coordinate where the countline ends.
direction_in - The compass direction of the countline when moving toward the sensor’s view.
direction_out - The compass direction of the countline when moving away from the sensor’s view.
earliest - The earliest date when the countline was recorded.
latest - The latest date when the countline was recorded. An older date may indicate that the countline is inactive or no longer in use.
2. Count Dataset - This dataset aggregates mobility data from different countline sources, providing a comprehensive view of traffic flow and directionality.
Fields:
countline_id - A unique identifier for each countline.
countline_transport_class* - Classification of the transport modes, indicating the type of traffic being measured.
countline_date - The date when the countline data was recorded.
countline_hour - The hour of the day when the countline data was recorded.
direction_count - The total count of traffic in a specific direction during the hour.
direction - Normalised direction label, indicating the flow of traffic, as follows:
N: North
NE: North East
E: East
SE: South East
S: South
SW: South West
W: West
NW: North West
Countline transport classes
Wellington Transport Class | Description |
Pedestrian | People on foot |
Cyclist | People on any type of bikes |
Escooter | Electric scooters |
Motorbike | Motorbike |
Car | Small passenger vehicles including car, taxi, and emergency car. |
LGV | LGV (Light Goods Vehicle) includes van and emergency van. |
Bus | All types of buses and minibuses |
OGV1 | OGV 1 (Ordinary Goods Vehicle 1). Larger vehicles with two or three axles. Includes Rigid and Fire Engine in Wellington context. |
OGV2 | OGV 2 (Ordinary Goods Vehicle 2). Includes truck in Wellington context. |
Countline Directionality and Data Inclusions
Countline data can be recorded in two directions (in and out) to capture movement across a countline location. In certain cases, only one direction is relevant. For example, if a countline is located on a one-way street, only the direction that aligns with traffic flow may be included in the dataset.
This directionality inclusion is reflected in the Countline Meta Info columns:
direction_in and direction_out indicate the compass direction of movement.
If a direction is excluded, the corresponding column will show no compass direction, signalling that data for that direction is not part of the countline record.
This approach ensures that the dataset accurately represents valid transport movements and avoids misleading counts for irrelevant directions.
Intended Purpose: The WCC ttr footpaths layer is intended to provides a spatial representation of the footpath network within the Wellington City Council area.
Abbreviations/Acronyms:
WCC = Wellington City Council
Refresh Rate (Data only): As needed.
Data Security: Public
Ownership: Transport and Infrastructure team, WCC
Stewardship: Transport Data Analysts team, WCC
Custodianship: Spatial Systems Team, WCC
Authoritative Data Sources (Data only): RAMM
Summary of Data Collection (Data only):
Intended Purpose: This tree cover feature class was produced for Wellington City and Suburbs; the study area can be seen in the accompanying tree canopy cover report (http://dx.doi.org/10.26021/11224). The tree cover feature class was produced using an object-based image analysis (OBIA) approach. OBIA is a semi-automated image classification method that can be used to identify trees based on aerial photography and LiDAR data. Following the OBIA, tree canopy cover was manually refined to correct errors in the tree cover classification. Boundary adjustment for tree crowns was also undertaken at a scale of no greater than 1:2,500.
Abbreviations/Acronyms:
WCC = Wellington City Council
OBIA = object-based image analysis
Refresh Rate (Data only): Static - March 2022
Data Security: Public
Ownership: Urban Design Team, WCC
Stewardship: Corporate GIS, WCC
Custodianship: Corporate GIS, WCC
Authoritative Data Sources (Data only): LiDAR data captured for Wellington City Council by Aerial Surveys from 20 March 2019 to 14 March 2020
Summary of Data Collection (Data only):
For the purpose of the OBIA, a tree was defined as an object having vegetation-like reflectance characteristics, exceeding 3.5 m in height and having a minimum diameter of 1. 5 m. Treefeatures comprise all tree and forest types. This includes, but is not limited to, park and reserve trees, street trees, trees on private property, orchards, remnant patches of native forest, hedgerows, and trees in commercially-managed, large-scale forestry plantations.
The data on which the OBIA was performed included aerial photography and LiDAR data. Aerial photography was captured by AAM NZ Ltd. for the Wellington City Council during the summer of 2016-17. Images were acquired on 24, 27, 28 February and 5 March 2017. Imagery was supplied as 10 cm pixel resolution, 3-band (RGB) uncompressed GeoTIFF. The final spatial accuracy is ± 0.2 m at 90% confidence level. LiDAR data were captured for Wellington City Council by Aerial Surveys from 20 March 2019 to 14 March 2020. As a consequence of the range in time of acquisition for LiDAR data, the tree canopy cover assessment that was completed for this report should be considered accurate as at 20 March 2019. Both aerial imagery and LiDAR data were sourced from the LINZ Data Service and licensed by Wellington City Council, for re-use under CC BY 4.0.