General FAQs

Q: What is the The National Geothermal Data System (NGDS)?

Q: Who uses the NGDS?

Q: How do I access the data?

Q: How do I submit or contribute data?

Q: Will NGDS own my data if I contribute to the system?

Q: What are Web Services?

Q: Who is currently providing data to the NGDS?

Q: What is United States Geoscience Information Network (USGIN)?

Q: What is the NGDS?

A: The National Geothermal Data System (NGDS) is a distributed data system providing access to information resources related to geothermal energy from a network of data providers. Data are contributed by academic researchers, private industry, and state and federal agencies.  Built on a scalable and open platform through the U.S. Geoscience Information Network (USGIN), NGDS respects data provenance while promoting shared resources.  Since NGDS is built using a set of open protocols and standards, relying on the Open Geospatial Consortium (OGC) and International Organization for Standardization (ISO), members of the community may access the data in a variety of proprietary and open-source applications and software. In addition, developers can add functionality to the system by creating new applications based on the open protocols and standards of the NGDS.  

Q: Who uses the NGDS?

A: There are three general groups that would use the NGDS: data providers, data users, and developers. Data providers may have environmental resource or geophysical data intended for wide availability and distribution or subscription-controlled access. Data consumers constitute a wide variety of data use cases, including state and federal government entities concerned with natural resources and geophysical data preservation, energy corporations accessing data for areas of potential resource (i.e. geothermal energy) development, as well as individuals conducting research or interested in local geophysical data. Due to the open standards and protocols on which the NGDS is built, developers that are interested in creating a new application, for example a data gap analysis, or financial analysis, may build their application to consume data resources in the NGDS.

This site is designed to invite and address the interests of each of these users.  Data providers should visit the Publish Data portion of the site; data users should visit the Use Data portion of the site; and developers should utilize the Developers portion of the site.

Q: How do I access the data?

A: Data in the NGDS catalog can be viewed using the custom search interface, or any of the applications for which the NGDS is compliant with. If you’re a developer interested in how you can build an application for the NGDS, visit our Developer’s page which includes a mechanism for submitting your application to the NGDS.

Q: How do I submit or contribute data?

A: Please refer to the Publish Data section of this website for complete information on submitting resources to the NGDS.

Q: Will NGDS own my data if I contribute to the system?

A: No, that’s the beauty of the NGDS. Data can be registered/contributed to the system in a variety of formats and published in a variety of formats. The simplest and easiest method for contributing data is to create a metadata record for your resource and register that in the catalog. In this instance, you will maintain the data at your site (either in hard copy or digitally on your server/website), and include brief information on the dataset and how to access the resource, if it is online, or how to contact you, if the resource is hard copy. While this permits end users to “find” your data, it does not promote the high degree of interoperability that NGDS has been designed for, i.e. working with multiple geospatial datasets and running queries against those datasets. When your data is deployed in an OGC compliant web service, it is provided to the public as a read-only dataset that can be downloaded and queried in geospatial software against other related datasets.  For more information, refer to the Publish Data section of this website.

Q: What are Web Services?

A: A web service is a resource with functional capabilities that can be invoked via a request (message) sent using the World Wide Web. Web services are the primary means by which digital geoscience information can be shared according to NGDS specifications. Services are well suited to this task for a number of reasons: owing to standardized data requests, they can be accessed from a variety of platforms; they are read-only and preserve data ownership; they come in a number of varieties for different purposes. An important operation of a web service includes the message format used to encode information which is sent to the server in a request, and the encoded information returned by the server. For the Web Map Service (WMS) examples given in Using Applications, the message format of particular interest is the XML encoding used to transmit requested data back to the client computer. Web Feature Services (WFS), which return Open Geospatial Consortium (OGC)—compliant, XML data interchange documents, are currently used by USGIN for data exchange.

For a data consumer, using a web service allows you to access a distributed network of data from many sources having disparate data types.

Q: Who is currently providing data to the NGDS?

A: There are currently five NGDS projects each representing a broad range of participants. A complete list of all project participants can be found at the Data Contributors portion of this site.

Q: What is United States Geoscience Information Network (USGIN)?

A: USGIN is a series of protocols and standards used to build a distributed data-sharing network that uses open-source software and existing World Wide Web infrastructure and browsers. For more information visit the USGIN website.

Anas Ramadan, from The Noun Project

Developer FAQs

Derived from a session at the ESIP Summer Meeting in 2012, for more information see Implementing USGIN, a Distributed Data Network for Geoscience Information. For additional developer questions, visit the Developers page or USGIN Lab.

Q:How was Excel chosen, over other tools such as Access or other database files, for standard input into the system? How is the data compiled or expected to be compiled on the provider’s side of things in to these Excel files? What is the process for exporting it to these Excel files? That is, what is the burden on the contributor and how do they feel about the process?

Q: Where are the standards listed for the syntax for the spreadsheet—how do you show which version of Lat/Long, etc.

Q: Is there a link to the CSW end point? On the revised catalog instance are you reloading/redeploying the CSW?

Q: How did we define the symbology for the WFS? How does the WFS ingest the symbology?

Q: How are we handling multiple authors or resources in a single field on the spreadsheet?

Q: Does the validation on the metadata only review that the field is complete or are their syntax checks in place as well?

Q: How was Excel chosen, over other tools such as Access or other database files, for standard input into the system? How is the data compiled or expected to be compiled on the provider’s side of things in to these Excel files? What is the process for exporting it to these Excel files? That is, what is the burden on the contributor and how do they feel about the process?

A: It is important to distinguish between “standard input into the system” and these Excel files. From the system’s perspective, “standard input” is data provided according to a specific content model (that is, has the right fields) and accessible via WFS requests. The Excel files that we have built are simply tools to help data providers map their data, in whatever format they have it, into a system-standard content model. The Excel files do not represent the only way for data to be included into the system; they’re simply a tool to assist in data transformation.

Excel files were chosen as they are a great way to organize your data into a scheme that USGIN can use to make your data interoperable. You may search the names of the content models at Data Interchange Content Models and choose the content model that best suits your data type. These excel files allow several tabs to explicate the process, data types, specific terms, and other information valuable to the data provider. Often, we do have project participants that submit Access databases to us and we work with them to help parse that data into content models, and are happy to do so. We like to assess what data the provider has and help them to submit their data. Additionally, these content models (given on our site as Excel files) may be viewed in Access, allowing the data provider to add data from their database, then submit to us, all using Access. (Actually this is great from our standpoint, as at this point, we can view the Access database in ArcCatalog and transform the data into the desired Geodatabase Feature Class for service deployment.)

Q: Where are the standards listed for the syntax for the spreadsheet—how do you show which version of Lat/Long, etc.

A: The versions of Latitude, Longitude, and all other fields are explicitly requested in a tab within the template excel file for any given dataset. This tab is the “Field List” where a short description of the intended data and data type are given for each of the field headings in the content model.

Q: Is there a link to the CSW end point? On the revised catalog instance are you reloading/redeploying the CSW?

A: There will be new CSW catalogs in the very near future. One will strictly contain AASG Resources, another will contain AASG resources as well as other assorted USGIN resources. The URL for the CSW endpoint itself is closely related to the Geoportal page—e.g., http://catalog.usgin.org/geoportal/csw?

The trick is knowing what to put after the question mark. That requires you know how to work a CSW.

Q: How did we define the symbology for the WFS?  How does the WFS ingest the symbology?

A: Strictly speaking, there's no such thing as symbology in a WFS. WFS conveys the raw data. We wrote SLD files, which are descriptions of how to look at the raw data and determine what a default symbolization should be. These files are used often when deploying a WMS (which is a symbolized picture of the data rather than just a data dump).

Q: How are we handling multiple authors or resources in a single field on the spreadsheet?

A: They're just pipe-delimited and the python script picks them apart.

Q: Does the validation on the metadata only review that the field is complete or are their syntax checks in place as well?

A: There is some level of "syntax" checking going on, but it isn't particularly robust.  It’s more like logic tests: if you told me the author's email address then you don't have to tell me her phone number—or, your abstract ought to have more than 50 characters in it.