This street centerline lines feature class represents current right of way in the City of Los Angeles. It shows the official street names and is related to the official street name data. The Mapping and Land Records Division of the Bureau of Engineering, Department of Public Works provides the most current geographic information of the public right of way. The right of way information is available on NavigateLA, a website hosted by the Bureau of Engineering, Department of Public Works. Street Centerline layer was created in geographical information systems (GIS) software to display Dedicated street centerlines. The street centerline layer is a feature class in the LACityCenterlineData.gdb Geodatabase dataset. The layer consists of spatial data as a line feature class and attribute data for the features. City of LA District Offices use Street Centerline layer to determine dedication and street improvement requirements. Engineering street standards are followed to dedicate the street for development. The Bureau of Street Services tracks the location of existing streets, who need to maintain that road. Additional information was added to Street Centerline layer. Address range attributes were added make layer useful for geocoding. Section ID values from Bureau of Street Services were added to make layer useful for pavement management. Department of City Planning added street designation attributes taken from Community Plan maps. The street centerline relates to the Official Street Name table named EASIS, Engineering Automated Street Inventory System, which contains data describing the limits of the street segment. A street centerline segment should only be added to the Street Centerline layer if documentation exists, such as a Deed or a Plan approved by the City Council. Paper streets are street lines shown on a recorded plan but have not yet come into existence on the ground. These street centerline segments are in the Street Centerline layer because there is documentation such as a Deed or a Plan for the construction of that street. Previously, some street line features were added although documentation did not exist. Currently, a Deed, Tract, or a Plan must exist in order to add street line features. Many street line features were edited by viewing the Thomas Bros Map's Transportation layer, TRNL_037 coverage, back when the street centerline coverage was created. When TBM and BOE street centerline layers were compared visually, TBM's layer contained many valid streets that BOE layer did not contain. In addition to TBM streets, Planning Department requested adding street line segments they use for reference. Further, the street centerline layer features are split where the lines intersect. The intersection point is created and maintained in the Intersection layer. The intersection attributes are used in the Intersection search function on NavigateLA on BOE's web mapping application NavigateLA. The City of Los Angeles Municipal code states, all public right-of-ways (roads, alleys, etc) are streets, thus all of them have intersections. Note that there are named alleys in the BOE Street Centerline layer. Since the line features for named alleys are stored in the Street Centerline layer, there are no line features for named alleys in those areas that are geographically coincident in the Alley layer. For a named alley , the corresponding record contains the street designation field value of ST_DESIG = 20, and there is a name stored in the STNAME and STSFX fields.List of Fields:SHAPE: Feature geometry.OBJECTID: Internal feature number.STNAME_A: Street name Alias.ST_SUBTYPE: Street subtype.SV_STATUS: Status of street in service, whether the street is an accessible roadway. Values: • Y - Yes • N - NoTDIR: Street direction. Values: • S - South • N - North • E - East • W - WestADLF: From address range, left side.ZIP_R: Zip code right.ADRT: To address range, right side.INT_ID_TO: Street intersection identification number at the line segment's end node. The value relates to the intersection layer attribute table, to the CL_NODE_ID field. The values are assigned automatically and consecutively by the ArcGIS software first to the street centerline data layer and then the intersections data layer, during the creation of new intersection points. Each intersection identification number is a unique value.SECT_ID: Section ID used by the Bureau of Street Services. Values: • none - No Section ID value • private - Private street • closed - Street is closed from service • temp - Temporary • propose - Proposed construction of a street • walk - Street line is a walk or walkway • known as - • numeric value - A 7 digit numeric value for street resurfacing • outside - Street line segment is outside the City of Los Angeles boundary • pierce - Street segment type • alley - Named alleySTSFX_A: Street suffix Alias.SFXDIR: Street direction suffix Values: • N - North • E - East • W - West • S - SouthCRTN_DT: Creation date of the polygon feature.STNAME: Street name.ZIP_L: Zip code left.STSFX: Street suffix. Values: • BLVD - BoulevardADLT: To address range, left side.ID: Unique line segment identifierMAPSHEET: The alpha-numeric mapsheet number, which refers to a valid B-map or A-map number on the Cadastral tract index map. Values: • B, A, -5A - Any of these alpha-numeric combinations are used, whereas the underlined spaces are the numbers.STNUM: Street identification number. This field relates to the Official Street Name table named EASIS, to the corresponding STR_ID field.ASSETID: User-defined feature autonumber.TEMP: This attribute is no longer used. This attribute was used to enter 'R' for reference arc line segments that were added to the spatial data, in coverage format. Reference lines were temporary and not part of the final data layer. After editing the permanent line segments, the user would delete temporary lines given by this attribute.LST_MODF_DT: Last modification date of the polygon feature.REMARKS: This attribute is a combination of remarks about the street centerline. Values include a general remark, the Council File number, which refers the street status, or whether a private street is a private driveway. The Council File number can be researched on the City Clerk's website http://cityclerk.lacity.org/lacityclerkconnect/INT_ID_FROM: Street intersection identification number at the line segment's start node. The value relates to the intersection layer attribute table, to the CL_NODE_ID field. The values are assigned automatically and consecutively by the ArcGIS software first to the street centerline data layer and then the intersections data layer, during the creation of new intersection points. Each intersection identification number is a unique value.ADRF: From address range, right side.

For full data description please visit: Vicmap Hydro (land.vic.gov.au)Vicmap Hydro represents the natural and man-made water resources for Victoria and consists of point, line and polygon vector features in a seamless, networked and topologically structured dataset series. It comprises a basic framework of linear features supplemented by related point and polygon features to value add data for the water networks across the State. Attribute tables classify and describe the real-world features using code lists that can be used for search, discovery and analysis. The following hydrographic features are contained within Vicmap Hydro:• Watercourse (line)- watercourse, connector, channel, drain• Water Area (polygon)- lake, flat, wetland, pondage, watercourse area• Water Area Boundary (line)- shoreline, junction• Water Point (point)- rapids, spring, waterfall, waterbody point• Water Area Fuzzy (polygon) – bay, beach, bend, entrance, inlet, passage, reach, seaIn inland and coastal areas, point and line features are used to describe various waterline related structures:• Water Structure Line (line)- wharf, marina, offshore platform, breakwater, launching ramp, dam wall, spillway, lock• Water Structure Point (point)- lock, well• Water Structure Area (polygon)- dam batter, spillwayPolygon voidsPolygon features may contain an inner set of lines, holes or voids that cannot be assigned to any feature class within that layer. For example, a Lake in the Water Area layer may have in the middle of it an area of dry land. This would appear in the data as a polygon with no paracentroid. Coincident featuresThere will be no coincident polygons, lines (whole or in part) or points of the same feature type in the data (also frequently known as double digitising). Differing features may be coincident, as may be the case where a dam wall also forms part of a dam polygon, (in these cases, the common data repeats for each feature type, and is appropriately tagged and supplied as part of each feature type)ConnectorDrainage patterns are made up of both linear (narrow streams) and polygon features (such as watercourse areas, lakes and swamps) and consequently do not constitute a rigorous linear network. To allow linear analysis of drainage networks an artificial feature called a "Connector" has been added to the data.This Connector feature is used to connect linear watercourse features where they are separated by water areas such as lakes, swamps and watercourses depicted as area features. The points that make up this chain cannot be given any value for planimetric accuracy. The Connector will only be used if there is flow across a waterbody polygon feature. Thus, if there is only inflow to a lake and no outflow the Connector feature will not be used. Tributary watercourses flowing into a polygon area will be linked to the areas with Connectors.Connectors are also used for drainage conveyed by pipelines (Connector_structure). The diagram below demonstrates the relationship between underground pipelines and other drainage features for the situation where pipelines cross drainage features. In this situation the underground pipeline will form the connection with connector features in the watercourse layer and needs to be cloned in the watercourse layer as a connector. A node is to be created in the watercourse layer, on the connector, at the intersection of any drainage lines crossing pipeline connector.Junction The Junction is a linear feature which is an artificial line used to separate adjacent polygon areas across which flow can occur. For example, a Junction feature will separate the confluence of two watercourses where both are depicted as polygons. A Junction also separates watercourse polygons from the Sea. The Junction feature is arbitrarily placed and cannot be given any value for planimetric accuracy.Junction devices carry the attributes of the area entity they enclose.Junction features will not be placed:• separating 2 water bodies with identical attributes.• separating polygons of different feature class except separating watercourse polygons, canal polygons, lakes, reservoirs and the sea from one another.Junction features will be placed:• separating double line watercourses from other water bodies such as lakes and reservoirs.• separating waterbody polygons of the same class but with different attributes.• closing the mouth of rivers (waterbodies).• filling the coastal gaps in the framework layer. Cross border data is not subject to the same data structures or accuracy as the content within Victoria. This is due to the differences in the data models between the States.

A spatial representation of structures where persons of various religious denominations congregate. This point feature class was created using heads up digitizing with Oakland County's 2002 orthoimagery and Road Centerline feature class as a reference.This dataset is not recreated each year. Instead it is verified and updated as necessary. In September, 2016, the existing feature class was compared to outside sources to verify if any updates or edits were necessary. The data was updated on May, 2018, per ad hoc requested by local municipality. The key attributes include the facility Name, Address and Type.

Overview: This dataset was designed for understanding the influence of various classroom environmental factors on student performance. It contains synthetic data based on real-world variables known to impact the learning experience, including air quality, classroom layout, student density, and environmental conditions. The data is primarily focused on classroom dimensions, air quality metrics, student engagement factors, and dynamic performance outcomes.

The dataset contains 15,000 data points of classroom settings from a variety of student environments, providing valuable insights for educational researchers, policymakers, and institutions looking to enhance the learning experience by optimizing environmental factors.

Features: Length (L) (m):

The length of the classroom (in meters), ranging from 8 to 12 meters. This affects space utilization and airflow, contributing to overall classroom comfort. Width (W) (m):

The width of the classroom (in meters), ranging from 6 to 10 meters. Influences classroom layout and seating arrangement. Height (H) (m):

The height of the classroom (in meters), ranging from 2.5 to 4 meters. Affects air circulation and overall comfort levels. Number of Students (N):

The number of students in the classroom, ranging from 51 to 120 students. Higher student count can affect air quality and classroom dynamics. Airflow (Q) (m³/hr):

The total airflow in cubic meters per hour, based on the number of students in the classroom. The airflow helps to maintain air quality, and reduced airflow may correlate with lower student performance due to poor ventilation. Heat Generation (Q, Watts):

The heat generated by students in the classroom, assuming each student generates 100 watts of heat. This can impact temperature levels, influencing comfort and student focus. Lighting Intensity (lux):

The intensity of lighting in the classroom (measured in lux), which can affect visual comfort and focus. Ranges from 200 to 1000 lux, with dim lighting potentially causing fatigue and reducing performance. Noise Level (dB):

The noise level in decibels, influenced by the number of students. More students lead to higher noise levels, which could negatively impact concentration. Ergonomic Comfort:

A rating of seating comfort, ranging from 50 to 100, depending on the number of students and classroom layout. Higher comfort levels correlate with better student focus and engagement. Classroom Layout:

A categorical variable indicating the classroom layout: 0: Rows 1: Clusters 2: Circles Different layouts can influence student interaction, visibility, and engagement. Visual Accessibility:

A score indicating how well students can see and interact with materials (e.g., the blackboard or projector). Larger classrooms or improper seating arrangements can reduce visual accessibility, impacting learning. Greenery (%):

The percentage of classroom space covered by plants, ranging from 0% to 10%. Greenery has been shown to improve cognitive function and learning outcomes by creating a more pleasant and relaxed environment. Time of Day (hrs):

The time during which the class is conducted, ranging from 8 AM to 4 PM. Later classes might see a decrease in student performance due to fatigue or circadian rhythms. Dynamic Learning Outcome:

The overall learning outcome for a given session, measured as a score between 50 and 90. The outcome is influenced by all of the above factors and includes add

itional adjustments for class dynamics, environmental conditions, and temporal factors (e.g., time of day).

Purpose of the Dataset: This dataset serves to model and analyze the relationship between various classroom environmental factors and student performance. Researchers can explore the effects of air quality, classroom layout, and other factors on learning outcomes. The dataset may also be used to develop predictive models to optimize classroom environments for improved student performance.

Example Applications: Educational Research: Studying how air quality and classroom layout affect student concentration and learning efficiency. Environmental Psychology: Analyzing the relationship between environmental comfort (e.g., lighting, temperature) and cognitive performance. Policy Development: Providing evidence-based recommendations for improving school infrastructure, air quality, and classroom design to support better learning outcomes. Machine Learning Models: Training machine learning algorithms to predict student performance based on environmental features and class conditions.

For full data description please visit: Vicmap Hydro (land.vic.gov.au)Vicmap Hydro represents the natural and man-made water resources for Victoria and consists of point, line and polygon vector features in a seamless, networked and topologically structured dataset series. It comprises a basic framework of linear features supplemented by related point and polygon features to value add data for the water networks across the State. Attribute tables classify and describe the real-world features using code lists that can be used for search, discovery and analysis. The following hydrographic features are contained within Vicmap Hydro:• Watercourse (line)- watercourse, connector, channel, drain• Water Area (polygon)- lake, flat, wetland, pondage, watercourse area• Water Area Boundary (line)- shoreline, junction• Water Point (point)- rapids, spring, waterfall, waterbody point• Water Area Fuzzy (polygon) – bay, beach, bend, entrance, inlet, passage, reach, seaIn inland and coastal areas, point and line features are used to describe various waterline related structures:• Water Structure Line (line)- wharf, marina, offshore platform, breakwater, launching ramp, dam wall, spillway, lock• Water Structure Point (point)- lock, well• Water Structure Area (polygon)- dam batter, spillwayPolygon voidsPolygon features may contain an inner set of lines, holes or voids that cannot be assigned to any feature class within that layer. For example, a Lake in the Water Area layer may have in the middle of it an area of dry land. This would appear in the data as a polygon with no paracentroid. Coincident featuresThere will be no coincident polygons, lines (whole or in part) or points of the same feature type in the data (also frequently known as double digitising). Differing features may be coincident, as may be the case where a dam wall also forms part of a dam polygon, (in these cases, the common data repeats for each feature type, and is appropriately tagged and supplied as part of each feature type)ConnectorDrainage patterns are made up of both linear (narrow streams) and polygon features (such as watercourse areas, lakes and swamps) and consequently do not constitute a rigorous linear network. To allow linear analysis of drainage networks an artificial feature called a "Connector" has been added to the data.This Connector feature is used to connect linear watercourse features where they are separated by water areas such as lakes, swamps and watercourses depicted as area features. The points that make up this chain cannot be given any value for planimetric accuracy. The Connector will only be used if there is flow across a waterbody polygon feature. Thus, if there is only inflow to a lake and no outflow the Connector feature will not be used. Tributary watercourses flowing into a polygon area will be linked to the areas with Connectors.Connectors are also used for drainage conveyed by pipelines (Connector_structure). The diagram below demonstrates the relationship between underground pipelines and other drainage features for the situation where pipelines cross drainage features. In this situation the underground pipeline will form the connection with connector features in the watercourse layer and needs to be cloned in the watercourse layer as a connector. A node is to be created in the watercourse layer, on the connector, at the intersection of any drainage lines crossing pipeline connector.Junction The Junction is a linear feature which is an artificial line used to separate adjacent polygon areas across which flow can occur. For example, a Junction feature will separate the confluence of two watercourses where both are depicted as polygons. A Junction also separates watercourse polygons from the Sea. The Junction feature is arbitrarily placed and cannot be given any value for planimetric accuracy.Junction devices carry the attributes of the area entity they enclose.Junction features will not be placed:• separating 2 water bodies with identical attributes.• separating polygons of different feature class except separating watercourse polygons, canal polygons, lakes, reservoirs and the sea from one another.Junction features will be placed:• separating double line watercourses from other water bodies such as lakes and reservoirs.• separating waterbody polygons of the same class but with different attributes.• closing the mouth of rivers (waterbodies).• filling the coastal gaps in the framework layer. Cross border data is not subject to the same data structures or accuracy as the content within Victoria. This is due to the differences in the data models between the States.

Export Data Access API Geocoded Addressing Theme Please Note: WGS 84 service aligned to GDA94This dataset has spatial reference [WGS 84 ≈ GDA94] which may result in misalignments when viewed in GDA2020 environments. A similar service with a ‘multiCRS’ suffix is available which can support GDA2020, GDA94 and WGS 84 ≈ GDA2020 environments.In due course, and allowing time for user feedback and testing, it is intended that the original service name will adopt the new 'multiCRS' functionality. Metadata Portal Metadata Information Content TitleNSW Geocoded Addressing ThemeContent TypeHosted Feature LayerDescriptionThe Geocoded Urban and Rural Addressing System (GURAS) is a ‘property’ based address database. Each property polygon captured within GURAS has a unique numeric identifier and contains at least one authoritative address which is sourced from local councils via the valuation of land database, also managed by LPI-Valnet. Properties may contain more than one address sourced from various other organisations.The GURAS database is commonly used by all levels of government for emergency services, computer aided dispatch systems, postal and delivery services, and to identify location.Address points are generally system generated points and do not always have a direct correlation to the dwelling location. In circumstances where there are multiple disparate lots for one property, particularly in rural addresses, the system generated address points may not reside within the correct property polygon. Owner's names are not part of the GURAS database, nor does GURAS contain any personal information.The Geocoded Addressing Theme is a single source of truth for address information in NSW, GURAS eliminates the costly duplication of effort where all local councils, Australia Post, emergency service organisations and other agencies and businesses maintained individual address databases with different creation and distribution regimes.Geocoded Addressing Data Theme includes the following feature classes:Waypoint - A WayPoint is a point located on the RoadSegment feature class for an address where the road naming attributes from both the AddressString and the RoadSegment classes are identical. Indicates the approximate entry point of for an address.Address Point - A point feature class used to spatially locate an address / address stringThe Address Point Layer includes the below sub types:BuildingHomesteadMonumentPropertyUnit/StrataOtherPro Way - A Proway is a line that spatially connects the AddressPoint and WayPoint.The Pro Way Layer includes the following subtypes:RightLeftOtherInitial Publication Date06/04/2020Data Currency01/01/3000Data Update FrequencyOtherContent SourceData provider filesFile TypeESRI File Geodatabase (*.gdb)Attribution© State of New South Wales (Spatial Services, a business unit of the Department of Customer Service NSW). For current information go to spatial.nsw.gov.auData Theme, Classification or Relationship to other DatasetsNSW Geocoded Addressing Theme of the Foundation Spatial Data FrameworkAccuracyThis dataset was captured by utilising the best available source at a variety of scales and accuracies, ranging from 1:500 to 1:250 000 according to the National Mapping Council of Australia, Standards of Map Accuracy (1975). Therefore, the position of the feature instance will be within 0.5mm at map scale for 90% of the well-defined points. That is, 1:500 = 0.25m, 1:2000 = 1m, 1:4000 = 2m, 1:25000 = 12.5m, 1:50000 = 25m and 1:100000 = 50m. A program to upgrade the spatial location and accuracy of data is ongoing.Spatial Reference System (dataset)GDA94Spatial Reference System (web service)EPSG:3857WGS84 Equivalent ToGDA94Spatial ExtentFull StateContent LineageFor additional information, please contact us via the Spatial Services Customer HubData ClassificationUnclassifiedData Access PolicyOpenData QualityFor additional information, please contact us via the Spatial Services Customer HubTerms and ConditionsCreative CommonsStandard and SpecificationOpen Geospatial Consortium (OGC) implemented and compatible for consumption by common GIS platforms. Available as either cache or non-cache, depending on client use or requirement. Information about the “Feature Class” and “Domain Name” descriptions for the NSW Administrative Boundaries Theme can be found in the GURAS Delivery Model Data DictionarySome of Spatial Services Datasets are designed to work together for example “NSW Address Point” and “NSW Address String Table”, NSW Property (Polygon) and NSW Property Lot Table and NSW Lot (polygons). To do this you need to add a “Spatial Join”.A Spatial join is a GIS operation that affixes data from one feature layer’s attribute table to another from a spatial perspective.To see how Address, Property and Lot Geometry data and Tables can be joined together download the Data Model Document. This will show what attributes in the datasets can be linked.Data CustodianDCS Spatial Services346 Panorama AveBathurst NSW 2795Point of ContactPlease contact us via the Spatial Services Customer HubData AggregatorDCS Spatial Services346 Panorama AveBathurst NSW 2795Data DistributorDCS Spatial Services346 Panorama AveBathurst NSW 2795Additional Supporting InformationData DictionariesTRIM Number

The National Center for Education Statistics’ (NCES) Education Demographic and Geographic Estimates (EDGE) program develops annually updated point locations (latitude and longitude) for postsecondary institutions included in the NCES Integrated Postsecondary Education Data System (IPEDS). The IPEDS program annually collects information about enrollments, program completions, graduation rates, faculty and staff, finances, institutional prices, and student financial aid from colleges, universities, and technical and vocational institutions that participate in federal student financial aid programs under the Higher Education Act of 1965 (as amended). The NCES EDGE program uses address information reported in the annually updated IPEDS directory file to develop point locations for all institutions reported in IPEDS. The point locations in this data layer represent the most current IPEDS collection available. For more information about NCES school point data, see: https://nces.ed.gov/programs/edge/Geographic/SchoolLocations. Collections are available for the following years: 2022-23 2021-22 2020-21 2019-20 2018-19 2017-18 2016-17 2015-16 All information contained in this file is in the public domain. Data users are ad vised to review NCES program documentation and feature class metadata to understand the limitations and appropriate use of these data.

24 participants learned the features of 15 novel “satellite” objects organized into three classes. Each satellite has a “class” name (Alpha, Beta, or Gamma) shared with other members of the same category, a unique “code” name, and five visual parts. One of the learned satellites in each category is the prototype, which contains all the prototypical parts for that category. Each of the other satellites has one part deviating from the prototype. Thus, each non-prototype shares 4 features with the prototype and 3 features with other non-prototypes from the same category. Exemplars from different categories do not share any features. Each satellite has shared features: the class name and the parts shared among members of the category, and unique features: the code name and the part unique to that satellite (except for the prototype, which has no unique parts). Satellites were constructed randomly for each participant, constrained by this category structure.

Procedure: Session 1 Training. Participants learned about the satellites in two phases. In the first phase, which lasted 15 minutes on average, satellites were introduced one by one, with each of the 15 satellites shown once. For each satellite, the class and code name were displayed, followed by the image of the satellite. A box highlighted each of the five visual features on the satellite image one by one, to encourage participants to attend to each feature. Participants were then asked to recall the class and code names by clicking on one of three options given for each name. Next, participants used a point-and-click interface to try to reconstruct the satellite image from scratch. Icons representing the five part types were displayed on the right hand side of the screen, and when an icon was clicked, all the possible versions of that part were displayed in a row on the bottom of the screen. The participant could then click on one of the part versions on the bottom to add it to the satellite in the center of the screen. If the participant was too slow at this task (took longer than 15 s), or reconstructed the satellite incorrectly, a feedback screen would appear displaying the correct features.

In the second phase of training, which lasted 32 minutes on average, participants were shown a satellite with one feature missing, which could be one of the five visual features, the code name, or the class name (code and class name buttons were displayed along with the part icons on the right hand side of the screen, and when selected, displayed the corresponding name options in a row on the bottom). Using the same point-and-click interface, participants chose a feature (out of all possible) to complete the satellite. If they chose the correct feature, they were told it was correct, and could move on to the next trial. If they chose an incorrect feature, they were shown the correct feature, and had to repeat the trial until they chose the correct feature.

Remembering the shared properties of the satellites is easier than remembering the unique properties, as the shared properties are reinforced across study of all the satellites in the same class. The task was titrated in pilot testing to ensure that, at the end of training, participants performed equivalently at retrieving shared and unique properties of the satellites. To accomplish this, unique features were queried 24 times more frequently than shared features. This phase of training continued until the participant reached a criterion of 66% of trials correct on a block of 32 trials, or until 60 minutes had passed. Only one participant did not reach the criterion, but was very close, with an accuracy of 63%.

Procedure: Session 1 Test. Immediately after training, participants were tested by again filling in missing features of the satellites, now without feedback. The test phase had 39 trials, with two missing features per trial. The test phase took 10 minutes on average. Each satellite appeared twice in the test phase: once with its code name and its class name or one shared part tested, and once with two shared parts or one unique part and one shared part tested. The remaining 9 trials tested generalization to novel satellites. Novel satellites were members of the trained categories but had one novel feature. The queried feature for novel items was always a shared part (class name or shared visual feature). Test trials were presented in a random order.

Procedure: fMRI scanning. After completion of the first session test phase, participants were scanned while viewing the satellite images (without names) for 52 minutes. Satellites subtended up to 19 degrees of visual angle on the scanner projection. There were 8 runs, lasting 6.5 mins each, with self-paced breaks between runs. In each run, each of the 15 images was presented four times in pseudo-random order, such that each satellite appeared in the first, second, third, and fourth quarter of the trials. Four trials in each run were randomly chosen to be duplicated, such that these satellites were shown twice in immediate succession. These served as rare (4 trials out of 64) targets for a one-back task that subjects performed while viewing the satellites, to encourage maintenance of attention. Subjects pressed one key on a keypad to indicate that the current satellite was not an exact repetition of the previous satellite, and a different key to indicate that it was a repetition. Keys corresponded to index and middle fingers of the right hand, with key assignment for repetition and no-repetition counterbalanced across subjects. Feedback for responses at each trial was provided as a green or red dot at fixation. Each satellite was presented for 3s with a jittered interstimulus interval (40% 1s, 40% 3s, 20% 5s), to facilitate modeling of the response to individual items.

Next, we collected a 6.5-min functional rest run where participants were instructed to relax and watch the fixation dot on the screen, emphasizing that they should keep their eyes open.

Procedure: Session 2. In Session 2, participants did the same scan procedure, with images presented in a different random order. Then they got out of the scanner and completed the same test phase as in the first session, with identical trials presented in a different random order.

Participants in the Sleep group (n=12) began the first session around 7pm and the second session around 9am, and participants in the Wake group (n=12) began the first session around 9:30am and the second session around 10pm.

fMRI data acquisition. Data were acquired using a 3T Siemens Skyra scanner with a volume head coil. In each session, we collected 9 functional runs with a T2*-weighted gradient-echo EPI sequence (36 oblique axial slices: 3×3 mm inplane, 3 mm thickness; TE=30 ms; TR=2000 ms; FA=71°; matrix=64×64). Each run contained 195 volumes. We collected two anatomical runs for registration across subjects to standard space: a coplanar T1-weighted FLASH sequence and a high-resolution 3D T1-weighted MPRAGE sequence. An in-plane magnetic field map image was also acquired for EPI undistortion.

Group membership:

Sleep: sub-01, sub-04, sub-07, sub-08, sub-10, sub-12, sub-15, sub-17, sub-18, sub-21, sub-22, sub-24 Wake: sub-02, sub-03, sub-05, sub-06, sub-09, sub-11, sub-13, sub-14, sub-16, sub-19, sub-20, sub-23

Behavioral memory test files with data from outside scanner (beh/sub-*_ses-*_task-test_beh.tsv):

trial: trial number item: identifier for each satellite, with indication of category membership querytype: feature queried is unique, shared, or belonging to novel satellite subtype: feature queried is verbal (name) or visual (part) feature: specific queried feature (v1-v5 refer to the five visual parts) accuracy: whether feature filled in correctly

Stimulus presentation and behavior files with data from inside scanner (func/sub-*_ses-*_task-satellite_run-*_events.tsv):

onset: onset time in seconds relative to beginning of run duration: duration of stimulus (always 3 seconds) item: identifier for each satellite, with indication of category membership repeat: whether the current item is a repeat of the previous item accuracy: whether the participant correctly reported the item as a repeat or not a repeat (n/a if no response) reaction_time: time between stimulus onset and response in seconds (n/a if no response)

Data Type: Dynamic. Vintage: Current. Editing of street features within ASP is ad-hoc. Such generally occurs on a daily to weekly basis.Data is in State Plane Grid Coordinates, Colorado Central Zone, NAD83 (US feet).This street data is maintained in the Address Street Political (ASP) production database by the Business Innovation & Technology Division via the ASP Tools. Source data is the BaseLine feature class, an atomic-level linear dataset which includes street, unnamed road and political line features. Column BL_TYPE has a domain of 'S' (street), 'U' (unnamed road and 'N' (non-street political line) and is used by the ASP DERIVATIVE processing, through tabular selection, to pull the street and unnamed road subsets to distinct features classes whenever geometric or attribute editing occurs. These linear derivatives are then pushed to the spatial data warehouse (SDEWHP) by the ASP To Warehouse (ASP2WH) processing. Here, BLTYPE is obviously 'S' for all features.Original street feature digitization in the early 1990s occurred using 1:4,800 scale ortho-rectified imagery and remnants of that digitation effort remain, where road geometry will appear quite jagged and rough when zoomed to larger scales. Between 2003 and 2011, using the Address Geocode Environment (AGE) toolset, street digitization generally occurred at higher resolutions, where1:1,000 was the desired scale. Since 2012, when ASP and the ASP Tools went live, efforts have been made to consistently digitize new street features, and fix old, at a 1:500 scale. Due to the offset in the 2022 ortho-imagery relevant the 2020 through 2012 image data, streets seen in 2020 or prior imagery will generally match to that data, where only streets new to the 2022 imagery will be aligned to such. Column BLUID (BaseLine Unique Identifier) is the unique BaseLine feature key maintained by the ASP Tools, which is independant and not-to-be confused with Esri's OBJECTID. Column BLUID is used in all ASP bridge tables where many-to-many street-related correspondences are managed.Columns BL_LBPUID (Left BPUID) and BL_RBPUID (Right BPUID) refer to the associated coincident BasePoly polgonal feature associated with the respective side of the street. Cul-de-sacs and dead-end roads, where one endpoint of the road has no connectivity to another BaseLine feature, will obviously carry the same value for BL_LBPUID and BL_RBPUID. Note BasePoly features carry political or jurisdictional attributes, and the relation of an adddress to the side of a street to which it matches and the political polygon associated with that side of the street feature is how all political attributes are tied to address point features- with the exception of special districts (tax authorities). The latter are the only political component attached to addresses via point-in-poly spatial overlay.Columns STREET_LLO (left low), STREET_LHI (left high), STREET_RLO (right low) and STREET_RHI (right high) refer to the left- and right-side address range attributes attached to a street feature. Addressible street features carry non-zero values in these columns. Note feature directionality always corresponds with address-range attribution: low values are associated with the feature's from-node and high values with the to-node.Columns STREET_LADDRESSABLE and STREET_RADDRESSABLE are flags indicating whether the side of the street is addressable, where the domain is 'Y' (yes) or null (no).Columns STREET_LZIP and STREET_RZIP refer to the left- and right zip codes associated with the street feature. Columns STREET_DIRECTION_PREFIX (street direction prefix), STREET_NAME (street name), STREET_TYPE (street type) and STREET_DIRECTION_SUFFIX (street direction suffix) form the individual components of the full street name (column STREET_NAME_FULL). Note column STREET_NAME may not be null whereas the other individual components may. Columns STREET_DIRECTION_PREFIX, STREET_TYPE and STREET_DIRECTION_SUFFIX all utilize appropriate domain tables for data entry. Table "StreetNameFull" carries the domain of all distinct (unique) street name full combinations, while table "StreetName" carries the domain of all distinct column STREET_NAME values. Both of these tables are available in SDEWHP.Column STREET_ALIAS (street alias) is a "flag" which is 'Y' where the street feature is an aliased street and null otherwise. By aliased, we mean multiple street names are attached to the feature where the primary name (generally what is signed) is shown in column STREET_NAME_FULL. The many-to-many correspondence of street features to street names is managed through the "StreetAndName" bridge table, which contains all street feature (BLUID) and street name full unique identifier (SNFUID) combinations. Table StreetAndName column STRNAMPRIORITY is used to manage which street name is primary, where a '1' indicates the signed street name and '2' the secondary name. Note the "StreetToStreetName" and "StreetNameToStreet" relationship classes (RCs) exist in SDEWHP so that when the "Street" feature class is added to an MXD, identify operations will return the multiple street names when such exist. To find all aliased streets through a tabular join, use the syntax per the following SQL:SELECT bluid, c.street_name_full, strnampriority FROM street a, streetandname b, streetnamefull c WHERE a.bluid = b.bluid AND b.snfuid = c.snfuid AND street_alias = 'Y' ORDER BY c.street_name_full, bluid, strnampriorityColumn STREET_GRID_NAME contains a code for how the street was named and addressed. For most street features, the code will be either 'DMAG' (Denver Metropolitan Addressing Grid) or 'JCAG' (Jefferson County Addressing Grid), where the latter is the County's extention to DMAG. The City of Golden (GOLDEN) is an exceptiopn, where most city streets were named and addressed based on Golden's grid. However, there are three areas within the City of Golden's municipal extents where no grid (GOLDNG) was employed. Another prominent exception is the Ken caryl Ranch Plains (KCRP) subdivision, which was granted an exemption from County addressing standards. Column STREET_GRID_KEY contains the numeric JAGUID key from the feature class JefffersonCountyAddressingGrid where such are associated with features from the Denver (DMAG) standards.Coulmns STREET_BUILT (street built) and STREET_PAVED (street paved) are "flags" which are 'Y' where true and null otherwise.Column STREET_CLASS (street classification) is a three-digit code with this domain: '010' (freeway), '020' (parkway), '030' (principal arterial), '040' (minor arterial), '050' (principal collector), '060' (collector), '070' (local residential street). ASP street classifications are periodically reviewed relative the County's Major Thoroughfare Plan (per Highways & Transportation).Column STREET_SPEED_CAD contains a two-to-three digit value associated with street classification (STREET_CLASS) and maintained solely for Sheriff Computer Aided Dispatch (CAD) purposes. Column STREET_SPEED_LIMIT contain a two digit value representing the posted speed limit. The default value for a feature derived from the STREET_SPEED_LIMIT associated with the street classification (STREET_CLASS) but may be adjusted up-or-down in 5 mile-per-hour increments to reflect actual posted speed limits. Note column STREET_SPEED_LIMIT was initially assogned based on defaults for street classificaitons; no effort has been made to correct. Over time, these values will be adjusted using both Cartegraph road maintenance information and actual observation. Column STREET_TRAVEL_DIRECTION is a two-character code for how travel occurs on a street segment. Note travel directionality, on one-way segments, often differs from feature directionality (orientation of a feature in terms of from- and to-nodes) where feature directionality is always based on addressing and the associated addressing grid. Column STREET_TRAVEL_DIRECTION contains this domain: 'BI' (bi-directional, two-way travel), 'FT' (one way travel, from feature from-node to to-node), 'TF' (one way travel, from to-node to from node), and 'NT' (no travel allowed).Columns STREET_ZLEVEL_FROM and STREET_ZLEVEL_TO are one-digit codes used to manage feature connectivity in the database relative real-world road connectivity. As an example, in the database the street features for I-70 and WARD RD show connectivity whereas in the real world Ward Road is at ground level and I-70 is an overpass- one may not directly turn left- or right from one to the other. The domain of values are '0' (underpass), '1' (ground level) and '2' and '3' for overpass conditions, where '1' is the norm for the from- and to-nodes (endpoints) of most street features. These columns consequently help manage where turns may or may not occur and are of great value in general routing operations and in dispatch. Columns LCOUNTYCODE, LCOUNTYNAME and RCOUNTYCODE, RCOUNTYNAME refer to the respective left- and right three digit Colorado county code and its associated county name. These columns do not exist in the source 'BaseLine' feature class in ASP but are appended and populated by the nightly ASP DERIVATIVE processing whenever editing has occurred. The county code is populated on the basis of left- or right- BPUID for the street segment. Given some street features on the county boundary, or extending out-of-county, have no associated BasePoly feature then LBPUID or RBPUID must be null. Consequently, in these cases, the LCOUNTYCODE or RCOUNTYCODE is null, and the associated LCOUNTYNAME or RCOUNTYNAME is designated as 'OUT OF COUNTY' rather than carrying the actual county name.

Colorado Community Anchor Institutions (CAI) Feature Class Summary This layer represents the National Telecommunications Information Administration (NTIA) State Broadband Data Development Program (SBDD) Community Anchor Institutions (CAI) which subscribe to broadband. Description Introduction This layer represents the National Telecommunications Information Administration (NTIA) State Broadband Data Development Program (SBDD) Community Anchor Institutions (CAI) which subscribe to broadband. ''Community Anchor Institutions'' consist of schools, libraries, medical and healthcare providers, public safety entities, community colleges and other institutions of higher education, and other community support organizations and entities. These locations may not offer broadband availability to the public (although most libraries and many schools, and community centers do) but rather offer an opportunity for policy makers to understand where community anchor institutions who have broadband access are which can help in identifying challenges and opportunities to reaching national connectivity goals. For additional information visit NOFA (Notice of Funding Availability) website: http://www.ntia.doc.gov/broadbandgrants/nofa.html Intent The primary source of information has been online address and location research, in combination with google maps and NAIP aerial imagery. Ideally, our end goal is to have every county maintain and provide data directly. The advantage being that local officials have more direct access to acquiring accurate data for their respective counties, and more experience within these counties. Secondly, it will allow each county to sustain accurate CAI data without being reliant on the state government. For example, if Hinsdale county sustained its own CAIs, it would not need to wait on the state to complete and update their CAI data. Achieving this goal will provide the counties in Colorado with accurate and useful data without the limitations of being bottle necked by a single data editing source. Process The existing CAI point data is edited and maintained using ESRI Arc Desktop 10.1. Points have first been verified for their spatial accuracy. They are overlayed onto NAIP aerial imagery. Using a combination of online sources, such as Google Maps and Google Earth, the address and location of each point is verified. If the point is inaccurately positioned, it is moved to the correct location. Attributes are also check for accuracy and updated. Sometimes street names or address numbers are not present, and must be identified through research. Presently a total of 5478 CAI locations have been researched and edited. We were unable to indentify the definitive location of 4% of these CAIs. This results in a favorable 96% accuracy rate thus far. This dataset will be continuously checked and improved upon as time goes on. In addition, CAI locations have been contacted in order to acquire internet speed test results. Currently 1356 of the total Community Anchor Institutions have speed test results. We will continute to add to this number as time goes on. Finally, this data will be accessible and modifiable via GIS services. This will allow county officials to actively edit the data. Data Fields The following items are the fields within the CAI feature class. There are several different field types within this dataset. The bold faced portion is representative of the field name, while the following text represents the type of the field as well as length, precision, and scale. Additionally, OBJECTIDand SHAPE are generated by Arc Map. OBJECTID- ObjectID Longitude- Double P38 S8 OITIndex- Short Latitude- Double P38 S8 AnchorName- String 200 FKProvider- Short FullAddress- String 200 KEY_- Short StreetAddress- 50 URL- String 100 Status- Short CAICategory - String 2 AddressNumber- Long CAIID- String 50 NumberSuffix - String 15 FullCensusBlockID- String 16 StreetPreModifier - String 10 TransTech- Double P38 S8 StreetPreDirectional - String 20 BBService- String 1 StreetPreType- String 20 PublicWiFi- String 1 StreetSeparator - String 10 CAIComments- String 255 StreetName - String 75 BBComments- String 255 StreetPostType- String 20 MaxAdDown- String 2 StreetPostDirectional- String 20 MaxAdUp- String 2 StreetPostModifier- String 20 SubScrbDown - String 2 SubAddress- String 50 SubScrbUp- String 2 Intersection- String 100 ActualDown- Double P38 S8 PlaceName- String 100 ActualUp- Double P38 S8 District- String 100 TestDate- String 255 County- String 50 ProviderNM- String 255 StateAbbrev- String 50 LocationChanged_Y_N- String 1 ZipCode- Long Done- String 1 Zip4- Short SHAPE- Geometry AddressLocDesc- String 255

Credits State of Colorado, Governor's Office of Information Technology (OIT) Archuleta County Baca County City and County of Broomfield Custer County Eagle County El Paso - Teller E911 Authority Garfield County Grand County La Plata County Larimer County Las Animas County E911 Authority Lincoln County Mesa County Moffat County Montezuma County North Central All - Hazards Region Pueblo County Routt County Use limitations None Extent West -109.011097 East -102.082504 North 40.994186 South 37.005858 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  structure, location, health, utilitiesCommunication * CONTENT TYPE  Downloadable Data EXPORT TO FGDC CSDGM XML FORMAT AS RESOURCE DESCRIPTION No

DISCIPLINE KEYWORDS  Public Service Facilities Broadband Internet Service

PLACE KEYWORDS  Colorado

TEMPORAL KEYWORDS  2014

THEME KEYWORDS  Public Use Structures, Community Anchor Institutions, Essential Facilities, Landmark Features, Key Geographic Locations, Points of Interest, Structures, Public Buildings, Facilities of General Interest, Civic or Government Buildings, Public Service Facilities, Fire Station, Police Station, School, Library, Post Office, Town Hall.

Hide Topics and Keywords ▲ Citation ► TITLE Colorado Community Anchor Institutions (CAI) ALTERNATE TITLES  Colorado CAIs CREATION DATE 2012-08-31 00:00:00 REVISION DATE 2013-02-07 00:00:00 EDITION Early 2013 Local Review Edition EDITION DATE 2013-02-07 PRESENTATION FORMATS  digital map SERIES  NAME Colorado Broadband Map Database

COLLECTION TITLE Colorado Broadband Map Database OTHER CITATION DETAILS The locations and Internet broadband speeds of Community Anchor Institututions within the State are required deliverables to the National Telecommunications and Information Administrations (NTIA) in accordance with the State Broadband Data and Development Grant Program requirements found in Federal Register /Vol. 74, No. 129 /Wednesday, July 8, 2009 /Notices, pages 32548 and 32563. Hide Citation ▲ Citation Contacts ► RESPONSIBLE PARTY  INDIVIDUAL'S NAME Nathan Lowry ORGANIZATION'S NAME State of Colorado, Governor's Office of Information Technology CONTACT'S POSITION GIS Outreach Coordinator CONTACT'S ROLE  publisher RESPONSIBLE PARTY  INDIVIDUAL'S NAME Tudor Stanescu ORGANIZATION'S NAME Governor's Office of Information Technology CONTACT'S POSITION GIS Technician CONTACT'S ROLE  publisher

CONTACT INFORMATION  ► PHONE  VOICE (303)-764-6861 FAX N/A

ADDRESS  TYPE both DELIVERY POINT 601 East 18th Avenue Suite 220 CITY Denver ADMINISTRATIVE AREA Colorado POSTAL CODE 80203-1494 COUNTRY US E-MAIL ADDRESS tudor.stanescu@state.co.us

HOURS OF SERVICE 7:00am - 4:00pm Hide Contact information ▲

Hide Citation Contacts ▲ Resource Details ► DATASET LANGUAGES  English (UNITED STATES) DATASET CHARACTER SET  utf8 - 8 bit UCS Transfer Format STATUS  on-going SPATIAL REPRESENTATION TYPE  vector GRAPHIC OVERVIEW  FILE NAME ColoradoCAIs.png at https://docs.google.com/file/d/0B_O_LJbuRH4azB0RlZ1SUVKMXc/edit?usp=sharing FILE DESCRIPTION Colorado Community Anchor Institutions (CAIs) FILE TYPE Portable Network Graphic file (.png)

* PROCESSING ENVIRONMENT Microsoft Windows 7 Version 6.1 (Build 7601) Service Pack 1; Esri ArcGIS 10.1.1.3143 CREDITS State of Colorado, Governor's Office of Information Technology (OIT) Archuleta County Baca County City and County of Broomfield Custer County Eagle County El Paso - Teller E911 Authority Garfield County Grand County La Plata County Larimer County Las Animas County E911 Authority Lincoln County Mesa County Moffat County Montezuma County North Central All - Hazards Region Pueblo County Routt County

ARCGIS ITEM PROPERTIES  * NAME CAIs.DBO.ColoradoCAI * LOCATION Server=10.12.1.28; Service=sde:sqlserver:10.12.1.28; Database=CAIs; User=stanescut; Version=dbo.DEFAULT * ACCESS PROTOCOL ArcSDE Connection

Hide Resource Details ▲ Extents ► EXTENT  DESCRIPTION The State of Colorado, United States of America GEOGRAPHIC EXTENT  BOUNDING RECTANGLE  WEST LONGITUDE -114.996946 EAST LONGITUDE -96.104491 SOUTH LATITUDE 32.485329 NORTH LATITUDE 45.503973 EXTENT CONTAINS THE RESOURCE No

TEMPORAL EXTENT  BEGINNING DATE 2010-01-01 00:00:00 ENDING DATE 2010-12-31 00:00:00

EXTENT  GEOGRAPHIC EXTENT  BOUNDING RECTANGLE  EXTENT TYPE  Extent used for searching * WEST LONGITUDE -109.011097 * EAST LONGITUDE -102.082504 * NORTH LATITUDE 40.994186 * SOUTH LATITUDE 37.005858

EXTENT IN THE ITEM'S COORDINATE SYSTEM  * WEST LONGITUDE -109.011097 * EAST LONGITUDE -102.082504 * SOUTH LATITUDE 37.005858 * NORTH LATITUDE 40.994186 * EXTENT CONTAINS THE RESOURCE Yes

Hide Extents ▲ Resource Points of Contact ► POINT OF CONTACT  INDIVIDUAL'S NAME Nathan Lowry ORGANIZATION'S NAME State of

Shellfish Area Classification Set: The Connecticut Department of Environmental Protection cooperated with the Department of Agriculture, Bureau of Aquaculture to publish the Connecticut Shellfish Classification data. More recent information may be available from the Department of Agriculture since the time this information was originally published in 2007. For information or questions on shellfish area classifications contact the Connecticut Department of Agriculture, Bureau of Aquaculture (DA/BA). Mailing address: P.O. Box 97, Milford, CT, 06460, USA. Voice: 203-874-0696. Fax: 203-783-9976. E-mail: dept.agriculture@snet.net. Final authority for the classification of any shellfish area rests with the DA/BA. One of a set of three 1:24,000-scale datalayers that represent the classifications of shellfish growing waters for the State of Connecticut shoreline towns. This datalayer is composed of polygon features. The shellfishing areas are delineated and classified by the DA/BA, which is the state shellfish control authority in Connecticut. The Connecticut Department of Environmental Protection (DEP) applied information from the DA/BA to the hydrography data to create digital data of shellfish area classifications. DA/BA reassesses pollution sources and shellfish growing areas annually. The digital data is current to that effective date or last amended date recorded on the assessment date list (see supplemental information). This data is subject to change and the DA/BA may have more recent information for some areas. DEP cooperated with the DA/BA to publish the DA/BA Shellfish Area Classifications data. More recent shellfish classification information may now be available from DA/BA since the time this information was originally published in 2007. The three classification datalayers are feature based. Waterbodies, such as rivers and lakes and ponds, that appear as area features in the hydrography datalayer are classified in the Shellfish Area polygon shapefile. Smaller water bodies, such as streams and creeks, that appear as line features in the hydrography datalayer are classified in the Shellfish Area line shapefile. A separate point shapefile contains the marinas that are classified by DA/BA. Contact DA/BA or local health departments for additional information regarding the classification of marinas and anchorage areas. Three additional datalayers add to the classification picture. Markers, such as buoys, demarcation signs and piers, are referred to in DA/BA text describing the shellfish area classifications. The town boundary lines as depicted on DA/BA oyster/shellfish ground charts extend to the Connecticut/New York mid-Long Island Sound boundary line. The jurisdiction line on the charts indicates the boundary between state and town jurisdictional control over shellfish grounds. The jurisdiction line is separate from the shellfishing area classifications The Connecticut Department of Environmental Protection cooperated with the Department of Agriculture, Bureau of Aquaculture to publish the Connecticut Shellfish Classification data. More recent information may be available from the Department of Agriculture since the time this information was originally published in 2006. For information or questions on shellfish area classifications contact the Connecticut Department of Agriculture, Bureau of Aquaculture (DA/BA). Mailing address: P.O. Box 97, Milford, CT, 06460, USA. Voice: 203-874-0696. Fax: 203-783-9976. E-mail: dept.agriculture@snet.net. Final authority for the classification of any shellfish area rests with the DA/BA. This 1:24,000 scale layer depicts town boundary lines as shown on DA/BA oyster/shellfish ground charts. These boundary lines extend to the Connecticut/New York mid-Long Island Sound boundary line. This datalayer is composed of polygon features. See also the corresponding line feature class (Shellfish Area Town Line). This layer is intended to be used for cartographic purposes in conjunction with the 1:24

This is the classification based E-commerce text dataset for 4 categories - "Electronics", "Household", "Books" and "Clothing & Accessories", which almost cover 80% of any E-commerce website.

The dataset is in ".csv" format with two columns - the first column is the class name and the second one is the datapoint of that class. The data point is the product and description from the e-commerce website.

The dataset has the following features :

Data Set Characteristics: Multivariate

Number of Instances: 50425

Number of classes: 4

Area: Computer science

Attribute Characteristics: Real

Number of Attributes: 1

Associated Tasks: Classification

Missing Values? No

Gautam. (2019). E commerce text dataset (version - 2) [Data set]. Zenodo. https://doi.org/10.5281/zenodo.3355823

Access APIGeocoded Addressing Theme Please Note WGS 84 service aligned to GDA94 This dataset has spatial reference [WGS 84 ≈ GDA94] which may result in misalignments when viewed in GDA2020 …Show full description Access APIGeocoded Addressing Theme Please Note WGS 84 service aligned to GDA94 This dataset has spatial reference [WGS 84 ≈ GDA94] which may result in misalignments when viewed in GDA2020 environments. A similar service with a ‘multiCRS’ suffix is available which can support GDA2020, GDA94 and WGS 84 ≈ GDA2020 environments. In due course, and allowing time for user feedback and testing, it is intended that the original service name will adopt the new multiCRS functionally.The Geocoded Urban and Rural Addressing System (GURAS) is a ‘property’ based address database. Each property polygon captured within GURAS has a unique numeric identifier and contains at least one authoritative address which is sourced from local councils via the valuation of land database, also managed by LPI-Valnet. Properties may contain more than one address sourced from various other organisations. The GURAS database is commonly used by all levels of government for emergency services, computer aided dispatch systems, postal and delivery services, and to identify location. Address points are generally system generated points and do not always have a direct correlation to the dwelling location. In circumstances where there are multiple disparate lots for one property, particularly in rural addresses, the system generated address points may not reside within the correct property polygon. Owners names are not part of the GURAS database, nor does GURAS contain any personal information. The Geocoded Addressing Theme is a single source of truth for address information in NSW, GURAS eliminates the costly duplication of effort where all local councils, Australia Post, emergency service organisations and other agencies and businesses maintained individual address databases with different creation and distribution regimes.Geocoded Addressing Data Theme includes the following feature classes:Waypoint - A WayPoint is a point located on the RoadSegment feature class for an address where the road naming attributes from both the AddressString and the RoadSegment classes are identical. Indicates the approximate entry point of for an address.Address Point - A point feature class used to spatially locate an address / address stringThe Address Point Layer includes the below subtypes:· Building· Homestead· Monument· Property· Unit/Strata· OtherPro Way - A Proway is a line that spatially connects the AddressPoint and WayPoint.The Pro Way Layer includes the following subtypes:· Right· Left· Other Metadata Type Esri Feature Service Update Frequency As required Contact Details Contact us via the Spatial Services Customer Hub Relationship to Themes and Datasets NSW Geocoded Addressing Theme of the Foundation Spatial Data Framework (FSDF) Accuracy The dataset maintains a positional relationship to, and alignment with, the Lot and Property digital datasets. This dataset was captured by digitising the best available cadastral mapping at a variety of scales and accuracies, ranging from 1:500 to 1:250 000 according to the National Mapping Council of Australia, Standards of Map Accuracy (1975). Therefore, the position of the feature instance will be within 0.5mm at map scale for 90% of the well-defined points. That is, 1:500 = 0.25m, 1:2000 = 1m, 1:4000 = 2m, 1:25000 = 12.5m, 1:50000 = 25m and 1:100000 = 50m. A program of positional upgrade (accuracy improvement) is currently underway. Spatial Reference System (dataset) Geocentric Datum of Australia 1994 (GDA94), Australian Height Datum (AHD) Spatial Reference System    (web service) EPSG 4326: WGS 84 Geographic 2D WGS 84 Equivalent To GDA94 Spatial Extent Full State Standards and Specifications Open Geospatial Consortium (OGC) implemented and compatible for consumption by common GIS platforms. Available as either cache or non-cache, depending on client use or requirement. Information about the “Feature Class” and “Domain Name” descriptions for the NSW Administrative Boundaries Theme can be found in the GURAS Delivery Model Data DictionarySome of Spatial Services Datasets are designed to work together for example “NSW Address Point” and “NSW Address String Table”, NSW Property (Polygon) and NSW Property Lot Table and NSW Lot (polygons). To do this you need to add a “Spatial Join”. A Spatial join is a GIS operation that affixes data from one feature layer’s attribute table to another from a spatial perspective. To see how Address, Property and Lot Geometry data and Tables can be joined together download the Data Model Document. This will show what attributes in the datasets can be linked. Distributors Service Delivery, DCS Spatial Services 346 Panorama Ave Bathurst NSW 2795 Dataset Producers and Contributors Administrative Spatial Programs, DCS Spatial Services 346 Panorama Ave Bathurst NSW 2795

Feature class that compares the elevations between sand dune crests (extracted from available LiDAR datasets from 2010 and 2013) with published FEMA Base Flood Elevations (BFEs) from preliminary FEMA DFIRMS (Panels issued in 2018 and 2019) in coastal York and Cumberland counties (up through Willard Beach in South Portland). Steps to create the dataset included:Shoreline structures from the most recent NOAA EVI LANDWARD_SHORETYPE feature class were extracted using the boundaries of York and Cumberland counties. This included 1B: Exposed, Solid Man-Made structures, 8B: Sheltered, Solid Man-Made Structures; 6B: Riprap, and 8C: Sheltered Riprap. This resulted in the creation of Cumberland_ESIL_Structures and York_ESIL_Structures. Note that ESIL uses the MHW line as the feature base.Shoreline structures from the work by Rice (2015) were extracted using the York and Cumberland county boundaries. This resulted in the creation of Cumberland_Rice_Structures and York_Rice_Structures.Additional feature classes for structures were created for York and Cumberland county structures that were missed. This was Slovinsky_York_Structures and Slovinsky_Cumberland_Structures. GoogleEarth imagery was inspected while additional structures were being added to the GIS. 2012 York and Cumberland County imagery was used as the basemap, and structures were classified as bulkheads, rip rap, or dunes (if known). Also, whether or not the structure was in contact with the 2015 HAT was noted.MEDEP was consulted to determine which permit data (both PBR and Individual Permit, IP, data) could be used to help determine where shoreline stabilization projects may have been conducted adjacent to or on coastal bluffs. A file was received for IP data and brought into GIS (DEP_Licensing_Points). This is a point file for shoreline stabilization permits under NRPA.Clip GISVIEW.MEDEP.Permit_By_Rule_Locations to the boundaries of the study area and output DEP_PBR_Points.Join GISVIEW.sde>GISVIEW.MEDEP.PBR_ACTIVITY to the DEP_PBR_Points using the PBR_ID Field. Then, export this file as DEP_PBR_Points2. Using the new ACTIVITY_DESC field, select only those activities that relate to shoreline stabilization projects:PBR_ACTIVITY ACTIVITY_DESC02 Act. Adjacent to a Protected Natural Resource04 Maint Repair & Replacement of Structure08 Shoreline StabilizationSelect by Attributes > PBR_ACTIVITY IN (‘02’, ‘04’, ‘08’) select only those activities likely to be related to shoreline stabilization, and export the selected data as a DEP_PBR_Points3. Then delete 1 and 2, and rename this final product as DEP_PBR_Points.Next, visually inspect the Licensing and PBR files using ArcMap 2012, 2013 imagery, along with Google Earth imagery to determine the extents of armoring along the shoreline.Using EVI and Rice data as indicators, manually inspect and digitize sections of the coastline that are armored. Classify the seaward shoreline type (beach, mudflat, channel, dune, etc.) and the armor type (wall or bulkhead). Bring in the HAT line and, using that and visual indicators, identify whether or not the armored sections are in contact with HAT. Use Google Earth at the same time as digitizing in order to help constrain areas. Merge digitized armoring into Cumberland_York_Merged.Bring the preliminary FEMA DFIRM data in and use “intersect” to assign the different flood zones and elevations to the digitized armored sections. This was done first for Cumberland, then for York Counties. Delete ancillary attributes, as needed. Resulting layer is Cumberland_Structure_FloodZones and York_Structure_FloodZones.Go to NOAA Digital Coast Data Layers and download newest LiDAR data for York and Cumberland county beach, dune, and just inland areas. This includes 2006 and newer topobathy data available from 2010 (entire coast), and selected areas from 2013 and 2014 (Wells, Scarborough, Kennebunk).Mosaic the 2006, 2010, 2013 and 2014 data (with 2013 and 2014 being the first dataset laying on top of the 2010 data) Mosaic this dataset into the sacobaydem_ftNAVD raster (this is from the MEGIS bare-earth model). This will cover almost all of the study area except for armor along several areas in York. Resulting in LidAR206_2010_2013_Mosaic.tif.Using the LiDAR data as a proxy, create a “seaward crest” line feature class which follows along the coast and extracts the approximate highest point (cliff, bank, dune) along the shoreline. This will be used to extract LiDAR data and compare with preliminary flood zone information. The line is called Dune_Crest.Using an added tool Points Along Line, create points at 5 m spacing along each of the armored shoreline feature lines and the dune crest lines. Call the outputs PointsonLines and PointsonDunes.Using Spatial Analyst, Extract LIDAR elevations to the points using the 2006_2010_2013 Mosaic first. Call this LidarPointsonLines1. Select those points which have NULL values, export as this LiDARPointsonLines2. Then rerun Extract Values to Points using just the selected data and the state MEGIS DEM. Convert RASTERVALU to feet by multiplying by 3.2808 (and rename as Elev_ft). Select by Attributes, find all NULL values, and in an edit session, delete them from LiDARPointsonLines. Then, merge the 2 datasets and call it LidarPointsonLines. Do the same above with dune lines and create LidarPointsonDunes.Next, use the Cumberland and York flood zone layers to intersect the points with the appropriate flood zone data. Create ….CumbFIRM and …YorkFIRM files for the dunes and lines.Select those points from the Dunes feature class that are within the X zone – these will NOT have an associated BFE for comparison with the Lidar data. Export the Dune Points as Cumberland_York_Dunes_XZone. Run NEAR and use the merged flood zone feature class (with only V, AE, and AO zones selected). Then, join the flood zone data to the feature class using FID (from the feature class) and OBJECTID (from the flood zone feature class). Export as Cumberland_York_Dunes_XZone_Flood. Delete ancillary columns of data, leaving the original FLD_ZONE (X), Elev_ft, NEAR_DIST (distance, in m, to the nearest flood zone), FLD_ZONE_1 (the near flood zone), and the STATIC_BFE_1 (the nearest static BFE).Do the same as above, except with the Structures file (Cumberland_York_Structures_Lidar_DFIRM_Merged), but also select those features that are within the X zone and the OPEN WATER. Export the points as Cumberland_York_Structures_XZone. Again, run the NEAR using the merged flood zone and only AE, VE, and AO zones selected. Export the file as Cumberland_York_Structures_XZone_Flood.Merge the above feature classes with the original feature classes. Add a field BFE_ELEV_COMPARE. Select all those features whose attributes have a VE or AE flood zone and use field calculator to calculate the difference between the Elev_ft and the BFE (subtracting the STATIC_BFE from Elev_ft). Positive values mean the maximum wall value is higher than the BFE, while negative values mean the max is below the BFE. Then, select the remaining values with switch selection. Calculate the same value but use the NEAR_STATIC_BFE value instead. Select by Attributes>FLD_ZONE=AO, and use the DEPTH value to enter into the above created fields as negative values. Delete ancilary attribute fields, leaving those listed in the _FINAL feature classes described above the process steps section.

Access APIAdministrative Boundaries Theme - Parish Please Note WGS 84 service aligned to GDA94 This dataset has spatial reference [WGS 84 ≈ GDA94] which may result in misalignments when viewed in …Show full description Access APIAdministrative Boundaries Theme - Parish Please Note WGS 84 service aligned to GDA94 This dataset has spatial reference [WGS 84 ≈ GDA94] which may result in misalignments when viewed in GDA2020 environments. A similar service with a ‘multiCRS’ suffix is available which can support GDA2020, GDA94 and WGS 84 ≈ GDA2020 environments. In due course, and allowing time for user feedback and testing, it is intended that the original service name will adopt the new multiCRS functionally.NSW Parish is a dataset within the Administrative boundaries theme of the FSDF. It contains 7,459 administrative areas (Parishes) formed by the division of 141 counties. Counties and parishes are administrative divisions of the state and are not separately disposable land parcels. County and Parish are historical layers and the information contained on these layers was gathered from Parish and County maps which are now held at State Records (digital versions can be accessed through the Historical Lands Records Viewer). However, they can be updated (if necessary) after a title inspection. Parishes are divided into separately land parcels called “portions”, these being the common basic units of land disposed of by the Crown (sold), held in occupation (leased) or reserved for public purposes. Other basic units are section and allotments in Towns and Villages. The dataset contains county and parish names. Any changes that occur to the dataset should have a reference in the authority of reference feature class in the lot and property data sets. Features are positioned in topological alignment within the extents of the land and property polygons for each county and are held in alignment, including changes resulting cadastral maintenance and upgrades. NSW Parish is a subset of NSW County. This dataset contains an historical land administration boundary. The original Parish definition is static, however, data will move with changes to the Land Parcel and Property theme. Metadata Type Esri Feature Service Update Frequency As required Contact Details Contact us via the Spatial Services Customer Hub Relationship to Themes and Datasets Administrative Boundaries Theme of the Foundation Spatial Data Framework (FSDF) Accuracy The dataset maintains a positional relationship to, and alignment with, the Lot and Property digital datasets. This dataset was captured by digitising the best available cadastral mapping at a variety of scales and accuracies, ranging from 1:500 to 1:250 000 according to the National Mapping Council of Australia, Standards of Map Accuracy (1975). Therefore, the position of the feature instance will be within 0.5mm at map scale for 90% of the well-defined points. That is, 1:500 = 0.25m, 1:2000 = 1m, 1:4000 = 2m, 1:25000 = 12.5m, 1:50000 = 25m and 1:100000 = 50m. A program of positional upgrade (accuracy improvement) is currently underway. Spatial Reference System (dataset) Geocentric Datum of Australia 1994 (GDA94), Australian Height Datum (AHD) Spatial Reference System    (web service) EPSG 4326: WGS 84 Geographic 2D WGS 84 Equivalent To GDA94 Spatial Extent Full State Standards and Specifications Open Geospatial Consortium (OGC) implemented and compatible for consumption by common GIS platforms. Available as either cache or non-cache, depending on client use or requirement. Information about the Feature Class and Domain Name descriptions for the NSW Administrative Boundaries Theme can be found in the NSW Cadastral Delivery Model Data Dictionary Some of Spatial Services Datasets are designed to work together for example NSW Address Point and NSW Address String (table), NSW Property (Polygon) and NSW Property Lot (table) and NSW Lot (polygons). To do this you need to add a Spatial Join. A Spatial Join is a GIS operation that affixes data from one feature layer’s attribute table to another from a spatial perspective. To see how NSW Address, Property, Lot Geometry data and tables can be spatially joined, download the Data Model Document. Distributors Service Delivery, DCS Spatial Services 346 Panorama Ave Bathurst NSW 2795 Dataset Producers and Contributors Administrative Spatial Programs, DCS Spatial Services 346 Panorama Ave Bathurst NSW 2795

Notice: this is not the latest Heat Island Anomalies image service.This layer contains the relative degrees Fahrenheit difference between any given pixel and the mean heat value for the city in which it is located, for every city in the contiguous United States, Alaska, Hawaii, and Puerto Rico. This 30-meter raster was derived from Landsat 8 imagery band 10 (ground-level thermal sensor) from the summer of 2022, with patching from summer of 2021 where necessary.Federal statistics over a 30-year period show extreme heat is the leading cause of weather-related deaths in the United States. Extreme heat exacerbated by urban heat islands can lead to increased respiratory difficulties, heat exhaustion, and heat stroke. These heat impacts significantly affect the most vulnerable—children, the elderly, and those with preexisting conditions.The purpose of this layer is to show where certain areas of cities are hotter or cooler than the average temperature for that same city as a whole. This dataset represents a snapshot in time. It will be updated yearly, but is static between updates. It does not take into account changes in heat during a single day, for example, from building shadows moving. The thermal readings detected by the Landsat 8 sensor are surface-level, whether that surface is the ground or the top of a building. Although there is strong correlation between surface temperature and air temperature, they are not the same. We believe that this is useful at the national level, and for cities that don’t have the ability to conduct their own hyper local temperature survey. Where local data is available, it may be more accurate than this dataset. Dataset SummaryThis dataset was developed using proprietary Python code developed at The Trust for Public Land, running on the Descartes Labs platform through the Descartes Labs API for Python. The Descartes Labs platform allows for extremely fast retrieval and processing of imagery, which makes it possible to produce heat island data for all cities in the United States in a relatively short amount of time.In order to click on the image service and see the raw pixel values in a map viewer, you must be signed in to ArcGIS Online, then Enable Pop-Ups and Configure Pop-Ups.Using the Urban Heat Island (UHI) Image ServicesThe data is made available as an image service. There is a processing template applied that supplies the yellow-to-red or blue-to-red color ramp, but once this processing template is removed (you can do this in ArcGIS Pro or ArcGIS Desktop, or in QGIS), the actual data values come through the service and can be used directly in a geoprocessing tool (for example, to extract an area of interest). Following are instructions for doing this in Pro.In ArcGIS Pro, in a Map view, in the Catalog window, click on Portal. In the Portal window, click on the far-right icon representing Living Atlas. Search on the acronyms “tpl” and “uhi”. The results returned will be the UHI image services. Right click on a result and select “Add to current map” from the context menu. When the image service is added to the map, right-click on it in the map view, and select Properties. In the Properties window, select Processing Templates. On the drop-down menu at the top of the window, the default Processing Template is either a yellow-to-red ramp or a blue-to-red ramp. Click the drop-down, and select “None”, then “OK”. Now you will have the actual pixel values displayed in the map, and available to any geoprocessing tool that takes a raster as input. Below is a screenshot of ArcGIS Pro with a UHI image service loaded, color ramp removed, and symbology changed back to a yellow-to-red ramp (a classified renderer can also be used): A typical operation at this point is to clip out your area of interest. To do this, add your polygon shapefile or feature class to the map view, and use the Clip Raster tool to export your area of interest as a geoTIFF raster (file extension ".tif"). In the environments tab for the Clip Raster tool, click the dropdown for "Extent" and select "Same as Layer:", and select the name of your polygon. If you then need to convert the output raster to a polygon shapefile or feature class, run the Raster to Polygon tool, and select "Value" as the field.Other Sources of Heat Island InformationPlease see these websites for valuable information on heat islands and to learn about exciting new heat island research being led by scientists across the country:EPA’s Heat Island Resource CenterDr. Ladd Keith, University of ArizonaDr. Ben McMahan, University of Arizona Dr. Jeremy Hoffman, Science Museum of Virginia Dr. Hunter Jones, NOAA Daphne Lundi, Senior Policy Advisor, NYC Mayor's Office of Recovery and ResiliencyDisclaimer/FeedbackWith nearly 14,000 cities represented, checking each city's heat island raster for quality assurance would be prohibitively time-consuming, so The Trust for Public Land checked a statistically significant sample size for data quality. The sample passed all quality checks, with about 98.5% of the output cities error-free, but there could be instances where the user finds errors in the data. These errors will most likely take the form of a line of discontinuity where there is no city boundary; this type of error is caused by large temperature differences in two adjacent Landsat scenes, so the discontinuity occurs along scene boundaries (see figure below). The Trust for Public Land would appreciate feedback on these errors so that version 2 of the national UHI dataset can be improved. Contact Dale.Watt@tpl.org with feedback.

Access API Administrative Boundaries Theme - Parish Please Note WGS 84 service aligned to GDA94 This dataset has spatial reference [WGS 84 ≈ GDA94] which may result in misalignments when viewed in GDA2020 environments. A similar service with a ‘multiCRS’ suffix is available which can support GDA2020, GDA94 and WGS 84 ≈ GDA2020 environments. In due course, and allowing time for user feedback and testing, it is intended that the original service name will adopt the new multiCRS functionality. Metadata Portal Metadata InformationContent TitleNSW Administrative Boundaries Theme - Mines Subsidence DistrictContent TypeHosted Feature LayerDescriptionNSW Parish is a dataset within the Administrative Boundaries Theme of the FSDF. It contains 7,459 administrative areas (Parishes) formed by the division of 141 counties. Counties and parishes are administrative divisions of the state and are not separately disposable land parcels. County and Parish are historical layers and the information contained on these layers was gathered from Parish and County maps which are now held at State Records (digital versions can be accessed through the Historical Lands Records Viewer). However, they can be updated (if necessary) after a title inspection.Parishes are divided into separately land parcels called “portions”, these being the common basic units of land disposed of by the Crown (sold), held in occupation (leased) or reserved for public purposes. Other basic units are section and allotments in Towns and Villages. The dataset contains county and parish names. Any changes that occur to the dataset should have a reference in the authority of reference feature class in the lot and property data sets.Features are positioned in topological alignment within the extents of the land and property polygons for each county and are held in alignment, including changes resulting cadastral maintenance and upgrades. NSW Parish is a subset of NSW County.This dataset contains an historical land administration boundary. The original Parish definition is static, however, data will move with changes to the Land Parcel and Property theme.Initial Publication Date05/02/2020Data Currency01/01/3000Data Update FrequencyOtherContent SourceData provider filesFile TypeESRI File Geodatabase (*.gdb)Attribution© State of New South Wales (Spatial Services, a business unit of the Department of Customer Service NSW). For current information go to spatial.nsw.gov.auData Theme, Classification or Relationship to other DatasetsNSW Administrative Boundaries Theme of the Foundation Spatial Data Framework (FSDF)AccuracyThe dataset maintains a positional relationship to, and alignment with, the Lot and Property digital datasets. This dataset was captured by digitising the best available cadastral mapping at a variety of scales and accuracies, ranging from 1:500 to 1:250 000 according to the National Mapping Council of Australia, Standards of Map Accuracy (1975). Therefore, the position of the feature instance will be within 0.5mm at map scale for 90% of the well-defined points. That is, 1:500 = 0.25m, 1:2000 = 1m, 1:4000 = 2m, 1:25000 = 12.5m, 1:50000 = 25m and 1:100000 = 50m. A program to upgrade the spatial location and accuracy of data is ongoing.Spatial Reference System (dataset)GDA94Spatial Reference System (web service)EPSG:4326WGS84 Equivalent ToGDA94Spatial ExtentFull StateContent LineageFor additional information, please contact us via the Spatial Services Customer HubData ClassificationUnclassifiedData Access PolicyOpenData QualityFor additional information, please contact us via the Spatial Services Customer HubTerms and ConditionsCreative CommonsStandard and SpecificationOpen Geospatial Consortium (OGC) implemented and compatible for consumption by common GIS platforms. Available as either cache or non-cache, depending on client use or requirement.Information about the Feature Class and Domain Name descriptions for the NSW Administrative Boundaries Theme can be found in the NSW Cadastral Data Dictionary.Some of Spatial Services Datasets are designed to work together for example NSW Address Point and NSW Address String (table), NSW Property (Polygon) and NSW Property Lot (table) and NSW Lot (polygons). To do this you need to add a Spatial Join.A Spatial Join is a GIS operation that affixes data from one feature layer’s attribute table to another from a spatial perspective.To see how NSW Address, Property, Lot Geometry data and tables can be spatially joined, download the Data Model Document. Data CustodianDCS Spatial Services346 Panorama AveBathurst NSW 2795Point of ContactPlease contact us via the Spatial Services Customer HubData AggregatorDCS Spatial Services346 Panorama AveBathurst NSW 2795Data DistributorDCS Spatial Services346 Panorama AveBathurst NSW 2795Additional Supporting InformationData DictionariesData Model Document. TRIM Number

Export DataAccess APIAdministrative Boundaries Theme – Local Government AreaPlease Note WGS 84 service aligned to GDA94 This dataset has spatial reference [WGS 84 ≈ GDA94] which may result in misalignments when viewed in GDA2020 environments. A similar service with a ‘multiCRS’ suffix is available which can support GDA2020, GDA94 and WGS 84 ≈ GDA2020 environments. In due course, and allowing time for user feedback and testing, it is intended that the original service name will adopt the new multiCRS functionality.Metadata Portal Metadata InformationContent TitleNSW Administrative Boundaries Theme - Local Government AreaContent TypeHosted Feature LayerDescriptionNSW Local Government Area is a dataset within the Administrative Boundaries Theme (FSDF). It depicts polygons of gazetted boundaries defining the Local Government Area. It contains all of the cadastral line data or topographic features which are used to define the boundaries between adjoining shires, municipalities, cities (Local Government Act) and the unincorporated areas of NSW.The dataset also contains Council Names, ABS Codes, Ito Codes, Vg Codes, and Wb Codes. Any changes that occur to the dataset should have a reference in the authority of reference feature class in the Land Parcel and Property.Features are positioned in topological alignment within the extents of the land parcel and property polygons for each Local Government Area and are held in alignment, including changes resulting cadastral maintenance and upgrades.Initial Publication Date05/05/2020Data Currency01/01/3000Data Update FrequencyDailyContent SourceData provider filesFile TypeESRI File Geodatabase (*.gdb)Attribution© State of New South Wales (Spatial Services, a business unit of the Department of Customer Service NSW). For current information go to spatial.nsw.gov.auData Theme, Classification or Relationship to other DatasetsNSW Administrative Boundaries Theme of the Foundation Spatial Data Framework (FSDF)AccuracyThe dataset maintains a positional relationship to, and alignment with, the Lot and Property digital datasets. This dataset was captured by digitising the best available cadastral mapping at a variety of scales and accuracies, ranging from 1:500 to 1:250 000 according to the National Mapping Council of Australia, Standards of Map Accuracy (1975). Therefore, the position of the feature instance will be within 0.5mm at map scale for 90% of the well-defined points. That is, 1:500 = 0.25m, 1:2000 = 1m, 1:4000 = 2m, 1:25000 = 12.5m, 1:50000 = 25m and 1:100000 = 50m. A program to upgrade the spatial location and accuracy of data is ongoing.Spatial Reference System (dataset)GDA94Spatial Reference System (web service)EPSG:4326WGS84 Equivalent ToGDA94Spatial ExtentFull StateContent LineageFor additional information, please contact us via the Spatial Services Customer HubData ClassificationUnclassifiedData Access PolicyOpenData QualityFor additional information, please contact us via the Spatial Services Customer HubTerms and ConditionsCreative CommonsStandard and SpecificationOpen Geospatial Consortium (OGC) implemented and compatible for consumption by common GIS platforms. Available as either cache or non-cache, depending on client use or requirement.Information about the Feature Class and Domain Name descriptions for the NSW Administrative Boundaries Theme can be found in the NSW Cadastral Data Dictionary.Some of Spatial Services Datasets are designed to work together for example NSW Address Point and NSW Address String (table), NSW Property (Polygon) and NSW Property Lot (table) and NSW Lot (polygons). To do this you need to add a Spatial Join.A Spatial Join is a GIS operation that affixes data from one feature layer’s attribute table to another from a spatial perspective.To see how NSW Address, Property, Lot Geometry data and tables can be spatially joined, download the Data Model Document. Data CustodianDCS Spatial Services346 Panorama AveBathurst NSW 2795Point of ContactPlease contact us via the Spatial Services Customer HubData AggregatorDCS Spatial Services346 Panorama AveBathurst NSW 2795Data DistributorDCS Spatial Services346 Panorama AveBathurst NSW 2795Additional Supporting InformationData DictionariesData Model Document. TRIM Number