Date: Thu, 28 Mar 2024 11:16:34 +0100 (CET) Message-ID: <1593054521.1008.1711620994124@voparis-wiki.obspm.fr> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1007_1350200134.1711620994122" ------=_Part_1007_1350200134.1711620994122 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
As of Dec 2017, the VESPA portal is supporting the 2 existing PDAP serve= rs, at PSA and DARTS (see comment about NASA below).
However, these servers only accept limited queries, and the PDAP protoco= l seems intrinsically unable to handle detailed queries as EPN-TAP does (no= wonder - this is why we developed EPN-TAP in the first place).
This page gathers pros and cons about continuing support of PDAP in the = VESPA portal.
An initial assessment of PDAP was performed during the FP7 contract in t= he IDIS activity (Feb 2011). This relied in particular on a PDAP client dev= eloped and installed at PADC (ObsParis), and focused on the capacity of PDA= P to retrieve individual data products in data archives (including, but not= limited, to space missions), based on operational and observational parame= ters (what EPN-TAP is now doing).
The assessment document (PDAP_assessmen= t_v5.pdf) was discussed during an IPDA meeting in Oct 2011; some items = were agreed upon and implemented in a later update of the PDAP protocol doc= ument, other were not. In particular, there was no intention to enlarge PDA= P to support data not included in space archives (e.g. telescopic ones, but= also derived data from space missions), and a clear will to stick to PDS3 = references (dictionary, parameters, etc). Besides, no solution was in view = to read PDS3 data on-line.
Altogether, the IDIS team concluded that PDAP would never be flexible en= ough to allow the type of search sought by Europlanet, and decided to devel= op a restriction of IVOA's TAP protocol instead (EPN-TAP), similar to ObsTA= P for Astronomy. This was later refined and improved by VESPA in Europlanet= 2020 (EPN-TAP v2).
=E2=80=A2 The initial PDAP client in PADC is still accessible at the tim= e of writing (12/2017), but no longer supported: http= ://voparis-srv.obspm.fr/portal/ipda.php
=E2=80=A2 The VESPA portal has included from the start a similar functio= n. The EPN-TAP query entered in the query form is translated to a minimal P= DAP request. This was initially passed to the 2 existing servers supporting= the protocol (DARTS at Jaxa and PSA at ESA), the results of which are list= ed at the bottom of the service result page after all EPN-TAP services.
Given the answer to such queries, the VESPA PDAP client capacities were = reduced progressively to avoid constant errors. PDAP queries were limited t= o dataset (not dataproducts); the PSA service was deactivated at some point= , then reactivated in Dec 2018 in the updated VESPA portal, after an update= of the PDAP service at ESA. We now consider removing this function altoget= her because DARTS is returning mostly errors or impractical results.
=E2=80=A2 Later analyses of the situation led to the conclusion that PDA= P is only used as low-level tool for automatic updates/mirroring of dataset= s between archives. Practically, PDAP seems to be only able to search by da= taproduct_name, instrument_name or time range. The current capacities of PD= AP therefore cannot fulfill the functions provided by EPN-TAP, and will not= do so until a big development is made to define missing topical extensions= .
EPN-TAP now covers mirroring functions efficiently, with the addition of= the modification_date parameter in 2014, and the File grabbing interface (fgi) (scripts loca= ting files distributed in an EPN-TAP service) in July 2017.
(as of Jan. 2020)
=E2=80=A2 Given the high score of errors in PDAP queries, the non-workin= g NASA access, and the practical impossibility to locate a file correspondi= ng to given conditions, maintaining the PDAP client in VESPA is now conside= red problematic - it mostly projects a degraded picture of both PDAP and VE= SPA capacity access to space data archives.
In consequence, we propose to drop PDAP support in the VESPA portal unti= l possible improvements are implemented both in the protocol and the server= s.