USGS is assessing the feasibility of map projections and grid systems for lunar surface operations. We propose developing a new Lunar Transverse Mercator (LTM), the Lunar Polar Stereographic (LPS), and the Lunar Grid Reference Systems (LGRS). We have also designed additional grids designed to NASA requirements for astronaut navigation, referred to as LGRS in Artemis Condensed Coordinates (ACC), but this is not released here. LTM, LPS, and LGRS are similar in design and use to the Universal Transverse Mercator (UTM), Universal Polar Stereographic (LPS), and Military Grid Reference System (MGRS), but adhere to NASA requirements. LGRS ACC format is similar in design and structure to historic Army Mapping Service Apollo orthotopophoto charts for navigation. The Lunar Transverse Mercator (LTM) projection system is a globalized set of lunar map projections that divides the Moon into zones to provide a uniform coordinate system for accurate spatial representation. It uses a transverse Mercator projection, which maps the Moon into 45 transverse Mercator strips, each 8°, longitude, wide. These transverse Mercator strips are subdivided at the lunar equator for a total of 90 zones. Forty-five in the northern hemisphere and forty-five in the south. LTM specifies a topocentric, rectangular, coordinate system (easting and northing coordinates) for spatial referencing. This projection is commonly used in GIS and surveying for its ability to represent large areas with high positional accuracy while maintaining consistent scale. The Lunar Polar Stereographic (LPS) projection system contains projection specifications for the Moon’s polar regions. It uses a polar stereographic projection, which maps the polar regions onto an azimuthal plane. The LPS system contains 2 zones, each zone is located at the northern and southern poles and is referred to as the LPS northern or LPS southern zone. LPS, like is equatorial counterpart LTM, specifies a topocentric, rectangular, coordinate system (easting and northing coordinates) for spatial referencing. This projection is commonly used in GIS and surveying for its ability to represent large polar areas with high positional accuracy, while maintaining consistent scale across the map region. LGRS is a globalized grid system for lunar navigation supported by the LTM and LPS projections. LGRS provides an alphanumeric grid coordinate structure for both the LTM and LPS systems. This labeling structure is utilized in a similar manner to MGRS. LGRS defines a global area grid based on latitude and longitude and a 25×25 km grid based on LTM and LPS coordinate values. Two implementations of LGRS are used as polar areas require a LPS projection and equatorial areas a transverse Mercator. We describe the difference in the techniques and methods report associated with this data release. Request McClernan et. al. (in-press) for more information. ACC is a method of simplifying LGRS coordinates and is similar in use to the Army Mapping Service Apollo orthotopophoto charts for navigation. These data will be released at a later date. Two versions of the shape files are provided in this data release, PCRS and Display only. See LTM_LPS_LGRS_Shapefiles.zip file. PCRS are limited to a single zone and are projected in either LTM or LPS with topocentric coordinates formatted in Eastings and Northings. Display only shapefiles are formatted in lunar planetocentric latitude and longitude, a Mercator or Equirectangular projection is best for these grids. A description of each grid is provided below: Equatorial (Display Only) Grids: Lunar Transverse Mercator (LTM) Grids: LTM zone borders for each LTM zone Merged LTM zone borders Lunar Polar Stereographic (LPS) Grids: North LPS zone border South LPS zone border Lunar Grid Reference System (LGRS) Grids: Global Areas for North and South LPS zones Merged Global Areas (8°×8° and 8°×10° extended area) for all LTM zones Merged 25km grid for all LTM zones PCRS Shapefiles:` Lunar Transverse Mercator (LTM) Grids: LTM zone borders for each LTM zone Lunar Polar Stereographic (LPS) Grids: North LPS zone border South LPS zone border Lunar Grid Reference System (LGRS) Grids: Global Areas for North and South LPS zones 25km Gird for North and South LPS zones Global Areas (8°×8° and 8°×10° extended area) for each LTM zone 25km grid for each LTM zone The rasters in this data release detail the linear distortions associated with the LTM and LPS system projections. For these products, we utilize the same definitions of distortion as the U.S. State Plane Coordinate System. Scale Factor, k - The scale factor is a ratio that communicates the difference in distances when measured on a map and the distance reported on the reference surface. Symbolically this is the ratio between the maps grid distance and distance on the lunar reference sphere. This value can be precisely calculated and is provided in their defining publication. See Snyder (1987) for derivation of the LPS scale factor. This scale factor is unitless and typically increases from the central scale factor k_0, a projection-defining parameter. For each LPS projection. Request McClernan et. al., (in-press) for more information. Scale Error, (k-1) - Scale-Error, is simply the scale factor differenced from 1. Is a unitless positive or negative value from 0 that is used to express the scale factor’s impact on position values on a map. Distance on the reference surface are expended when (k-1) is positive and contracted when (k-1) is negative. Height Factor, h_F - The Height Factor is used to correct for the difference in distance caused between the lunar surface curvature expressed at different elevations. It is expressed as a ratio between the radius of the lunar reference sphere and elevations measured from the center of the reference sphere. For this work, we utilized a radial distance of 1,737,400 m as recommended by the IAU working group of Rotational Elements (Archinal et. al., 2008). For this calculation, height factor values were derived from a LOLA DEM 118 m v1, Digital Elevation Model (LOLA Science Team, 2021). Combined Factor, C_F – The combined factor is utilized to “Scale-To-Ground” and is used to adjust the distance expressed on the map surface and convert to the position on the actual ground surface. This value is the product of the map scale factor and the height factor, ensuring the positioning measurements can be correctly placed on a map and on the ground. The combined factor is similar to linear distortion in that it is evaluated at the ground, but, as discussed in the next section, differs numerically. Often C_F is scrutinized for map projection optimization. Linear distortion, δ - In keeping with the design definitions of SPCS2022 (Dennis 2023), we refer to scale error when discussing the lunar reference sphere and linear distortion, δ, when discussing the topographic surface. Linear distortion is calculated using C_F simply by subtracting 1. Distances are expended on the topographic surface when δ is positive and compressed when δ is negative. The relevant files associated with the expressed LTM distortion are as follows. The scale factor for the 90 LTM projections: LUNAR_LTM_GLOBAL_PLOT_HEMISPHERES_distortion_K_grid_scale_factor.tif Height Factor for the LTM portion of the Moon: LUNAR_LTM_GLOBAL_PLOT_HEMISPHERES_distortion_EF_elevation_factor.tif Combined Factor in LTM portion of the Moon LUNAR_LTM_GLOBAL_PLOT_HEMISPHERES_distortion_CF_combined_factor.tif The relevant files associated with the expressed LPS distortion are as follows. Lunar North Pole The scale factor for the northern LPS zone: LUNAR_LGRS_NP_PLOT_LPS_K_grid_scale_factor.tif Height Factor for the north pole of the Moon: LUNAR_LGRS_NP_PLOT_LPS_EF_elevation_factor.tif Combined Factor for northern LPS zone: LUNAR_LGRS_NP_PLOT_LPS_CF_combined_factor.tif Lunar South Pole Scale factor for the northern LPS zone: LUNAR_LGRS_SP_PLOT_LPS_K_grid_scale_factor.tif Height Factor for the south pole of the Moon: LUNAR_LGRS_SP_PLOT_LPS_EF_elevation_factor.tif Combined Factor for northern LPS zone: LUNAR_LGRS_SP_PLOT_LPS_CF_combined_factor.tif For GIS utilization of grid shapefiles projected in Lunar Latitude and Longitude, referred to as “Display Only”, please utilize a registered lunar geographic coordinate system (GCS) such as IAU_2015:30100 or ESRI:104903. LTM, LPS, and LGRS PCRS shapefiles utilize either a custom transverse Mercator or polar Stereographic projection. For PCRS grids the LTM and LPS projections are recommended for all LTM, LPS, and LGRS grid sizes. See McClernan et. al. (in-press) for such projections. Raster data was calculated using planetocentric latitude and longitude. A LTM and LPS projection or a registered lunar GCS may be utilized to display this data. Note: All data, shapefiles and rasters, require a specific projection and datum. The projection is recommended as LTM and LPS or, when needed, IAU_2015:30100 or ESRI:104903. The datum utilized must be the Jet Propulsion Laboratory (JPL) Development Ephemeris (DE) 421 in the Mean Earth (ME) Principal Axis Orientation as recommended by the International Astronomy Union (IAU) (Archinal et. al., 2008).

The test data set can be used to test high accuracy coordinate transformation (for compiled GIS data) and coordinate conversion in and around Victoria in relation to the Geocentric Datum of Australia. The test data can be used to compare outputs from software that: · Claims to use the official Intergovernmental Committee on Survey and Mapping (ICSM) high accuracy combined 7 parameter/distortion model transformation process and incorporating or derived from file data contained in called National 66 (13.09.01).gsb (refer to (http://www.anzlic.org.au/icsm/gdatm/) which is provided in the National Transformation Version 2 (NTv2) grid file format. · Claims to perform conversions between coordinate types relating to the Australian Geodetic Datum and Geocentric Datum of Australia including: - Geographicals: Latitude and Longitude coordinates (ie AGD66 and GDA94), - Universal Transverse Mercator (UTM) grid coordinates (ie Australian Map Grid 1966 (AMG66) and Map Grid of Australia 1994 (MGA94)) and - Custom Lambert conformal conic projection coordinates relating to the Land Victoria Vicgrid66 and Vicgrid94 projection specifications as they apply to Victoria (refer to www.giconnections.vic.gov.au)

LEOWEB 11 is a tool to convert geographic coordinates to PLSS legal land descriptions. The project is hosted at the Kansas Geological Survey and has been funded by Kansas GIS Policy Board and the Kansas Geological Survey. It is not a surveying tool and only provides an approximate conversion. The application runs via contemporary web browsers with server side interaction thru the Oracle APEX 4.0 environment.

The Geoprocessing tool embeds the Web-based Transformation Tool released by Lands Department of HKSAR in ArcGIS and provides an instant extraction of height information of Hong Kong Principal Datum from various coordinate systems/datums. The Transformation Tool from Lands Department uses the conversion methods, parameters and formulas listed in the "Explanatory Notes on Geodetic Datums in Hong Kong" (PDF) and the "Datum Transformation and Transformation Parameters" (The "7-parameters") (PDF) as well as the Geoid Model established by the Hong Kong Polytechnic University. Please refer to this guidelines for using this geoprocessing tool in ArcGIS Pro.(Note: This tool is only applicable in ArcGIS Pro, and for coordinates within Hong Kong territories.)

The GIS-Grid serves the coordinate transformation between the national Austrian system of national surveying MGI (also known as the use system) and the European global reference system ETRS89. It is based on the grid-based transformation method NTv2 (National Transformation version 2) developed and defined in Canada, whose format and method has now become a standard in the GIS field. For Austria it was developed between the latitudes 46° 21′ and 49° 03′ and the geographical longitudes 9° 30′ and 17° 09′ 45 Ω in a regular grid of 30“x45” (equivalent to about 1 km x 1 km). Each grid element contains parameter values in the components East-West and North-South. The transformation of height is not defined in the GIS grid.

This dataset comes from the Department of Licensing and Regulatory Affairs' Office of Land Survey and Remonumentation (OLSR). See Act 345 of 1990: State Survey and Remonumentation Act for more information.The system of record was queried for approved locations where grid coordinates were provided. Records with coordinates outside the state's geographical boundary were retained (34 locations). The columns "DMS LAT" and "DMS LONG" were added to the extraction table and populated with data from fields "Latitude N" and "Longitude W" and formatted to DMS2. The data was exported as feature class using geoprocessing tool "Convert Coordinate Notation," geographic coordinate system WGS 1984 Web Mercator (auxiliary sphere).This dataset was last updated June 6, 2022, with quarterly updates to begin in 2023.More Metadata

This resource provides a Jupyter notebook demonstrating how to use GeoPandas and Shapely in Python to extract bounding box information from a shapefile or GeoJSON file. It ensures that the returned values are in a specified projection system, regardless of whether the original file uses a geographic or projected coordinate system. Users can adjust the parameters in the notebook to fit their specific use case. In this example, the parameters are based on the Kings River Watershed in California, with the target projection system being Lambert Conformal Conic, as used in National Water Model versions 1-3.

This Python script (Shape2DJI_Pilot_KML.py) will scan a directory, find all the ESRI shapefiles (.shp), reproject to EPSG 4326 (geographic coordinate system WGS84 ellipsoid), create an output directory and make a new Keyhole Markup Language (.kml) file for every line or polygon found in the files. These new *.kml files are compatible with DJI Pilot 2 on the Smart Controller (e.g., for M300 RTK). The *.kml files created directly by ArcGIS or QGIS are not currently compatible with DJI Pilot.

Update information can be found within the layer’s attributes and in a table on the Utah Parcel Data webpage under LIR Parcels.In Spring of 2016, the Land Information Records work group, an informal committee organized by the Governor’s Office of Management and Budget’s State Planning Coordinator, produced recommendations for expanding the sharing of GIS-based parcel information. Participants in the LIR work group included representatives from county, regional, and state government, including the Utah Association of Counties (County Assessors and County Recorders), Wasatch Front Regional Council, Mountainland and Bear River AOGs, Utah League of Cities and Towns, UDOT, DNR, AGRC, the Division of Emergency Management, Blue Stakes, economic developers, and academic researchers. The LIR work group’s recommendations set the stage for voluntary sharing of additional objective/quantitative parcel GIS data, primarily around tax assessment-related information. Specifically the recommendations document establishes objectives, principles (including the role of local and state government), data content items, expected users, and a general process for data aggregation and publishing. An important realization made by the group was that ‘parcel data’ or ‘parcel record’ products have a different meaning to different users and data stewards. The LIR group focused, specifically, on defining a data sharing recommendation around a tax year parcel GIS data product, aligned with the finalization of the property tax roll by County Assessors on May 22nd of each year. The LIR recommendations do not impact the periodic sharing of basic parcel GIS data (boundary, ID, address) from the County Recorders to AGRC per 63F-1-506 (3.b.vi). Both the tax year parcel and the basic parcel GIS layers are designed for general purpose uses, and are not substitutes for researching and obtaining the most current, legal land records information on file in County records. This document, below, proposes a schedule, guidelines, and process for assembling county parcel and assessment data into an annual, statewide tax parcel GIS layer. gis.utah.gov/data/sgid-cadastre/It is hoped that this new expanded parcel GIS layer will be put to immediate use supporting the best possible outcomes in public safety, economic development, transportation, planning, and the provision of public services. Another aim of the work group was to improve the usability of the data, through development of content guidelines and consistent metadata documentation, and the efficiency with which the data sharing is distributed.GIS Layer Boundary Geometry:GIS Format Data Files: Ideally, Tax Year Parcel data should be provided in a shapefile (please include the .shp, .shx, .dbf, .prj, and .xml component files) or file geodatabase format. An empty shapefile and file geodatabase schema are available for download at:At the request of a county, AGRC will provide technical assistance to counties to extract, transform, and load parcel and assessment information into the GIS layer format.Geographic Coverage: Tax year parcel polygons should cover the area of each county for which assessment information is created and digital parcels are available. Full coverage may not be available yet for each county. The county may provide parcels that have been adjusted to remove gaps and overlaps for administrative tax purposes or parcels that retain these expected discrepancies that take their source from the legally described boundary or the process of digital conversion. The diversity of topological approaches will be noted in the metadata.One Tax Parcel Record Per Unique Tax Notice: Some counties produce an annual tax year parcel GIS layer with one parcel polygon per tax notice. In some cases, adjacent parcel polygons that compose a single taxed property must be merged into a single polygon. This is the goal for the statewide layer but may not be possible in all counties. AGRC will provide technical support to counties, where needed, to merge GIS parcel boundaries into the best format to match with the annual assessment information.Standard Coordinate System: Parcels will be loaded into Utah’s statewide coordinate system, Universal Transverse Mercator coordinates (NAD83, Zone 12 North). However, boundaries stored in other industry standard coordinate systems will be accepted if they are both defined within the data file(s) and documented in the metadata (see below).Descriptive Attributes:Database Field/Column Definitions: The table below indicates the field names and definitions for attributes requested for each Tax Parcel Polygon record.FIELD NAME FIELD TYPE LENGTH DESCRIPTION EXAMPLE SHAPE (expected) Geometry n/a The boundary of an individual parcel or merged parcels that corresponds with a single county tax notice ex. polygon boundary in UTM NAD83 Zone 12 N or other industry standard coordinates including state plane systemsCOUNTY_NAME Text 20 - County name including spaces ex. BOX ELDERCOUNTY_ID (expected) Text 2 - County ID Number ex. Beaver = 1, Box Elder = 2, Cache = 3,..., Weber = 29ASSESSOR_SRC (expected) Text 100 - Website URL, will be to County Assessor in most all cases ex. webercounty.org/assessorBOUNDARY_SRC (expected) Text 100 - Website URL, will be to County Recorder in most all cases ex. webercounty.org/recorderDISCLAIMER (added by State) Text 50 - Disclaimer URL ex. gis.utah.gov...CURRENT_ASOF (expected) Date - Parcels current as of date ex. 01/01/2016PARCEL_ID (expected) Text 50 - County designated Unique ID number for individual parcels ex. 15034520070000PARCEL_ADD (expected, where available) Text 100 - Parcel’s street address location. Usually the address at recordation ex. 810 S 900 E #304 (example for a condo)TAXEXEMPT_TYPE (expected) Text 100 - Primary category of granted tax exemption ex. None, Religious, Government, Agriculture, Conservation Easement, Other Open Space, OtherTAX_DISTRICT (expected, where applicable) Text 10 - The coding the county uses to identify a unique combination of property tax levying entities ex. 17ATOTAL_MKT_VALUE (expected) Decimal - Total market value of parcel's land, structures, and other improvements as determined by the Assessor for the most current tax year ex. 332000LAND _MKT_VALUE (expected) Decimal - The market value of the parcel's land as determined by the Assessor for the most current tax year ex. 80600PARCEL_ACRES (expected) Decimal - Parcel size in acres ex. 20.360PROP_CLASS (expected) Text 100 - Residential, Commercial, Industrial, Mixed, Agricultural, Vacant, Open Space, Other ex. ResidentialPRIMARY_RES (expected) Text 1 - Is the property a primary residence(s): Y'(es), 'N'(o), or 'U'(nknown) ex. YHOUSING_CNT (expected, where applicable) Text 10 - Number of housing units, can be single number or range like '5-10' ex. 1SUBDIV_NAME (optional) Text 100 - Subdivision name if applicable ex. Highland Manor SubdivisionBLDG_SQFT (expected, where applicable) Integer - Square footage of primary bldg(s) ex. 2816BLDG_SQFT_INFO (expected, where applicable) Text 100 - Note for how building square footage is counted by the County ex. Only finished above and below grade areas are counted.FLOORS_CNT (expected, where applicable) Decimal - Number of floors as reported in county records ex. 2FLOORS_INFO (expected, where applicable) Text 100 - Note for how floors are counted by the County ex. Only above grade floors are countedBUILT_YR (expected, where applicable) Short - Estimated year of initial construction of primary buildings ex. 1968EFFBUILT_YR (optional, where applicable) Short - The 'effective' year built' of primary buildings that factors in updates after construction ex. 1980CONST_MATERIAL (optional, where applicable) Text 100 - Construction Material Types, Values for this field are expected to vary greatly by county ex. Wood Frame, Brick, etc Contact: Sean Fernandez, Cadastral Manager (email: sfernandez@utah.gov; office phone: 801-209-9359)

There are many useful strategies for preparing GIS data for Next Generation 9-1-1. One step of preparation is making sure that all of the required fields exist (and sometimes populated) before loading into the system. While some localities add needed fields to their local data, others use an extract, transform, and load process to transform their local data into a Next Generation 9-1-1 GIS data model, and still others may do a combination of both.There are several strategies and considerations when loading data into a Next Generation 9-1-1 GIS data model. The best place to start is using a GIS data model schema template, or an empty file with the needed data layout to which you can append your data. Here are some resources to help you out. 1) The National Emergency Number Association (NENA) has a GIS template available on the Next Generation 9-1-1 GIS Data Model Page.2) The NENA GIS Data Model template uses a WGS84 coordinate system and pre-builds many domains. The slides from the Virginia NG9-1-1 User Group meeting in May 2021 explain these elements and offer some tips and suggestions for working with them. There are also some tips on using field calculator. Click the "open" button at the top right of this screen or here to view this information.3) VGIN adapted the NENA GIS Data Model into versions for Virginia State Plane North and Virginia State Plane South, as Virginia recommends uploading in your local coordinates and having the upload tools consistently transform your data to the WGS84 (4326) parameters required by the Next Generation 9-1-1 system. These customized versions only include the Site Structure Address Point and Street Centerlines feature classes. Address Point domains are set for address number, state, and country. Street Centerline domains are set for address ranges, parity, one way, state, and country. 4) A sample extract, transform, and load (ETL) for NG9-1-1 Upload script is available here.Additional resources and recommendations on GIS related topics are available on the VGIN 9-1-1 & GIS page.

This is the GIS data and imagery used for analyses in the article
Sixty-seven years of land-use change in southern Costa Rica by Zahawi
et al. currently in revision at PLOS One.

This study required the orthorectification of historic aerial photographs, as well as forest cover mapping and landscape analysis of 320 km² around the Las Cruces Biological Station in San Vito de Coto Brus, Costa Rica. The imagery and GIS data generated were used to account for forest cover change over five different time periods from 1947 to 2014.

The datasets supplied include GIS files for:

• Extent of the study area (shapefile).
• Forest cover mapped for each time period (geotiff).
• Imagery of the mosaics generated with the orthorectified historic aerial photographs (geotiff).
• Age in studied time periods of the current forest patches (shapefile).
• Connectivity lines inside the studied area (shapefiles).

All files are in Costa Rica Transverse Mercator 2005 (CRTM05) projected coordinate reference system. For transformation between coordinate systems please refer to http://epsg.io/5367

Aerial photographs for the years 1947, 1960, 1980 and 1997 were acquired from the Organization for Tropical Studies GIS Lab and the Instituto Geográfico Nacional of Costa Rica. The orthorectification process was done first on the 1997 set of images and used the current 1:50,000 and 1:25,000 Costa Rican cartography to identify geographical reference points. The set of 1997 orthophotos was used as a reference set to orthorectify remaining years with the exception of 1947 images. The orthorectification process and all other geospatial analyses were done on the CRTM05 spatial reference system and the resulting orthophotos had a 2m cell size. The largest Root Mean Square error (RMSE) of the orthorectification of these three time slices of aerial photographs was 15 m.

Given the lack of information on flight parameters, and the expansive forest coverage in 1947 photographs, images were georeferenced and built into a mosaic using river basins and the few forest clearings that had a similar shape in the 1960 flyover. The 1947 set of images did not cover the whole study area, having empty areas without photographs that represented ˜12.1% of the analysis extent. Nonetheless, these areas were classified as forested given that forest was present in these same areas in the 1960 imagery.

Forest mapping was done by visual interpretation of orthophotos and Google imagery. The areas were considered forested if tree crowns were easily identified when viewing the images at a scale of 1:10,000. In areas where it was difficult to discern the type of land cover, a scale of 1:5,000 was used. This was done to eliminate agroforestry systems such as shaded coffee areas (with trees planted in rows) or very early stages of forest regeneration from the forest land-cover class. The analysis was done only in areas that were cloud free in the five time slices. This resulted in the elimination of 134 ha (~0.4%) from of the original area outlined above. Polygons were drawn over the different areas using QGIS and were transformed into raster files of 10 m cell size.

The Postal Code Conversion File (PCCF) is a digital file which provides a correspondence between the Canada Post Corporation (CPC) six-character postal code and Statistics Canada's standard geographic areas for which census data and other statistics are produced. Through the link between postal codes and standard geographic areas, the PCCF permits the integration of data from various sources. The Single Link Indicator provides one best link for every postal code, as there are multiple records for many postal codes. To obtain the postal code conversion file or for questions, consult the DLI contact at your educational institution. The geographic coordinates attached to each postal code on the PCCF are commonly used to map the distribution of data for spatial analysis (e.g., clients, activities). The location information is a powerful tool for planning, or research purposes. The geographic coordinates, which represent the standard geostatistical areas linked to each postal codeOM on the PCCF, are commonly used to map the distribution of data for spatial analysis (e.g., clients, activities). The location information is a powerful tool for marketing, planning, or research purposes. In April 1983, the Statistical Registers and Geography Division released the first version of the PCCF, which linked postal codesOM to 1981 Census geographic areas and included geographic coordinates. Since then, the file has been updated on a regular basis to reflect changes. For this release of the PCCF, the vast majority of the postal codesOM are directly geocoded to 2016 Census geography while others are linked via various conversion processes. A quality indicator for the confidence of this linkage is available in the PCCF.

Usage note: please be aware … Statistics Canada confirmed on May 10th, 2018, that a number of particular postal codesOM are missing in the June 2017 (published in December 2017) release of the PCCF, but was not able provide specifics about why these are missing. However, Statistics Canada checked each missing postal code against the newest internal release of the product, and they did exist in that file. The postal codesOM in question should be available in the August 2018 file. The Postal Code Conversion File (PCCF) is a digital file which provides a correspondence between the Canada Post Corporation (CPC) six-character postal code and Statistics Canada's standard geographic areas for which census data and other statistics are produced. Through the link between postal codes and standard geographic areas, the PCCF permits the integration of data from various sources. The Single Link Indicator provides one best link for every postal code, as there are multiple records for many postal codes. To obtain the postal code conversion file or for questions, consult the DLI contact at your educational institution. The geographic coordinates attached to each postal code on the PCCF are commonly used to map the distribution of data for spatial analysis (e.g., clients, activities). The location information is a powerful tool for planning, or research purposes. The geographic coordinates, which represent the standard geostatistical areas linked to each postal codeOM on the PCCF, are commonly used to map the distribution of data for spatial analysis (e.g., clients, activities). The location information is a powerful tool for marketing, planning, or research purposes. In April 1983, the Statistical Registers and Geography Division released the first version of the PCCF, which linked postal codesOM to 1981 Census geographic areas and included geographic coordinates. Since then, the file has been updated on a regular basis to reflect changes. For this release of the PCCF, the vast majority of the postal codesOM are directly geocoded to 2016 Census geography while others are linked via various conversion processes. A quality indicator for the confidence of this linkage is available in the PCCF.

The Postal Code Conversion File (PCCF) is a digital file which provides a correspondence between the Canada Post Corporation (CPC) six-character postal code and Statistics Canada's standard geographic areas for which census data and other statistics are produced. Through the link between postal codes and standard geographic areas, the PCCF permits the integration of data from various sources. The Single Link Indicator provides one best link for every postal code, as there are multiple records for many postal codes. To obtain the postal code conversion file or for questions, consult the DLI contact at your educational institution. The geographic coordinates attached to each postal code on the PCCF are commonly used to map the distribution of data for spatial analysis (e.g., clients, activities). The location information is a powerful tool for planning, or research purposes. In April 1983, the Geography Division released the first version of the PCCF, which linked postal codes to 1981 Census geographic areas and included geographic coordinates. Since then, the file has been updated on a regular basis to reflect changes. For this release of the PCCF, the vast majority of the postal codes are directly geocoded to 2006 Census geography. This improves precision of the file over the previous conversion process used to align postal code linkages to new geographic areas after each census. About 94% of the postal codes were linked to geographic areas using the new automated process. A quality indicator for the confidence of this linkage is available in the PCCF.

The Geocode Job extension for CKAN enables users to automatically geocode resources by scheduling a background job. By using a specified metadata field, this extension triggers a process that attaches or updates geographic coordinates for a dataset's resources. This automation enhances the value of datasets by making them discoverable and usable in location-based applications. This is especially useful for datasets containing address or location information that requires conversion and integration with mapping software and services. Key Features: Automated Geocoding: Automatically geocodes resources. Metadata Field Trigger: Initiates geocoding process based on the presence or update of a designated metadata field and value. Background Processing: Executes geocoding tasks in the background, ensuring a smooth user experience without interrupting normal CKAN operation. Specifically this avoids delaying interaction with the user interface. Resource Attachment/Update: Attaches geographic coordinates (latitude/longitude) to existing resources or updates them if already present and updated. Use Cases: Address-Based Datasets: Enhance datasets containing street addresses by automatically converting them to geographic coordinates. Location-Based Services: Integrate datasets with location-based services by providing accurate geographic data. Data Enrichment: Automatically add geographic context to datasets, making them more valuable and usable for mapping and spatial analysis. Benefits & Impact: The Geocode Job extension simplifies the process of enriching datasets with geographic information, improving their discoverability and usability. Scheduling background geocoding operations reduces the manual effort involved in data preparation, saving time and resources. This will therefore make such datasets more discoverable within the CKAN catalog. By automating the process, the extension helps to maintain accurate and up-to-date geographic data within the CKAN repository.

Mineral mining licence data as geodata based on 6th MEITI Data Summary Report (FY2018) annex (https://myanmareiti.org/sites/myanmareiti.org/files/publication_docs/license_information1st_april_to_30_september2018.xlsx & https://myanmareiti.org/en/publication/6th-meiti-summary-data-report). It includes 1218 of 1246 mineral mining licences reported in the 6th MEITI Data Summary Report licence annex. This dataset includes the original and cleaned data columns and geodata for licence block boundary coordinates, licence block areas and licence areas. Additional attributes were added during the geodata generation process. The detailed description of attribute fields can be found in attached metadata attributes excel sheet. The generation of the geodata is based on the coordinate values (usually "6 digit One Inch" coordinates) for every licence block. As the mineral mining license information shared by Department of Mining with MEITI was not based on the better quality Mineral Mining Pre-Cadastre but on another lower quality excel list, P. Oswald estimates that at least 30% of all mineral mining licenses have some sort of quality issues. Out of 1246 mineral mining licences reported in the MEITI annex, 28 could not be processed, over 300 licences had at least one wrong or missing coordinate, and approx. 40 licences had only one simplified centre coordinate instead of mining block boundary coordinates.Lineage: Version 2022-07-15: updated Metadata and attribute names Version 2021-07-01: Data downloaded from MEITI https://myanmareiti.org/sites/myanmareiti.org/files/publication_docs/license_information1st_april_to_30_september2018.xlsx on 2021-05-01. Data columns cleaned and standardized by P. Oswald (obvious typos corrected, removal of whitespaces and line breaks, standardize value domains where possible, etc.). Matching of descriptive location information with MIMU Township codes where possible. Change detection vs. licence data from MEITI5th report licence annexe and transfer of ""fixed"" data where licences remained identical. Add managing Mining Enterprise name information based on commodity matching with a reference table (commodities managed by which Mining Enterprise). Geometry created based on coordinate information columns by conversion of coordinate values to GIS data and connecting the coordinates with straight lines (in ArcMap using SRS EPSG4326) to mining block and mining licence area polygons. Projection of licence geodata to EPSG4326 applying a Molodensky transformation using 3-parameters shared by Myanmar Survey Department. Linking the MEITI 6th data summary report attribute data to the licence block and licence geometries. As P. Oswald (as well as MEITI) has no access to the underlying individual licence contracts nor other verified reference data, the completeness and correctness of the data and cross-checking or reliable corrections cannot be undertaken. Preliminary assessments indicate that many coordinates in the licence information annex are simplified, inaccurate, wrong or completely missing. Thus, the generated licence geodata data inherits those data quality problems. In some cases P. Oswald corrected obviously wrong coordinates using a "best-guess" approach. Those corrections include correcting obvious typos and data input errors in excel, the “squaring” of concession blocks if one coordinate is very far away from all the other licence block coordinates, changing the order of the coordinates to avoid self-overlapping block boundaries, creating a circular shape of the size of the permitted area around the centre point when only one coordinate was provided, change of One Inch Map sheet numbers to make the coordinates fit with the indicated township location description etc. Edits performed are documented in processing-attributes added to the data sets.

Internal view of the parcel layer. This view contains all the attributes that can be seen by County employees.There are approximately 51,300 real property parcels in Napa County. Parcels delineate the approximate boundaries of property ownership as described in Napa County deeds, filed maps, and other source documents. GIS parcel boundaries are maintained by the Information Technology Services GIS team. Assessor Parcel Maps are created and maintained by the Assessor Division Mapping Section. Each parcel has an Assessor Parcel Number (APN) that is its unique identifier. The APN is the link to various Napa County databases containing information such as owner name, situs address, property value, land use, zoning, flood data, and other related information. Data for this map service is sourced from the Napa County Parcels dataset which is updated nightly with any recent changes made by the mapping team. There may at times be a delay between when a document is recorded and when the new parcel boundary configuration and corresponding information is available in the online GIS parcel viewer.From 1850 to early 1900s assessor staff wrote the name of the property owner and the property value on map pages. They began using larger maps, called “tank maps” because of the large steel cabinet they were kept in, organized by school district (before unification) on which names and values were written. In the 1920s, the assessor kept large books of maps by road district on which names were written. In the 1950s, most county assessors contracted with the State Board of Equalization for board staff to draw standardized 11x17 inch maps following the provisions of Assessor Handbook 215. Maps were originally drawn on linen. By the 1980’s Assessor maps were being drawn on mylar rather than linen. In the early 1990s Napa County transitioned from drawing on mylar to creating maps in AutoCAD. When GIS arrived in Napa County in the mid-1990s, the AutoCAD images were copied over into the GIS parcel layer. Sidwell, an independent consultant, was then contracted by the Assessor’s Office to convert these APN files into the current seamless ArcGIS parcel fabric for the entire County. Beginning with the 2024-2025 assessment roll, the maps are being drawn directly in the parcel fabric layer.Parcels in the GIS parcel fabric are drawn according to the legal description using coordinate geometry (COGO) drawing tools and various reference data such as Public Lands Survey section boundaries and road centerlines. The legal descriptions are not defined by the GIS parcel fabric. Any changes made in the GIS parcel fabric via official records, filed maps, and other source documents are uploaded overnight. There is always at least a 6-month delay between when a document is recorded and when the new parcel configuration and corresponding information is available in the online parcel viewer for search or download.Parcel boundary accuracy can vary significantly, with errors ranging from a few feet to several hundred feet. These distortions are caused by several factors such as: the map projection - the error derived when a spherical coordinate system model is projected into a planar coordinate system using the local projected coordinate system; and the ground to grid conversion - the distortion between ground survey measurements and the virtual grid measurements. The aim of the parcel fabric is to construct a visual interpretation that is adequate for basic geographic understanding. This digital data is intended for illustration and demonstration purposes only and is not considered a legal resource, nor legally authoritative.SFAP & CFAP DISCLAIMER: Per the California Code, RTC 606. some legal parcels may have been combined for assessment purposes (CFAP) or separated for assessment purposes (SFAP) into multiple parcels for a variety of tax assessment reasons. SFAP and CFAP parcels are assigned their own APN number and primarily result from a parcel being split by a tax rate area boundary, due to a recorded land use lease, or by request of the property owner. Assessor parcel (APN) maps reflect when parcels have been separated or combined for assessment purposes, and are one legal entity. The goal of the GIS parcel fabric data is to distinguish the SFAP and CFAP parcel configurations from the legal configurations, to convey the legal parcel configurations. This workflow is in progress. Please be advised that while we endeavor to restore SFAP and CFAP parcels back to their legal configurations in the primary parcel fabric layer, SFAP and CFAP parcels may be distributed throughout the dataset. Parcels that have been restored to their legal configurations, do not reflect the SFAP or CFAP parcel configurations that correspond to the current property tax delineations. We intend for parcel reports and parcel data to capture when a parcel has been separated or combined for assessment purposes, however in some cases, information may not be available in GIS for the SFAP/CFAP status of a parcel configuration shown. For help or questions regarding a parcel’s SFAP/CFAP status, or property survey data, please visit Napa County’s Surveying Services or Property Mapping Information. For more information you can visit our website: When a Parcel is Not a Parcel | Napa County, CA

Overview

This dataset provides high-resolution, georeferenced vehicle trajectories collected via drone footage at three roundabouts located in the municipalities of Frick and Laufenburg, Canton of Aargau, Switzerland. The data were collected as part of a collaborative drone campaign organized by the Urban Transport Systems Laboratory (LUTS), EPFL, within the framework of NCCR Automation, in cooperation with the cantonal traffic planning department of Aargau. The collection took place on Monday, 23rd October 2023, during peak morning and afternoon hours, resulting in nearly 11 hours of 4K video data.

Dataset Composition

This dataset contains CSV files structured with consistent data fields representing georeferenced trajectories, vehicle types (car, bus, truck), and timestamps, capturing detailed vehicle movements within roundabout environments.

File Organization

File names follow the convention:

D{X}_{TP}{N}_{S}.csv

D{X} — the drone identifier, where {X} is a number (e.g., 1, 2) indicating which drone captured the data.→ Example: D1 = data collected by Drone 1.

{TP}{N} — the time period and session number, where {TP} is either AM (morning) or PM (afternoon), and {N} is an integer indicating the session number.→ Example: AM2 = second morning session.

{S} — the site identifier, corresponding to one of the monitored sites:→ F1 = Roundabout F1 (Frick)→ F2 = Roundabout F2 (Frick)→ L1 = Roundabout L1 (Laufenburg)

CSV File Structure

Each CSV file includes:

Column Name Description Format / Units

track_id Unique vehicle identifier (per file) Integer

type Vehicle type (Car, Bus, Truck) Categorical

lon WGS84 geographic longitude Decimal degrees (15 d.p.)

lat WGS84 geographic latitude Decimal degrees (15 d.p.)

time Local timestamp in ISO 8601 format String (hh:mm:ss.ss)

Data Collection and Processing

Collection Method: Two drones flying at an altitude of 120 meters above ground level, capturing videos at 4K resolution (3840×2160 pixels) at 29.97 FPS.

Locations:

Roundabout F1 (Frick): Intersection of Bahnhofstrasse and Hauptstrasse 3 (Urban)

Roundabout F2 (Frick): Intersection of Hauptstrasse 3 with Gänsacker and Stöcklimattstrasse (Urban)

Roundabout L1 (Laufenburg): Intersection at Hauptstrasse 7 near the German border (Rural)

Data Processing: The detection, tracking, and trajectory stabilization were performed using the early version of the Geo-trax framework (v0.1.0), an advanced computer vision pipeline tailored for drone-captured traffic footage. The resulting trajectories are precisely represented in stabilized pixel coordinates, which are subsequently transformed into geographic coordinates (WGS84). This georeferencing process follows a procedure similar to that described in Espadaler-Clapés et al., 2023, and includes:

Identification and extraction of Ground Control Points (GCPs) in the first stabilized video frame using QGIS Georeferencer, linking pixel coordinates to UTM coordinates.

Linear regression modeling between stabilized pixel coordinates and corresponding UTM coordinates derived from GCPs to estimate transformation parameters.

Projection to WGS84, converting UTM coordinates into global geographic coordinates using a standard GIS transformation (EPSG:4326).

Dataset Statistics

Roundabout Videos Avg. Duration (min) Total Duration (min) Vehicles (total) Cars Buses Trucks

F1 8 18.63 149.04 4,283 3,967 72 244

F2 6 19.24 115.44 2,528 2,205 26 297

L1 4 20.39 81.56 2,130 1,980 24 126

Potential Applications

This dataset is well-suited for:

Gap acceptance behavior studies at roundabouts (e.g., Pascual Anglès et al., 2025)

Traffic flow analysis and modeling

Safety assessments using surrogate safety measures (SSMs)

Validation of traffic simulation models