[RFC-004]Comment-1

Organization: Jet Propulsion Laboratory (JPL)

• I co-maintain the OPeNDAP server at JPL. I designed the POET data server at PO.DAAC.
• The specification provides most of the information needed to create a server, but is not specific in implementation details (e.g., how to create an aggregation server). The spec is less complete in its description of creating a client.
• The specification is accurate and internally consistent.
• The specification is generally clear. There is mention in 2.1 of OpenGIS as if it were a format. OGC is an organization and there really are no OGC formats, but the reference could be to GML.
• OPeNDAP includes a wide range of data types and data models. There is no swath data type, but such a structure can be created from the existing data types. The spec achieves simplicity by focusing on data syntax rather than semantics. This compromise decision can be a deficiency. For Earth science applications, standard naming of common attributes is desirable (spatial/temporal mapping, variable names, units, scale factors/offsets, etc.), and it would be desirable for OPeNDAP clients to make use of some of this information (e.g., apply scale factors).
• OPeNDAP is very useful for integrating with existing software, although an IDL client is currently lacking. OPeNDAP users generally must extract data by row/column rather than lat/lon. This is a major deficiency that can be resolved through the use of client tools such as Live Access Server or GRADS. Without such an add-on tool, the OPeNDAP protocol is very limiting for our users. The Web Mapping Server and Web Coverage Server (WMS/WCS) protocols enable users to directly specify lat/lon range rather than row/col. These protocols put the job of converting row/col to lat/lon on the server end (where it belongs) rather than on the client end (as is required by OPeNDAP). Accommodating semantics would make the protocol more useful in the Earth sciences.
• It is implementable on a wide range of platforms, both on the server and client ends. It uses minimal computing resources. There is a current limit of 2 billion array elements that will prove to be a limitation in accessing very large data products. The use of XDR for data transfer may result in relatively slow access speeds for the largest datasets.