Abstract In this work, we report the mapping of electrical equipotential lines (1D) and equipotential surfaces (3D) using the free Quantum Geographic information system (QGIS) software. For this purpose, experiments taking into account, four different electrical configurations were performed on physics classes of undergraduate students, using two conductors of opposite electrical charges for each experiment. For the first experiment two copper parallel linear conductors; for the second, a copper parallel linear conductor with a small circular ring acting as a point charge; for the third, two concentric circular ring and for the fourth one a semicircular ring with a small circular ring acting as point charge. The experimental data were treated and interpolated in the, open source, QGIS software, used in geoprocessing, to map the electrical equipotential planes and surfaces.

The Digital Geologic-GIS Map of Grant's Headquarters at City Point, Petersburg National Battlefield, Virginia is composed of GIS data layers and GIS tables, and is available in the following GRI-supported GIS data formats: 1.) a 10.1 file geodatabase (cipo_geology.gdb), a 2.) Open Geospatial Consortium (OGC) geopackage, and 3.) 2.2 KMZ/KML file for use in Google Earth, however, this format version of the map is limited in data layers presented and in access to GRI ancillary table information. The file geodatabase format is supported with a 1.) ArcGIS Pro map file (.mapx) file (cipo_geology.mapx) and individual Pro layer (.lyrx) files (for each GIS data layer), as well as with a 2.) 10.1 ArcMap (.mxd) map document (cipo_geology.mxd) and individual 10.1 layer (.lyr) files (for each GIS data layer). The OGC geopackage is supported with a QGIS project (.qgz) file. Upon request, the GIS data is also available in ESRI 10.1 shapefile format. Contact Stephanie O'Meara (see contact information below) to acquire the GIS data in these GIS data formats. In addition to the GIS data and supporting GIS files, three additional files comprise a GRI digital geologic-GIS dataset or map: 1.) A GIS readme file (pete_geology_gis_readme.pdf), 2.) the GRI ancillary map information document (.pdf) file (pete_geology.pdf) which contains geologic unit descriptions, as well as other ancillary map information and graphics from the source map(s) used by the GRI in the production of the GRI digital geologic-GIS data for the park, and 3.) a user-friendly FAQ PDF version of the metadata (cipo_geology_metadata_faq.pdf). Please read the pete_geology_gis_readme.pdf for information pertaining to the proper extraction of the GIS data and other map files. Google Earth software is available for free at: https://www.google.com/earth/versions/. QGIS software is available for free at: https://www.qgis.org/en/site/. Users are encouraged to only use the Google Earth data for basic visualization, and to use the GIS data for any type of data analysis or investigation. The data were completed as a component of the Geologic Resources Inventory (GRI) program, a National Park Service (NPS) Inventory and Monitoring (I&M) Division funded program that is administered by the NPS Geologic Resources Division (GRD). For a complete listing of GRI products visit the GRI publications webpage: For a complete listing of GRI products visit the GRI publications webpage: https://www.nps.gov/subjects/geology/geologic-resources-inventory-products.htm. For more information about the Geologic Resources Inventory Program visit the GRI webpage: https://www.nps.gov/subjects/geology/gri,htm. At the bottom of that webpage is a "Contact Us" link if you need additional information. You may also directly contact the program coordinator, Jason Kenworthy (jason_kenworthy@nps.gov). Source geologic maps and data used to complete this GRI digital dataset were provided by the following: U.S. Geological Survey. Detailed information concerning the sources used and their contribution the GRI product are listed in the Source Citation section(s) of this metadata record (cipo_geology_metadata.txt or cipo_geology_metadata_faq.pdf). Users of this data are cautioned about the locational accuracy of features within this dataset. Based on the source map scale of 1:24,000 and United States National Map Accuracy Standards features are within (horizontally) 12.2 meters or 40 feet of their actual location as presented by this dataset. Users of this data should thus not assume the location of features is exactly where they are portrayed in Google Earth, ArcGIS, QGIS or other software used to display this dataset. All GIS and ancillary tables were produced as per the NPS GRI Geology-GIS Geodatabase Data Model v. 2.3. (available at: https://www.nps.gov/articles/gri-geodatabase-model.htm).

This dataset shows the results of mapping the connectivity of key values (natural heritage, indigenous heritage, social and historic and economic) of the Great Barrier Reef with its neighbouring regions (Torres Strait, Coral Sea and Great Sandy Strait). The purpose of this mapping process was to identify values that need joint management across multiple regions. It contains a spreadsheet containing the connection information obtained from expert elicitation, all maps derived from this information and all GIS files needed to recreate these maps. This dataset contains the connection strength for 59 attributes of the values between 7 regions (GBR Far Northern, GBR Cairns-Cooktown, GBR Whitsunday-Townsville, GBR Mackay-Capricorn, Torres Strait, Coral Sea and Great Sandy Strait) based on expert opinion. Each connection is assessed based on its strength, mechanism and confidence. Where a connection was known to not exist between two regions then this was also explicitly recorded. A video tutorial on this dataset and its maps is available from https://vimeo.com/335053846.

Methods:

The information for the connectivity maps was gathered from experts (~30) during a 3-day workshop in August 2017. Experts were provided with a template containing a map of Queensland and the neighbouring seas, with an overlay of the regions of interest to assess the connectivity. These were Torres Strait, GBR:Far North Queensland, GBR:Cairns to Cooktown, GBC: Townsville to Whitsundays, GBR: Mackay to Capricorn Bunkers and Great Sandy Strait (which includes Hervey bay). A range of reference maps showing locations of the values were provided, where this information could be obtained. As well as the map the template provided 7x7 table for filling in the connectivity strength and connection type between all combinations of these regions. The experts self-organised into groups to discuss and complete the template for each attribute to be mapped. Each expert was asked to estimate the strength of connection between each region as well as the connection mechanism and their confidence in the information. Due to the limited workshop time the experts were asked to focus on initially recording the connections between the GBR and its neighbouring regions and not to worry about the internal connections in the GBR, or long-distance connections along the Queensland coast. In the second half of the workshop the experts were asked to review the maps created and expand on the connections to include those internal to the GBR. After the workshop an initial set of maps were produced and reviewed by the project team and a range of issues were identified and resolved. Additional connectivity maps for some attributes were prepared after the workshop by the subject experts within the project team. The data gathered from these templates was translated into a spreadsheet, then processing into the graphic maps using QGIS to present the connectivity information. The following are the value attributes where their connectivity was mapped: Seagrass meadows: pan-regional species (e.g. Halophila spp. and Halodule spp.) Seagrass meadows: tropical/sub-tropical (Cymodocea serrulata, Syringodium isoetifolium) Seagrass meadows: tropical (Thalassia, Cymodocea, Thalassodendron, Enhalus, Rotundata) Seagrass meadows: Zostera muelleri Mangroves & saltmarsh Hard corals Crustose coralline algae Macroalgae Crown of thorns starfish larval flow Acropora larval flow Casuarina equisetifolia & Pandanus tectorius Argusia argentia Pisonia grandis: cay vegetation Inter-reef gardens (sponges + gorgonians) (Incomplete) Halimeda Upwellings Pelagic foraging seabirds Inshore and offshore foraging seabirds Migratory shorebirds Ornate rock lobster Yellowfin tuna Black marlin Spanish mackerel Tiger shark Grey nurse shark Humpback whales Dugongs Green turtles Hawksbill turtles Loggerhead turtles Flatback turtles Longfin & Shortfin Eels Red-spot king prawn Brown tiger prawn Eastern king prawns Great White Shark Sandfish (H. scabra) Black teatfish (H. whitmaei) Location of sea country Tangible cultural resources Location of place attachment Location of historic shipwrecks Location of places of social significance Location of commercial fishing activity Location of recreational use Location of tourism destinations Australian blacktip shark (C. tilstoni) Barramundi Common black tip shark (C. limbatus) Dogtooth tuna Grey mackerel Mud crab Coral trout (Plectropomus laevis) Coral trout (Plectropomus leopardus) Red throat emperor Reef manta Saucer scallop (Ylistrum balloti) Bull shark Grey reef shark

Limitations of the data:

The connectivity information in this dataset is only rough in nature, capturing the interconnections between 7 regions. The connectivity data is based on expert elicitation and so is limited by the knowledge of the experts that were available for the workshop. In most cases the experts had sufficient knowledge to create robust maps. There were however some cases where the knowledge of the participants was limited, or the available scientific knowledge on the topic was limited (particularly for the ‘inter-reefal gardens’ attribute) or the exact meaning of the value attribute was poorly understood or could not be agreed up on (particularly for the social and indigenous heritage maps). This information was noted with the maps. These connectivity maps should be considered as an initial assessment of the connections between each of the regions and should not be used as authoritative maps without consulting with additional sources of information. Each of the connectivity links between regions was recorded with a level of confidence, however these were self-reported, and each assessment was performed relatively quickly, with little time for reflection or review of all the available evidence. It is likely that in many cases the experts tended to have a bias to mark links with strong confidence. During subsequent revisions of some maps there were substantial corrections and adjustments even for connections with a strong confidence, indicating that there could be significant errors in the maps where the experts were not available for subsequent revisions. Each of the maps were reviewed by several project team members with broad general knowledge. Not all connection combinations were captured in this process due to the limited expert time available. A focus was made on capturing the connections between the GBR and its neighbouring regions. Where additional time was available the connections within 4 regions in the GBR was also captured. The connectivity maps only show connections between immediately neighbouring regions, not far connections such as between Torres Strait and Great Sandy Strait. In some cases the connection information for longer distances was recorded from the experts but not used in the mapping process. The coastline polygon and the region boundaries in the maps are not spatially accurate. They were simplified to make the maps more diagrammatic. This was done to reduce the chance of misinterpreting the connection arrows on the map as being spatially explicit.

Format:

This dataset is made up of a spreadsheet that contains all the connectivity information recorded from the expert elicitation and all the GIS files needed to recreate the generated maps.

original/GBR_NESP-TWQ-3-3-3_Seascape-connectivity_Master_v2018-09-05.xlsx: ‘Values connectivity’: This sheet contains the raw connectivity codes transcribed from the templates produced prepared by the subject experts. This is the master copy of the connection information. Subsequent sheets in the spreadsheet are derived using formulas from this table. 1-Vertical-data: This is a transformation of the ‘Values connectivity’ sheet so that each source and destination connection is represented as a single row. This also has the connection mechanism codes split into individual columns to allow easier processing in the map generation. This sheet pulls in the spatial information for the arrows on the maps (‘LinkGeom’ attribute) or crosses that represent no connections (‘NoLinkGeom’) using lookup tables from the ‘Arrow-Geom-LUT’ and ‘NoConnection-Geom-LUT’ sheets. 2.Point-extract: This contains all the ‘no connection’ points from the ‘Values connectivity’ dataset. This was saved as working/ GBR_NESP-TWQ-3-3-3_Seascape-connectivity_no-con-pt.csv and used by the QGIS maps to draw all the crosses on the maps. This table is created by copy and pasting (values only) the ‘1-Vertical-data’ sheet when the ‘NoLinkGeom’ attribute is used to filter out all line features, by unchecking blank rows in the ‘NoLinkGeom’ filter. 2.Line-extract: This contains all the ‘connections’ between regions from the ‘Values connectivity’ dataset. This was saved as working/GBR_NESP-TWQ-3-3-3_Seascape-connectivity_arrows.csv and used by the QGIS maps to draw all the arrows on the maps. This table is created by copy and pasting (values only) the ‘1-Vertical-data’ sheet when the ‘LinkGeom’ attribute is used to filter out all point features, by unchecking blank rows in the ‘LinkGeom’ filter. Map-Atlas-Settings: This contains the metadata for each of the maps generated by QGIS. This sheet was exported as working/GBR_NESP-TWQ-3-3-3_Seascape-connectivity_map-atlas-settings.csv and used by QGIS to drive its Atlas feature to generate one map per row of this table. The AttribID is used to enable and disable the appropriate connections on the map being generated. The WKT attribute (Well Known Text) determines the bounding box of the map to be generated and the other attributes are used to display text on the map. map-image-metadata: This table contains metadata descriptions for each of the value attribute maps. This metadata was exported as a CSV and saved into the final generated JPEG maps using the eAtlas Image Metadata Editor Application

The Digital Geologic-GIS Map of the Cogswell Point Quadrangle, Utah is composed of GIS data layers and GIS tables, and is available in the following GRI-supported GIS data formats: 1.) an ESRI file geodatabase (cogp_geology.gdb), and a 2.) Open Geospatial Consortium (OGC) geopackage. The file geodatabase format is supported with a 1.) ArcGIS Pro 3.X map file (.mapx) file (cogp_geology.mapx) and individual Pro 3.X layer (.lyrx) files (for each GIS data layer). Upon request, the GIS data is also available in ESRI shapefile format. Contact Stephanie O'Meara (see contact information below) to acquire the GIS data in these GIS data formats. In addition to the GIS data and supporting GIS files, three additional files comprise a GRI digital geologic-GIS dataset or map: 1.) a readme file (zion_geology_gis_readme.pdf), 2.) the GRI ancillary map information document (.pdf) file (zion_geology.pdf) which contains geologic unit descriptions, as well as other ancillary map information and graphics from the source map(s) used by the GRI in the production of the GRI digital geologic-GIS data for the park, and 3.) a user-friendly FAQ PDF version of the metadata (cogp_geology_metadata_faq.pdf). Please read the zion_geology_gis_readme.pdf for information pertaining to the proper extraction of the GIS data and other map files. QGIS software is available for free at: https://www.qgis.org/en/site/. The data were completed as a component of the Geologic Resources Inventory (GRI) program, a National Park Service (NPS) Inventory and Monitoring (I&M) Division funded program that is administered by the NPS Geologic Resources Division (GRD). For a complete listing of GRI products visit the GRI publications webpage: https://www.nps.gov/subjects/geology/geologic-resources-inventory-products.htm. For more information about the Geologic Resources Inventory Program visit the GRI webpage: https://www.nps.gov/subjects/geology/gri.htm. At the bottom of that webpage is a "Contact Us" link if you need additional information. You may also directly contact the program coordinator, Jason Kenworthy (jason_kenworthy@nps.gov). Source geologic maps and data used to complete this GRI digital dataset were provided by the following: Utah Geological Survey. Detailed information concerning the sources used and their contribution the GRI product are listed in the Source Citation section(s) of this metadata record (cogp_geology_metadata.txt or cogp_geology_metadata_faq.pdf). Users of this data are cautioned about the locational accuracy of features within this dataset. Based on the source map scale of 1:24,000 and United States National Map Accuracy Standards features are within (horizontally) 12.2 meters or 40 feet of their actual _location as presented by this dataset. Users of this data should thus not assume the _location of features is exactly where they are portrayed in ArcGIS Pro, QGIS or other software used to display this dataset. All GIS and ancillary tables were produced as per the NPS GRI Geology-GIS Geodatabase Data Model v. 2.3. (available at: https://www.nps.gov/articles/gri-geodatabase-model.htm).

This resource contains the test data for the GeoServer OGC Web Services tutorials for various GIS applications including ArcGIS Pro, ArcMap, ArcGIS Story Maps, and QGIS. The contents of the data include a polygon shapefile, a polyline shapefile, a point shapefile, and a raster dataset; all of which pertain to the state of Utah, USA. The polygon shapefile is of every county in the state of Utah. The polyline is of every trail in the state of Utah. The point shapefile is the current list of GNIS place names in the state of Utah. The raster dataset covers a region in the center of the state of Utah. All datasets are projected to NAD 1983 Zone 12N.

Example datasets provided for testing the GeoTrace (QGIS) and Compass (CloudCompare) plugins. The first dataset consists of two 10x10 meter orthophoto and DEM tiles from a high-resolution UAV survey of Bingie Bingie point (New South Wales, Australia) containing abundant joint traces as well as several mafic dykes. The GeoTrace plugin for QGIS can be used to extract the joint and contact traces from this dataset.The second dataset comprises a dense-point cloud from a UAV survey of granite pinnacles at Cape Woolamai (Victoria, Australia), and can be used to test/demonstrate the Compass plugin in CloudCompare.

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 is a vector GIS data shapefile that delivers the indexing of vegetated surfaces in Albania by their wildfire spreading capacity index (WSCI). WSCI relies on a multi-criteria approach in assessing wildfire risk, which considers the anthropogenic, climatic, geophysical, and fuel properties of the study area. The data is produced in QGIS software and is automated via processing modeler extension. The data consists of a points layer, where each point is representing the inventory and indexing values for a vegetated surface of 25ha. The data is useful as reference material to studies that focus on natural hazards scenarios in Albania and in the western Balkans.

Overview

3DHD CityScenes is the most comprehensive, large-scale high-definition (HD) map dataset to date, annotated in the three spatial dimensions of globally referenced, high-density LiDAR point clouds collected in urban domains. Our HD map covers 127 km of road sections of the inner city of Hamburg, Germany including 467 km of individual lanes. In total, our map comprises 266,762 individual items.

Our corresponding paper (published at ITSC 2022) is available here.
Further, we have applied 3DHD CityScenes to map deviation detection here.

Moreover, we release code to facilitate the application of our dataset and the reproducibility of our research. Specifically, our 3DHD_DevKit comprises:

• Python tools to read, generate, and visualize the dataset,
• 3DHDNet deep learning pipeline (training, inference, evaluation) for
  map deviation detection and 3D object detection.

The DevKit is available here:

https://github.com/volkswagen/3DHD_devkit.

The dataset and DevKit have been created by Christopher Plachetka as project lead during his PhD period at Volkswagen Group, Germany.

When using our dataset, you are welcome to cite:

@INPROCEEDINGS{9921866,
  author={Plachetka, Christopher and Sertolli, Benjamin and Fricke, Jenny and Klingner, Marvin and 
  Fingscheidt, Tim},
  booktitle={2022 IEEE 25th International Conference on Intelligent Transportation Systems (ITSC)}, 
  title={3DHD CityScenes: High-Definition Maps in High-Density Point Clouds}, 
  year={2022},
  pages={627-634}}

Acknowledgements

We thank the following interns for their exceptional contributions to our work.

• Benjamin Sertolli: Major contributions to our DevKit during his master thesis
• Niels Maier: Measurement campaign for data collection and data preparation

The European large-scale project Hi-Drive (www.Hi-Drive.eu) supports the publication of 3DHD CityScenes and encourages the general publication of information and databases facilitating the development of automated driving technologies.

The Dataset

After downloading, the 3DHD_CityScenes folder provides five subdirectories, which are explained briefly in the following.

1. Dataset

This directory contains the training, validation, and test set definition (train.json, val.json, test.json) used in our publications. Respective files contain samples that define a geolocation and the orientation of the ego vehicle in global coordinates on the map.

During dataset generation (done by our DevKit), samples are used to take crops from the larger point cloud. Also, map elements in reach of a sample are collected. Both modalities can then be used, e.g., as input to a neural network such as our 3DHDNet.

To read any JSON-encoded data provided by 3DHD CityScenes in Python, you can use the following code snipped as an example.

import json

json_path = r"E:\3DHD_CityScenes\Dataset\train.json"
with open(json_path) as jf:
  data = json.load(jf)
print(data)

2. HD_Map

Map items are stored as lists of items in JSON format. In particular, we provide:

• traffic signs,
• traffic lights,
• pole-like objects,
• construction site locations,
• construction site obstacles (point-like such as cones, and line-like such as fences),
• line-shaped markings (solid, dashed, etc.),
• polygon-shaped markings (arrows, stop lines, symbols, etc.),
• lanes (ordinary and temporary),
• relations between elements (only for construction sites, e.g., sign to lane association).

3. HD_Map_MetaData

Our high-density point cloud used as basis for annotating the HD map is split in 648 tiles. This directory contains the geolocation for each tile as polygon on the map. You can view the respective tile definition using QGIS. Alternatively, we also provide respective polygons as lists of UTM coordinates in JSON.

Files with the ending .dbf, .prj, .qpj, .shp, and .shx belong to the tile definition as “shape file” (commonly used in geodesy) that can be viewed using QGIS. The JSON file contains the same information provided in a different format used in our Python API.

4. HD_PointCloud_Tiles

The high-density point cloud tiles are provided in global UTM32N coordinates and are encoded in a proprietary binary format. The first 4 bytes (integer) encode the number of points contained in that file. Subsequently, all point cloud values are provided as arrays. First all x-values, then all y-values, and so on. Specifically, the arrays are encoded as follows.

• x-coordinates: 4 byte integer
• y-coordinates: 4 byte integer
• z-coordinates: 4 byte integer
• intensity of reflected beams: 2 byte unsigned integer
• ground classification flag: 1 byte unsigned integer

After reading, respective values have to be unnormalized. As an example, you can use the following code snipped to read the point cloud data. For visualization, you can use the pptk package, for instance.

import numpy as np
import pptk

file_path = r"E:\3DHD_CityScenes\HD_PointCloud_Tiles\HH_001.bin"
pc_dict = {}
key_list = ['x', 'y', 'z', 'intensity', 'is_ground']
type_list = ['

The Digital Geologic-GIS Map of Tutuila, American Samoa is composed of GIS data layers and GIS tables, and is available in the following GRI-supported GIS data formats: 1.) a 10.1 file geodatabase (tutu_geology.gdb), and a 2.) Open Geospatial Consortium (OGC) geopackage. The file geodatabase format is supported with a 1.) ArcGIS Pro map file (.mapx) file (tutu_geology.mapx) and individual Pro layer (.lyrx) files (for each GIS data layer), as well as with a 2.) 10.1 ArcMap (.mxd) map document (tutu_geology.mxd) and individual 10.1 layer (.lyr) files (for each GIS data layer). Upon request, the GIS data is also available in ESRI 10.1 shapefile format. Contact Stephanie O'Meara (see contact information below) to acquire the GIS data in these GIS data formats. In addition to the GIS data and supporting GIS files, three additional files comprise a GRI digital geologic-GIS dataset or map: 1.) A GIS readme file (npsa_geology_gis_readme.pdf), 2.) the GRI ancillary map information document (.pdf) file (npsa_geology.pdf) which contains geologic unit descriptions, as well as other ancillary map information and graphics from the source map(s) used by the GRI in the production of the GRI digital geologic-GIS data for the park, and 3.) a user-friendly FAQ PDF version of the metadata (tutu_geology_metadata_faq.pdf). Please read the npsa_geology_gis_readme.pdf for information pertaining to the proper extraction of the GIS data and other map files. QGIS software is available for free at: https://www.qgis.org/en/site/. The data were completed as a component of the Geologic Resources Inventory (GRI) program, a National Park Service (NPS) Inventory and Monitoring (I&M) Division funded program that is administered by the NPS Geologic Resources Division (GRD). For a complete listing of GRI products visit the GRI publications webpage: For a complete listing of GRI products visit the GRI publications webpage: https://www.nps.gov/subjects/geology/geologic-resources-inventory-products.htm. For more information about the Geologic Resources Inventory Program visit the GRI webpage: https://www.nps.gov/subjects/geology/gri,htm. At the bottom of that webpage is a "Contact Us" link if you need additional information. You may also directly contact the program coordinator, Jason Kenworthy (jason_kenworthy@nps.gov). Source geologic maps and data used to complete this GRI digital dataset were provided by the following: University of Hawaii, Cartographic Laboratory. Detailed information concerning the sources used and their contribution the GRI product are listed in the Source Citation section(s) of this metadata record (tutu_geology_metadata.txt or tutu_geology_metadata_faq.pdf). Users of this data are cautioned about the locational accuracy of features within this dataset. Based on the source map scale of 1:63,000 and United States National Map Accuracy Standards features are within (horizontally) 32.0 meters or 105 feet of their actual location as presented by this dataset. Users of this data should thus not assume the location of features is exactly where they are portrayed in ArcGIS, QGIS or other software used to display this dataset. All GIS and ancillary tables were produced as per the NPS GRI Geology-GIS Geodatabase Data Model v. 2.3. (available at: https://www.nps.gov/articles/gri-geodatabase-model.htm).

The Digital Geologic-GIS Map of the Brian Head Quadrangle, Utah is composed of GIS data layers and GIS tables, and is available in the following GRI-supported GIS data formats: 1.) a 10.1 file geodatabase (brhe_geology.gdb), a 2.) Open Geospatial Consortium (OGC) geopackage, and 3.) 2.2 KMZ/KML file for use in Google Earth, however, this format version of the map is limited in data layers presented and in access to GRI ancillary table information. The file geodatabase format is supported with a 1.) ArcGIS Pro map file (.mapx) file (brhe_geology.mapx) and individual Pro layer (.lyrx) files (for each GIS data layer), as well as with a 2.) 10.1 ArcMap (.mxd) map document (brhe_geology.mxd) and individual 10.1 layer (.lyr) files (for each GIS data layer). The OGC geopackage is supported with a QGIS project (.qgz) file. Upon request, the GIS data is also available in ESRI 10.1 shapefile format. Contact Stephanie O'Meara (see contact information below) to acquire the GIS data in these GIS data formats. In addition to the GIS data and supporting GIS files, three additional files comprise a GRI digital geologic-GIS dataset or map: 1.) this file (cebr_geology_gis_readme.pdf), 2.) the GRI ancillary map information document (.pdf) file (cebr_geology.pdf) which contains geologic unit descriptions, as well as other ancillary map information and graphics from the source map(s) used by the GRI in the production of the GRI digital geologic-GIS data for the park, and 3.) a user-friendly FAQ PDF version of the metadata (brhe_geology_metadata_faq.pdf). Please read the cebr_geology_gis_readme.pdf for information pertaining to the proper extraction of the GIS data and other map files. Google Earth software is available for free at: https://www.google.com/earth/versions/. QGIS software is available for free at: https://www.qgis.org/en/site/. Users are encouraged to only use the Google Earth data for basic visualization, and to use the GIS data for any type of data analysis or investigation. The data were completed as a component of the Geologic Resources Inventory (GRI) program, a National Park Service (NPS) Inventory and Monitoring (I&M) Division funded program that is administered by the NPS Geologic Resources Division (GRD). For a complete listing of GRI products visit the GRI publications webpage: For a complete listing of GRI products visit the GRI publications webpage: https://www.nps.gov/subjects/geology/geologic-resources-inventory-products.htm. For more information about the Geologic Resources Inventory Program visit the GRI webpage: https://www.nps.gov/subjects/geology/gri,htm. At the bottom of that webpage is a "Contact Us" link if you need additional information. You may also directly contact the program coordinator, Jason Kenworthy (jason_kenworthy@nps.gov). Source geologic maps and data used to complete this GRI digital dataset were provided by the following: Utah Geological Survey. Detailed information concerning the sources used and their contribution the GRI product are listed in the Source Citation section(s) of this metadata record (brhe_geology_metadata.txt or brhe_geology_metadata_faq.pdf). Users of this data are cautioned about the locational accuracy of features within this dataset. Based on the source map scale of 1:24,000 and United States National Map Accuracy Standards features are within (horizontally) 12.2 meters or 40 feet of their actual location as presented by this dataset. Users of this data should thus not assume the location of features is exactly where they are portrayed in Google Earth, ArcGIS, QGIS or other software used to display this dataset. All GIS and ancillary tables were produced as per the NPS GRI Geology-GIS Geodatabase Data Model v. 2.3. (available at: https://www.nps.gov/articles/gri-geodatabase-model.htm).

The Digital Geologic-GIS Map of National Park American Samoa, American Samoa is composed of GIS data layers and GIS tables, and is available in the following GRI-supported GIS data formats: 1.) a 10.1 file geodatabase (npsa_geology.gdb), a 2.) Open Geospatial Consortium (OGC) geopackage, and 3.) 2.2 KMZ/KML file for use in Google Earth, however, this format version of the map is limited in data layers presented and in access to GRI ancillary table information. The file geodatabase format is supported with a 1.) ArcGIS Pro map file (.mapx) file (npsa_geology.mapx) and individual Pro layer (.lyrx) files (for each GIS data layer), as well as with a 2.) 10.1 ArcMap (.mxd) map document (npsa_geology.mxd) and individual 10.1 layer (.lyr) files (for each GIS data layer). The OGC geopackage is supported with a QGIS project (.qgz) file. Upon request, the GIS data is also available in ESRI 10.1 shapefile format. Contact Stephanie O'Meara (see contact information below) to acquire the GIS data in these GIS data formats. In addition to the GIS data and supporting GIS files, three additional files comprise a GRI digital geologic-GIS dataset or map: 1.) A GIS readme file (npsa_geology_gis_readme.pdf), 2.) the GRI ancillary map information document (.pdf) file (npsa_geology.pdf) which contains geologic unit descriptions, as well as other ancillary map information and graphics from the source map(s) used by the GRI in the production of the GRI digital geologic-GIS data for the park, and 3.) a user-friendly FAQ PDF version of the metadata (npsa_geology_metadata_faq.pdf). Please read the npsa_geology_gis_readme.pdf for information pertaining to the proper extraction of the GIS data and other map files. Google Earth software is available for free at: https://www.google.com/earth/versions/. QGIS software is available for free at: https://www.qgis.org/en/site/. Users are encouraged to only use the Google Earth data for basic visualization, and to use the GIS data for any type of data analysis or investigation. The data were completed as a component of the Geologic Resources Inventory (GRI) program, a National Park Service (NPS) Inventory and Monitoring (I&M) Division funded program that is administered by the NPS Geologic Resources Division (GRD). For a complete listing of GRI products visit the GRI publications webpage: For a complete listing of GRI products visit the GRI publications webpage: https://www.nps.gov/subjects/geology/geologic-resources-inventory-products.htm. For more information about the Geologic Resources Inventory Program visit the GRI webpage: https://www.nps.gov/subjects/geology/gri,htm. At the bottom of that webpage is a "Contact Us" link if you need additional information. You may also directly contact the program coordinator, Jason Kenworthy (jason_kenworthy@nps.gov). Source geologic maps and data used to complete this GRI digital dataset were provided by the following: University of Hawaii, Cartographic Laboratory. Detailed information concerning the sources used and their contribution the GRI product are listed in the Source Citation section(s) of this metadata record (npsa_geology_metadata.txt or npsa_geology_metadata_faq.pdf). Users of this data are cautioned about the locational accuracy of features within this dataset. Based on the source map scales of 1:56,000 (Ofu/Olosega and Tau maps) or 1:63,000 (Tutuila map) and United States National Map Accuracy Standards features are within 28.45 meters or 93.33 feet (1:56,000 scale maps) or 32.0 meters or 105 feet (1:63,000 scale maps) of their actual location as presented by this dataset. Users of this data should thus not assume the location of features is exactly where they are portrayed in Google Earth, ArcGIS, QGIS or other software used to display this dataset. All GIS and ancillary tables were produced as per the NPS GRI Geology-GIS Geodatabase Data Model v. 2.3. (available at: https://www.nps.gov/articles/gri-geodatabase-model.htm).

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.

This dataset visualises the spatial distribution of the rental value in Amsterdam between 1647 and 1652. The source of rental value comes from the Verponding registration in Amsterdam. The verponding or the ‘Verpondings-quohieren van den 8sten penning’ was a tax in the Netherlands on the 8th penny of the rental value of immovable property that had to be paid annually. In Amsterdam, the citywide verponding registration started in 1647 and continued into the early 19th century. With the introduction of the cadastre system in 1810, the verponding came to an end.

The original tax registration is kept in the Amsterdam City Archives (Archief nr. 5044) and the four registration books transcribed in this dataset are Archief 5044, inventory 255, 273, 281, 284. The verponding was collected by districts (wijken). The tax collectors documented their collecting route by writing down the street or street-section names as they proceed. For each property, the collector wrote down the names of the owner and, if applicable, the renter (after ‘per’), and the estimated rental value of the property (in guilders). Next to the rental value was the tax charged (in guilders and stuivers). Below the owner/renter names and rental value were the records of tax payments by year.

This dataset digitises four registration books of the verponding between 1647 and 1652 in two ways. First, it transcribes the rental value of all real estate properties listed in the registrations. The names of the owners/renters are transcribed only selectively, focusing on the properties that exceeded an annual rental value of 300 guilders. These transcriptions can be found in Verponding1647-1652.csv. For a detailed introduction to the data, see Verponding1647-1652_data_introduction.txt.

Second, it geo-references the registrations based on the street names and the reconstruction of tax collectors’ travel routes in the verponding. The tax records are then plotted on the historical map of Amsterdam using the first cadaster of 1832 as a reference. Since the geo-reference is based on the street or street sections, the location of each record/house may not be the exact location but rather a close proximation of the possible locations based on the street names and the sequence of the records on the same street or street section. Therefore, this geo-referenced verponding can be used to visualise the rental value distribution in Amsterdam between 1647 and 1652. The preview below shows an extrapolation of rental values in Amsterdam. And for the geo-referenced GIS files, see Verponding_wijken.shp.

GIS specifications:

Coordination Reference System (CRS): Amersfoort/RD New (ESPG:28992)

Historical map tiles URL (From Amsterdam Time Machine)

NB: This verponding dataset is a provisional version. The georeferenced points and the name transcriptions might contain errors and need to be treated with caution.

Contributors

Historical and archival research: Weixuan Li, Bart Reuvekamp

Plotting of geo-referenced points: Bart Reuvekamp

Spatial analysis: Weixuan Li

Mapping software: QGIS

Acknowledgements: Virtual Interiors project, Daan de Groot

Contenu Carte de chaque département extrait d'Open Street Map, mise à jour chaque semaine. NB : Les régions sont également disponibles. Chaque département est livré sous forme d'une archive ZIP qui contient plusieurs couches cartographiques au fomat shapefile (le .doc de la cartographie) : places.shp : noms des villes ou des quartiers roads.shp : toutes les voies de passage de l'autoroute au chemin piéton buildings.shp : l'espace bâti raillways.shp : les voies ferrées waterways.shp :le réseau hydrolique points.shp : une liste de point d’intérêt natural.shp : zones vertes landuse.shp : occupation des sol admin-departement.shp : le département Par ailleurs, un fichier projet QGis très sommaire est fourni dans l'archive, afin de visualiser la superposition des couches dans un outil libre. Origine Les données proviennent de la base de données cartographique communautaire et libre OpenStreetMap. Le découpage par département provient du Contours des départements français issus d'OpenStreetMap. Les shapefile sont extraits selon la méthode exposée par l'excellent article de Maxime Résibois sur PortailSIG : http://www.portailsig.org/content/recuperer-des-donnees-openstreetmap-gdalogr Les sources du traitement automatique d'extraction sont disponibles sur github. Elles s'appuyent sur tuttle, un système de build pour les données. Licence Ces données sont issues du crowdsourcing effectué par les contributeurs au projet OpenStreetMap et sont sous licence ODbL qui impose un partage à l'identique et la mention obligatoire d'attribution doit être "© les contributeurs d'OpenStreetMap sous licence ODbL" conformément à http://osm.org/copyright Historique des modifications 7 avril 2018 correction d'un bug qui pouvait retirer une partie de la donnée sur les départements côtiers mise à jour du fichier QGis pour que la carte soit plus jolie de près Départements et covid Si votre département est soumis au pass sanitaire, commandez le vôtre au format carte bancaire sur carte-sanitaire.fr

The GIS database contains the data of aufeis (naleds) in the Indigirka River basin (Russia) from historical and nowadays sources, and complete ArcGIS 10.1/10.2 and Qgis 3* projects to view and analyze the data. All data and projects have WGS 1984 coordinate system (without projection). ArcGIS and Qgis projects contain two layers, such as Aufeis_kadastr (historical aufeis data collection, point objects) and Aufeis_Landsat (satellite-derived aufeis data collection, polygon objects). Historical data collection is created based on the Cadastre of aufeis (naleds) of the North-East of the USSR (1958). Each aufeis was digitized as point feature by the inventory map (scale 1:2 000 000), or by topographic maps. Attributive data was obtained from the Cadastre of aufeis. According to the historical data, there were 896 aufeis with a total area 2063.6 km² within the studied basin. Present-day aufeis dataset was created by Landsat-8 OLI images for the period 2013-2017. Each aufeis was delineated by satellite images as polygon. Cloud-free Landsat images are obtained immediately after snowmelt season (e.g. between May, 15 and June, 18), to detect the highest possible number of aufeis. Critical values of Normalized Difference Snow Index (NDSI) were used for semi-automated aufeis detection. However, a detailed expert-based verification was performed after automated procedure, to distinguish snow-covered areas from aufeis and cross-reference historical and satellite-based data collections. According to Landsat data, the number of aufeis reaches 1213, with their total area about 1287 km². The difference between the Cadastre (1958) and the satellite-derived data may indicate significant changes of aufeis formation environments.

The GIS database contains the data of aufeis (naleds) in the Kolyma River basin (Russia) from historical and nowadays sources, and complete ArcGIS 10.1/10.2 and Qgis 3* projects to view and analyze the data. All data and projects have WGS 1984 coordinate system (without projection). ArcGIS and Qgis projects contain two layers, such as Aufeis_kadastr (historical aufeis data collection, point objects) and Aufeis_Landsat (satellite-derived aufeis data collection, polygon objects). Historical data collection is created based on the Cadastre of aufeis (naled) of the North-East of the USSR (1958). Each aufeis was digitized as point feature by the inventory map (scale 1:2 000 000), or by topographic maps. Attributive data was obtained from the Cadastre of aufeis. According to the historical data, there were 1755 aufeis with a total area 1945.2 km² within the studied basin. Present-day aufeis dataset was created by Landsat-8 OLI images for the period 2013-2019. Each aufeis was delineated by satellite images as polygon. Cloud-free Landsat images are obtained immediately after snowmelt season (e.g. between May, 17 and June, 16), to detect the highest possible number of aufeis. Critical values of Normalized Difference Snow Index (NDSI) were used for semi-automated aufeis detection. However, a detailed expert-based verification was performed after automated procedure, to distinguish snow-covered areas from aufeis and cross-reference historical and satellite-based data collections. According to Landsat data, the number of aufeis reaches 2216, with their total area about 879.7 km². The difference between the Cadastre (1958) and the satellite-derived data may indicate significant changes of aufeis formation environments.

OpenStreetMap (OSM) is a free, editable map & spatial database of the whole world. This dataset is an extract of OpenStreetMap data for 21 Pacific Island Countries, in a GIS-friendly format. The OSM data has been split into separate layers based on themes (buildings, roads, points of interest, etc), and it comes bundled with a QGIS project and styles, to help you get started with using the data in your maps. This OSM product will be updated weekly and contains data for Cook Islands, Federated States of Micronesia, Fiji, Kiribati, Republic of the Marshall Islands, Nauru, Niue, Palau, Papua New Guinea, Samoa, Solomon Islands, Tonga, Tuvalu, Vanuatu, Guam, Northern Mariana Islands, French Polynesia, Wallis and Futuna, Tokelau, American Samoa as well as data on the Pacific region. The goal is to increase awareness among Pacific GIS users of the richness of OpenStreetMap data in Pacific countries, as well as the gaps, so that they can take advantage of this free resource, become interested in contributing to OSM, and perhaps join the global OSM community.

Data acquisitionOccurrence data for bee species were downloaded from ALA60 using ALA4R version 1.8.064 in R version 3.6.265.Floral visitation data were obtained from ALA60, Museums Victoria, the Western Australian Museum66,67, and publications (Tables S1 and S2). Floral visitation records were checked for errors and synonymies using the Australian Plant Name Index68. Life-history traits for bee species were sourced, in most cases, from the most recent taxonomic descriptions, or other publications (Tables S1 and S2). A one-hectare resolution Major Vegetation Subgroup (MVS) map was sourced from Geoscience Australia’s National Mapping Division (NMD)61. Fire frequency data from 1988 to 2016 were downloaded from the Department of Environment and Energy (DEE)69, 2019–20 wildfire occurrence data (National Indicative Aggregated Fire Extent Dataset — NIAFED — version 20200623) were sourced from the Department of Agriculture, Water and the Environment (DAWE)36, and 2019–20 wildfire intensity data (Google Earth Engine Burnt Area Map — GEEBAM) were sourced from the Department of Planning, Industry and Environment (DPIE)62. All raster data sources were matched in resolution to the one-hectare MVS map. These GIS data sources may vary in spatial uncertainty or resolution and their caveats can be found at their respective locations online.Data filtering and analysesOccurrence data from ALA were filtered to include only reliable (“preserved specimens”, “machine observations” — e.g., malaise traps, — and data from published datasets) and “present” (compared to “absent”) records. Records without geographic locations or that did not align with base maps were excluded from GIS analyses. Species were then filtered for minimum sample size (n = 30) and minimum number of unique localities (n = 5). However, if there were 15 or more unique localities and a sample size of less than 30, the species was included.The MVS map was reprojected to a world geodetic system (WGS 1984, EPSG:4326) and clipped to the 2019–20 wildfire map in QGIS version 3.1270. The NIAFED and GEEBAM maps were aligned and matched to the resolution of the MVS map using the package raster version 3.0-1271 in R version 3.6.265. Major vegetation subgroups61, 2019–20 wildfire status36, and fire frequency69 were extracted for each ALA record using raster. The proportion of each MVS burnt was calculated by clipping MVS maps with the 2019–20 burn map in ArcMap Version 10.6.172. All map files used in our analyses are available at (html location to be confirmed upon acceptance) for use with our R script.We complemented species distributional data (ALA60 point data) with spatial information on their associated habitat (MVS61), to avoid reliance on the limited data for some species. To determine the potential distribution of each species we buffered the latitudinal and longitudinal extents of the raster datasets (MVS, fire frequency, NIAFED, and GEEBAM) by 20% in each direction. For geographically-restricted species with latitudinal or longitudinal ranges less than one degree (~111 km), we buffered their extent by one degree in each direction along that axis or axes. These values were chosen as conservative estimates of species distributional extents, but we recognize that this treatment may over-inflate the distribution of some species with highly-localized ranges. These data are broken into four files:Map_data — hosts all of the map files used in the analysesBee-plant_point_data — hosts the ALA download data, combined bee dataset, and the life history and plant data spreadsheetWard_comparison_data — hosts some of the data used for the Ward co-analysis using our methodAll_other_R_data — hosts many of the runfiles from our main analysis

Please note this dataset is the most recent version of the Administrative Boundaries (AB). For previous versions of the AB please go to this url: https://data.gov.au/dataset/ds-dga-b4ad5702-ea2b-4f04-833c-d0229bfd689e/details?q=previous

Geoscape Administrative Boundaries is Australia’s most comprehensive national collection of boundaries, including government, statistical and electoral boundaries. It is built and maintained by Geoscape Australia using authoritative government data. Further information about contributors to Administrative Boundaries is available here.

This dataset comprises seven Geoscape products:

• Localities
• Local Government Areas (LGAs)
• Wards
• Australian Bureau of Statistics (ABS) Boundaries
• Electoral Boundaries
• State Boundaries and
• Town Points

Updated versions of Administrative Boundaries are published on a quarterly basis.

Users have the option to download datasets with feature coordinates referencing either GDA94 or GDA2020 datums.

Notable changes in the May 2025 release

• Victorian Wards have seen almost half of the dataset change now reflecting the boundaries from the 2024 subdivision review. https://www.vec.vic.gov.au/electoral-boundaries/council-reviews/ subdivision-reviews.

  • There have been spatial changes (area) greater than 1 km2 to 66 wards in Victoria.

• One new locality ‘Kenwick Island’ has been added to the local Government area ‘Mackay Regional’ in Queensland.

  • There have been spatial changes(area) greater than 1 km2 to the local government areas 'Burke Shire' and 'Mount Isa City' in Queensland.

• There have been spatial changes(area) greater than 1 km2 to the localities ‘Nicholson’, ‘Lawn Hill’ and ‘Coral Sea’ in Queensland and ‘Calguna’, ‘Israelite Bay’ and ‘Balladonia’ in Western Australia.

• An update to the NT Commonwealth Electoral Boundaries has been applied to reflect the redistribution of the boundaries gazetted on 4 March 2025.

• Geoscape has become aware that the DATE_CREATED and DATE_RETIRED attributes in the commonwealth_electoral_polygon MapInfo TAB tables were incorrectly ordered and did not match the product data model. These attributes have been re-ordered to match the data model for the May 2025 release.

IMPORTANT NOTE: correction of issues with the 22 November 2022 release

• On 28 November 2022, the Administrative Boundaries dataset originally released on 22 November 2022 was amended and re-uploaded after Geoscape identified some issues with the original data for 'Electoral Boundaries'.
• As a result of the error, some shapefiles were published in 3D rather than 2D, which may affect some users when importing data into GIS applications.
• The error affected the Electoral Boundaries dataset, specifically the Commonwealth boundary data for Victoria and Western Australia, including 'All States'.
• Only the ESRI Shapefile formats were affected (both GDA94 and GDA2020). The MapInfo TAB format was not affected.
• Because the datasets are zipped into a single file, once the error was fixed by Geoscape all of Administrative Boundaries shapefiles had to be re-uploaded, rather than only the affected files.
• If you downloaded either of the two Administrative Boundary ESRI Shapefiles between 22 November and 28 November 2022 and plan to use the Electoral Boundary component, you are advised to download the revised version dated 28 November 2022. Apologies for any inconvenience.

Further information on Administrative Boundaries, including FAQs on the data, is available here or through Geoscape Australia’s network of partners. They provide a range of commercial products based on Administrative Boundaries, including software solutions, consultancy and support.

Note: On 1 October 2020, PSMA Australia Limited began trading as Geoscape Australia.

The Australian Government has negotiated the release of Administrative Boundaries to the whole economy under an open CCBY 4.0 licence.

Users must only use the data in ways that are consistent with the Australian Privacy Principles issued under the Privacy Act 1988 (Cth).

Users must also note the following attribution requirements:

Preferred attribution for the Licensed Material:

Administrative Boundaries © Geoscape Australia licensed by the Commonwealth of Australia under Creative Commons Attribution 4.0 International license (CC BY 4.0).

Preferred attribution for Adapted Material:

Incorporates or developed using Administrative Boundaries © Geoscape Australia licensed by the Commonwealth of Australia under Creative Commons Attribution 4.0 International licence (CC BY 4.0).

What to Expect When You Download Administrative Boundaries

Administrative Boundaries is large dataset (around 1.5GB unpacked), made up of seven themes each containing multiple layers.

Users are advised to read the technical documentation including the product change notices and the individual product descriptions before downloading and using the product.

Please note this dataset is the most recent version of the Administrative Boundaries (AB). For previous versions of the AB please go to this url: https://data.gov.au/dataset/ds-dga-b4ad5702-ea2b-4f04-833c-d0229bfd689e/details?q=previous

License Information