You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 18, 2019. It is now read-only.
The relationship between data sets and services is unclear. It is clearly many to many, which is fine, but the way it is implemented from different configurations of THREDDS, ERDDAP, 52North etc is unclear and uneven. Let's clarify this once and for all and determine necessary changes for the next round of data base modifications.
For example, one model hosted on a THREDDS server that has OPeNDAP, ncISO, and ncWMS enabled. The following image should result in a catalog count of DataSet +=1 and DataService +=3. Shouldn't it? I think the current behavior is DataSet+=1 and DataService+=2 because we don't count ncISO as a service. Is this desirable?
Example 2: i52N SOS with several ObservationOfferings
Another case is for an i52N SOS service that has say 4 Observation Offerings. Should be DataSet +=4, DataService+=1. I think this desired behavior is what is currently implemented.
Example 3: in situ data sets hosted on TDS with ncSOS enabled.
In this case we've paid special attention to ncSOS so I think it gets special treatment. Desired behavior is DataSet +=1 and DataService +=3. Current behavior (I think) is DataSet +=2 and DataService +=2. I think the reasoning is that a) ncISO is not counted so the services are only 2 and b) the OPeNDAP URL and the ncSOS URL are both counted as Data Sets (hence 2).
I want to point out something about the counts, and their wide differences:
The front page dataset and services looks at unique datasets that are active
The "inventory" page looks at datasets that are active and have an active service directly associated with it
The reports count everything, including duplicates
A unique dataset is defined as having a unique "uid" which in the case of DAP services are the URL to which the data resolves. For SOS, the uid is the IOOS URN.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The relationship between data sets and services is unclear. It is clearly many to many, which is fine, but the way it is implemented from different configurations of THREDDS, ERDDAP, 52North etc is unclear and uneven. Let's clarify this once and for all and determine necessary changes for the next round of data base modifications.
 [Editable URL for the image](http://yuml.me/diagram/scruffy/class/edit/%2F%2F Cool Class Diagram, [DataSet]0..--0..[DataService])
Example 1: A gridded data set hosted on TDS
For example, one model hosted on a THREDDS server that has OPeNDAP, ncISO, and ncWMS enabled. The following image should result in a catalog count of DataSet +=1 and DataService +=3. Shouldn't it? I think the current behavior is DataSet+=1 and DataService+=2 because we don't count ncISO as a service. Is this desirable?
 [Editable URL](http://yuml.me/diagram/scruffy/class/edit/%2F%2F Cool Class Diagram, , [<> MyModelRun]--[<> OPeNDAP], [<> MyModelRun]--[<> ncWMS], [<> MyModelRun]--[<> ncISO])
Example 2: i52N SOS with several ObservationOfferings
Another case is for an i52N SOS service that has say 4 Observation Offerings. Should be DataSet +=4, DataService+=1. I think this desired behavior is what is currently implemented.
Example 3: in situ data sets hosted on TDS with ncSOS enabled.
In this case we've paid special attention to ncSOS so I think it gets special treatment. Desired behavior is DataSet +=1 and DataService +=3. Current behavior (I think) is DataSet +=2 and DataService +=2. I think the reasoning is that a) ncISO is not counted so the services are only 2 and b) the OPeNDAP URL and the ncSOS URL are both counted as Data Sets (hence 2).

[Editable URL](http://yuml.me/diagram/scruffy/class/edit/%2F%2F Cool Class Diagram, , [<> Station 1]--[<> OPeNDAP], [<> Station 1]--[<> ncSOS], [<> Station 1]--[<> ncISO])
Discussion? This confusion and the special treatment of ncSOS is the heart of the issue here.
The text was updated successfully, but these errors were encountered: