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

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

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

(Link to Metadata) Generated from exact latitude-longitude coordinates and projected from Geographic coordinates (Lat/Long) NAD83 into State Plane Meters NAD83. The Arc/Info GENERATE command was used with the following parameters; generate BoundaryTile_QUAD83 fishnet no labels -73.500,42.625 -73.500,42.725 0.125,0.125 20,17 The Arc/Info project command was then used to re-project from Geographic (DD)NAD83 into Vermont State Plane Meters (NAD83). Extraneous polygons where removed. Polygon label points where transfered from the QUAD coverage into the new coverage, resulting in duplicate attribute items. The tics in this data layer should only be used for digitizing if your source data is in NAD83! Use BoundaryTile_QUAD27 if your source data is in NAD27. In both cases you should re-project this coverage into UTM before digitizing. When you've completed your digitizing work re-project the data back into Vermont State Plane Meters NAD83.

Overview

This dataset contains all DOMI Street Closure Permit data in the Computronix (CX) system from the date of its adoption (in May 2020) until the present. The data in each record can be used to determine when street closures are occurring, who is requesting these closures, why the closure is being requested, and for mapping the closures themselves. It is updated hourly (as of March 2024).

Preprocessing/Formatting

It is important to distinguish between a permit, a permit's street closure(s), and the roadway segments that are referenced to that closure(s).

• The CX system identifies a street in segments of roadway. (As an example, the CX system could divide Maple Street into multiple segments.)

• A single street closure may span multiple segments of a street.

• The street closure permit refers to all the component line segments.

• A permit may have multiple streets which are closed. Street closure permits often reference many segments of roadway.

The roadway_id field is a unique GIS line segment representing the aforementioned segments of road. The roadway_id values are assigned internally by the CX system and are unlikely to be known by the permit applicant. A section of roadway may have multiple permits issued over its lifespan. Therefore, a given roadway_id value may appear in multiple permits.

The field closure_id represents a unique ID for each closure, and permit_id uniquely identifies each permit. This is in contrast to the aforementioned roadway_id field which, again, is a unique ID only for the roadway segments.

City teams that use this data requested that each segment of each street closure permit be represented as a unique row in the dataset. Thus, a street closure permit that refers to three segments of roadway would be represented as three rows in the table. Aside from the roadway_id field, most other data from that permit pertains equally to those three rows. Thus, the values in most fields of the three records are identical.

Each row has the fields segment_num and total_segments which detail the relationship of each record, and its corresponding permit, according to street segment. The above example produced three records for a single permit. In this case, total_segments would equal 3 for each record. Each of those records would have a unique value between 1 and 3.

The geometry field consists of string values of lat/long coordinates, which can be used to map the street segments.

All string text (most fields) were converted to UPPERCASE data. Most of the data are manually entered and often contain non-uniform formatting. While several solutions for cleaning the data exist, text were transformed to UPPERCASE to provide some degree of regularization. Beyond that, it is recommended that the user carefully think through cleaning any unstructured data, as there are many nuances to consider. Future improvements to this ETL pipeline may approach this problem with a more sophisticated technique.

Known Uses

These data are used by DOMI to track the status of street closures (and associated permits).

Further Documentation and Resources

An archived dataset containing historical street closure records (from before May of 2020) for the City of Pittsburgh may be found here: https://data.wprdc.org/dataset/right-of-way-permits

This feature class represents an index of records from the California Department of Water Resources' (DWR) Online System for Well Completion Reports (OSWCR). This feature class is for informational purposes only. All attribute values should be verified by reviewing the original Well Completion Report. Known issues include: - Missing and duplicate records - Missing values (either missing on original Well Completion Report, or not key entered into database) - Incorrect values (e.g. incorrect Latitude, Longitude, Record Type, Planned Use, Total Completed Depth) - Limited spatial resolution: The majority of well completion reports have been spatially registered to the center of the 1x1 mile Public Land Survey System section that the well is located in.

Summary Rail Crossings is a spatial file maintained by the Federal Railroad Administration (FRA) for use by States and railroads. Description FRA Grade Crossings is a spatial file that originates from the National Highway-Rail Crossing, Inventory Program. The program is to provide information to Federal, State, and local governments, as well as the railroad industry for the improvements of safety at highway-rail crossing. Credits Federal Railroad Administration (FRA) Use limitations There are no access and use limitations for this item. Extent West -79.491008 East -75.178954 North 39.733500 South 38.051719 Scale Range Maximum (zoomed in) 1:5,000 Minimum (zoomed out) 1:150,000,000 ArcGIS Metadata ▼►Topics and Keywords ▼►Themes or categories of the resource  transportation * Content type  Downloadable Data Export to FGDC CSDGM XML format as Resource Description No Temporal keywords  2013 Theme keywords  Rail Theme keywords  Grade Crossing Theme keywords  Rail Crossings Citation ▼►Title rr_crossings Creation date 2013-03-15 00:00:00 Presentation formats  * digital map Citation Contacts ▼►Responsible party  Individual's name Raquel Hunt Organization's name Federal Railroad Administration (FRA) Contact's position GIS Program Manager Contact's role  custodian Responsible party  Organization's name Research and Innovative Technology Administration/Bureau of Transportation Statistics Individual's name National Transportation Atlas Database (NTAD) 2013 Contact's position Geospatial Information Systems Contact's role  distributor Contact information  ▼►Phone  Voice 202-366-DATA Address  Type  Delivery point 1200 New Jersey Ave. SE City Washington Administrative area DC Postal code 20590 e-mail address answers@BTS.gov Resource Details ▼►Dataset languages  * English (UNITED STATES) Dataset character set  utf8 - 8 bit UCS Transfer Format Spatial representation type  * vector * Processing environment Microsoft Windows 7 Version 6.1 (Build 7600) ; Esri ArcGIS 10.2.0.3348 Credits Federal Railroad Administration (FRA) ArcGIS item properties  * Name USDOT_RRCROSSINGS_MD * Size 0.047 Location withheld * Access protocol Local Area Network Extents ▼►Extent  Geographic extent  Bounding rectangle  Extent type  Extent used for searching * West longitude -79.491008 * East longitude -75.178954 * North latitude 39.733500 * South latitude 38.051719 * Extent contains the resource Yes Extent in the item's coordinate system  * West longitude 611522.170675 * East longitude 1824600.445629 * South latitude 149575.449134 * North latitude 752756.624659 * Extent contains the resource Yes Resource Points of Contact ▼►Point of contact  Individual's name Raquel Hunt Organization's name Federal Railroad Administration (FRA) Contact's position GIS Program Manager Contact's role  custodian Resource Maintenance ▼►Resource maintenance  Update frequency  annually Resource Constraints ▼►Constraints  Limitations of use There are no access and use limitations for this item. Spatial Reference ▼►ArcGIS coordinate system  * Type Projected * Geographic coordinate reference GCS_North_American_1983_HARN * Projection NAD_1983_HARN_StatePlane_Maryland_FIPS_1900_Feet * Coordinate reference details  Projected coordinate system  Well-known identifier 2893 X origin -120561100 Y origin -95444400 XY scale 36953082.294548117 Z origin -100000 Z scale 10000 M origin -100000 M scale 10000 XY tolerance 0.0032808333333333331 Z tolerance 0.001 M tolerance 0.001 High precision true Latest well-known identifier 2893 Well-known text PROJCS["NAD_1983_HARN_StatePlane_Maryland_FIPS_1900_Feet",GEOGCS["GCS_North_American_1983_HARN",DATUM["D_North_American_1983_HARN",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree"

The dataset and the validation are fully described in a Nature Scientific Data Descriptor https://www.nature.com/articles/s41597-019-0265-5

If you want to use this dataset in an interactive environment, then use this link https://mybinder.org/v2/gh/GeographerAtLarge/TravelTime/HEAD

The following text is a summary of the information in the above Data Descriptor.

The dataset is a suite of global travel-time accessibility indicators for the year 2015, at approximately one-kilometre spatial resolution for the entire globe. The indicators show an estimated (and validated), land-based travel time to the nearest city and nearest port for a range of city and port sizes.

The datasets are in GeoTIFF format and are suitable for use in Geographic Information Systems and statistical packages for mapping access to cities and ports and for spatial and statistical analysis of the inequalities in access by different segments of the population.

These maps represent a unique global representation of physical access to essential services offered by cities and ports.

The datasets travel_time_to_cities_x.tif (where x has values from 1 to 12) The value of each pixel is the estimated travel time in minutes to the nearest urban area in 2015. There are 12 data layers based on different sets of urban areas, defined by their population in year 2015 (see PDF report).

travel_time_to_ports_x (x ranges from 1 to 5)

The value of each pixel is the estimated travel time to the nearest port in 2015. There are 5 data layers based on different port sizes.

Format Raster Dataset, GeoTIFF, LZW compressed Unit Minutes

Data type Byte (16 bit Unsigned Integer)

No data value 65535

Flags None

Spatial resolution 30 arc seconds

Spatial extent

Upper left -180, 85

Lower left -180, -60 Upper right 180, 85 Lower right 180, -60 Spatial Reference System (SRS) EPSG:4326 - WGS84 - Geographic Coordinate System (lat/long)

Temporal resolution 2015

Temporal extent Updates may follow for future years, but these are dependent on the availability of updated inputs on travel times and city locations and populations.

Methodology Travel time to the nearest city or port was estimated using an accumulated cost function (accCost) in the gdistance R package (van Etten, 2018). This function requires two input datasets: (i) a set of locations to estimate travel time to and (ii) a transition matrix that represents the cost or time to travel across a surface.

The set of locations were based on populated urban areas in the 2016 version of the Joint Research Centre’s Global Human Settlement Layers (GHSL) datasets (Pesaresi and Freire, 2016) that represent low density (LDC) urban clusters and high density (HDC) urban areas (https://ghsl.jrc.ec.europa.eu/datasets.php). These urban areas were represented by points, spaced at 1km distance around the perimeter of each urban area.

Marine ports were extracted from the 26th edition of the World Port Index (NGA, 2017) which contains the location and physical characteristics of approximately 3,700 major ports and terminals. Ports are represented as single points

The transition matrix was based on the friction surface (https://map.ox.ac.uk/research-project/accessibility_to_cities) from the 2015 global accessibility map (Weiss et al, 2018).

Code The R code used to generate the 12 travel time maps is included in the zip file that can be downloaded with these data layers. The processing zones are also available.

Validation The underlying friction surface was validated by comparing travel times between 47,893 pairs of locations against journey times from a Google API. Our estimated journey times were generally shorter than those from the Google API. Across the tiles, the median journey time from our estimates was 88 minutes within an interquartile range of 48 to 143 minutes while the median journey time estimated by the Google API was 106 minutes within an interquartile range of 61 to 167 minutes. Across all tiles, the differences were skewed to the left and our travel time estimates were shorter than those reported by the Google API in 72% of the tiles. The median difference was −13.7 minutes within an interquartile range of −35.5 to 2.0 minutes while the absolute difference was 30 minutes or less for 60% of the tiles and 60 minutes or less for 80% of the tiles. The median percentage difference was −16.9% within an interquartile range of −30.6% to 2.7% while the absolute percentage difference was 20% or less in 43% of the tiles and 40% or less in 80% of the tiles.

This process and results are included in the validation zip file.

Usage Notes The accessibility layers can be visualised and analysed in many Geographic Information Systems or remote sensing software such as QGIS, GRASS, ENVI, ERDAS or ArcMap, and also by statistical and modelling packages such as R or MATLAB. They can also be used in cloud-based tools for geospatial analysis such as Google Earth Engine.

The nine layers represent travel times to human settlements of different population ranges. Two or more layers can be combined into one layer by recording the minimum pixel value across the layers. For example, a map of travel time to the nearest settlement of 5,000 to 50,000 people could be generated by taking the minimum of the three layers that represent the travel time to settlements with populations between 5,000 and 10,000, 10,000 and 20,000 and, 20,000 and 50,000 people.

The accessibility layers also permit user-defined hierarchies that go beyond computing the minimum pixel value across layers. A user-defined complete hierarchy can be generated when the union of all categories adds up to the global population, and the intersection of any two categories is empty. Everything else is up to the user in terms of logical consistency with the problem at hand.

The accessibility layers are relative measures of the ease of access from a given location to the nearest target. While the validation demonstrates that they do correspond to typical journey times, they cannot be taken to represent actual travel times. Errors in the friction surface will be accumulated as part of the accumulative cost function and it is likely that locations that are further away from targets will have greater a divergence from a plausible travel time than those that are closer to the targets. Care should be taken when referring to travel time to the larger cities when the locations of interest are extremely remote, although they will still be plausible representations of relative accessibility. Furthermore, a key assumption of the model is that all journeys will use the fastest mode of transport and take the shortest path.

GapMaps GIS Data by Azira uses location data on mobile phones sourced by Azira which is collected from smartphone apps when the users have given their permission to track their location. It can shed light on consumer visitation patterns (“where from” and “where to”), frequency of visits, profiles of consumers and much more.

Businesses can utilise GIS data to answer key questions including: - What is the demographic profile of customers visiting my locations? - What is my primary catchment? And where within that catchment do most of my customers travel from to reach my locations? - What points of interest drive customers to my locations (ie. work, shopping, recreation, hotel or education facilities that are in the area) ? - How far do customers travel to visit my locations? - Where are the potential gaps in my store network for new developments?
- What is the sales impact on an existing store if a new store is opened nearby? - Is my marketing strategy targeted to the right audience? - Where are my competitor's customers coming from?

Mobile Location data provides a range of benefits that make it a valuable GIS Data source for location intelligence services including: - Real-time - Low-cost at high scale - Accurate - Flexible - Non-proprietary - Empirical

Azira have created robust screening methods to evaluate the quality of Mobile location data collected from multiple sources to ensure that their data lake contains only the highest-quality mobile location data.

This includes partnering with trusted location SDK providers that get proper end user consent to track their location when they download an application, can detect device movement/visits and use GPS to determine location co-ordinates.

Data received from partners is put through Azira's data quality algorithm discarding data points that receive a low quality score.

Use cases in Europe will be considered on a case to case basis.

These data include the individual responses for the City of Tempe Annual Business Survey conducted by ETC Institute. These data help determine priorities for the community as part of the City's on-going strategic planning process. Averaged Business Survey results are used as indicators for city performance measures. The performance measures with indicators from the Business Survey include the following (as of 2023):1. Financial Stability and Vitality5.01 Quality of Business ServicesThe location data in this dataset is generalized to the block level to protect privacy. This means that only the first two digits of an address are used to map the location. When they data are shared with the city only the latitude/longitude of the block level address points are provided. This results in points that overlap. In order to better visualize the data, overlapping points were randomly dispersed to remove overlap. The result of these two adjustments ensure that they are not related to a specific address, but are still close enough to allow insights about service delivery in different areas of the city.Additional InformationSource: Business SurveyContact (author): Adam SamuelsContact E-Mail (author): Adam_Samuels@tempe.govContact (maintainer): Contact E-Mail (maintainer): Data Source Type: Excel tablePreparation Method: Data received from vendor after report is completedPublish Frequency: AnnualPublish Method: ManualData DictionaryMethods:The survey is mailed to a random sample of businesses in the City of Tempe. Follow up emails and texts are also sent to encourage participation. A link to the survey is provided with each communication. To prevent people who do not live in Tempe or who were not selected as part of the random sample from completing the survey, everyone who completed the survey was required to provide their address. These addresses were then matched to those used for the random representative sample. If the respondent’s address did not match, the response was not used.To better understand how services are being delivered across the city, individual results were mapped to determine overall distribution across the city.Processing and Limitations:The location data in this dataset is generalized to the block level to protect privacy. This means that only the first two digits of an address are used to map the location. When they data are shared with the city only the latitude/longitude of the block level address points are provided. This results in points that overlap. In order to better visualize the data, overlapping points were randomly dispersed to remove overlap. The result of these two adjustments ensure that they are not related to a specific address, but are still close enough to allow insights about service delivery in different areas of the city.The data are used by the ETC Institute in the final published PDF report.

On March 10, 2023, the Johns Hopkins Coronavirus Resource Center ceased collecting and reporting of global COVID-19 data. For updated cases, deaths, and vaccine data please visit the following sources:Global: World Health Organization (WHO)U.S.: U.S. Centers for Disease Control and Prevention (CDC)For more information, visit the Johns Hopkins Coronavirus Resource Center.This feature layer contains the most up-to-date COVID-19 cases for the US and Canada. Data sources: WHO, CDC, ECDC, NHC, DXY, 1point3acres, Worldometers.info, BNO, state and national government health departments, and local media reports. This layer is created and maintained by the Center for Systems Science and Engineering (CSSE) at the Johns Hopkins University. This feature layer is supported by the Esri Living Atlas team and JHU Data Services. This layer is opened to the public and free to share. Contact Johns Hopkins.IMPORTANT NOTICE: 1. Fields for Active Cases and Recovered Cases are set to 0 in all locations. John Hopkins has not found a reliable source for this information at the county level but will continue to look and carry the fields.2. Fields for Incident Rate and People Tested are placeholders for when this becomes available at the county level.3. In some instances, cases have not been assigned a location at the county scale. those are still assigned a state but are listed as unassigned and given a Lat Long of 0,0.Data Field Descriptions by Alias Name:Province/State: (Text) Country Province or State Name (Level 2 Key)Country/Region: (Text) Country or Region Name (Level 1 Key)Last Update: (Datetime) Last data update Date/Time in UTCLatitude: (Float) Geographic Latitude in Decimal Degrees (WGS1984)Longitude: (Float) Geographic Longitude in Decimal Degrees (WGS1984)Confirmed: (Long) Best collected count of Confirmed Cases reported by geographyRecovered: (Long) Not Currently in Use, JHU is looking for a sourceDeaths: (Long) Best collected count for Case Deaths reported by geographyActive: (Long) Confirmed - Recovered - Deaths (computed) Not Currently in Use due to lack of Recovered dataCounty: (Text) US County Name (Level 3 Key)FIPS: (Text) US State/County CodesCombined Key: (Text) Comma separated concatenation of Key Field values (L3, L2, L1)Incident Rate: (Long) People Tested: (Long) Not Currently in Use Placeholder for additional dataPeople Hospitalized: (Long) Not Currently in Use Placeholder for additional data

This data provides monthly average and annual average daily total solar resource averaged over surface cells of 0.1 degrees in both latitude and longitude, or about 10 km in size. This data was developed using the State University of New York/Albany satellite radiation model. This model was developed by Dr. Richard Perez and collaborators at the National Renewable Energy Laboratory and other universities for the U.S. Department of Energy. Specific information about this model can be found in Perez, et al. (2002). This model uses hourly radiance images from geostationary weather satellites, daily snow cover data, and monthly averages of atmospheric water vapor, trace gases, and the amount of aerosols in the atmosphere to calculate the hourly total insolation (sun and sky) falling on a horizontal surface. Atmospheric water vapor, trace gases, and aerosols are derived from a variety of sources. A modified Bird model is used to calculate clear sky direct normal (DNI). This is then adjusted as a function of the ratio of clear sky global horizontal (GHI) and the model predicted GHI. Where possible, existing ground measurement stations are used to validate the data. Nevertheless, there is uncertainty associated with the meteorological input to the model, since some of the input parameters are not available at a 10km resolution. As a result, it is believed that the modeled values are accurate to approximately 15% of a true measured value within the grid cell. Due to terrain effects and other microclimate influences, the local cloud cover can vary significantly even within a single grid cell. Furthermore, the uncertainty of the modeled estimates increase with distance from reliable measurement sources and with the complexity of the terrain.

License Info

DISCLAIMER NOTICE This GIS data was developed by the National Renewable Energy Laboratory ("NREL"), which is operated by the Alliance for Sustainable Energy, LLC for the U.S. Department of Energy ("DOE"). The user is granted the right, without any fee or cost, to use, copy, modify, alter, enhance and distribute this data for any purpose whatsoever, provided that this entire notice appears in all copies of the data. Further, the user of this data agrees to credit NREL in any publications or software that incorporate or use the data.

Access to and use of the GIS data shall further impose the following obligations on the User. The names DOE/NREL may not be used in any advertising or publicity to endorse or promote any product or commercial entity using or incorporating the GIS data unless specific written authorization is obtained from DOE/NREL. The User also understands that DOE/NREL shall not be obligated to provide updates, support, consulting, training or assistance of any kind whatsoever with regard to the use of the GIS data.

THE GIS DATA IS PROVIDED "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL DOE/NREL BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER, INCLUDING BUT NOT LIMITED TO CLAIMS ASSOCIATED WITH THE LOSS OF DATA OR PROFITS, WHICH MAY RESULT FROM AN ACTION IN CONTRACT, NEGLIGENCE OR OTHER TORTIOUS CLAIM THAT ARISES OUT OF OR IN CONNECTION WITH THE ACCESS OR USE OF THE GIS DATA.

The User acknowledges that access to the GIS data is subject to U.S. Export laws and regulations and any use or transfer of the GIS data must be authorized under those regulations. The User shall not use, distribute, transfer, or transmit GIS data or any products incorporating the GIS data except in compliance with U.S. export regulations. If requested by DOE/NREL, the User agrees to sign written assurances and other export-related documentation as may be required to comply with U.S. export regulations.

311 is a City of Cleveland program for reporting complaints and submitting service requests for non-emergency issues, such as potholes or problems with trash pickups. For emergencies, dial 911. This dataset includes 311 requests filed since 2/29/24. All records filed before 2/29/24 are archived. To view this list of archived 311 requests, click here. More information on Cleveland 311 can be found here: https://www.clevelandohio.gov/311. Please note: Prior to the new system launching on 9/4/2024, some dates in the close_date field are after the true date of closure. Update FrequencyDaily around 7:00 AM EST Contacts:311 or Open Data Team (opendata@clevelandohio.gov) Data GlossaryThis dataset is based on the Open311 data standard. Column | Descriptionservice_request_id | The unique ID (reference number) of the service request created in the 311 system. service_name | The human-readable name of the service request type.division_responsible | The Division or operation unit responsible for fulfilling or otherwise addressing the service request. agency_responsible | The Department responsible for fulfilling or otherwise addressing the service request.status_description | A single-word indicator of the current state of the service request.address | Human-readable address or description of location.requested_date | The date and time when the service request was made.updated_datetime | The date and time when the service request was last modified.closed_date | Date and time the request record was closed or cancelled.target_date | The date by which the request is targeted to be addressed by the responsible Department. source | Mechanism or path by which the service request was received.parcelpin | The ID number for the parcel where the request is located.neighborhood | The neighborhood where the request is located.ward_name | The ward where the request is located (full name). Will be updated from 2014 to 2026 wards at the start of the 2026 council term.ward | The ward where the request is located (as a number). Will be updated from 2014 to 2026 wards at the start of the 2026 council term.ward_name_2014 | The 2014 ward where the request is located (full name).ward_2014 | The 2014 ward where the request is located (as a number).ward_name_2026 | The 2026 ward where the request is located (full name).ward_2026 | The 2026 ward where the request is located (as a number).lat | Latitude of the location in decimal degrees.long | Longitude of the location in decimal degrees. Related Data Products:Cleveland 311 Request Explorer Cleveland 311 Service Request Report

Solar Footprints in CaliforniaThis GIS dataset consists of polygons that represent the footprints of solar powered electric generation facilities and related infrastructure in California called Solar Footprints. The location of solar footprints was identified using other existing solar footprint datasets from various sources along with imagery interpretation. CEC staff reviewed footprints identified with imagery and digitized polygons to match the visual extent of each facility. Previous datasets of existing solar footprints used to locate solar facilities include: GIS Layers: (1) California Solar Footprints, (2) UC Berkeley Solar Points, (3) Kruitwagen et al. 2021, (4) BLM Renewable Project Facilities, (5) Quarterly Fuel and Energy Report (QFER)Imagery Datasets: Esri World Imagery, USGS National Agriculture Imagery Program (NAIP), 2020 SENTINEL 2 Satellite Imagery, 2023Solar facilities with large footprints such as parking lot solar, large rooftop solar, and ground solar were included in the solar footprint dataset. Small scale solar (approximately less than 0.5 acre) and residential footprints were not included. No other data was used in the production of these shapes. Definitions for the solar facilities identified via imagery are subjective and described as follows: Rooftop Solar: Solar arrays located on rooftops of large buildings. Parking lot Solar: Solar panels on parking lots roughly larger than 1 acre, or clusters of solar panels in adjacent parking lots. Ground Solar: Solar panels located on ground roughly larger than 1 acre, or large clusters of smaller scale footprints. Once all footprints identified by the above criteria were digitized for all California counties, the features were visually classified into ground, parking and rooftop categories. The features were also classified into rural and urban types using the 42 U.S. Code § 1490 definition for rural. In addition, the distance to the closest substation and the percentile category of this distance (e.g. 0-25th percentile, 25th-50th percentile) was also calculated. The coverage provided by this data set should not be assumed to be a complete accounting of solar footprints in California. Rather, this dataset represents an attempt to improve upon existing solar feature datasets and to update the inventory of "large" solar footprints via imagery, especially in recent years since previous datasets were published. This procedure produced a total solar project footprint of 150,250 acres. Attempts to classify these footprints and isolate the large utility-scale projects from the smaller rooftop solar projects identified in the data set is difficult. The data was gathered based on imagery, and project information that could link multiple adjacent solar footprints under one larger project is not known. However, partitioning all solar footprints that are at least partly outside of the techno-economic exclusions and greater than 7 acres yields a total footprint size of 133,493 acres. These can be approximated as utility-scale footprints. Metadata: (1) CBI Solar FootprintsAbstract: Conservation Biology Institute (CBI) created this dataset of solar footprints in California after it was found that no such dataset was publicly available at the time (Dec 2015-Jan 2016). This dataset is used to help identify where current ground based, mostly utility scale, solar facilities are being constructed and will be used in a larger landscape intactness model to help guide future development of renewable energy projects. The process of digitizing these footprints first began by utilizing an excel file from the California Energy Commission with lat/long coordinates of some of the older and bigger locations. After projecting those points and locating the facilities utilizing NAIP 2014 imagery, the developed area around each facility was digitized. While interpreting imagery, there were some instances where a fenced perimeter was clearly seen and was slightly larger than the actual footprint. For those cases the footprint followed the fenced perimeter since it limits wildlife movement through the area. In other instances, it was clear that the top soil had been scraped of any vegetation, even outside of the primary facility footprint. These footprints included the areas that were scraped within the fencing since, especially in desert systems, it has been near permanently altered. Other sources that guided the search for solar facilities included the Energy Justice Map, developed by the Energy Justice Network which can be found here:https://www.energyjustice.net/map/searchobject.php?gsMapsize=large&giCurrentpageiFacilityid;=1&gsTable;=facility&gsSearchtype;=advancedThe Solar Energy Industries Association’s “Project Location Map” which can be found here: https://www.seia.org/map/majorprojectsmap.phpalso assisted in locating newer facilities along with the "Power Plants" shapefile, updated in December 16th, 2015, downloaded from the U.S. Energy Information Administration located here:https://www.eia.gov/maps/layer_info-m.cfmThere were some facilities that were stumbled upon while searching for others, most of these are smaller scale sites located near farm infrastructure. Other sites were located by contacting counties that had solar developments within the county. Still, others were located by sleuthing around for proposals and company websites that had images of the completed facility. These helped to locate the most recently developed sites and these sites were digitized based on landmarks such as ditches, trees, roads and other permanent structures.Metadata: (2) UC Berkeley Solar PointsUC Berkeley report containing point location for energy facilities across the United States.2022_utility-scale_solar_data_update.xlsm (live.com)Metadata: (3) Kruitwagen et al. 2021Abstract: Photovoltaic (PV) solar energy generating capacity has grown by 41 per cent per year since 2009. Energy system projections that mitigate climate change and aid universal energy access show a nearly ten-fold increase in PV solar energy generating capacity by 2040. Geospatial data describing the energy system are required to manage generation intermittency, mitigate climate change risks, and identify trade-offs with biodiversity, conservation and land protection priorities caused by the land-use and land-cover change necessary for PV deployment. Currently available inventories of solar generating capacity cannot fully address these needs. Here we provide a global inventory of commercial-, industrial- and utility-scale PV installations (that is, PV generating stations in excess of 10 kilowatts nameplate capacity) by using a longitudinal corpus of remote sensing imagery, machine learning and a large cloud computation infrastructure. We locate and verify 68,661 facilities, an increase of 432 per cent (in number of facilities) on previously available asset-level data. With the help of a hand-labelled test set, we estimate global installed generating capacity to be 423 gigawatts (−75/+77 gigawatts) at the end of 2018. Enrichment of our dataset with estimates of facility installation date, historic land-cover classification and proximity to vulnerable areas allows us to show that most of the PV solar energy facilities are sited on cropland, followed by arid lands and grassland. Our inventory could aid PV delivery aligned with the Sustainable Development GoalsEnergy Resource Land Use Planning - Kruitwagen_etal_Nature.pdf - All Documents (sharepoint.com)Metadata: (4) BLM Renewable ProjectTo identify renewable energy approved and pending lease areas on BLM administered lands. To provide information about solar and wind energy applications and completed projects within the State of California for analysis and display internally and externally. This feature class denotes "verified" renewable energy projects at the California State BLM Office, displayed in GIS. The term "Verified" refers to the GIS data being constructed at the California State Office, using the actual application/maps with legal descriptions obtained from the renewable energy company. https://www.blm.gov/wo/st/en/prog/energy/renewable_energy https://www.blm.gov/style/medialib/blm/wo/MINERALS_REALTY_AND_RESOURCE_PROTECTION_/energy/solar_and_wind.Par.70101.File.dat/Public%20Webinar%20Dec%203%202014%20-%20Solar%20and%20Wind%20Regulations.pdfBLM CA Renewable Energy Projects | BLM GBP Hub (arcgis.com)Metadata: (5) Quarterly Fuel and Energy Report (QFER) California Power Plants - Overview (arcgis.com)

World Latitude and Longitude Grids represents five latitude-longitude grids covering the world. The grids are provided at intervals of 1, 5, 10, 15, and 30 degrees and have visibility and scale ranges set for each to provide continuous delivery of a grid at any scale. To download the data for this layer as a layer package for use in ArcGIS desktop applications, refer to World Latitude and Longitude Grids.

(Link to Metadata) Generated from exact latitude-longitude coordinates and projected from Geographic coordinates (Lat/Long) NAD83 into State Plane Meters NAD83. The Arc/Info GENERATE command was used with the following parameters; generate BoundaryTile_QUAD83 fishnet no labels -73.500,42.625 -73.500,42.725 0.125,0.125 20,17 The Arc/Info project command was then used to re-project from Geographic (DD)NAD83 into Vermont State Plane Meters (NAD83). Extraneous polygons where removed. Polygon label points where transfered from the QUAD coverage into the new coverage, resulting in duplicate attribute items. The tics in this data layer should only be used for digitizing if your source data is in NAD83! Use BoundaryTile_QUAD27 if your source data is in NAD27. In both cases you should re-project this coverage into UTM before digitizing. When you've completed your digitizing work re-project the data back into Vermont State Plane Meters NAD83.

This is a list of all building permits issued in the City of Syracuse. The data details the location, type of permits, and cost of project.Data Dictionary:Application Date: The date that the permit was applied for.Permit Number: The number that is assigned to this permit request by the Central Permit Office.Parcel ID: The property parcel that this permit application is referencing.Zone Type Description: What type of district and class this parcel is located within.Issue Date: The date that the permit was issued by theApplication Number:Issue Date: The date that this permit was issued.LONG: The longitude coordinate for the permit, if available.LAT: The latitude coordinate for the permit, if available.

Points are extracted from the Citrix Facilities database. Locations are derived from the latitude/longitude coordinates entered into the Facilities database.

In this skill builder, you'll work with coordinates on the map. You'll do the following:View the coordinates as you move your mouse over the map Copy the coordinates Capture the coordinates of a location clicked on the map Convert the coordinates between different formats, including latitude and longitude (XY), decimal degrees (DD), degrees decimal minutes (DDM), degrees minutes seconds (DMS), military grid reference system (MGRS), United States National Grid (USNG), and Universal Transverse Mercator (UTM) Enter a coordinate and go to that location on the map