fellahst
commented
5 months ago The requirements enumerated in your ticket have been addressed in the latest version of DCAT-US 3.0.
Closed sofianef closed 5 months ago
fellahst
commented
5 months ago The requirements enumerated in your ticket have been addressed in the latest version of DCAT-US 3.0.
mrratcliffe
commented
5 months ago +1
Creator Name: Dominic Menegus Creator Contact Information: Geographer/NTAD Program Manager, dominic.menegus@dot.gov Creator Affiliation: USDOT/Bureau of Transportation Statistics (BTS)
Requirement(s)
The National Transportation Atlas Database (NTAD) is a congressionally mandated program within the Bureau of Transportation Statistics (BTS), to collect and disseminate geospatial data in various formats related to the location of transportation infrastructure/networks, how freight and passengers traverse the networks, and how the networks impact social, environmental, and economic variables. With publishing these datasets to the public, metadata that would accompany them is also extremely important for the NTAD mandate, our stakeholders, and our users.
Therefore the requirements for BTS’ use case for a future metadata schema would be have metadata elements that could be easily viewed and retrieved from our NTAD datasets via different data formats, such as an open data catalog or website for downloading data as a shapefile/ESRI Geodatabase/Excel file, metadata to be ingested into OGC WMS and WFS standard services, and other various APIs such as GeoeJSON. Organizing such a schema so that the metadata could appear in these formats consistently across the board would also be a requirement.
Some metadata elements to make sure the schema could handle would be:
· Dataset name · Description/Abstract · Purpose · Data as of date · Data published date · Contact information (Name, position, title, organization, address information, email, phone number) · Credits/attribution · Keywords/tags · Update interval · Process description (how the dataset was created) and date the process took place · Geographic information/elements (bounding box, projections, scale) · Use constraints · Access constraints · Data dictionary (field name, field domains, definitions, and sources; either in the standard itself or also being able to link to a dictionary somewhere else as a reference) · Links to where the data are stored
Problem Statement
There is no “problem” per se with our current metadata schema.
Target Audience / Stakeholders
Our target audience/stakeholders are very broad, it is the general public looking to find geospatial data related to the US transportation infrastructure. The general public will also be looking to utilize the information on NTAD in many formats and therefore needed to lookup metadata for the layers accordingly. These include users who are able to discover metadata in the environments:
· An Esri Open Data Catalog · OGC Web Feature Service (WFS) · OGC Web Mapping Service (WMS) · OGC Vector Tile Service · Esri Service · GeoJSON · GeoService · Discover metadata for layer on data.gov and geoplatform.gov
Consequently, these would be: · Consumers of DataServices/APIs · Geospatial web developers · Consumers of geospatial transportation data · Transportation network modelers
Intended Uses / Use Cases
Being able to systematically create an xml metadata file that can live and be part of a geospatial dataset in the environments stipulated above. Also to have an xml with a schema be able to be uploaded to data.gov and geoplatform.gov
Existing Approaches
The ISO 19115 is the standard currently being used. https://www.fgdc.gov/metadata/iso-standards
It has worked fairly well, a metadata schema with significant overlap but catering to a more widespread of data formats consistently may work.
Additional context, comments, or links
Original Email Submission: DCAT-US-3-Requirements-BTS.docx