-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
review of OpenDAP interface/capabilities #4
Comments
We are open to alternate names if we can can come up with something that improves. There is always the question of whether P(rotocol) needs to be in the name - it is is SIAP-1.x and TAP-1.x and not in SIA-2.0 I had kind of favoured Simple Data Access (SDA-2.1 as the successor to SIA-2.0), where Simple nominally means "query parameters" rather than "query language" and there is a fixed data model (ObsCore). Probably since the model used to be referred to in the protocol spec, this could refer to ObsCore... Simple ObsCore Access (SOA)? Simple ObsCore Query (SOQ) since access is really covered by DataLink and SODA? soooo many possibilities... :-) |
If you like going for abused and conflicting ones there's Parametric Observational Dataset Search that embeds parameters query, meant for observations, related to datasets in general and has the search like in Cone |
My initial comment included the issue on the name, but I’m serious about the study of that other DAP interface. For once, it may be an occasion to build up interoperability with a wider community. |
From a quick skim through the OPenDAP documents, it seems to me that it spans more than the purpose of the IVOA DAP, going from discovery of services to filtering on them, including specific access based on the abstract representation on datasets (including basic datatypes mappings and others), so it goes from something like Registry up to DataLink/SODA, via models and annotations and ReST resource specific syntax (reminds me of HAPI for time series in a sense). What might be looked after is the way request/response are built, since I feel we always struggle a bit about how to build and alert about query parameters. I only wonder how to cope with SIA/SODA idea of having the same parameter calls if we change that way (need not loose the existing solutions). |
Anyone in the authors have looked into OPeNDAP? (documentation is here)
Of course this is not IVOA, not FITS. It is Earth observation and NetCDF (mostly). But it contains a lot of capabilities and features that I would be very happy to see implemented.
Beware that this ecosystem also has an interface called DAP (Data Access Protocol).
The text was updated successfully, but these errors were encountered: