The USDA Long-Term Agroecosystem Research was established to develop national strategies for sustainable intensification of agricultural production. As part of the Agricultural Research Service, the LTAR Network incorporates numerous geographies consisting of experimental areas and locations where data are being gathered. Starting in early 2019, two working groups of the LTAR Network (Remote Sensing and GIS, and Data Management) set a major goal to jointly develop a geodatabase of LTAR Standard GIS Data Layers. The purpose of the geodatabase was to enhance the Network's ability to utilize coordinated, harmonized datasets and reduce redundancy and potential errors associated with multiple copies of similar datasets. Project organizers met at least twice with each of the 18 LTAR sites from September 2019 through December 2020, compiling and editing a set of detailed geospatial data layers comprising a geodatabase, describing essential data collection areas within the LTAR Network. The LTAR Standard GIS Data Layers geodatabase consists of geospatial data that represent locations and areas associated with the LTAR Network as of late 2020, including LTAR site locations, addresses, experimental plots, fields and watersheds, eddy flux towers, and phenocams. There are six data layers in the geodatabase available to the public. This geodatabase was created in 2019-2020 by the LTAR network as a national collaborative effort among working groups and LTAR sites. The creation of the geodatabase began with initial requests to LTAR site leads and data managers for geospatial data, followed by meetings with each LTAR site to review the initial draft. Edits were documented, and the final draft was again reviewed and certified by LTAR site leads or their delegates. Revisions to this geodatabase will occur biennially, with the next revision scheduled to be published in 2023. Resources in this dataset:Resource Title: LTAR Standard GIS Data Layers, 2020 version, File Geodatabase. File Name: LTAR_Standard_GIS_Layers_v2020.zipResource Description: This file geodatabase consists of authoritative GIS data layers of the Long-Term Agroecosystem Research Network. Data layers include: LTAR site locations, LTAR site points of contact and street addresses, LTAR experimental boundaries, LTAR site "legacy region" boundaries, LTAR eddy flux tower locations, and LTAR phenocam locations.Resource Software Recommended: ArcGIS,url: esri.com Resource Title: LTAR Standard GIS Data Layers, 2020 version, GeoJSON files. File Name: LTAR_Standard_GIS_Layers_v2020_GeoJSON_ADC.zipResource Description: The contents of the LTAR Standard GIS Data Layers includes geospatial data that represent locations and areas associated with the LTAR Network as of late 2020. This collection of geojson files includes spatial data describing LTAR site locations, addresses, experimental plots, fields and watersheds, eddy flux towers, and phenocams. There are six data layers in the geodatabase available to the public. This dataset was created in 2019-2020 by the LTAR network as a national collaborative effort among working groups and LTAR sites. Resource Software Recommended: QGIS,url: https://qgis.org/en/site/

This is a collection of all GPS- and computer-generated geospatial data specific to the Alpine Treeline Warming Experiment (ATWE), located on Niwot Ridge, Colorado, USA. The experiment ran between 2008 and 2016, and consisted of three sites spread across an elevation gradient. Geospatial data for all three experimental sites and cone/seed collection locations are included in this package. ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– Geospatial files include cone collection, experimental site, seed trap, and other GPS location/terrain data. File types include ESRI shapefiles, ESRI grid files or Arc/Info binary grids, TIFFs (.tif), and keyhole markup language (.kml) files. Trimble-imported data include plain text files (.txt), Trimble COR (CorelDRAW) files, and Trimble SSF (Standard Storage Format) files. Microsoft Excel (.xlsx) and comma-separated values (.csv) files corresponding to the attribute tables of many files within this package are also included. A complete list of files can be found in this document in the “Data File Organization” section in the included Data User's Guide. Maps are also included in this data package for reference and use. These maps are separated into two categories, 2021 maps and legacy maps, which were made in 2010. Each 2021 map has one copy in portable network graphics (.png) format, and the other in .pdf format. All legacy maps are in .pdf format. .png image files can be opened with any compatible programs, such as Preview (Mac OS) and Photos (Windows). All GIS files were imported into geopackages (.gpkg) using QGIS, and double-checked for compatibility and data/attribute integrity using ESRI ArcGIS Pro. Note that files packaged within geopackages will open in ArcGIS Pro with “main.” preceding each file name, and an extra column named “geom” defining geometry type in the attribute table. The contents of each geospatial file remain intact, unless otherwise stated in “niwot_geospatial_data_list_07012021.pdf/.xlsx”. This list of files can be found as an .xlsx and a .pdf in this archive. As an open-source file format, files within gpkgs (TIFF, shapefiles, ESRI grid or “Arc/Info Binary”) can be read using both QGIS and ArcGIS Pro, and any other geospatial softwares. Text and .csv files can be read using TextEdit/Notepad/any simple text-editing software; .csv’s can also be opened using Microsoft Excel and R. .kml files can be opened using Google Maps or Google Earth, and Trimble files are most compatible with Trimble’s GPS Pathfinder Office software. .xlsx files can be opened using Microsoft Excel. PDFs can be opened using Adobe Acrobat Reader, and any other compatible programs. A selection of original shapefiles within this archive were generated using ArcMap with associated FGDC-standardized metadata (xml file format). We are including these original files because they contain metadata only accessible using ESRI programs at this time, and so that the relationship between shapefiles and xml files is maintained. Individual xml files can be opened (without a GIS-specific program) using TextEdit or Notepad. Since ESRI’s compatibility with FGDC metadata has changed since the generation of these files, many shapefiles will require upgrading to be compatible with ESRI’s latest versions of geospatial software. These details are also noted in the “niwot_geospatial_data_list_07012021” file.

Please note: for a correct view and use of this dataset it is advisable to consult it at original page on the Arezzo Portal. At the same address there are also, for the enabled datasets, additional access formats, the preview of the visualization via API call, the consultation of the fields in DCAT-AP IT format, the possibility to express an evaluation and comment on the dataset itself. All resource formats available for this dataset can be downloaded as ZIP packages: inside the package sarà available the resource in the chosen format, complete with all the information on the metadata and the license associated with it. The conceptual model illustrated in the PDF file attached to the metadata sheet refers to the main classes adopted for the representation of the thematic layers in the QGIS project prepared for the realization of the cartographic elaboration referred to in the title of the sheet. The model was created as a diagram of the classes according to the UML language, adopting a reduced set of specifications. The classes represented in the diagram generally have a name coinciding with that of the corresponding dataset of the physical model. In the conceptual model, “classes” that are actually descriptive of layers representing particular thematic sub-sets of another class can also be illustrated by means of specific queries (Provided Feature Filter) and particular categorical representations. For the main classes are highlighted in special labels, with description enclosed by braces {}, the constraints (constraints) defined between the instances of the class and with the instances of the related classes. Additional natural language annotations have been added, including the name of the corresponding QGIS layer, a brief description of the class, and the data source. The colors assigned to the classes illustrated in the UML model are representative of the Spatialite geodatabases in which the corresponding datasets are stored: a descriptive legend of the various reference geodatabases has been reported in the UML model.

A continuous dataset of Land Surface Temperature (LST) is vital for climatological and environmental studies. LST can be regarded as a combination of seasonal mean temperature (climatology) and daily anomaly, which is attributed mainly to the synoptic-scale atmospheric circulation (weather). To reproduce LST in cloudy pixels, time series (2002-2019) of cloud-free 1km MODIS Aqua LST images were generated and the pixel-based seasonality (climatology) was calculated using temporal Fourier analysis. To add the anomaly, we used the NCEP Climate Forecast System Version 2 (CFSv2) model, which provides air surface temperature under both cloudy and clear sky conditions. The combination of the two sources of data enables the estimation of LST in cloudy pixels.

Data structure

The dataset consists of geo-located continuous LST (Day, Night and Daily) which calculates LST values of cloudy pixels. The spatial domain of the data is the Eastern Mediterranean, at the resolution of the MYD11A1 product (~1 Km). Data are stored in GeoTIFF format as signed 16-bit integers using a scale factor of 0.02, with one file per day, each defined by 4 dimensions (Night LST Cont., Day LST Cont., Daily Average LST Cont., QA). The QA band stores information about the presence of cloud in the original pixel. If in both original files, Day LST and Night LST there was NoData due to clouds, then the QA value is 0. QA value of 1 indicates NoData at original Day LST, 2 indicates NoData at Night LST and 3 indicates valid data at both, day and night. File names follow this naming convention: LST_ 

This dataset contains both large (A0) printable maps of the Torres Strait broken into six overlapping regions, based on a clear sky, clear water composite Sentinel 2 composite imagery and the imagery used to create these maps. These maps show satellite imagery of the region, overlaid with reef and island boundaries and names. Not all features are named, just the more prominent features. This also includes a vector map of Ashmore Reef and Boot Reef in Coral Sea as these were used in the same discussions that these maps were developed for. The map of Ashmore Reef includes the atoll platform, reef boundaries and depth polygons for 5 m and 10 m.

This dataset contains all working files used in the development of these maps. This includes all a copy of all the source datasets and all derived satellite image tiles and QGIS files used to create the maps. This includes cloud free Sentinel 2 composite imagery of the Torres Strait region with alpha blended edges to allow the creation of a smooth high resolution basemap of the region.

The base imagery is similar to the older base imagery dataset: Torres Strait clear sky, clear water Landsat 5 satellite composite (NERP TE 13.1 eAtlas, AIMS, source: NASA).

Most of the imagery in the composite imagery from 2017 - 2021.

Method: The Sentinel 2 basemap was produced by processing imagery from the World_AIMS_Marine-satellite-imagery dataset (not yet published) for the Torres Strait region. The TrueColour imagery for the scenes covering the mapped area were downloaded. Both the reference 1 imagery (R1) and reference 2 imagery (R2) was copied for processing. R1 imagery contains the lowest noise, most cloud free imagery, while R2 contains the next best set of imagery. Both R1 and R2 are typically composite images from multiple dates.

The R2 images were selectively blended using manually created masks with the R1 images. This was done to get the best combination of both images and typically resulted in a reduction in some of the cloud artefacts in the R1 images. The mask creation and previewing of the blending was performed in Photoshop. The created masks were saved in 01-data/R2-R1-masks. To help with the blending of neighbouring images a feathered alpha channel was added to the imagery. The processing of the merging (using the masks) and the creation of the feathered borders on the images was performed using a Python script (src/local/03-merge-R2-R1-images.py) using the Pillow library and GDAL. The neighbouring image blending mask was created by applying a blurring of the original hard image mask. This allowed neighbouring image tiles to merge together.

The imagery and reference datasets (reef boundaries, EEZ) were loaded into QGIS for the creation of the printable maps.

To optimise the matching of the resulting map slight brightness adjustments were applied to each scene tile to match its neighbours. This was done in the setup of each image in QGIS. This adjustment was imperfect as each tile was made from a different combinations of days (to remove clouds) resulting in each scene having a different tonal gradients across the scene then its neighbours. Additionally Sentinel 2 has slight stripes (at 13 degrees off the vertical) due to the swath of each sensor having a slight sensitivity difference. This effect was uncorrected in this imagery.

Single merged composite GeoTiff: The image tiles with alpha blended edges work well in QGIS, but not in ArcGIS Pro. To allow this imagery to be used across tools that don't support the alpha blending we merged and flattened the tiles into a single large GeoTiff with no alpha channel. This was done by rendering the map created in QGIS into a single large image. This was done in multiple steps to make the process manageable.

The rendered map was cut into twenty 1 x 1 degree georeferenced PNG images using the Atlas feature of QGIS. This process baked in the alpha blending across neighbouring Sentinel 2 scenes. The PNG images were then merged back into a large GeoTiff image using GDAL (via QGIS), removing the alpha channel. The brightness of the image was adjusted so that the darkest pixels in the image were 1, saving the value 0 for nodata masking and the boundary was clipped, using a polygon boundary, to trim off the outer feathering. The image was then optimised for performance by using internal tiling and adding overviews. A full breakdown of these steps is provided in the README.md in the 'Browse and download all data files' link.

The merged final image is available in export\TS_AIMS_Torres Strait-Sentinel-2_Composite.tif.

Change Log: 2023-03-02: Eric Lawrey Created a merged version of the satellite imagery, with no alpha blending so that it can be used in ArcGIS Pro. It is now a single large GeoTiff image. The Google Earth Engine source code for the World_AIMS_Marine-satellite-imagery was included to improve the reproducibility and provenance of the dataset, along with a calculation of the distribution of image dates that went into the final composite image. A WMS service for the imagery was also setup and linked to from the metadata. A cross reference to the older Torres Strait clear sky clear water Landsat composite imagery was also added to the record.

22 Nov 2023: Eric Lawrey Added the data and maps for close up of Mer. - 01-data/TS_DNRM_Mer-aerial-imagery/ - preview/Torres-Strait-Mer-Map-Landscape-A0.jpeg - exports/Torres-Strait-Mer-Map-Landscape-A0.pdf Updated 02-Torres-Strait-regional-maps.qgz to include the layout for the new map.

Source datasets: Complete Great Barrier Reef (GBR) Island and Reef Feature boundaries including Torres Strait Version 1b (NESP TWQ 3.13, AIMS, TSRA, GBRMPA), https://eatlas.org.au/data/uuid/d2396b2c-68d4-4f4b-aab0-52f7bc4a81f5

Geoscience Australia (2014b), Seas and Submerged Lands Act 1973 - Australian Maritime Boundaries 2014a - Geodatabase [Dataset]. Canberra, Australia: Author. https://creativecommons.org/licenses/by/4.0/ [license]. Sourced on 12 July 2017, https://dx.doi.org/10.4225/25/5539DFE87D895

Basemap/AU_GA_AMB_2014a/Exclusive_Economic_Zone_AMB2014a_Limit.shp The original data was obtained from GA (Geoscience Australia, 2014a). The Geodatabase was loaded in ArcMap. The Exclusive_Economic_Zone_AMB2014a_Limit layer was loaded and exported as a shapefile. Since this file was small no clipping was applied to the data.

Geoscience Australia (2014a), Treaties - Australian Maritime Boundaries (AMB) 2014a [Dataset]. Canberra, Australia: Author. https://creativecommons.org/licenses/by/4.0/ [license]. Sourced on 12 July 2017, http://dx.doi.org/10.4225/25/5539E01878302 Basemap/AU_GA_Treaties-AMB_2014a/Papua_New_Guinea_TSPZ_AMB2014a_Limit.shp The original data was obtained from GA (Geoscience Australia, 2014b). The Geodatabase was loaded in ArcMap. The Papua_New_Guinea_TSPZ_AMB2014a_Limit layer was loaded and exported as a shapefile. Since this file was small no clipping was applied to the data.

AIMS Coral Sea Features (2022) - DRAFT This is a draft version of this dataset. The region for Ashmore and Boot reef was checked. The attributes in these datasets haven't been cleaned up. Note these files should not be considered finalised and are only suitable for maps around Ashmore Reef. Please source an updated version of this dataset for any other purpose. CS_AIMS_Coral-Sea-Features/CS_Names/Names.shp CS_AIMS_Coral-Sea-Features/CS_Platform_adj/CS_Platform.shp CS_AIMS_Coral-Sea-Features/CS_Reef_Boundaries_adj/CS_Reef_Boundaries.shp CS_AIMS_Coral-Sea-Features/CS_Depth/CS_AIMS_Coral-Sea-Features_Img_S2_R1_Depth5m_Coral-Sea.shp CS_AIMS_Coral-Sea-Features/CS_Depth/CS_AIMS_Coral-Sea-Features_Img_S2_R1_Depth10m_Coral-Sea.shp

Murray Island 20 Sept 2011 15cm SISP aerial imagery, Queensland Spatial Imagery Services Program, Department of Resources, Queensland This is the high resolution imagery used to create the map of Mer.

Marine satellite imagery (Sentinel 2 and Landsat 8) (AIMS), https://eatlas.org.au/data/uuid/5d67aa4d-a983-45d0-8cc1-187596fa9c0c - World_AIMS_Marine-satellite-imagery

Data Location: This dataset is filed in the eAtlas enduring data repository at: data\custodian\2020-2029-AIMS\TS_AIMS_Torres-Strait-Sentinel-2-regional-maps. On the eAtlas server it is stored at eAtlas GeoServer\data\2020-2029-AIMS.

Please note: for a correct view and use of this dataset it is advisable to consult it at original page on the Arezzo Portal. At the same address there are also, for the enabled datasets, additional access formats, the preview of the visualization via API call, the consultation of the fields in DCAT-AP IT format, the possibility to express an evaluation and comment on the dataset itself. All resource formats available for this dataset can be downloaded as ZIP packages: inside the package sarà available the resource in the chosen format, complete with all the information on the metadata and the license associated with it. The conceptual model illustrated in the PDF file attached to the metadata sheet refers to the main classes adopted for the representation of the thematic layers in the QGIS project prepared for the realization of the cartographic elaboration referred to in the title of the sheet. The model was created as a diagram of the classes according to the UML language, adopting a reduced set of specifications. The classes represented in the diagram generally have a name coinciding with that of the corresponding dataset of the physical model. In the conceptual model, “classes” that are actually descriptive of layers representing particular thematic sub-sets of another class can also be illustrated by means of specific queries (Provided Feature Filter) and particular categorical representations. For the main classes are highlighted in special labels, with description enclosed by braces {}, the constraints (constraints) defined between the instances of the class and with the instances of the related classes. Additional natural language annotations have been added, including the name of the corresponding QGIS layer, a brief description of the class, and the data source. The colors assigned to the classes illustrated in the UML model are representative of the Spatialite geodatabases in which the corresponding datasets are stored: a descriptive legend of the various reference geodatabases has been reported in the UML model.

Information layer "road names" of the Kunbaja online resource model built in QGIS as dataset in the ESRI shapefile format

World Countries Generalized represents generalized boundaries for the countries of the world as of August 2022. The generalized political boundaries improve draw performance and effectiveness at a global or continental level. This layer is best viewed out beyond a scale of 1:5,000,000.This layer's geography was developed by Esri and sourced from Garmin International, Inc., the U.S. Central Intelligence Agency (The World Factbook), and the National Geographic Society for use as a world basemap. It is updated annually as country names or significant borders change.

The Residential Schools Locations Dataset in Geodatabase format (IRS_Locations.gbd) contains a feature layer "IRS_Locations" that contains the locations (latitude and longitude) of Residential Schools and student hostels operated by the federal government in Canada. All the residential schools and hostels that are listed in the Residential Schools Settlement Agreement are included in this dataset, as well as several Industrial schools and residential schools that were not part of the IRRSA. This version of the dataset doesn’t include the five schools under the Newfoundland and Labrador Residential Schools Settlement Agreement. The original school location data was created by the Truth and Reconciliation Commission, and was provided to the researcher (Rosa Orlandini) by the National Centre for Truth and Reconciliation in April 2017. The dataset was created by Rosa Orlandini, and builds upon and enhances the previous work of the Truth and Reconcilation Commission, Morgan Hite (creator of the Atlas of Indian Residential Schools in Canada that was produced for the Tk'emlups First Nation and Justice for Day Scholar's Initiative, and Stephanie Pyne (project lead for the Residential Schools Interactive Map). Each individual school location in this dataset is attributed either to RSIM, Morgan Hite, NCTR or Rosa Orlandini. Many schools/hostels had several locations throughout the history of the institution. If the school/hostel moved from its’ original location to another property, then the school is considered to have two unique locations in this dataset,the original location and the new location. For example, Lejac Indian Residential School had two locations while it was operating, Stuart Lake and Fraser Lake. If a new school building was constructed on the same property as the original school building, it isn't considered to be a new location, as is the case of Girouard Indian Residential School.When the precise location is known, the coordinates of the main building are provided, and when the precise location of the building isn’t known, an approximate location is provided. For each residential school institution location, the following information is provided: official names, alternative name, dates of operation, religious affiliation, latitude and longitude coordinates, community location, Indigenous community name, contributor (of the location coordinates), school/institution photo (when available), location point precision, type of school (hostel or residential school) and list of references used to determine the location of the main buildings or sites. Access Instructions: there are 47 files in this data package. Please download the entire data package by selecting all the 47 files and click on download. Two files will be downloaded, IRS_Locations.gbd.zip and IRS_LocFields.csv. Uncompress the IRS_Locations.gbd.zip. Use QGIS, ArcGIS Pro, and ArcMap to open the feature layer IRS_Locations that is contained within the IRS_Locations.gbd data package. The feature layer is in WGS 1984 coordinate system. There is also detailed file level metadata included in this feature layer file. The IRS_locations.csv provides the full description of the fields and codes used in this dataset.

Please note: for a correct view and use of this dataset it is advisable to consult it at original page on the Arezzo Portal. At the same address there are also, for the enabled datasets, additional access formats, the preview of the visualization via API call, the consultation of the fields in DCAT-AP IT format, the possibility to express an evaluation and comment on the dataset itself.

All resource formats available for this dataset can be downloaded as ZIP packages: inside the package sarà available the resource in the chosen format, complete with all the information on the metadata and the license associated with it.

The conceptual model illustrated in the PDF file attached to the metadata sheet refers to the main classes adopted for the representation of the thematic layers in the QGIS project prepared for the realization of the cartographic elaboration referred to in the title of the sheet. The model was created as a diagram of the classes according to the UML language, adopting a reduced set of specifications. The classes represented in the diagram generally have a name coinciding with that of the corresponding dataset of the physical model. In the conceptual model, “classes” that are actually descriptive of layers representing particular thematic sub-sets of another class can also be illustrated by means of specific queries (Provided Feature Filter) and particular categorical representations. For the main classes are highlighted in special labels, with description enclosed by braces {}, the constraints (constraints) defined between the instances of the class and with the instances of the related classes. Additional natural language annotations have been added, including the name of the corresponding QGIS layer, a brief description of the class, and the data source. The colors assigned to the classes illustrated in the UML model are representative of the Spatialite geodatabases in which the corresponding datasets are stored: a descriptive legend of the various reference geodatabases has been reported in the UML model.

This dataset comprises land use maps of Maputo city, with exception of the KaTembe urban district, for the years 1964, 1973, 1982, 1991 and 2001. It is the digital version of the land use maps published by Henriques [1] and revised under the LUCO research project.

The land use of Maputo city was identified from: i) aerial photographs (1964, 1982, 1991), orthophoto maps (1973) and IKONOS images (2001); ii) documentary sources, such as the Urbanization Master Plan (1969) and the Maputo City Addressing (1997); iii) the recognition made during several field survey campaigns. The methodology is described in Henriques [1].

Land use was classified into three levels, resulting from a hierarchical classification system, including descriptive and parametric classes. Levels I and II are available in this repository.

Level I, composed by 10 classes, contains the main forms of occupation: built-up areas (residential, economic activity, equipment, and infrastructure) and non-built-up areas (vacant or "natural"). It is geared towards analyses that serve policymaking and resource management at the regional or national scale [1].

Level II, composed by 31 classes, discriminates the higher hierarchical level according to its functional land use to become useful for municipal planning and management in municipal master plans, for example [1].

Maps are available in shapefile format and include predefined symbology-legend files, for QGIS and ArcGIS (v.10.7 or higher). The urban land use classes are described in Portuguese and English, and their meaning is provided as an accompanying document (ULU_Maputo_Nomenclatura_PT.pdf / ULU_Maputo_Nomenclature_EN.pdf).

Data format: vector (shapefile, polygon)

Reference system: WGS84, UTM 36S (EPSG:32736)

Original minimum mapping unit: 25 m2

Urban Land Use dataset attributes:

[N_I_C] – code of level I

[N_I_D_PT] – name of level I, in Portuguese

[N_I_D_EN] - name of level I, in English

[N_II_C] – code of level II

[N_II_D_PT] - name of level II, in Portuguese

[N_II_D_EN] - name of level II, in English

Funding: this research was supported by national funds through FCT – Fundação para a Ciência e Tecnologia, I.P. Project number: FCT AGA-KHAN/ 541731809 / 2019

[1] Henriques, C.D. (2008). Maputo. Cinco décadas de mudança territorial. O uso do solo observado por tecnologias de informação geográfica [Maputo. Five decades of territorial transformation. Land use assessed by geographical information technologies]. Lisboa, Instituto Português de Apoio ao Desenvolvimento (ISBN: 978-972-8975-22-7).

A Google Earth Engine implementation of the Floodwater Depth Estimation Tool (FwDET) This is a Google Earth Engine implementation of the Floodwater Depth Estimation Tool (FwDET) developed by the Surface Dynamics and Modeling Lab at the University of Alabama that calculates flood depth using a flood extent layer and a digital elevation model. This research is made possible by the CyberSeed Program at the University of Alabama. Project name: WaterServ: A Cyberinfrastructure for Analysis, Visualization and Sharing of Hydrological Data. Please see the associated publications: 1. Peter, B.G., Cohen, S., Lucey, R., Munasinghe, D., Raney, A. and Brakenridge, G.R., 2020. Google Earth Engine Implementation of the Floodwater Depth Estimation Tool (FwDET-GEE) for rapid and large scale flood analysis. IEEE Geoscience and Remote Sensing Letters, 19, pp.1-5. https://ieeexplore.ieee.org/abstract/document/9242297 2. Cohen, S., Peter, B.G., Haag, A., Munasinghe, D., Moragoda, N., Narayanan, A. and May, S., 2022. Sensitivity of remote sensing floodwater depth calculation to boundary filtering and digital elevation model selections. Remote Sensing, 14(21), p.5313. https://github.com/csdms-contrib/fwdet 3. Cohen, S., A. Raney, D. Munasinghe, J.D. Loftis J, A. Molthan, J. Bell, L. Rogers, J. Galantowicz, G.R. Brakenridge7, A.J. Kettner, Y. Huang, Y. Tsang, (2019). The Floodwater Depth Estimation Tool (FwDET v2.0) for Improved Remote Sensing Analysis of Coastal Flooding. Natural Hazards and Earth System Sciences, 19, 2053–2065. https://doi.org/10.5194/nhess-19-2053-2019 4. Cohen, S., G. R. Brakenridge, A. Kettner, B. Bates, J. Nelson, R. McDonald, Y. Huang, D. Munasinghe, and J. Zhang (2018), Estimating Floodwater Depths from Flood Inundation Maps and Topography, Journal of the American Water Resources Association, 54 (4), 847–858. https://doi.org/10.1111/1752-1688.12609 Sample products and data availability: https://sdml.ua.edu/models/fwdet/ https://sdml.ua.edu/michigan-flood-may-2020/ https://cartoscience.users.earthengine.app/view/fwdet-gee-mi https://alabama.app.box.com/s/31p8pdh6ngwqnbcgzlhyk2gkbsd2elq0 GEE implementation output: fwdet_gee_brazos.tif ArcMap implementation output (see Cohen et al. 2019): fwdet_v2_brazos.tif iRIC validation layer (see Nelson et al. 2010): iric_brazos_hydraulic_model_validation.tif Brazos River inundation polygon access in GEE: var brazos = ee.FeatureCollection('users/cartoscience/FwDET-GEE-Public/Brazos_River_Inundation_2016') Nelson, J.M., Shimizu, Y., Takebayashi, H. and McDonald, R.R., 2010. The international river interface cooperative: public domain software for river modeling. In 2nd Joint Federal Interagency Conference, Las Vegas, June (Vol. 27). Google Earth Engine Code /* ---------------------------------------------------------------------------------------------------------------------- # FwDET-GEE calculates floodwater depth from a floodwater extent layer and a DEM Authors: Brad G. Peter, Sagy Cohen, Ronan Lucey, Dinuke Munasinghe, Austin Raney Emails: bpeter@ua.edu, sagy.cohen@ua.edu, ronan.m.lucey@nasa.gov, dsmunasinghe@crimson.ua.edu, aaraney@crimson.ua.edu Organizations: BP, SC, DM, AR - University of Alabama; RL - University of Alabama in Huntsville Last Modified: 10/08/2020 To cite this code use: Peter, Brad; Cohen, Sagy; Lucey, Ronan; Munasinghe, Dinuke; Raney, Austin, 2020, "A Google Earth Engine implementation of the Floodwater Depth Estimation Tool (FwDET-GEE)", https://doi.org/10.7910/DVN/JQ4BCN, Harvard Dataverse, V2 ------------------------------------------------------------------------------------------------------------------------- This is a Google Earth Engine implementation of the Floodwater Depth Estimation Tool (FwDETv2.0) [1] developed by the Surface Dynamics and Modeling Lab at the University of Alabama that calculates flood depth using a flood extent layer and a digital elevation model. This research is made possible by the CyberSeed Program at the University of Alabama. Project name: WaterServ: A Cyberinfrastructure for Analysis, Visualization and Sharing of Hydrological Data. GitHub Repository (ArcMap and QGIS implementations): https://github.com/csdms-contrib/fwdet ------------------------------------------------------------------------------------------------------------------------- How to run this code with your flood extent GEE asset: User of this script will need to update path to flood extent (line 32 or 33) and select from the processing options. Available DEM options (1) are USGS/NED (U.S.) and USGS/SRTMGL1_003 (global). Other options include (2) running the elevation outlier filtering algorithm, (3) adding water body data to the inundation extent, (4) add a water body data layer uploaded by the user rather than using the JRC global surface water data, (5) masking out regular water body data, (6) masking out 0 m depths, (7) choosing whether or not to export, (8) exporting additional data layers, and (9) setting an export file name....

The Los Angeles County Storm Drain System is a geometric network model representing the storm drain infrastructure within Los Angeles County. The long term goal of this network is to seamlessly integrate the countywide drainage infrastructure, regardless of ownership or jurisdiction. Current uses by the Department of Public Works (DPW) include asset inventory, operational maintenance, and compliance with environmental regulations.

GIS DATA DOWNLOADS: (More information is in the table below)

File geodatabase: A limited set of feature classes comprise the majority of this geometric network. These nine feature classes are available in one file geodatabase (.gdb). ArcMap versions compatible with the .gdb are 10.1 and later. Read-only access is provided by the open-source software QGIS. Instructions on opening a .gdb file are available here, and a QGIS plugin can be downloaded here.

Acronyms and Definitions (pdf) are provided to better understand terms used.

ONLINE VIEWING: Use your PC’s browser to search for drains by street address or drain name and download engineering drawings. The Web Viewer link is: https://dpw.lacounty.gov/fcd/stormdrain/

MOBILE GIS: This storm drain system can also be viewed on mobile devices as well as your PC via ArcGIS Online. (As-built plans are not available with this mobile option.)

More About these Downloads All data added or updated by Public Works is contained in nine feature classes, with definitions listed below. The file geodatabase (.gdb) download contains these eleven feature classes without network connectivity. Feature classes include attributes with unabbreviated field names and domains.

ArcMap versions compatible with the .gdb are 10.1 and later.

Feature Class Download Description

CatchBasin In .gdb Catch basins collect urban runoff from gutters

Culvert In .gdb A relatively short conduit that conveys storm water runoff underneath a road or embankment. Typical materials include reinforced concrete pipe (RCP) and corrugated metal pipe (CMP). Typical shapes are circular, rectangular, elliptical, or arched.

ForceMain In .gdb Force mains carry stormwater uphill from pump stations into gravity mains and open channels.

GravityMain In .gdb Underground pipes and channels.

LateralLine In .gdb Laterals connect catch basins to underground gravity mains or open channels.

MaintenanceHole In .gdb The top opening to an underground gravity main used for inspection and maintenance.

NaturalDrainage In .gdb Streams and rivers that flow through natural creek beds

OpenChannel In .gdb Concrete lined stormwater channels.

PumpStation In .gdb Where terrain causes accumulation, lift stations are used to pump stormwater to where it can once again flow towards the ocean

Data Field Descriptions

Most of the feature classes in this storm drain geometric network share the same GIS table schema. Only the most critical attributes are listed here per LACFCD operations.

Attribute Description

ASBDATE The date the design plans were approved “as-built” or accepted as “final records”.

CROSS_SECTIN_SHAPE The cross-sectional shape of the pipe or channel. Examples include round, square, trapezoidal, arch, etc.

DIAMETER_HEIGHT The diameter of a round pipe or the height of an underground box or open channel.

DWGNO Drain Plan Drawing Number per LACFCD Nomenclature

EQNUM Asset No. assigned by the Department of Public Works’ (in Maximo Database).

MAINTAINED_BY Identifies, to the best of LAFCD’s knowledge, the agency responsible for maintaining the structure.

MOD_DATE Date the GIS features were last modified.

NAME Name of the individual drainage infrastructure.

OWNER Agency that owns the drainage infrastructure in question.

Q_DESIGN The peak storm water runoff used for the design of the drainage infrastructure.

SOFT_BOTTOM For open channels, indicates whether the channel invert is in its natural state (not lined).

SUBTYPE Most feature classes in this drainage geometric nature contain multiple subtypes.

UPDATED_BY The person who last updated the GIS feature.

WIDTH Width of a channel in feet.

The "NSDI Zambia Operational Health Facility Layer, Version 01 (Beta)" provides health facility and health affiliated infrastructure point locations, names, types, and source of the data. The dataset was developed by compiling and standardizing existing government data sources of health facility and affiliated infrastructure locations and names data from the Ministry of Health (MoH) obtained in 2019 and from the 2010 census cartography from Zambia Statistics Agency (ZamStats). The dataset is available for download in shapefile format and can be viewed in Geographic Information Systems(GIS) such as ArcMap, QGIS, or Google Earth (Pro). The data is available for all of Zambia. It has the following attributes: Name, Original Name (from original dataset), Type, Sub Type, Source, Province (Code), District (Code), Global ID. The dataset also includes a Label column which can be used for labeling.For more information about the settlement data and methodology, see the data release notes here.

The dataset is available for download in shapefile format and can be viewed in Geographic Information Systems(GIS) such as ArcMap, QGIS, or Google Earth (Pro).The data is available for all of Zambia. It has the following attributes: Name, Original Name, Type, Sub Type, Source, Province (Code), District (Code), Ward (Code), Constituency (Code), Global ID, LAT, LONG

This map is designed to be used as a basemap by marine GIS professionals and as a reference map by anyone interested in ocean data. The basemap includes bathymetry, marine water body names, undersea feature names, and derived depth values in meters. Land features include administrative boundaries, cities, inland waters, roads, overlaid on land cover and shaded relief imagery.

The map was compiled from a variety of best available sources from several data providers, including General Bathymetric Chart of the Oceans GEBCO_08 Grid version 20100927 and IHO-IOC GEBCO Gazetteer of Undersea Feature Names August 2010 version (https://www.gebco.net), National Oceanic and Atmospheric Administration (NOAA) and National Geographic for the oceans; and DeLorme, HERE, and Esri for topographic content. The basemap was designed and developed by Esri.

The Ocean Basemap currently provides coverage for the world down to a scale of ~1:577k; coverage down to ~1:72k in United States coastal areas and various other areas; and coverage down to ~1:9k in limited regional areas. You can contribute your bathymetric data to this service and have it served by Esri for the benefit of the Ocean GIS community. For details, see the Community Maps Program.

Tip: Here are some famous oceanic locations as they appear in this map. Each URL below launches this map at a particular location via parameters specified in the URL: Challenger Deep, Galapagos Islands, Hawaiian Islands, Maldive Islands, Mariana Trench, Tahiti, Queen Charlotte Sound, Notre Dame Bay, Labrador Trough, New York Bight, Massachusetts Bay, Mississippi Sound

Abstract Landslides are damaging and deadly, and they occur in every U.S. state. However, our current ability to understand landslide hazards at the national scale is limited, in part because spatial data on landslide occurrence across the U.S. varies greatly in quality, accessibility, and extent. Landslide inventories are typically collected and maintained by different agencies and institutions, usually within specific jurisdictional boundaries, and often with varied objectives and information attributes or even in disparate formats. The purpose of this data release is to provide an openly accessible, centralized map of existing information about landslide occurrence across the entire U.S. This data release is an update of previous versions 1 (Jones and others, 2019) and 2 (Belair and others, 2022). Changes relative to version 2 are summarized in us_ls_v3_changes.txt. It provides an integrated database of the landslides from these inventories (refer to US_Landslide_v3_gpkg) with a selection of uniform attributes, including links to the original digital inventory files (whenever available) (“Inv_URL”). The data release includes digital inventories created by both USGS and non-USGS authors. The original inventory is denoted by an abbreviation in the “Inventory” attribute. The full citation for each abbreviation can be found in us_ls_v3_references.csv. The date of the landslide event is included as a minimum and maximum (“Date_Min” and “Date_Max”) to accommodate events that happen within a range of dates. The date value is inherently difficult to interpret or discern due to the nature of landsliding, where some landslides move for long periods of time or move intermittently, and some areas can exhibit multiple landslide events. To preserve the constituent inventories as much as possible, we include all entries even if they are not considered landslides, such as “gullies” or “avalanche chutes.” We include a landslide type attribute when that information is available (“LS_Type”). The landslide classification system used in the original inventories is not always known or stated in the metadata, but many mapping entities use the schema from Cruden and Varnes (1996) or the updated schema from Hungr and others (2014). Given the wide range of landslide information sources in this data compilation, we provide an attribute to assess the relative confidence in the characterization of the _location and extent of each landslide (entry) (“Confidence”). The confidence level reflects the resolution and quality of input data, as well as the method used for identification and mapping. This confidence does not reflect a formal accuracy assessment of field attributes. Relative to the previous data releases (version 1 and 2), this update (v3) includes more inventories, updated confidence rules, a new landslide type attribute, a new unique identifier (“USGS_ID”), new machine-readable date fields, and an ancillary database containing all fields from the original inventories (refer to US_Landslide_v3_ancillary). Please contact gs-haz_landslides_inventory@usgs.gov for more information on how to contribute additional inventories to this community effort. When possible, please cite the constituent inventories as well as this data release. This data release includes: (1) a landslide point file and polygon file in multiple forms (US_Landslide_v3_gpkg, US_Landslide_v3_shp, US_Landslide_v3_csv), (2) an ancillary database with original fields (US_Landslide_v3_ancillary), (3) a spreadsheet that summarizes the confidence rules, their justification, and any extra analyses (us_ls_v3_analyses.csv), (4) a summary file of the changes made between version 2 and version 3 (us_ls_v3_changes.txt), (5) a file containing the references of the constituent inventories (us_ls_v3_references.csv), (6) and a readme (README.txt). Disclaimer: Any use of trade, firm, or product names is for descriptive purposes only and does not imply endorsement by the U.S. Government. Data fields Field Names Definitions USGS_ID Unique USGS identifier for each landslide entry. Date_Min Minimum possible date of landslide occurrence. If date is known to the day, Date_Min will have a value while Date_Max is empty. Time zone is assumed to be local, except for Inventories ‘USGS Earthquake-Triggered Ground Failure’ and ‘USGS Seismogenic Mass Movements’ which are in UTC. Date_Max Maximum possible date of landslide occurrence. If date is known to the day, Date_Max will be empty while Date_Min has a value. Time zone is assumed to be local, except for Inventories ‘USGS Earthquake-Triggered Ground Failure’ and ‘USGS Seismogenic Mass Movements’ which are in UTC. Fatalities Number of fatalities caused by landslide event. Confidence Confidence in landslide (entry) extent, nature, and _location. LS_Type Landslide (entry) type. Classification schema of original inventories is often not specified. Inventory Name of original source inventory. Inv_URL URL or link to original source inventory. Info_Source Information source or sub-layer from original source inventory. Notes Unformatted notes field, includes additional information. Lat_N Latitude of point or polygon centroid in WGS 1984 Lon_W Longitude of point or polygon centroid in WGS 1984 Confidence attributes Confidence Definitions 1 Possible landslide (feature) in the area 2 Probable landslide (feature) in the area 3 Likely landslide (feature) at or near this _location 5 Moderate confidence in extent or nature of landslide (feature) at this _location 8 High confidence in extent or nature of landslide (feature) References Belair, G.M., Jones, E.S., Slaughter, S.L., and Mirus, B.B., 2022, Landslide Inventories across the United States version 2: U.S. Geological Survey data release, https://doi.org/10.5066/P9FZUX6N. Cruden, D.M. and Varnes, D.J., 1996, Landslide Types and Processes, in Turner, K.A. and Schuster R. L., eds., Landslides Investigation and Mitigation: Transportation Research Board, U.S. National Research Council Special Report 247, U.S. National Academy of Sciences, Chapter 3, p. 36-75. ESRI, 2023, ArcGIS Pro (Version 3.1.3), Redlands, CA: Environmental Systems Research Institute, Retrieved from https://www.esri.com/en-us/arcgis/products/arcgis-pro/resources. Hungr, O., Leroueil, S., and Picarelli, L., 2014, The Varnes classification of landslide types, an update, Landslides, 11(2), p. 167-194, https://doi.org/10.1007/s10346-013-0436-y. Jones, E.S., Mirus, B.B, Schmitt, R.G., Baum, R.L., Burns, W.J., Crawford, M., Godt, J.W., Kirschbaum, D.B., Lancaster, J.T., Lindsey, K.O., McCoy, K.E., Slaughter, S., and Stanley, T.A., 2019, Landslide Inventories across the United States: U.S. Geological Survey data release, https://doi.org/10.5066/P9E2A37P. Python Software Foundation, 2023, Python Language Reference, version 3.9, Retrieved from http://www.python.org. QGIS.org, 2022, QGIS Geographic Information System (Version 3.28.4-Firenze), QGIS Association, Retrieved from http://www.qgis.org.

Please note: for a correct view and use of this dataset it is advisable to consult it at original page on the Arezzo Portal. At the same address there are also, for the enabled datasets, additional access formats, the preview of the visualization via API call, the consultation of the fields in DCAT-AP IT format, the possibility to express an evaluation and comment on the dataset itself. All resource formats available for this dataset can be downloaded as ZIP packages: inside the package sarà available the resource in the chosen format, complete with all the information on the metadata and the license associated with it. The conceptual model illustrated in the PDF file attached to the metadata sheet refers to the main classes adopted for the representation of the thematic layers in the QGIS project prepared for the realization of the cartographic elaboration referred to in the title of the sheet. The model was created as a diagram of the classes according to the UML language, adopting a reduced set of specifications. The classes represented in the diagram generally have a name coinciding with that of the corresponding dataset of the physical model. In the conceptual model, “classes” that are actually descriptive of layers representing particular thematic sub-sets of another class can also be illustrated by means of specific queries (Provided Feature Filter) and particular categorical representations. For the main classes are highlighted in special labels, with description enclosed by braces {}, the constraints (constraints) defined between the instances of the class and with the instances of the related classes. Additional natural language annotations have been added, including the name of the corresponding QGIS layer, a brief description of the class, and the data source. The colors assigned to the classes illustrated in the UML model are representative of the Spatialite geodatabases in which the corresponding datasets are stored: a descriptive legend of the various reference geodatabases has been reported in the UML model.

Urban Tree Canopy Assessment. This was created using the Urban Tree Canopy Syracuse 2010 (All Layers) file HERE.The data for this map was created using LIDAR and other spatial analysis tools to identify and measure tree canopy in the landscape. This was a collaboration between the US Forest Service Northern Research Station (USFS), the University of Vermont Spatial Laboratory, and SUNY ESF. Because the full map is too large to be viewed in ArcGIS Online, this has been reduced to a vector tile layer to allow it to be viewed online. To download and view the shapefiles and all of the layers, you can download the data HERE and view this in either ArcGIS Pro or QGIS.Data DictionaryDescription source  USDA Forest ServiceList of values  Value 1 Description Tree CanopyValue 2 Description Grass/ShrubValue 3 Description Bare SoilValue 4 Description WaterValue 5 Description BuildingsValue 6 Description Roads/RailroadsValue 7 Description Other PavedField Class Alias Class Data type String Width 20Geometric objects  Feature class name landcover_2010_syracusecity Object type  complex Object count 7ArcGIS Feature Class Properties Feature class name landcover_2010_syracusecity Feature type  Simple Geometry type Polygon Has topology FALSE Feature count 7 Spatial index TRUE Linear referencing  FALSEDistributionAvailable format  Name ShapefileTransfer options  Transfer size 163.805Description Downloadable DataFieldsDetails for object landcover_2010_syracusecityType Feature Class Row count  7 Definition  UTCField FIDAlias FID Data type OID Width  4 Precision 0 Scale 0Field descriptionInternal feature number.Description source ESRIDescription of valueSequential unique whole numbers that are automatically generated.Field ShapeAlias Shape Data type Geometry Width 0 Precision 0 Scale 0Field description Feature geometry.Description source  ESRIDescription of values Coordinates defining the features.Field CodeAlias Code Data type Number Width 4Overview Description  Metadata DetailsMetadata language  English Metadata character set utf8 - 8 bit UCS Transfer FormatScope of the data described by the metadata  dataset Scope name  datasetLast update 2011-06-02ArcGIS metadata properties Metadata format ArcGIS 1.0 Metadata style North American Profile of ISO19115 2003Created in ArcGIS for the item 2011-06-02 16:48:35 Last modified in ArcGIS for the item 2011-06-02 16:44:43Automatic updates Have been performed Yes Last update 2011-06-02 16:44:43Item location history  Item copied or moved 2011-06-02 16:48:35 From T:\TestSites\NY\Syracuse\Temp\landcover_2010_syracusecity To \T7500\F$\Export\LandCover_2010_SyracuseCity\landcover_2010_syracusecity

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