Confluence Retirement

In an effort to consolidate USGS hosted Wikis, the myUSGS Confluence service is targeted for retirement on January 28, 2022. The official USGS Wiki and collaboration space is now SharePoint. Please migrate existing spaces and content to the SharePoint platform and remove it from Confluence at your earliest convenience. If you need any additional information or have any concerns about this change, please contact Thank you for your prompt attention to this matter.
Skip to end of metadata
Go to start of metadata

Do you work with spatial features in your scientific workflows?

Do you want to improve the way you discover and access the appropriate and best sources for your data?

Check out the Earth Science Information Partners - hosted IdeaScale challenge:

Building a SpatioTemporal Feature Registry

Taking experiences from the National Biogeographic Map, Sky Bristol has outlined a number of questions around designing and building a system for usable and repeatable processes that use spatial features.

Your ideas and thoughts on how you could use such a system in your work are wanted!

Read more at IdeaScale, or ask more questions here!


  1. Here's a video with more detail that I will be watching tomorrow during the Tech Stack working group time slot! 

  2. A notebook that Sky put together using the Places API and Data Repository (the Registry)

    I will be reporting back if I can execute that code!

  3. Here's Annie Burgess' distillation of the key concepts, which she outlined in the latest ESIP Lab Update:

    Key Design Principals

    1. A feature within the SpatioTemporal Feature Registry (SFR) is a real-world place with spatial and temporal properties.
    2. Don’t think of this as a database of features. Think of it as a set of community-contributed open codes that do work to integrate and synthesize features for many uses.
    3. A feature’s data source must be referenceable and accessible with software code.
    4. Semantic methods will identify and expose associations between features beyond spatiotemporal proximity-type relationships. A challenge will be how to balance a distributed and possibly transient data system with the need to build, store, and serve relationships discovered dynamically between heterogeneous endmembers.
    5. It would be useful to build at least one ‘master index’ to make everything discovered searchable through an API that people can build on.
    1. Watched the video. I understand the Ideation challenge better now, but also think there are a number of topics that I need better knowledge about before I could make any comments about whether there are improvements to the concepts and systems presented in the video.

    2. Some notes

      1. Analysis package: a way to package a scientific workflow, documentation, source information

      2. Motivating example: Using the example of the features Large Marine Ecosystems, how can one document where are these features are coming from, and how should we maintain them over time and distribute them?  

    3. List of things to learn more about:

      1. JSON Schema:

      2. GeoJSON:

      3. ESIP Community Ontology Repository:, and example for this work:

      4. pyBIS: : modules that perform data management functions for the Biogeographic Information System.

      5. Try out the API: . If you click around there are buttons to "try it out" with different queries.

    4. Probably my main question: Since I am not in the field of Biogeographic Information, what is the scope here? It seems like there could be an infinite number of applications of this concept to any type of earth science data. If I don’t have the technical background to implement any of this for the field/type of data that I work with, it still seems abstract to me.

    5. Ideas for who could use it

      1. Projects who have a lot of site boundaries and need to do analysis on data taking into account things like elevation, slope, aspect, average precip, average temp. (thinking of the Critical Zone Observatories, for example).

      2. Portals that allow search by geographic feature name. Especially where there might be some difference of opinion on the exact boundary and “where to draw the line” for things like rift zones, volcanoes... or features that may change in time like seafloor vent locations, ocean drilling sites.

      3. A research group that is more technologically-inclined may want to have a system to keep track of each member’s field sites and analysis packages, or others in the group to use and compare. Is this too specific a case and something that you would not want to “clutter” the registry?

      4. Is there any tie in to or the tools they are providing to find monitoring sites and document protocols?

      5. Maybe there is some application to sediment deposits that change quickly through time - active alluvial fans or deltas, like the Mississippi Delta, etc., that change through time and are modeled a lot. It is possible that modelers would want to grab the boundary for different points in time. I am speculating because this is not my research field.

  4. I definitely do not understand all of the video, so a couple of possibly bozoic questions:

    • does the json schema constitute a metadata model and, if so, does/would/should it relate to existing ones (like netcdf-CF, eg) in a systematic/automatable kind of way? Sky mentioned something about this but it kinda blew by me.
    • is ScienceBase responding to queries on a schema file associated with an item?
    • is it the case that the schema would replace the mapping information contained in the config and hard-coded SQL files?
    • I'd like to hear more about the generation of recognized, globally unique identifiers. Sky mentioned details about the namespace; I'm wondering whether or how the process of creating an identifier is governed.

    Very cool stuff!

  5. Looks like the IdeaScale is no longer active...shame