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.

If you have geographic information stored as a table, ArcGIS Pro can display it on a map and convert it to spatial data. In this tutorial, you'll create spatial data from a table containing the latitude-longitude coordinates of huts in a New Zealand national park. Huts in New Zealand are equivalent to cabins in the United States—they may or may not have sleeping bunks, kitchen facilities, electricity, and running water. The table of hut locations is stored as a comma-separated values (CSV) file. CSV files are a common, nonproprietary file type for tabular data.Estimated time: 45 minutesSoftware requirements: ArcGIS Pro

Crowther_Nature_Files.zip This description pertains to the original download. Details on revised (newer) versions of the datasets are listed below. When more than one version of a file exists in Figshare, the original DOI will take users to the latest version, though each version technically has its own DOI. -- Two global maps (raster files) of tree density. These maps highlight how the number of trees varies across the world. One map was generated using biome-level models of tree density, and applied at the biome scale. The other map was generated using ecoregion-level models of tree density, and applied at the ecoregion scale. For this reason, transitions between biomes or between ecoregions may be unrealistically harsh, but large-scale estimates are robust (see Crowther et al 2015 and Glick et al 2016). At the outset, this study was intended to generate reliable estimates at broad spatial scales, which inherently comes at the cost of fine-scale precision. For this reason, country-scale (or larger) estimates are generally more robust than individual pixel-level estimates. Additionally, due to data limitations, estimates for Mangroves and Tropical coniferous forest (as identified by WWF and TNC) were generated using models constructed from Topical moist broadleaf forest data and Temperate coniferous forest data, respectively. Because we used ecological analogy, the estimates for these two biomes should be considered less reliable than those of other biomes . These two maps initially appeared in Crowther et al (2015), with the biome map being featured more prominently. Explicit publication of the data is associated with Glick et al (2016). As they are produced, updated versions of these datasets, as well as alternative formats, will be made available under Additional Versions (see below).

Methods: We collected over 420,000 ground-sources estimates of tree density from around the world. We then constructed linear regression models using vegetative, climatic, topographic, and anthropogenic variables to produce forest tree density estimates for all locations globally. All modeling was done in R. Mapping was done using R and ArcGIS 10.1.

Viewing Instructions: Load the files into an appropriate geographic information system (GIS). For the original download (ArcGIS geodatabase files), load the files into ArcGIS to view or export the data to other formats. Because these datasets are large and have a unique coordinate system that is not read by many GIS, we suggest loading them into an ArcGIS dataframe whose coordinate system matches that of the data (see File Format). For GeoTiff files (see Additional Versions), load them into any compatible GIS or image management program.

Comments: The original download provides a zipped folder that contains (1) an ArcGIS File Geodatabase (.gdb) containing one raster file for each of the two global models of tree density – one based on biomes and one based on ecoregions; (2) a layer file (.lyr) for each of the global models with the symbology used for each respective model in Crowther et al (2015); and an ArcGIS Map Document (.mxd) that contains the layers and symbology for each map in the paper. The data is delivered in the Goode homolosine interrupted projected coordinate system that was used to compute biome, ecoregion, and global estimates of the number and density of trees presented in Crowther et al (2015). To obtain maps like those presented in the official publication, raster files will need to be reprojected to the Eckert III projected coordinate system. Details on subsequent revisions and alternative file formats are list below under Additional Versions.----------

Additional Versions: Crowther_Nature_Files_Revision_01.zip contains tree density predictions for small islands that are not included in the data available in the original dataset. These predictions were not taken into consideration in production of maps and figures presented in Crowther et al (2015), with the exception of the values presented in Supplemental Table 2. The file structure follows that of the original data and includes both biome- and ecoregion-level models.

Crowther_Nature_Files_Revision_01_WGS84_GeoTiff.zip contains Revision_01 of the biome-level model, but stored in WGS84 and GeoTiff format. This file was produced by reprojecting the original Goode homolosine files to WGS84 using nearest neighbor resampling in ArcMap. All areal computations presented in the manuscript were computed using the Goode homolosine projection. This means that comparable computations made with projected versions of this WGS84 data are likely to differ (substantially at greater latitudes) as a product of the resampling. Included in this .zip file are the primary .tif and its visualization support files.

References:

Crowther, T. W., Glick, H. B., Covey, K. R., Bettigole, C., Maynard, D. S., Thomas, S. M., Smith, J. R., Hintler, G., Duguid, M. C., Amatulli, G., Tuanmu, M. N., Jetz, W., Salas, C., Stam, C., Piotto, D., Tavani, R., Green, S., Bruce, G., Williams, S. J., Wiser, S. K., Huber, M. O., Hengeveld, G. M., Nabuurs, G. J., Tikhonova, E., Borchardt, P., Li, C. F., Powrie, L. W., Fischer, M., Hemp, A., Homeier, J., Cho, P., Vibrans, A. C., Umunay, P. M., Piao, S. L., Rowe, C. W., Ashton, M. S., Crane, P. R., and Bradford, M. A. 2015. Mapping tree density at a global scale. Nature, 525(7568): 201-205. DOI: http://doi.org/10.1038/nature14967Glick, H. B., Bettigole, C. B., Maynard, D. S., Covey, K. R., Smith, J. R., and Crowther, T. W. 2016. Spatially explicit models of global tree density. Scientific Data, 3(160069), doi:10.1038/sdata.2016.69.

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).

Geoform is a configurable app template for form based data editing of a Feature Service. This application allows users to enter data through a form instead of a map's pop-up while leveraging the power of the Web Map and editable Feature Services. This app geo-enables data and workflows by lowering the barrier of entry for completing simple tasks. Use CasesProvides a form-based experience for entering data through a form instead of a map pop-up. This is a good choice for users who find forms a more intuitive format than pop-ups for entering data.Useful to collect new point data from a large audience of non technical staff or members of the community.Configurable OptionsGeoform has an interactive builder used to configure the app in a step-by-step process. Use Geoform to collect new point data and configure it using the following options:Choose a web map and the editable layer(s) to be used for collection.Provide a title, logo image, and form instructions/details.Control and choose what attribute fields will be present in the form. Customize how they appear in the form, the order they appear in, and add hint text.Select from over 15 different layout themes.Choose the display field that will be used for sorting when viewing submitted entries.Enable offline support, social media sharing, default map extent, locate on load, and a basemap toggle button.Choose which locate methods are available in the form, including: current location, search, latitude and longitude, USNG coordinates, MGRS coordinates, and UTM coordinates.Supported DevicesThis application is responsively designed to support use in browsers on desktops, mobile phones, and tablets.Data RequirementsThis web app includes the capability to edit a hosted feature service or an ArcGIS Server feature service. Creating hosted feature services requires an ArcGIS Online organizational subscription or an ArcGIS Developer account. Get Started This application can be created in the following ways:Click the Create a Web App button on this pageShare a map and choose to Create a Web AppOn the Content page, click Create - App - From Template Click the Download button to access the source code. Do this if you want to host the app on your own server and optionally customize it to add features or change styling.

The Terrain 3D layer provides global elevation surface to use in ArcGIS 3D applicationsWhat can you do with this layer?Use this layer to visualize your maps and layers in 3D using applications like the Scene Viewer in ArcGIS Online and ArcGIS Pro. Show me how1) Working with Scenes in ArcGIS Pro or ArcGIS Online Scene Viewer2) Select an appropriate basemap or use your own3) Add your unique 2D and 3D data layers to the scene. Your data are simply added on the elevation. If your data have defined elevation (z coordinates) this information will be honored in the scene4) Share your work as a Web Scene with others in your organization or the publicDataset Coverage To see the coverage and sources of various datasets comprising this elevation layer, view the Elevation Coverage Map. Additionally, this layer uses data from Maxar’s Precision 3D Digital Terrain Models for parts of the globe.This layer is part of a larger collection of elevation layers. For more information, see the Elevation Layers group on ArcGIS Online.

View service - topographic map of the territory of the Republic of Lithuania M1: 50,000 in the LKS-94 coordinate system (TOP50LKS). The map was created using a cartographic data set. The map depicts natural and anthropogenic objects on the Earth's surface. The cartographic data set consists of spatial objects related to water bodies, land cover, transport network, engineering communications, geodetic points, relief, place names, boundaries of administrative units and protected areas, and so on. TOP50LKS data are prepared automatically.

Xverum’s Global GIS & Geospatial Data is a high-precision dataset featuring 230M+ verified points of interest across 249 countries. With rich metadata, structured geographic attributes, and continuous updates, our dataset empowers businesses, researchers, and governments to extract location intelligence and conduct advanced geospatial analysis.

Perfectly suited for GIS systems, mapping tools, and location intelligence platforms, this dataset covers everything from businesses and landmarks to public infrastructure, all classified into over 5000 categories. Whether you're planning urban developments, analyzing territories, or building location-based products, our data delivers unmatched coverage and accuracy.

Key Features: ✅ 230M+ Global POIs Includes commercial, governmental, industrial, and service locations - updated regularly for accurate relevance.

✅ Comprehensive Geographic Coverage Worldwide dataset covering 249 countries, with attributes including latitude, longitude, city, country code, postal code, etc.

✅ Detailed Mapping Metadata Get structured address data, place names, categories, and location, which are ideal for map visualization and geospatial modeling.

✅ Bulk Delivery for GIS Platforms Available in .json - delivered via S3 Bucket or cloud storage for easy integration into ArcGIS, QGIS, Mapbox, and similar systems.

✅ Continuous Discovery & Refresh New POIs added and existing ones refreshed on a regular refresh cycle, ensuring reliable, up-to-date insights.

✅ Compliance & Scalability 100% compliant with global data regulations and scalable for enterprise use across mapping, urban planning, and retail analytics.

Use Cases: 📍 Location Intelligence & Market Analysis Identify high-density commercial zones, assess regional activity, and understand spatial relationships between locations.

🏙️ Urban Planning & Smart City Development Design infrastructure, zoning plans, and accessibility strategies using accurate location-based data.

🗺️ Mapping & Navigation Enrich digital maps with verified business listings, categories, and address-level geographic attributes.

📊 Retail Site Selection & Expansion Analyze proximity to key POIs for smarter retail or franchise placement.

📌 Risk & Catchment Area Assessment Evaluate location clusters for insurance, logistics, or regional outreach strategies.

Why Xverum? ✅ Global Coverage: One of the largest POI geospatial databases on the market ✅ Location Intelligence Ready: Built for GIS platforms and spatial analysis use ✅ Continuously Updated: New POIs discovered and refreshed regularly ✅ Enterprise-Friendly: Scalable, compliant, and customizable ✅ Flexible Delivery: Structured format for smooth data onboarding

Request a free sample and discover how Xverum’s geospatial data can power your mapping, planning, and spatial analysis projects.

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.

A major objective of plant ecology research is to determine the underlying processes responsible for the observed spatial distribution patterns of plant species. Plants can be approximated as points in space for this purpose, and thus, spatial point pattern analysis has become increasingly popular in ecological research. The basic piece of data for point pattern analysis is a point location of an ecological object in some study region. Therefore, point pattern analysis can only be performed if data can be collected. However, due to the lack of a convenient sampling method, a few previous studies have used point pattern analysis to examine the spatial patterns of grassland species. This is unfortunate because being able to explore point patterns in grassland systems has widespread implications for population dynamics, community-level patterns and ecological processes. In this study, we develop a new method to measure individual coordinates of species in grassland communities. This method records plant growing positions via digital picture samples that have been sub-blocked within a geographical information system (GIS). Here, we tested out the new method by measuring the individual coordinates of Stipa grandis in grazed and ungrazed S. grandis communities in a temperate steppe ecosystem in China. Furthermore, we analyzed the pattern of S. grandis by using the pair correlation function g(r) with both a homogeneous Poisson process and a heterogeneous Poisson process. Our results showed that individuals of S. grandis were overdispersed according to the homogeneous Poisson process at 0-0.16 m in the ungrazed community, while they were clustered at 0.19 m according to the homogeneous and heterogeneous Poisson processes in the grazed community. These results suggest that competitive interactions dominated the ungrazed community, while facilitative interactions dominated the grazed community. In sum, we successfully executed a new sampling method, using digital photography and a Geographical Information System, to collect experimental data on the spatial point patterns for the populations in this grassland community.

Methods 1. Data collection using digital photographs and GIS

A flat 5 m x 5 m sampling block was chosen in a study grassland community and divided with bamboo chopsticks into 100 sub-blocks of 50 cm x 50 cm (Fig. 1). A digital camera was then mounted to a telescoping stake and positioned in the center of each sub-block to photograph vegetation within a 0.25 m2 area. Pictures were taken 1.75 m above the ground at an approximate downward angle of 90° (Fig. 2). Automatic camera settings were used for focus, lighting and shutter speed. After photographing the plot as a whole, photographs were taken of each individual plant in each sub-block. In order to identify each individual plant from the digital images, each plant was uniquely marked before the pictures were taken (Fig. 2 B).

Digital images were imported into a computer as JPEG files, and the position of each plant in the pictures was determined using GIS. This involved four steps: 1) A reference frame (Fig. 3) was established using R2V software to designate control points, or the four vertexes of each sub-block (Appendix S1), so that all plants in each sub-block were within the same reference frame. The parallax and optical distortion in the raster images was then geometrically corrected based on these selected control points; 2) Maps, or layers in GIS terminology, were set up for each species as PROJECT files (Appendix S2), and all individuals in each sub-block were digitized using R2V software (Appendix S3). For accuracy, the digitization of plant individual locations was performed manually; 3) Each plant species layer was exported from a PROJECT file to a SHAPE file in R2V software (Appendix S4); 4) Finally each species layer was opened in Arc GIS software in the SHAPE file format, and attribute data from each species layer was exported into Arc GIS to obtain the precise coordinates for each species. This last phase involved four steps of its own, from adding the data (Appendix S5), to opening the attribute table (Appendix S6), to adding new x and y coordinate fields (Appendix S7) and to obtaining the x and y coordinates and filling in the new fields (Appendix S8).

1. Data reliability assessment

To determine the accuracy of our new method, we measured the individual locations of Leymus chinensis, a perennial rhizome grass, in representative community blocks 5 m x 5 m in size in typical steppe habitat in the Inner Mongolia Autonomous Region of China in July 2010 (Fig. 4 A). As our standard for comparison, we used a ruler to measure the individual coordinates of L. chinensis. We tested for significant differences between (1) the coordinates of L. chinensis, as measured with our new method and with the ruler, and (2) the pair correlation function g of L. chinensis, as measured with our new method and with the ruler (see section 3.2 Data Analysis). If (1) the coordinates of L. chinensis, as measured with our new method and with the ruler, and (2) the pair correlation function g of L. chinensis, as measured with our new method and with the ruler, did not differ significantly, then we could conclude that our new method of measuring the coordinates of L. chinensis was reliable.

We compared the results using a t-test (Table 1). We found no significant differences in either (1) the coordinates of L. chinensis or (2) the pair correlation function g of L. chinensis. Further, we compared the pattern characteristics of L. chinensis when measured by our new method against the ruler measurements using a null model. We found that the two pattern characteristics of L. chinensis did not differ significantly based on the homogenous Poisson process or complete spatial randomness (Fig. 4 B). Thus, we concluded that the data obtained using our new method was reliable enough to perform point pattern analysis with a null model in grassland communities.

Statistical analyses and maps representing mean, high, and low water-level conditions in the surface water and groundwater of Miami-Dade County were made by the U.S. Geological Survey, in cooperation with the Miami-Dade County Department of Regulatory and Economic Resources, to help inform decisions necessary for urban planning and development. Sixteen maps were created that show contours of (1) the mean of daily water levels at each site during October and May for the 2000-2009 water years; (2) the 25th, 50th, and 75th percentiles of the daily water levels at each site during October and May and for all months during 2000-2009; and (3) the differences between mean October and May water levels, as well as the differences in the percentiles of water levels for all months, between 1990-1999 and 2000-2009. The 80th, 90th, and 96th percentiles of the annual maximums of daily groundwater levels during 1974-2009 (a 35-year period) were computed to provide an indication of unusually high groundwater-level conditions. These maps and statistics provide a generalized understanding of the variations of water levels in the aquifer, rather than a survey of concurrent water levels. Water-level measurements from 473 sites in Miami-Dade County and surrounding counties were analyzed to generate statistical analyses. The monitored water levels included surface-water levels in canals and wetland areas and groundwater levels in the Biscayne aquifer. Maps were created by importing site coordinates, summary water-level statistics, and completeness of record statistics into a geographic information system, and by interpolating between water levels at monitoring sites in the canals and water levels along the coastline. Raster surfaces were created from these data by using the triangular irregular network interpolation method. The raster surfaces were contoured by using geographic information system software. These contours were imprecise in some areas because the software could not fully evaluate the hydrology given available information; therefore, contours were manually modified where necessary. The ability to evaluate differences in water levels between 1990-1999 and 2000-2009 is limited in some areas because most of the monitoring sites did not have 80 percent complete records for one or both of these periods. The quality of the analyses was limited by (1) deficiencies in spatial coverage; (2) the combination of pre- and post-construction water levels in areas where canals, levees, retention basins, detention basins, or water-control structures were installed or removed; (3) an inability to address the potential effects of the vertical hydraulic head gradient on water levels in wells of different depths; and (4) an inability to correct for the differences between daily water-level statistics. Contours are dashed in areas where the locations of contours have been approximated because of the uncertainty caused by these limitations. Although the ability of the maps to depict differences in water levels between 1990-1999 and 2000-2009 was limited by missing data, results indicate that near the coast water levels were generally higher in May during 2000-2009 than during 1990-1999; and that inland water levels were generally lower during 2000-2009 than during 1990-1999. Generally, the 25th, 50th, and 75th percentiles of water levels from all months were also higher near the coast and lower inland during 2000–2009 than during 1990-1999. Mean October water levels during 2000-2009 were generally higher than during 1990-1999 in much of western Miami-Dade County, but were lower in a large part of eastern Miami-Dade County.

Xverum’s Point of Interest (POI) Data is a comprehensive dataset containing 230M+ verified locations across 5000 business categories. Our dataset delivers structured geographic data, business attributes, location intelligence, and mapping insights, making it an essential tool for GIS applications, market research, urban planning, and competitive analysis.

With regular updates and continuous POI discovery, Xverum ensures accurate, up-to-date information on businesses, landmarks, retail stores, and more. Delivered in bulk to S3 Bucket and cloud storage, our dataset integrates seamlessly into mapping, geographic information systems, and analytics platforms.

🔥 Key Features:

Extensive POI Coverage: ✅ 230M+ Points of Interest worldwide, covering 5000 business categories. ✅ Includes retail stores, restaurants, corporate offices, landmarks, and service providers.

Geographic & Location Intelligence Data: ✅ Latitude & longitude coordinates for mapping and navigation applications. ✅ Geographic classification, including country, state, city, and postal code. ✅ Business status tracking – Open, temporarily closed, or permanently closed.

Continuous Discovery & Regular Updates: ✅ New POIs continuously added through discovery processes. ✅ Regular updates ensure data accuracy, reflecting new openings and closures.

Rich Business Insights: ✅ Detailed business attributes, including company name, category, and subcategories. ✅ Contact details, including phone number and website (if available). ✅ Consumer review insights, including rating distribution and total number of reviews (additional feature). ✅ Operating hours where available.

Ideal for Mapping & Location Analytics: ✅ Supports geospatial analysis & GIS applications. ✅ Enhances mapping & navigation solutions with structured POI data. ✅ Provides location intelligence for site selection & business expansion strategies.

Bulk Data Delivery (NO API): ✅ Delivered in bulk via S3 Bucket or cloud storage. ✅ Available in structured format (.json) for seamless integration.

🏆Primary Use Cases:

Mapping & Geographic Analysis: 🔹 Power GIS platforms & navigation systems with precise POI data. 🔹 Enhance digital maps with accurate business locations & categories.

Retail Expansion & Market Research: 🔹 Identify key business locations & competitors for market analysis. 🔹 Assess brand presence across different industries & geographies.

Business Intelligence & Competitive Analysis: 🔹 Benchmark competitor locations & regional business density. 🔹 Analyze market trends through POI growth & closure tracking.

Smart City & Urban Planning: 🔹 Support public infrastructure projects with accurate POI data. 🔹 Improve accessibility & zoning decisions for government & businesses.

💡 Why Choose Xverum’s POI Data?

• 230M+ Verified POI Records – One of the largest & most detailed location datasets available.
• Global Coverage – POI data from 249+ countries, covering all major business sectors.
• Regular Updates – Ensuring accurate tracking of business openings & closures.
• Comprehensive Geographic & Business Data – Coordinates, addresses, categories, and more.
• Bulk Dataset Delivery – S3 Bucket & cloud storage delivery for full dataset access.
• 100% Compliant – Ethically sourced, privacy-compliant data.

Access Xverum’s 230M+ POI dataset for mapping, geographic analysis, and location intelligence. Request a free sample or contact us to customize your dataset today!

Unlock precise, high-quality GIS data covering 164M+ verified locations across 220+ countries. With 50+ enriched attributes including coordinates, building structures, and spatial geometry our dataset provides the granularity and accuracy needed for in-depth spatial analysis. Powered by AI-driven enrichment and deduplication, and backed by 30+ years of expertise, our GIS solutions support industries ranging from mapping and navigation to urban planning and market analysis, helping businesses and organizations make smarter, data-driven decisions.

Key use cases of GIS Data helping our customers :

1. Optimize Mapping & Spatial Analysis : Use GIS data to analyse landscapes, urban infrastructure, and competitor locations, ensuring data-driven planning and decision-making.
2. Enhance Navigation & Location-Based Services : Improve real-time route planning, asset tracking, and EV charging station discovery for seamless location-based experiences.
3. Identify Strategic Sites for Business Expansion : Leverage GIS intelligence to select optimal retail sites, franchise locations, and warehouses with precision.
4. Improve Logistics & Address Accuracy : Streamline delivery networks, validate addresses, and optimize courier routes to boost efficiency and customer satisfaction.
5. Support Environmental & Urban Development Initiatives : Utilize GIS insights for disaster preparedness, sustainable city planning, and land-use management.

The new Oregon Address Geocoder is used to find the location coordinates for street addresses in the State of Oregon. This service is:Free PublicUpdated regularlyOutputs location coordinates in Oregon Lambert, feet (SRID 2992)Uses over 2 million address points and 288,000 streets for referenceIt is an ArcGIS multirole locator with two roles:Point Address - Generally more accurate results from rooftop location points. Includes a Subaddress if a unit number is located. Street Address - Less accurate results from an estimated distance along a street centerline address range if a Point Address was not found.Instructions for using the Geocoder via ArcGIS Pro, ArcGIS Online, and REST Services are below:ArcGIS ProWeb ServicesArcGIS Online

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)

Last Revised: February 2016

Map Information

This nowCOAST™ time-enabled map service provides maps depicting the latest global forecast guidance of water currents, water temperature, and salinity at forecast projections: 0, 12, 24, 36, 48, 60, 72, 84, and 96-hours from the NWS/NCEP Global Real-Time Ocean Forecast System (GRTOFS). The surface water currents velocity maps display the direction using white or black streaklets. The magnitude of the current is indicated by the length and width of the streaklet. The maps of the GRTOFS surface forecast guidance are updated on the nowCOAST™ map service once per day. For more detailed information about layer update frequency and timing, please reference the
nowCOAST™ Dataset Update Schedule.

Background Information

GRTOFS is based on the Hybrid Coordinates Ocean Model (HYCOM), an eddy resolving, hybrid coordinate numerical ocean prediction model. GRTOFS has global coverge and a horizontal resolution of 1/12 degree and 32 hybrid vertical layers. It has one forecast cycle per day (i.e. 0000 UTC) which generates forecast guidance out to 144 hours (6 days). However, nowCOAST™ only provides guidance out to 96 hours (4 days). The forecast cycle uses 3-hourly momentum and radiation fluxes along with precipitation predictions from the NCEP Global Forecast System (GFS). Each forecast cycle is preceded with a 48-hr long nowcast cycle. The nowcast cycle uses daily initial 3-D fields from the NAVOCEANO operational HYCOM-based forecast system which assimilates situ profiles of temperature and salinity from a variety of sources and remotely sensed SST, SSH and sea-ice concentrations. GRTOFS was developed by NCEP/EMC/Marine Modeling and Analysis Branch. GRTOFS is run once per day (0000 UTC forecast cycle) on the NOAA Weather and Climate Operational Supercomputer System (WCOSS) operated by NWS/NCEP Central Operations.

The maps are generated using a visualization technique developed by the Data Visualization Research Lab at The University of New Hampshire's Center for Coastal and Ocean Mapping (http://www.ccom.unh.edu/vislab/). The method combines two techniques. First, equally spaced streamlines are computed in the flow field using Jobard and Lefer's (1977) algorithm. Second, a series of "streaklets" are rendered head to tail along each streamline to show the direction of flow. Each of these varies along its length in size, color and transparency using a method developed by Fowler and Ware (1989), and later refined by Mr. Pete Mitchell and Dr. Colin Ware (Mitchell, 2007).

Time Information

This map service is time-enabled, meaning that each individual layer contains time-varying data and can be utilized by clients capable of making map requests that include a time component.

In addition to ArcGIS Server REST access, time-enabled OGC WMS 1.3.0 access is also provided by this service.

This particular service can be queried with or without the use of a time component. If the time parameter is specified in a request, the data or imagery most relevant to the provided time value, if any, will be returned. If the time parameter is not specified in a request, the latest data or imagery valid for the present system time will be returned to the client. If the time parameter is not specified and no data or imagery is available for the present time, no data will be returned.

This service is configured with time coverage support, meaning that the service will always return the most relevant available data, if any, to the specified time value. For example, if the service contains data valid today at 12:00 and 12:10 UTC, but a map request specifies a time value of today at 12:07 UTC, the data valid at 12:10 UTC will be returned to the user. This behavior allows more flexibility for users, especially when displaying multiple time-enabled layers together despite slight differences in temporal resolution or update frequency.

When interacting with this time-enabled service, only a single instantaneous time value should be specified in each request. If instead a time range is specified in a request (i.e. separate start time and end time values are given), the data returned may be different than what was intended.

Care must be taken to ensure the time value specified in each request falls within the current time coverage of the service. Because this service is frequently updated as new data becomes available, the user must periodically determine the service's time extent. However, due to software limitations, the time extent of the service and map layers as advertised by ArcGIS Server does not always provide the most up-to-date start and end times of available data. Instead, users have three options for determining the latest time extent of the service:

  Issue a returnUpdates=true request (ArcGIS REST protocol only)
  for an individual layer or for the service itself, which will return
  the current start and end times of available data, in epoch time format
  (milliseconds since 00:00 January 1, 1970). To see an example, click on
  the "Return Updates" link at the bottom of the REST Service page under
  "Supported Operations". Refer to the
  ArcGIS REST API Map Service Documentation
  for more information.


  Issue an Identify (ArcGIS REST) or GetFeatureInfo (WMS) request against
  the proper layer corresponding with the target dataset. For raster
  data, this would be the "Image Footprints with Time Attributes" layer
  in the same group as the target "Image" layer being displayed. For
  vector (point, line, or polygon) data, the target layer can be queried
  directly. In either case, the attributes returned for the matching
  raster(s) or vector feature(s) will include the following:


      validtime: Valid timestamp.


      starttime: Display start time.


      endtime: Display end time.


      reftime: Reference time (sometimes referred to as
      issuance time, cycle time, or initialization time).


      projmins: Number of minutes from reference time to valid
      time.


      desigreftime: Designated reference time; used as a
      common reference time for all items when individual reference
      times do not match.


      desigprojmins: Number of minutes from designated
      reference time to valid time.




  Query the nowCOAST™ LayerInfo web service, which has been created to
  provide additional information about each data layer in a service,
  including a list of all available "time stops" (i.e. "valid times"),
  individual timestamps, or the valid time of a layer's latest available
  data (i.e. "Product Time"). For more information about the LayerInfo
  web service, including examples of various types of requests, refer to
  the 
  nowCOAST™ LayerInfo Help Documentation

References

Fowler, D. and C. Ware, 1989: Strokes for Representing Vector Field Maps. Proceedings: Graphics Interface '98 249-253. Jobard, B and W. Lefer,1977: Creating evenly spaced streamlines of arbitrary density. Proceedings: Eurographics workshop on Visualization in Scientific Computing. 43-55. Mitchell, P.W., 2007: The Perceptual optimization of 2D Flow Visualizations Using Human in the Loop Local Hill Climbing. University of New Hampshire Masters Thesis. Department of Computer Science. NWS, 2013: About Global RTOFS, NCEP/EMC/MMAB, College Park, MD (Available at http://polar.ncep.noaa.gov/global/about/). Chassignet, E.P., H.E. Hurlburt, E.J. Metzger, O.M. Smedstad, J. Cummings, G.R. Halliwell, R. Bleck, R. Baraille, A.J. Wallcraft, C. Lozano, H.L. Tolman, A. Srinivasan, S. Hankin, P. Cornillon, R. Weisberg, A. Barth, R. He, F. Werner, and J. Wilkin, 2009: U.S. GODAE: Global Ocean Prediction with the HYbrid Coordinate Ocean Model (HYCOM). Oceanography, 22(2), 64-75. Mehra, A, I. Rivin, H. Tolman, T. Spindler, and B. Balasubramaniyan, 2011: A Real-Time Operational Global Ocean Forecast System, Poster, GODAE OceanView –GSOP-CLIVAR Workshop in Observing System Evaluation and Intercomparisons, Santa Cruz, CA.

Protracted section boundaries were electronically generated using aliquot part algorithms developed by DNR staff. These digital protracted sections are based on a framework of non-graphic township coordinate files. The programs make calculations from the radian measurements representing township corner coordinates. At the time when these section coverages were constructed, both DNR and BLM stored their radian measurements to twelve positions of accuracy, which allows resolution of less than one meter.

Polygon attributes contain the BLM index number, meridian, township, range, and section number for each section. This coverage is intended to geographically represent BLM's protracted sections for on-shore townships and DNR's protracted sections for off-shore townships, and is not capable of supporting survey quality area calculations.

Statistical analyses and maps representing mean, high, and low water-level conditions in the surface water and groundwater of Miami-Dade County were made by the U.S. Geological Survey, in cooperation with the Miami-Dade County Department of Regulatory and Economic Resources, to help inform decisions necessary for urban planning and development. Sixteen maps were created that show contours of (1) the mean of daily water levels at each site during October and May for the 2000-2009 water years; (2) the 25th, 50th, and 75th percentiles of the daily water levels at each site during October and May and for all months during 2000-2009; and (3) the differences between mean October and May water levels, as well as the differences in the percentiles of water levels for all months, between 1990-1999 and 2000-2009. The 80th, 90th, and 96th percentiles of the annual maximums of daily groundwater levels during 1974-2009 (a 35-year period) were computed to provide an indication of unusually high groundwater-level conditions. These maps and statistics provide a generalized understanding of the variations of water levels in the aquifer, rather than a survey of concurrent water levels. Water-level measurements from 473 sites in Miami-Dade County and surrounding counties were analyzed to generate statistical analyses. The monitored water levels included surface-water levels in canals and wetland areas and groundwater levels in the Biscayne aquifer. Maps were created by importing site coordinates, summary water-level statistics, and completeness of record statistics into a geographic information system, and by interpolating between water levels at monitoring sites in the canals and water levels along the coastline. Raster surfaces were created from these data by using the triangular irregular network interpolation method. The raster surfaces were contoured by using geographic information system software. These contours were imprecise in some areas because the software could not fully evaluate the hydrology given available information; therefore, contours were manually modified where necessary. The ability to evaluate differences in water levels between 1990-1999 and 2000-2009 is limited in some areas because most of the monitoring sites did not have 80 percent complete records for one or both of these periods. The quality of the analyses was limited by (1) deficiencies in spatial coverage; (2) the combination of pre- and post-construction water levels in areas where canals, levees, retention basins, detention basins, or water-control structures were installed or removed; (3) an inability to address the potential effects of the vertical hydraulic head gradient on water levels in wells of different depths; and (4) an inability to correct for the differences between daily water-level statistics. Contours are dashed in areas where the locations of contours have been approximated because of the uncertainty caused by these limitations. Although the ability of the maps to depict differences in water levels between 1990-1999 and 2000-2009 was limited by missing data, results indicate that near the coast water levels were generally higher in May during 2000-2009 than during 1990-1999; and that inland water levels were generally lower during 2000-2009 than during 1990-1999. Generally, the 25th, 50th, and 75th percentiles of water levels from all months were also higher near the coast and lower inland during 2000–2009 than during 1990-1999. Mean October water levels during 2000-2009 were generally higher than during 1990-1999 in much of western Miami-Dade County, but were lower in a large part of eastern Miami-Dade County.

The geographic data are built from the Technical Information Management System (TIMS). TIMS consists of two separate databases: an attribute database and a spatial database. The attribute information for offshore activities is stored in the TIMS database. The spatial database is a combination of the ARC/INFO and FINDER databases and contains all the coordinates and topology information for geographic features. The attribute and spatial databases are interconnected through the use of common data elements in both databases, thereby creating the spatial datasets. The data in the mapping files are made up of straight-line segments. If an arc existed in the original data, it has been replaced with a series of straight lines that approximate the arc. The Gulf of America OCS Region stores all its mapping data in longitude and latitude format. All coordinates are in NAD 27. Data can be obtained in three types of digital formats: INTERACTIVE MAP: The ArcGIS web maps are an interactive display of geographic information, containing a basemap, a set of data layers (many of which include interactive pop-up windows with information about the data), an extent, navigation tools to pan and zoom, and additional tools for geospatial analysis. SHP: A Shapefile is a digital vector (non-topological) storage format for storing geometric location and associated attribute information. Shapefiles can support point, line, and area features with attributes held in a dBASE format file. GEODATABASE: An ArcGIS geodatabase is a collection of geographic datasets of various types held in a common file system folder, a Microsoft Access database, or a multiuser relational DBMS (such as Oracle, Microsoft SQL Server, PostgreSQL, Informix, or IBM DB2). The geodatabase is the native data structure for ArcGIS and is the primary data format used for editing and data management.