Overlapping service categories / inconsistent heirarchy

[Joshdpaul]

The current data API service categories have multiple overlapping items, which could be somewhat confusing to the user.

For example:

• "Snowfall Equivalent" and the precip part of "Temperature and Precipitation" are variables that one might expect to find under the "Hydrology" category.
• "Wet Days per Year" and "Degree Days" are really indicators that one might expect to find under the "Climate Indicators" category.
• "Flammability and Vegetation Type" might be considered wildfire data, but is separated from the "Wildfire" category

I know it's organized this way because the service categories actually aren't hierarchical data categories per se, they are just short names for different dataset coverages that have different temporal units (ie, different summarized eras), different grid sizes, etc.

Is there a way to organize the data categories more hierarchically? In a way that is less dependent on coverages? This does not necessarily mean changing the endpoints themselves, but they could be nested / bulleted into more general hierarchical units. And the geospatial units of analysis (point, polygon) could be clearly separated from the variables. Something like:

Service categories

• Spatial Units

  • Places / Community Points
  • Administrative Boundary Polygons
  • Watershed Polygons

• Datasets

  • Physiography

    • Hydrology
      • Temperature and Precipitation
      • Snowfall Equivalent
    • Geology
    • Ecology
      • Climate Protection from Spruce Beetles
    • Permafrost
    • Wildfire
      • Flammability and Vegetation Type (ALFRESCO)
    • Sea Ice
      • Landfast Sea Ice
      • Sea Ice Concentration
    • Elevation

  • Climate Indicators

    • Wet Days Per Year
    • Degree Days

[charparr]

I'm going to add that we have now have CMIP6 as a top level route, but that the CMIP6 indicators are nested in the "Indicators" top level route.