ps-places-metadata-v1.01

SUMMARY

This dataset comprises a pair of layers, (points and polys) which attempt to better locate "populated places" in NZ. Populated places are defined here as settled areas, either urban or rural where densitys of around 20 persons per hectare exist, and something is able to be seen from the air.

RATIONALE

The only liberally licensed placename dataset is currently LINZ geographic placenames, which has the following drawbacks: - coordinates are not place centers but left most label on 260 series map - the attributes are outdated

METHODOLOGY

This dataset necessarily involves cleaving the linz placenames set into two, those places that are poplulated, and those unpopulated. Work was carried out in four steps. First placenames were shortlisted according to the following criterion: - all places that rated at least POPL in the linz geographic places layer, ie POPL, METR or TOWN or USAT were adopted. - Then many additional points were added from a statnz meshblock density analysis.
- Finally remaining points were added from a check against linz residential polys, and zenbu poi clusters.

Spelling is broadly as per linz placenames, but there are differences for no particular reason. Instances of LINZ all upper case have been converted to sentance case. Some places not presently in the linz dataset are included in this set, usually new places, or those otherwise unnamed. They appear with no linz id, and are not authoritative, in some cases just wild guesses.

Density was derived from the 06 meshblock boundarys (level 2, geometry fixed), multipart conversion, merging in 06 usually resident MB population then using the formula pop/area*10000. An initial urban/rural threshold level of 0.6 persons per hectare was used.

Step two was to trace the approx extent of each populated place. The main purpose of this step was to determine the relative area of each place, and to create an intersection with meshblocks for population. Step 3 involved determining the political center of each place, broadly defined as the commercial center.

Tracing was carried out at 1:9000 for small places, and 1:18000 for large places using either bing or google satellite views. No attempt was made to relate to actual town 'boundarys'. For example large parks or raceways on the urban fringe were not generally included. Outlying industrial areas were included somewhat erratically depending on their connection to urban areas.

Step 3 involved determining the centers of each place. Points were overlaid over the following layers by way of a base reference:

a. original linz placenames b. OSM nz-locations points layer c. zenbu pois, latest set as of 5/4/11 d. zenbu AllSuburbsRegions dataset (a heavily hand modified) LINZ BDE extract derived dataset courtesy Zenbu. e. LINZ road-centerlines, sealed and highway f. LINZ residential areas, g. LINZ building-locations and building footprints h. Olivier and Co nz-urban-north and south

Therefore in practice, sources c and e, form the effective basis of the point coordinates in this dataset. Be aware that e, f and g are referenced to the LINZ topo data, while c and d are likely referenced to whatever roading dataset google possesses. As such minor discrepencys may occur when moving from one to the other.

Regardless of the above, this place centers dataset was created using the following criteria, in order of priority:

• attempts to represent the present (2011) subjective 'center' of each place as defined by its commercial/retail center ie. mainstreets where they exist, any kind of central retail cluster, even a single shop in very small places.
• the coordinate is almost always at the junction of two or more roads.
• most of the time the coordinate is at or near the centroid of the poi cluster
• failing any significant retail presence, the coordinate tends to be placed near the main road junction to the community.
• when the above criteria fail to yield a definitive answer, the final criteria involves the centroids of: . the urban polygons . the clusters of building footprints/locations.

To be clear the coordinates are manually produced by eye without any kind of computation. As such the points are placed approximately perhaps plus or minus 10m, but given that the roads layers are not that flash, no attempt was made to actually snap the coordinates to the road junctions themselves.

The final step involved merging in population from SNZ meshblocks (merge+sum by location) of popl polys). Be aware that due to the inconsistent way that meshblocks are defined this will result in inaccurate populations, particular small places will collect population from their surrounding area. In any case the population will generally always overestimate by including meshblocks that just nicked the place poly. Also there are a couple of dozen cases of overlapping meshblocks between two place polys and these will double count. Which i have so far made no attempt to fix.

Merged in also tla and regions from SNZ shapes, a few of the original linz atrributes, and lastly grading the size of urban areas according to SNZ 'urban areas" criteria. Ie: class codes:

1. Not used.
2. main urban area 30K+
3. secondary urban area 10k-30K
4. minor urban area 1k-10k
5. rural center 300-1K
6. village -300

Note that while this terminology is shared with SNZ the actual places differ owing to different decisions being made about where one area ends an another starts, and what constiutes a suburb or satellite. I expect some discussion around this issue. For example i have included tinwald and washdyke as part of ashburton and timaru, but not richmond or waikawa as part of nelson and picton. Im open to discussion on these.

No attempt has or will likely ever be made to locate the entire LOC and SBRB data subsets. We will just have to wait for NZFS to release what is thought to be an authoritative set.

PROJECTION

Shapefiles are all nztm. Orig data from SNZ and LINZ was all sourced in nztm, via koordinates, or SNZ. Satellite tracings were in spherical mercator/wgs84 and converted to nztm by Qgis. Zenbu POIS were also similarly converted.

ATTRIBUTES

Shapefile: Points id : integer unique to dataset name : name of popl place, string class : urban area size as above. integer tcode : SNZ tla code, integer rcode : SNZ region code, 1-16, integer area : area of poly place features, integer in square meters. pop : 2006 usually resident popluation, being the sum of meshblocks that intersect the place poly features. Integer lid : linz geog places id desc_code : linz geog places place type code

Shapefile: Polygons gid : integer unique to dataset, shared by points and polys name : name of popl place, string, where spelling conflicts occur points wins area : place poly area, m2 Integer

LICENSE

Clarification about the minorly derived nature of LINZ and google data needs to be sought. But pending these copyright complications, the actual points data is essentially an original work, released as public domain. I retain no copyright, nor any responsibility for data accuracy, either as is, or regardless of any changes that are subsequently made to it.

Peter Scott 16/6/2011

v1.01 minor spelling and grammar edits 17/6/11

This dataset consists of shapefiles that correspond to the model grids used in the CSIRO eReefs hydrodynamic and biogeochemical models. These models store their results in multi-dimensional NetCDF files using a curvilinear grid. This dataset corresponds to an extract from these files converting the curvilinear grid into polygons in a shapefile. This dataset only captures the structure of the grid, not the time series data generated by the model. It contains shapefiles of the 4 km model grid (GBR4) and the 1 km grid (GBR1) as well as shapefiles for the bounding polygon of all the 'wet' cells in the model. This dataset is useful for visualising the extent of the various CSIRO eReefs models.

This dataset contains shapefiles for the 1 km and 4 km eReefs grids, derived from version 2.0 of the eReefs Hydrodynamic model. It contains shapefiles of the individual grid cells and the bounds. It also includes a low resolution version of the bounds suitable for detecting whether locations are inside the eReefs model extent.

The grid shapefile contains polygons representing each of the grid cells. An attribution is associated with each polygon corresponding to the depth used in the model. This can be used to show where the model has 'wet' cells.

Methods:

1. Representative data files for the GBR1 and GBR4 hydrodynamic version model were downloaded from the public repository of eReefs model data on NCI. The two common grids GBR1 and GBR4 are used over the model time series and for the both the hydrodynamic and biogeochemical models. We therefore just chose one model NetCDF for each model resolution. These were taken from the hydrodynamic model version 2.

2. The grid was converted to shapefiles using an R script that calculated the coordinates corners of each curvilinear pixel in the grid based on the centroids of the neighbouring pixels.

3. The grid boundary shapefiles were calculated using the merge GIS operation in QGIS after selecting all the 'wet' cells, where the depth was greater than 0.

Full step-by-step instructions and scripts are available to reproduce this dataset from github (https://github.com/eatlas/GBR_AIMS_eReefs-grid-shapefiles).

Format:

Shapefile

Data Dictionary:

SP_ID: Row and column indices in the NetCDF grid joined together depth: Depth used in the eReefs model in metres. This is based on the botz variable in the original NetCDF eReefs model data file. row: Row index in the NetCDF tables for this pixel. col: Column index in the NetCDF tables for this pixel.

Change Log: 2025-10-16 - Added DOI, ROR and ORCIDs to the record.

Data Location:

This dataset is filed in the eAtlas enduring data repository at: X:\data\custodian\2018-22-eReefs\GBR_AIMS_eReefs-grid-shapefiles Source code for reproducing this dataset is available on github (https://github.com/eatlas/GBR_AIMS_eReefs-grid-shapefiles).

The Science Case in the Caribbean region presents records on landslides, precipitation, maps used as inputs of hazard models and drone imagery over the region of interest.
For the Carribean study-case, an analysis of open and proprietary satellite based dataset was used to facilitate the setup and evaluation of physically-based multi-hazard models. These allow for qualification and quantification of spatio-temporal multi-hazard patterns. These form a crucial input into the general hazard and risk assessment workflow.

Presented here are the datasets employed for Case Study 4 in Deliverable D3.1 with a short description, produced and saved within the following folders:

Dominica_landslide: the landslides datasets mapped by ITC using high-resolution satellite imagery. It is intended to calibrate and validate the flood and landslide modelling. The folder contains four shapefiles:

· Landslide_Part.shp - Shapefile containing landslide extent, flash flood extents, and their attributes.

· Cloud.shp – Shapefile represents the cloud-filled areas in the satellite imagery where no mapping was possible.

· The other two shapefiles are self-explanatory.

GPM_Maria: NASA Global Precipitation Mission (GPM) precipitation maps processed for model input in LISEM. GPM is a hybrid fusion with satellite datasets for precipitation estimates. Mean as input data to represent precipitation in the landslide and flood modelling.

Maps_Models_Input : Soil and land use and channels, lots of custom work, SOILGRIDS, and SPOT image classification; all the datasets are ready for model input for OpenLISEM and LISEM Hazard or FastFlood. The dataset is meant to calibrate and validate the flood and landslide modelling.

The raster files are either in Geotiff format or PCraster map format. Both can be opened by GIS systems such as GDAL or QGIS. The projection of each file is in UTM20N.

Some key files are:

• dem.map -elevation model, the height of the landscape in meters above sea level.
• lai.map - leaf area index, estimated using empirical relationships based on NDVI (Normalized Difference Vegetation Index)). The source data to calculate NDVI is Sentinel-2.
• KSat.map - Saturated hydraulic conductivity of the soil, estimated based on a combination of SOILGRIDS soil texture, Saxton et al. (2006) Pedotransfer functions, and a national soil map for Dominica.
• clay.map - Clay texture fraction, SoilGrids resampling
• silt.map - Silt texture fraction, SoilGrids resampling
• sand.map - Sand texture fraction, SoilGrids resampling
• cover.map - Vegetation cover as a fraction, estimated using linear correlation with NDVI.
• lu_new.map - Spot satellite image classification at 10 meters resolution for predominant land use types.
• n.map - Mannings surface roughness coefficient, specific value based on the land use type.
• ndvi.map - Normalized Differential Vegetation Index, based on Sentinel-2 images in summer.
• ldd.map - Drainage network map for the island, which can be used for flow accumulation and streamflow detection
• catchments.map - Catchment ID's based on the ldd.map drainage network.
• Channelldd.map - Channel-only drainage network map, calibrated manually to have all channels on the island represented correctly.
• Soildepth - Soil depth in meters, based on a physically-based soil depth model in meters and observational data obtained from landslide-sites during fieldwork in 2018.
• Slope.map - Slope map in gradient of the elevation model (m/m) in the steepest direction

StakeholderQuestionnaire_Survey_ITC: The stakeholder questionnaires particularly relating to the tools developed partly by this project on rapid hazard modelling. Stakeholder Engagement survey and Stakeholder Survey Results prepared and implemented by Sruthie Rajendran as part of her MSc Thesis Twin Framework For Decision Support In Flood Risk Management supervised by Dr. M.N. Koeva (Mila) and Dr. B. van den Bout (Bastian) submitted in July 2024.

·Drone_Images_ 2024: Images captured using a DJI drone of part of the Study area in February 2024. The file comprises three different regions: Coulibistrie, Pichelin and Point Michel. The 3D models for Coulibistrie were generated from the nadir drone images using photogrammetric techniques employed by the software Pix4D. The image Coordinate System is WGS 84 (EGM 96 Geoid0), but the Output Coordinate System of the 3D model is WGS 84 / UTM zone 20N (EGM 96 Geoid). The other two folders contain only the drone images captured for that particular region's Pichelin and Point Michel. The dataset is used with other datasets to prepare and create the digital twin framework tailored for flood risk management in the study area.

The High Resolution Digital Elevation Model (HRDEM) product is derived from airborne LiDAR data (mainly in the south) and satellite images in the north. The complete coverage of the Canadian territory is gradually being established. It includes a Digital Terrain Model (DTM), a Digital Surface Model (DSM) and other derived data. For DTM datasets, derived data available are slope, aspect, shaded relief, color relief and color shaded relief maps and for DSM datasets, derived data available are shaded relief, color relief and color shaded relief maps. The productive forest line is used to separate the northern and the southern parts of the country. This line is approximate and may change based on requirements. In the southern part of the country (south of the productive forest line), DTM and DSM datasets are generated from airborne LiDAR data. They are offered at a 1 m or 2 m resolution and projected to the UTM NAD83 (CSRS) coordinate system and the corresponding zones. The datasets at a 1 m resolution cover an area of 10 km x 10 km while datasets at a 2 m resolution cover an area of 20 km by 20 km. In the northern part of the country (north of the productive forest line), due to the low density of vegetation and infrastructure, only DSM datasets are generally generated. Most of these datasets have optical digital images as their source data. They are generated at a 2 m resolution using the Polar Stereographic North coordinate system referenced to WGS84 horizontal datum or UTM NAD83 (CSRS) coordinate system. Each dataset covers an area of 50 km by 50 km. For some locations in the north, DSM and DTM datasets can also be generated from airborne LiDAR data. In this case, these products will be generated with the same specifications as those generated from airborne LiDAR in the southern part of the country. The HRDEM product is referenced to the Canadian Geodetic Vertical Datum of 2013 (CGVD2013), which is now the reference standard for heights across Canada. Source data for HRDEM datasets is acquired through multiple projects with different partners. Since data is being acquired by project, there is no integration or edgematching done between projects. The tiles are aligned within each project. The product High Resolution Digital Elevation Model (HRDEM) is part of the CanElevation Series created in support to the National Elevation Data Strategy implemented by NRCan. Collaboration is a key factor to the success of the National Elevation Data Strategy. Refer to the “Supporting Document” section to access the list of the different partners including links to their respective data.

This dataset is a shapefile of 767 polygons describing the contours of Juniperus communis L. and Juniperus sabina L. shrubs for the year 2021 in rectangular plots across Sierra Nevada. The coordinates of the polygons were obtained from a field work campaign with a differential centimetric GPS, and their contours were drawn manually in QGIS using the Google Earth satellite image for 2020 and the PNOA aerial image for the 2020. This dataset also contains an excel file describing the features of each polygon: the polygon centroid coordinates, the type of species, the sexgender, the morphotype, the damage in the vegetation cover estimated in the field and telematically, certainty of the digitalization with QGIS and also if the differential centimetric GPS used belongs to the University of Granada or the University of Almeria.