This dataset contains the Supplementary Information of the article "Discovering Mathematical Patterns Behind HIV-1 Genetic Recombination: a new methodology to identify viral features" (Manuscript DOI: 10.1109/ACCESS.2023.3311752).

This lesson addresses the development of hydrology vocabulary and the identification of hydrological features through the pursuit of a hydrology “scavenger hunt,” where students try to locate and record various hydrological features on a river/stream in the field. The students hunt for the features which are listed on a field logsheet and are defined in a provided Glossary of Hydrological Features. The target hydrological features are grouped into three lists, depending on the chosen field setting: 1) General (routine) environments, 2) Whitewater environments, and 3) Waterfall environments. The breadth of hydrological features makes the lesson suitable for either lower division nonmajors or upper division geoscience majors (there is also an optional subsection of fluid dynamics terms for major students). The lesson is scalable for afternoon trips to multi-day excursions, and flexible for streamside travel by land (driving & walking, hiking, or backpacking) or water (rafting, canoeing, or kayaking).

Segmentation models perform a pixel-wise classification by classifying the pixels into different classes. The classified pixels correspond to different objects or regions in the image. These models have a wide variety of use cases across multiple domains. When used with satellite and aerial imagery, these models can help to identify features such as building footprints, roads, water bodies, crop fields, etc.Generally, every segmentation model needs to be trained from scratch using a dataset labeled with the objects of interest. This can be an arduous and time-consuming task. Meta's Segment Anything Model (SAM) is aimed at creating a foundational model that can be used to segment (as the name suggests) anything using zero-shot learning and generalize across domains without additional training. SAM is trained on the Segment Anything 1-Billion mask dataset (SA-1B) which comprises a diverse set of 11 million images and over 1 billion masks. This makes the model highly robust in identifying object boundaries and differentiating between various objects across domains, even though it might have never seen them before. Use this model to extract masks of various objects in any image.Using the modelFollow the guide to use the model. Before using this model, ensure that the supported deep learning libraries are installed. For more details, check Deep Learning Libraries Installer for ArcGIS. Fine-tuning the modelThis model can be fine-tuned using SamLoRA architecture in ArcGIS. Follow the guide and refer to this sample notebook to fine-tune this model.Input8-bit, 3-band imagery.OutputFeature class containing masks of various objects in the image.Applicable geographiesThe model is expected to work globally.Model architectureThis model is based on the open-source Segment Anything Model (SAM) by Meta.Training dataThis model has been trained on the Segment Anything 1-Billion mask dataset (SA-1B) which comprises a diverse set of 11 million images and over 1 billion masks.Sample resultsHere are a few results from the model.

We present Da-TACOS: a dataset for cover song identification and understanding. It contains two subsets, namely the benchmark subset (for benchmarking cover song identification systems) and the cover analysis subset (for analyzing the links among cover songs), with pre-extracted features and metadata for 15,000 and 10,000 songs, respectively. The annotations included in the metadata are obtained with the API of SecondHandSongs.com. All audio files we use to extract features are encoded in MP3 format and their sample rate is 44.1 kHz. Da-TACOS does not contain any audio files. For the results of our analyses on modifiable musical characteristics using the cover analysis subset and our initial benchmarking of 7 state-of-the-art cover song identification algorithms on the benchmark subset, you can look at our publication. For organizing the data, we use the structure of SecondHandSongs where each song is called a ‘performance’, and each clique (cover group) is called a ‘work’. Based on this, the file names of the songs are their unique performance IDs (PID, e.g. P_22), and their labels with respect to their cliques are their work IDs (WID, e.g. W_14). Metadata for each song includes performance title, performance artist, work title, work artist, release year, SecondHandSongs.com performance ID, SecondHandSongs.com work ID, whether the song is instrumental or not. In addition, we matched the original metadata with MusicBrainz to obtain MusicBrainz ID (MBID), song length and genre/style tags. We would like to note that MusicBrainz related information is not available for all the songs in Da-TACOS, and since we used just our metadata for matching, we include all possible MBIDs for a particular songs. For facilitating reproducibility in cover song identification (CSI) research, we propose a framework for feature extraction and benchmarking in our supplementary repository: acoss. The feature extraction component is designed to help CSI researchers to find the most commonly used features for CSI in a single address. The parameter values we used to extract the features in Da-TACOS are shared in the same repository. Moreover, the benchmarking component includes our implementations of 7 state-of-the-art CSI systems. We provide the performance results of an initial benchmarking of those 7 systems on the benchmark subset of Da-TACOS. We encourage other CSI researchers to contribute to acoss with implementing their favorite feature extraction algorithms and their CSI systems to build up a knowledge base where CSI research can reach larger audiences. The instructions for how to download and use the dataset are shared below. Please contact us if you have any questions or requests. 1. Structure 1.1. Metadata We provide two metadata files that contain information about the benchmark subset and the cover analysis subset. Both metadata files are stored as python dictionaries in .json format, and have the same hierarchical structure. An example to load the metadata files in python: import json with open('./da-tacos_metadata/da-tacos_benchmark_subset_metadata.json') as f: benchmark_metadata = json.load(f) The python dictionary obtained with the code above will have the respective WIDs as keys. Each key will provide the song dictionaries that contain the metadata regarding the songs that belong to their WIDs. An example can be seen below: "W_163992": { # work id "P_547131": { # performance id of the first song belonging to the clique 'W_163992' "work_title": "Trade Winds, Trade Winds", "work_artist": "Aki Aleong", "perf_title": "Trade Winds, Trade Winds", "perf_artist": "Aki Aleong", "release_year": "1961", "work_id": "W_163992", "perf_id": "P_547131", "instrumental": "No", "perf_artist_mbid": "9bfa011f-8331-4c9a-b49b-d05bc7916605", "mb_performances": { "4ce274b3-0979-4b39-b8a3-5ae1de388c4a": { "length": "175000" }, "7c10ba3b-6f1d-41ab-8b20-14b2567d384a": { "length": "177653" } } }, "P_547140": { # performance id of the second song belonging to the clique 'W_163992' "work_title": "Trade Winds, Trade Winds", "work_artist": "Aki Aleong", "perf_title": "Trade Winds, Trade Winds", "perf_artist": "Dodie Stevens", "release_year": "1961", "work_id": "W_163992", "perf_id": "P_547140", "instrumental": "No" } } 1.2. Pre-extracted features The list of features included in Da-TACOS can be seen below. All the features are extracted with acoss repository that uses open-source feature extraction libraries such as Essentia, LibROSA, and Madmom. To facilitate the use of the dataset, we provide two options regarding the file structure. 1- In da-tacos_benchmark_subset_single_files and da-tacos_coveranalysis_subset_single_files folders, we organize the data based on their respective cliques, and one file contains all the features for that particular song. { "chroma_cens": numpy.ndarray, "crema": numpy.ndarray, "hpcp": numpy.ndarray, "key_extractor": { "key": numpy.str_, "scale": numpy.str_,_ "strength": numpy.float64 }, "madmom_features": { "nov...

Average number of extracted features.

This dataset provides the code and the data sets used in the PHD thesis "Identification of Software Features in Issue Tracking System Data" as well as the files that represent the results measured in experiments. For problem studies (e.g. chapters 10 and 11) the folders include the raw data and the data annotations as well as the tools used to extract the data. For solution studies (e.g. chapters 14, 15, and 16) the folders include the raw data, tools used to extract the data, the gold standards, the code to process the data and finally the experiment results. This archive contains one folder per chaper and every folder again contains a README.md file describing its contents: Chapter10: SOFTWARE FEATURES IN ISSUE TRACKING SYSTEMS – AN EMPIRICAL STUDY Chapter11: ISSUE TYPES AND INFORMATION TYPES – AN EMPIRICAL STUDY Chapter14: PREPROCESSING ISSUES – AN EMPIRICAL STUDY Chapter15: RECOVERING RELATED ISSUES IN ISSUE TRACKING SYSTEMS Chapter16: DETECTING SOFTWARE FEATURE REQUESTS IN ISSUES

The Address Range / Feature Name Relationship File (ADDRFN.dbf) contains a record for each address range / linear feature name relationship. The purpose of this relationship file is to identify all street names associated with each address range. An edge can have several feature names; an address range located on an edge can be associated with one or any combination of the available feature names (an address range can be linked to multiple feature names). The address range is identified by the address range identifier (ARID) attribute that can be used to link to the Address Ranges Relationship File (ADDR.dbf). The linear feature name is identified by the linear feature identifier (LINEARID) attribute that can be used to link to the Feature Names Relationship File (FEATNAMES.dbf).

Untargeted metabolomics is an essential component of systems biology research, but it is plagued by a high proportion of detectable features not identified with a chemical structure. Liquid chromatography–tandem mass spectrometry (LC–MS/MS) experiments produce spectra that can be searched against databases to help identify or classify these unknowns, but many features do not generate spectra of sufficient quality to enable successful annotation. Here, we explore alterations to gradient length, mass loading, and rolling precursor ion exclusion parameters for reversed phase liquid chromatography (RPLC) and hydrophilic interaction liquid chromatography (HILIC) that improve compound identification performance for human plasma samples. A manual review of spectral matches from the HILIC data set was used to determine reasonable thresholds for search score and other metrics to enable semi-automated MS/MS data analysis. Compared to typical LC–MS/MS conditions, methods adapted for compound identification increased the total number of unique metabolites that could be matched to a spectral database from 214 to 2052. Following data alignment, 68.0% of newly identified features from the modified conditions could be detected and quantitated using a routine 20-min LC–MS run. Finally, a localized machine learning model was developed to classify the remaining unknowns and select a subset that shared spectral characteristics with successfully identified features. A total of 576 and 749 unidentified features in the HILIC and RPLC data sets were classified by the model as high-priority unknowns or higher-importance targets for follow-up analysis. Overall, our study presents a simple strategy to more deeply annotate untargeted metabolomics data for a modest additional investment of time and sample.

Vermont Conservation Design is the data and the vision that identifies features at the landscape and natural community scales that are necessary for maintaining an ecologically functional landscape – a landscape that conserves current biological diversity and allows species to move and shift in response to climate and land-use changes. At the landscape scale, users can see patterns in Vermont’s forests, waterways, and the places that connect both into functional networks. At the community scale appear significant natural communities, lakes representing high quality examples of different lake types, and similar important features that are vital to assemblages of plants and animals. Finally, a user can see components that support individual species—the habitats and locations on which rare and uncommon species rely, for example. On the map, community and species scale components are combined. At all scales, Vermont Conservation Design identifies locations of ecological priority. These are divided into "priority" or "highest priority" areas, to allow users to make informed decisions about the locations most suitable for development and those on which to focus conservation efforts. What makes Vermont Conservation Design unique is that instead of looking at one ecological component at a time—wetlands, rare species, large forest blocks, etc.—Vermont Conservation Design takes a holistic approach, identifying how these components work together to create a functional network of habitat that can be used by most Vermont species. In other words, all components are combined at each scale to identify overall priorities.

The TIGER/Line shapefiles and related database files (.dbf) are an extract of selected geographic and cartographic information from the U.S. Census Bureau's Master Address File / Topologically Integrated Geographic Encoding and Referencing (MAF/TIGER) Database (MTDB). The MTDB represents a seamless national file with no overlaps or gaps between parts, however, each TIGER/Line shapefile is designed to stand alone as an independent data set, or they can be combined to cover the entire nation. The Feature Names Relationship File (FEATNAMES.dbf) contains a record for each feature name and any attributes associated with it. Each feature name can be linked to the corresponding edges that make up that feature in the All Lines Shapefile (EDGES.shp), where applicable to the corresponding address range or ranges in the Address Ranges Relationship File (ADDR.dbf), or to both files. Although this file includes feature names for all linear features, not just road features, the primary purpose of this relationship file is to identify all street names associated with each address range. An edge can have several feature names; an address range located on an edge can be associated with one or any combination of the available feature names (an address range can be linked to multiple feature names). The address range is identified by the address range identifier (ARID) attribute, which can be used to link to the Address Ranges Relationship File (ADDR.dbf). The linear feature is identified by the linear feature identifier (LINEARID) attribute, which can be used to relate the address range back to the name attributes of the feature in the Feature Names Relationship File or to the feature record in the Primary Roads, Primary and Secondary Roads, or All Roads Shapefiles. The edge to which a feature name applies can be determined by linking the feature name record to the All Lines Shapefile (EDGES.shp) using the permanent edge identifier (TLID) attribute. The address range identifier(s) (ARID) for a specific linear feature can be found by using the linear feature identifier (LINEARID) from the Feature Names Relationship File (FEATNAMES.dbf) through the Address Range / Feature Name Relationship File (ADDRFN.dbf).

This dataset is a modified version of the FWS developed data depicting “Highly Important Landscapes”, as outlined in Memorandum FWS/AES/058711 and provided to the Wildlife Habitat Spatial analysis Lab on October 29th 2014. Other names and acronyms used to refer to this dataset have included: Areas of Significance (AoSs - name of GIS data set provided by FWS), Strongholds (FWS), and Sagebrush Focal Areas (SFAs - BLM). The BLM will refer to these data as Sagebrush Focal Areas (SFAs). Data were provided as a series of ArcGIS map packages which, when extracted, contained several datasets each. Based on the recommendation of the FWS Geographer/Ecologist (email communication, see data originator for contact information) the dataset called “Outiline_AreasofSignificance” was utilized as the source for subsequent analysis and refinement. Metadata was not provided by the FWS for this dataset. For detailed information regarding the dataset’s creation refer to Memorandum FWS/AES/058711 or contact the FWS directly. Several operations and modifications were made to this source data, as outlined in the “Description” and “Process Step” sections of this metadata file. Generally: The source data was named by the Wildlife Habitat Spatial Analysis Lab to identify polygons as described (but not identified in the GIS) in the FWS memorandum. The Nevada/California EIS modified portions within their decision space in concert with local FWS personnel and provided the modified data back to the Wildlife Habitat Spatial Analysis Lab. Gaps around Nevada State borders, introduced by the NVCA edits, were then closed as was a large gap between the southern Idaho & southeast Oregon present in the original dataset. Features with an area below 40 acres were then identified and, based on FWS guidance, either removed or retained. Guidance from BLM WO resulted in the removal of additional areas including: non-habitat with BLM surface or subsurface management authority, all areas within the Lander EIS boundary, and areas outside of PHMA once EISs had updated PHMA designation.Several Modifications from the original FWS dataset have been made. Below is a summary of each modification.1. The data as received from FWS.2. Edited to name SFAs by Wildlife Habitat Spatial Analysis Lab:Upon receipt of the “Outiline_AreasofSignificance” dataset from the FWS, a copy was made and the one existing & unnamed record was exploded in an edit session within ArcMap. A text field, “AoS_Name”, was added. Using the maps provided with Memorandum FWS/AES/058711, polygons were manually selected and the “AoS_Name” field was calculated to match the names as illustrated. Once all polygons in the exploded dataset were appropriately named, the dataset was dissolved, resulting in one record representing each of the seven SFAs identified in the memorandum.3. The NVCA EIS made modifications in concert with local FWS staff. Metadata and detailed change descriptions were not returned with the modified data. Contact Leisa Wesch, GIS Specialist, BLM Nevada State Office, 775-861-6421, lwesch@blm.gov, for details.4. Once the data was returned to the Wildlife Habitat Spatial Analysis Lab from the NVCA EIS, gaps surrounding the State of NV were closed. These gaps were introduced by the NVCA edits, exacerbated by them, or existed in the data as provided by the FWS. The gap closing was performed in an edit session by either extending each polygon towards each other or by creating a new polygon, which covered the gap, and merging it with the existing features. In addition to the gaps around state boundaries, a large area between the S. Idaho and S.E. Oregon SFAs was filled in. To accomplish this, ADPP habitat (current as of January 2015) and BLM GSSP SMA data were used to create a new polygon representing PHMA and BLM management that connected the two existing SFAs.5. In an effort to simplify the FWS dataset, features whose areas were less than 40 acres were identified and FWS was consulted for guidance on possible removal. To do so, features from #4 above were exploded once again in an ArcMap edit session. Features whose areas were less than forty acres were selected and exported (770 total features). This dataset was provided to the FWS and then returned with specific guidance on inclusion/exclusion via email by Lara Juliusson (lara_juliusson@fws.gov). The specific guidance was:a. Remove all features whose area is less than 10 acresb. Remove features identified as slivers (the thinness ratio was calculated and slivers identified by Lara Juliusson according to https://tereshenkov.wordpress.com/2014/04/08/fighting-sliver-polygons-in-arcgis-thinness-ratio/) and whose area was less than 20 acres.c. Remove features with areas less than 20 acres NOT identified as slivers and NOT adjacent to other features.d. Keep the remainder of features identified as less than 40 acres.To accomplish “a” and “b”, above, a simple selection was applied to the dataset representing features less than 40 acres. The select by location tool was used, set to select identical, to select these features from the dataset created in step 4 above. The records count was confirmed as matching between the two data sets and then these features were deleted. To accomplish “c” above, a field (“AdjacentSH”, added by FWS but not calculated) was calculated to identify features touching or intersecting other features. A series of selections was used: first to select records < 20 acres that were not slivers, second to identify features intersecting other features, and finally another to identify features touching the boundary of other features. Once the select by locations were applied, the field “AdjacentSH” was calculated to identify the features as touching, intersecting or not touching other features. Features identified as not touching or intersecting were selected, then the select by location tool was used , set to select identical, to select these features from the dataset created in step 4 above. The records count was confirmed as matching between the two data sets and then these features were deleted. 530 of the 770 features were removed in total.6. Based on direction from the BLM Washington Office, the portion of the Upper Missouri River Breaks National Monument (UMRBNM) that was included in the FWS SFA dataset was removed. The BLM NOC GSSP NLCS dataset was used to erase these areas from #5 above. Resulting sliver polygons were also removed and geometry was repaired.7. In addition to removing UMRBNM, the BLM Washington Office also directed the removal of Non-ADPP habitat within the SFAs, on BLM managed lands, falling outside of Designated Wilderness’ & Wilderness Study Areas. An exception was the retention of the Donkey Hills ACEC and adjacent BLM lands. The BLM NOC GSSP NLCS datasets were used in conjunction with a dataset containing all ADPP habitat, BLM SMA and BLM sub-surface management unioned into one file to identify and delete these areas.8. The resulting dataset, after steps 2 – 8 above were completed, was dissolved to the SFA name field yielding this feature class with one record per SFA area.9. The "Acres" field was added and calculated.10. All areas within the Lander EIS were erased from the dataset (ArcGIS 'Erase' function) and resulting sliver geometries removed.11. Data were clipped to Proposed Plan PHMA.12. The "Acres" field was re-calculated

The TIGER/Line shapefiles and related database files (.dbf) are an extract of selected geographic and cartographic information from the U.S. Census Bureau's Master Address File / Topologically Integrated Geographic Encoding and Referencing (MAF/TIGER) Database (MTDB). The MTDB represents a seamless national file with no overlaps or gaps between parts, however, each TIGER/Line shapefile is designed to stand alone as an independent data set, or they can be combined to cover the entire nation. The Feature Names Relationship File (FEATNAMES.dbf) contains a record for each feature name and any attributes associated with it. Each feature name can be linked to the corresponding edges that make up that feature in the All Lines Shapefile (EDGES.shp), where applicable to the corresponding address range or ranges in the Address Ranges Relationship File (ADDR.dbf), or to both files. Although this file includes feature names for all linear features, not just road features, the primary purpose of this relationship file is to identify all street names associated with each address range. An edge can have several feature names; an address range located on an edge can be associated with one or any combination of the available feature names (an address range can be linked to multiple feature names). The address range is identified by the address range identifier (ARID) attribute, which can be used to link to the Address Ranges Relationship File (ADDR.dbf). The linear feature is identified by the linear feature identifier (LINEARID) attribute, which can be used to relate the address range back to the name attributes of the feature in the Feature Names Relationship File or to the feature record in the Primary Roads, Primary and Secondary Roads, or All Roads Shapefiles. The edge to which a feature name applies can be determined by linking the feature name record to the All Lines Shapefile (EDGES.shp) using the permanent edge identifier (TLID) attribute. The address range identifier(s) (ARID) for a specific linear feature can be found by using the linear feature identifier (LINEARID) from the Feature Names Relationship File (FEATNAMES.dbf) through the Address Range / Feature Name Relationship File (ADDRFN.dbf).

The TIGER/Line shapefiles and related database files (.dbf) are an extract of selected geographic and cartographic information from the U.S. Census Bureau's Master Address File / Topologically Integrated Geographic Encoding and Referencing (MAF/TIGER) Database (MTDB). The MTDB represents a seamless national file with no overlaps or gaps between parts, however, each TIGER/Line shapefile is designed to stand alone as an independent data set, or they can be combined to cover the entire nation. The Feature Names Relationship File (FEATNAMES.dbf) contains a record for each feature name and any attributes associated with it. Each feature name can be linked to the corresponding edges that make up that feature in the All Lines Shapefile (EDGES.shp), where applicable to the corresponding address range or ranges in the Address Ranges Relationship File (ADDR.dbf), or to both files. Although this file includes feature names for all linear features, not just road features, the primary purpose of this relationship file is to identify all street names associated with each address range. An edge can have several feature names; an address range located on an edge can be associated with one or any combination of the available feature names (an address range can be linked to multiple feature names). The address range is identified by the address range identifier (ARID) attribute, which can be used to link to the Address Ranges Relationship File (ADDR.dbf). The linear feature is identified by the linear feature identifier (LINEARID) attribute, which can be used to relate the address range back to the name attributes of the feature in the Feature Names Relationship File or to the feature record in the Primary Roads, Primary and Secondary Roads, or All Roads Shapefiles. The edge to which a feature name applies can be determined by linking the feature name record to the All Lines Shapefile (EDGES.shp) using the permanent edge identifier (TLID) attribute. The address range identifier(s) (ARID) for a specific linear feature can be found by using the linear feature identifier (LINEARID) from the Feature Names Relationship File (FEATNAMES.dbf) through the Address Range / Feature Name Relationship File (ADDRFN.dbf).

Connecticut Hydrography Set:

Connecticut Hydrography Line includes the line features of a layer named Hydrography. Hydrography is a 1:24,000-scale, polygon and line feature-based layer that includes all hydrography features depicted on the U.S. Geological Survey (USGS) 7.5 minute topographic quadrangle maps for the State of Connecticut. This layer only includes features located in Connecticut. These hydrography features include waterbodies, inundation areas, marshes, dams, aqueducts, canals, ditches, shorelines, tidal flats, shoals, rocks, channels, and islands. Hydrography is comprised of polygon and line features. Polygon features represent areas of water for rivers, streams, brooks, reservoirs, lakes, ponds, bays, coves, and harbors. Polygon features also depict inundation areas, marshes, dams, aqueducts, canals, tidal flats, shoals, rocks, channels, and islands shown on the USGS 7.5 minute topographic quadrangle maps. Line features represent single-line rivers and streams, aqueducts, canals, and ditches. Line features also enclose all polygon features in the form of natural shorelines, manmade shorelines, dams, closure lines separating adjacent waterbodies, and the apparent limits for tidal flats, rocks, and areas of marsh. The layer is based on information from USGS topographic quadrangle maps published between 1969 and 1984 so it does not depict conditions at any one particular point in time. Also, the layer does not reflect recent changes with the course of streams or location of shorelines impacted by natural events or changes in development since the time the USGS 7.5 minute topographic quadrangle maps were published. Attribute information is comprised of codes to identify hydrography features by type, cartographically represent (symbolize) hydrography features on a map, select waterbodies appropriate to display at different map scales, identify individual waterbodies on a map by name, and describe feature area and length. The names assigned to individual waterbodies are based on information published on the USGS 7.5 minute topographic quadrangle maps or other state and local maps. The layer does not include bathymetric, stream gradient, water flow, water quality, or biological habitat information. This layer was originally published in 1994. The 2005 edition includes the same water features published in 1994, however some attribute information has been slightly modified and made easier to use. Also, the 2005 edition corrects previously undetected attribute coding errors.

Connecticut Hydrography Polygon includes the polygon features of a layer named Hydrography. Hydrography is a 1:24,000-scale, polygon and line feature-based layer that includes all hydrography features depicted on the U.S. Geological Survey (USGS) 7.5 minute topographic quadrangle maps for the State of Connecticut. This layer only includes features located in Connecticut. These hydrography features include waterbodies, inundation areas, marshes, dams, aqueducts, canals, ditches, shorelines, tidal flats, shoals, rocks, channels, and islands. Hydrography is comprised of polygon and line features. Polygon features represent areas of water for rivers, streams, brooks, reservoirs, lakes, ponds, bays, coves, and harbors. Polygon features also depict inundation areas, marshes, dams, aqueducts, canals, tidal flats, shoals, rocks, channels, and islands shown on the USGS 7.5 minute topographic quadrangle maps. Line features represent single-line rivers and streams, aqueducts, canals, and ditches. Line features also enclose all polygon features in the form of natural shorelines, manmade shorelines, dams, closure lines separating adjacent waterbodies, and the apparent limits for tidal flats, rocks, and areas of marsh. The layer is based on information from USGS topographic quadrangle maps published between 1969 and 1984 so it does not depict conditions at any one particular point in time. Also, the layer does not reflect recent changes with the course of streams or location of shorelines impacted by natural events or changes in development since the time the USGS 7.5 minute topographic quadrangle maps were published. Attribute information is comprised of codes to identify hydrography features by type, cartographically represent (symbolize) hydrography features on a map, select waterbodies appropriate to display at different map scales, identify individual waterbodies on a map by name, and describe feature area and length. The names assigned to individual waterbodies are based on information published on the USGS 7.5 minute topographic quadrangle maps or other state and local maps. The layer does not include bathymetric, stream gradient, water flow, water quality, or biological habitat information. This layer was originally published in 1994. The 2005 edition includes the same water features published in 1994, however some attribute information has been slightly modified and made easier to use. Also, the 2005 edition corrects previously undetected attribute coding errors.

Underwood et al. (2023) have recently introduced the tandem evolutionary algorithm (TEVA) of Hanley et al. (2020) to the water resources and ecology domains, and applied it to identify features (catchment-scale attributes) and feature interactions important in determining patterns in Dissolved Organic Carbon across the continental US. TEVA has particular advantages for feature selection in large, multivariate observational data sets of complex systems like riverscapes or ecosystems, and has been shown to outperform logistic regression or Random Forest for identifying feature interactions and equifinality (Hanley et al., 2020; Anderson et al., 2020). TEVA finds interactions between multiple variables that may result from either additive processes or feature interactions, and not only extracts features significantly associated with a given outcome class(es), but also identifies the specific value ranges associated with those features (Underwood et al., 2023; Hanley, et al., 2020). This algorithm is also robust to issues of mixed data types (continuous, categorical), missing data, censored data, skewed distributions, and unbalanced target classes or clusters (Hanley et al., 2020).

When presented with n observations of p features across a study domain and a target of one or more classes or outcomes, the algorithm identifies and archives two types of clauses below a given fitness threshold. In the first pass, TEVA identifies Conjunctive Clauses (CCs) - a combination of variables that may or may not be correlated and somehow interact to produce an outcome. For example, an Extreme Flood may result from steep slopes + shallow soils + intense rainfall. A second pass of TEVA identifies Disjunctive Clauses (DCs) - a sequence of CCs that are linked with a logical “OR” statement. For example, an Extreme Flood may results from (steep slopes + shallow soils + intense rainfall) OR (high antecedent soil moisture + rainfall) OR (thick snow pack + high temperatures). DCs are multi-order, while the CCs comprising a DC can themselves range from first-order to multi-order (Underwood et al., 2023).

In this workshop, we illustrate the functionality of TEVA using a dataset of 91 observations from forested catchments across the CONUS of 54 catchment attributes inferred to have importance to DOC dynamics. Combinations of these catchment attributes were identified in CCs and DCs with high probability to be linked to an outcome class of High or Low mean DOC concentration. Target classes were assigned using Jenks natural breaks for 91 catchments with sufficient (≥3) observations of DOC in stream water to calculate a mean value. Originally, computation of TEVA was performed in the MATLAB programming language; the codebase has now been transferred to the open-source coding language Python, and is accessed through CUAHSI JupyterHub.

The dataset was used to produce the results from the "Identifying zebrafish segmentation phenotype features using multiple instance learning" manuscript. It contains images of zebrafish embryos obtained by in situ hybridization that were used to train and evaluate the performance of different neural network-based image classifiers. Images were split into 4 classes: unmodified (WT) zebrafish embryo, and 3 more phenotypes reflecting different segmentation clock defects.
Folder 'data' contains 3 different directories: 'training', the set used for training of the classifiers, 'validation', the set used for evaluation of the performance of the classifiers, with 20 images from each class, and 'fish_part_labels' that contains the annotation of zebrafish embryo parts (head, trunk, tail, yolk, and yolk extension) of the images from the 'validation' set.

Over the last two decades, camera traps have revolutionised the ability of biologists to undertake faunal surveys and estimate population densities, although identifying individuals of species with subtle markings remains challenging. We conducted a two-year camera-trapping study as part of a long-term study of urban foxes: our objectives were to determine whether red foxes could be identified individually from camera-trap photos, and highlight camera-trapping protocols and techniques to facilitate photo identification of species with few or subtle natural markings. We collected circa 800,000 camera-trap photos over 4945 camera days in suburban gardens in the city of Bristol, UK: 152,134 (19 %) included foxes, of which 13,888 (9 %) contained more than one fox. These provided 174,063 timestamped capture records of individual foxes; 170,923 were of foxes ≥ 3 months old. Younger foxes were excluded because they have few distinguishing features. We identified the individual (192 different foxes: 110 males, 49 females, 33 of unknown sex) in 168,417 (99 %) of these capture records; the remainder could not be identified due to poor image quality or because key identifying feature(s) were not visible.
We show that carefully designed survey techniques facilitate individual identification of subtly-marked species. Accuracy is enhanced by camera-trapping techniques that yield large numbers of high resolution, colour images from multiple angles taken under varying environmental conditions. While identifying foxes manually was labour-intensive, currently available automated identification systems are unlikely to achieve the same levels of accuracy, especially since different features were used to identify each fox, the features were often inconspicuous, and their appearance varied with environmental conditions. We discuss how studies based on low numbers of photos, or which fail to identify the individual in a significant proportion of photos, risk losing important biological information, and may come to erroneous conclusions.

The construction of this data model was adapted from the Telvent Miner & Miner ArcFM MultiSpeak data model to provide interface functionality with Milsoft Utility Solutions WindMil engineering analysis program. Database adaptations, GPS data collection, and all subsequent GIS processes were performed by Southern Geospatial Services for the Town of Apex Electric Utilities Division in accordance to the agreement set forth in the document "Town of Apex Electric Utilities GIS/GPS Project Proposal" dated March 10, 2008. Southern Geospatial Services disclaims all warranties with respect to data contained herein. Questions regarding data quality and accuracy should be directed to persons knowledgeable with the forementioned agreement.The data in this GIS with creation dates between March of 2008 and April of 2024 were generated by Southern Geospatial Services, PLLC (SGS). The original inventory was performed under the above detailed agreement with the Town of Apex (TOA). Following the original inventory, SGS performed maintenance projects to incorporate infrastructure expansion and modification into the GIS via annual service agreements with TOA. These maintenances continued through April of 2024.At the request of TOA, TOA initiated in house maintenance of the GIS following delivery of the final SGS maintenance project in April of 2024. GIS data created or modified after April of 2024 are not the product of SGS.With respect to SGS generated GIS data that are point features:GPS data collected after January 1, 2013 were surveyed using mapping grade or survey grade GPS equipment with real time differential correction undertaken via the NC Geodetic Surveys Real Time Network (VRS). GPS data collected prior to January 1, 2013 were surveyed using mapping grade GPS equipment without the use of VRS, with differential correction performed via post processing.With respect to SGS generated GIS data that are line features:Line data in the GIS for overhead conductors were digitized as straight lines between surveyed poles. Line data in the GIS for underground conductors were digitized between surveyed at grade electric utility equipment. The configurations and positions of the underground conductors are based on TOA provided plans. The underground conductors are diagrammatic and cannot be relied upon for the determination of the actual physical locations of underground conductors in the field.The Service Locations feature class was created by Southern Geospatial Services (SGS) from a shapefile of customer service locations generated by dataVoice International (DV) as part of their agreement with the Town of Apex (TOA) regarding the development and implemention of an Outage Management System (OMS).Point features in this feature class represent service locations (consumers of TOA electric services) by uniquely identifying the features with the same unique identifier as generated for a given service location in the TOA Customer Information System (CIS). This is also the mechanism by which the features are tied to the OMS. Features are physically located in the GIS based on CIS address in comparison to address information found in Wake County GIS property data (parcel data). Features are tied to the GIS electric connectivity model by identifying the parent feature (Upline Element) as the transformer that feeds a given service location.SGS was provided a shapefile of 17992 features from DV. Error potentially exists in this DV generated data for the service location features in terms of their assigned physical location, phase, and parent element.Regarding the physical location of the features, SGS had no part in physically locating the 17992 features as provided by DV and cannot ascertain the accuracy of the locations of the features without undertaking an analysis designed to verify or correct for error if it exists. SGS constructed the feature class and loaded the shapefile objects into the feature class and thus the features exist in the DV derived location. SGS understands that DV situated the features based on the address as found in the CIS. No features were verified as to the accuracy of their physical location when the data were originally loaded. It is the assumption of SGS that the locations of the vast majority of the service location features as provided by DV are in fact correct.SGS understands that as a general rule that DV situated residential features (individually or grouped) in the center of a parcel. SGS understands that for areas where multiple features may exist in a given parcel (such as commercial properties and mobile home parks) that DV situated features as either grouped in the center of the parcel or situated over buildings, structures, or other features identifiable in air photos. It appears that some features are also grouped in roads or other non addressed locations, likely near areas where they should physically be located, but that these features were not located in a final manner and are either grouped or strung out in a row in the general area of where DV may have expected they should exist.Regarding the parent and phase of the features, the potential for error is due to the "first order approximation" protocol employed by DV for assigning the attributes. With the features located as detailed above, SGS understands that DV identified the transformer closest to the service location (straight line distance) as its parent. Phase was assigned to the service location feature based on the phase of the parent transformer. SGS expects that this protocol correctly assigned parent (and phase) to a significant portion of the features, however this protocol will also obviously incorretly assign parent in many instances.To accurately identify parent for all 17992 service locations would require a significant GIS and field based project. SGS is willing to undertake a project of this magnitude at the discretion of TOA. In the meantime, SGS is maintaining (editing and adding to) this feature class as part of the ongoing GIS maintenance agreement that is in place between TOA and SGS. In lieu of a project designed to quality assess and correct for the data provided by DV, SGS will verify the locations of the features at the request of TOA via comparison of the unique identifier for a service location to the CIS address and Wake County parcel data address as issues arise with the OMS if SGS is directed to focus on select areas for verification by TOA. Additionally, as SGS adds features to this feature class, if error related to the phase and parent of an adjacent feature is uncovered during a maintenance, it will be corrected for as part of that maintenance.With respect to the additon of features moving forward, TOA will provide SGS with an export of CIS records for each SGS maintenance, SGS will tie new accounts to a physical location based on address, SGS will create a feature for the CIS account record in this feature class at the center of a parcel for a residential address or at the center of a parcel or over the correct (or approximately correct) location as determined via air photos or via TOA plans for commercial or other relevant areas, SGS will identify the parent of the service location as the actual transformer that feeds the service location, and SGS will identify the phase of the service address as the phase of it's parent.Service locations with an ObjectID of 1 through 17992 were originally physically located and attributed by DV.Service locations with an ObjectID of 17993 or higher were originally physically located and attributed by SGS.DV originated data are provided the Creation User attribute of DV, however if SGS has edited or verified any aspect of the feature, this attribute will be changed to SGS and a comment related to the edits will be provided in the SGS Edits Comments data field. SGS originated features will be provided the Creation User attribute of SGS. Reference the SGS Edits Comments attribute field Metadata for further information.

The Michigan Department of Natural Resources (DNR) does have many locations or features which help or particularly benefit those public users, photography enthusiasts, birdwatchers, or hunters who have special mobility needs and benefit from special accessible conditions to reach our outdoor and wildlife resources. The DNR website has details and a wide variety of accessible, ADA compliant rules, guidelines and features and (see webpage http://www.michigan.gov/dnr/0,4570,7-153-10366_41825---,00.html and subpage on hunting / wildlife information at http://www.michigan.gov/dnr/0,4570,7-153-10366_41825_51108---,00.html ). Users may require only walking assistance devices or may be those with specific wheelchairs, personal assistive mobility devices (PAMDs), or other motorized-type vehicles.

Please check rules for specific rules, regulations, and restrictions as they relate to what equipment might be used, before using such equipment, as not all equipment legal on public places, residential or commercial buildings, or such are allowed on all areas of Michigan’s public land managed by the DNR.

Accessible features on State Wildlife/Game Area include those which have low-slope, no stairs or steps along features, and are accessible for wheelchairs, or personal assistive mobility devices (PAMDs). All buildings, DNR Shooting-Ranges, and other permanent public use structures are fully ADA compliant and accessible. It is the more natural features being identified in this layer. Many of these features are fully ADA code compliant (which is ~1 inch rise or less over 12 inch distances) and are regularly checked for obstructions, while other features comply with the low-slope requirements or are identified as such so they are not over-represented to a lower or no slope level. In natural rustic areas it can be difficult to maintain these slope limits and to clearing check for naturally-occurring obstructions like leaves, sticks or other naturally occurring items which blow or wash onto trails or outside features. Therefore, features are frequently identified as no-slope or low-slope/PAMD levels and not over-represented as fully ADA compliant.

The DNR Wildlife Division is in a updated state-wide review to identify features and provide better information on accessible features, such as by GIS compatible layers provided here. Accessible features typically include accessible combinations of parking, a trail and a destination location like a platform or blind location; read the attribute fields like the “comment” field, for details on what is at the provided data point, line or polygon. Although available for use by anyone, it's hoped consideration for use will be given to those individuals that have limited mobility, please, for use of these accessible parking, trails, blinds or platforms, and other features. Patience is appreciated for local site conditions which might be caused by weather, wind or rain, wildlife or other public users; please report any problems with features to either the local DNR Wildlife office or the main DNR Wildlife help options (e-mail DNR-Wildlife@michigan.gov , or call 517-284-9453).

Anomaly detection is a process of identifying items, events or observations, which do not conform to an expected pattern in a dataset or time series. Current and future missions and our research communities challenge us to rapidly identify features and anomalies in complex and voluminous observations to further science and improve decision support. Given this data intensive reality, we propose to develop an anomaly detection system, called OceanXtremes, powered by an intelligent, elastic Cloud-based analytic service backend that enables execution of domain-specific, multi-scale anomaly and feature detection algorithms across the entire archive of ocean science datasets. A parallel analytics engine will be developed as the key computational and data-mining core of OceanXtreams' backend processing. This analytic engine will demonstrate three new technology ideas to provide rapid turn around on climatology computation and anomaly detection: 1. An adaption of the Hadoop/MapReduce framework for parallel data mining of science datasets, typically large 3 or 4 dimensional arrays packaged in NetCDF and HDF. 2. An algorithm profiling service to efficiently and cost-effectively scale up hybrid Cloud computing resources based on the needs of scheduled jobs (CPU, memory, network, and bursting from a private Cloud computing cluster to public cloud provider like Amazon Cloud services). 3. An extension to industry-standard search solutions (OpenSearch and Faceted search) to provide support for shared discovery and exploration of ocean phenomena and anomalies, along with unexpected correlations between key measured variables. We will use a hybrid Cloud compute cluster (private Eucalyptus on-premise at JPL with bursting to Amazon Web Services) as the operational backend. The key idea is that the parallel data-mining operations will be run 'near' the ocean data archives (a local 'network' hop) so that we can efficiently access the thousands of (say, daily) files making up a three decade time-series, and then cache key variables and pre-computed climatologies in a high-performance parallel database. OceanXtremes will be equipped with both web portal and web service interfaces for users and applications/systems to register and retrieve oceanographic anomalies data. By leveraging technology such as Datacasting (Bingham, et.al, 2007), users can also subscribe to anomaly or 'event' types of their interest and have newly computed anomaly metrics and other information delivered to them by metadata feeds packaged in standard Rich Site Summary (RSS) format. Upon receiving new feed entries, users can examine the metrics and download relevant variables, by simply clicking on a link, to begin further analyzing the event. The OceanXtremes web portal will allow users to define their own anomaly or feature types where continuous backend processing will be scheduled to populate the new user-defined anomaly type by executing the chosen data mining algorithm (i.e. differences from climatology or gradients above a specified threshold). Metadata on the identified anomalies will be cataloged including temporal and geospatial profiles, key physical metrics, related observational artifacts and other relevant metadata to facilitate discovery, extraction, and visualization. Products created by the anomaly detection algorithm will be made explorable and subsettable using Webification (Huang, et.al, 2014) and OPeNDAP (http://opendap.org) technologies. Using this platform scientists can efficiently search for anomalies or ocean phenomena, compute data metrics for events or over time-series of ocean variables, and efficiently find and access all of the data relevant to their study (and then download only that data).