Closed dpsnowden closed 3 years ago
Are we publishing just the points? If so, then something like GeoJSON might be simpler to create and simpler for clients to integrate.
Otherwise if it's feature information WFS maybe?
I think it's more than just the points, but that's what I'd like to discuss and refine. We've had long history with trying to automate an asset inventory. I don't want to make a hasty decision without having folks look into it. This is probably something we'll have to do in several iterations. First and simplest iteration is probably
Lat; Lon; Name; ID; Data Provider; Region; Platform Type
We could get into many other types of metadata based on availability from the source.
See the Asset List Tab on NVS for a good example .
WFS might be fine, though I'd put it at the bottom of the list.. I'd say CSV, geoJSON are probably mandatory which is why I think ERDDAP could be a good solution for the service.
This task will be handled as a process outside of Catalog:
[ ] We will use an existing tool (EDS or Sensor Map) or some other means (NOAA GeoPlatform) to publish asset inventory quasi-static file that ideally is available via WMS and/or GeoJSON (for feature-based access
[ ] These service(s) will be described in a metadata file and published via the IOOS Catalog harvesting pathway (WAF -> Harvest Registry -> IOOS Catalog)
[ ] Asset inventory and file will be updated yearly-ish
cc @kbailey-noaa
Update: this will be handled by an IOOS-operated ERDDAP service (erddap.ioos.us ?) that will in turn have its metadata harvested by the IOOS Catalog.
Since we don't really need to do any Catalog work in order for this to happen - other than to register the IOOS ERDDAP in the Harvest Registry which is a standard process - closing this old issue out.
cc @MathewBiddle
xref to the 2020 asset inventory as a geojson file: https://github.com/ioos/ioos-asset-inventory/blob/main/2020/processed_inventory.geojson
We are routinely asked for a URL that provides the locations of IOOS platforms. The definition of IOOS platforms is fluid, to say the least, but we do need some sort of inventory.
This issue is just to open the conversation on the actual requirements and to get it published somewhere so that we can put it in a release plan eventually. The catalog repo may not even be the right place. My initial thoughts on how we might do this.