Missing zlib (deflate) compression level from dmrpp files
Opened this issue · 6 comments
I am working on parsing dmrpp metadata files to match the format of zarr metadata files (parser PR here). The only piece of missing information I have encountered in dmrpp files is the zlib (deflate) compression level. It seems like the opendap dmrpp generator has this logic to retrieve and store this attribute as deflateLevel
(see example below) but it is not implemented across many files. Many NASA datasets including SWOT L2 SSH
, MUR L4 SST
, and Ice-SAT
are missing this field.
You might check the version of the build_dmrpp
application that was used to build the dmr++ files that lack the information you are seeking. This should be available in the metadata of the dmr++:
<Attribute name="build_dmrpp_metadata" type="Container">
<Attribute name="build_dmrpp" type="String">
<Value>3.20.13-310</Value>
</Attribute>
<Attribute name="bes" type="String">
<Value>3.20.13-310</Value>
</Attribute>
<Attribute name="libdap" type="String">
<Value>libdap-3.20.11-93</Value>
</Attribute>
It may be the case that these dmr++ files were created prior to the deflateLevel
being included in the output. If so, we would like to know which NASA collections you encounter that lack this, as we may be able to get them to rebuild those files with the most recent build_dmrpp
application.
After reviewing the examples I think we'll need to appeal to @kyang2014 for his insights on this.
I can point to some examples of NASA datasets/dmrpp that have this issue but I'm not sure how to find all of them. The file I linked earlier with deflateLevel
was build_dmrpp
version 3.20.13
. Some of the files below are above that version number and still missing deflateLevel
. Could it be a DAAC/collection level issue?
metadata:
<Attribute name="build_dmrpp" type="String">
<Value>3.20.13-664</Value>
</Attribute>
<Attribute name="bes" type="String">
<Value>3.20.13-664</Value>
</Attribute>
<Attribute name="libdap" type="String">
<Value>libdap-3.20.11-198</Value>
</Attribute>
metadata:
<Attribute name="build_dmrpp" type="String">
<Value>3.21.0-272</Value>
</Attribute>
<Attribute name="bes" type="String">
<Value>3.21.0-272</Value>
</Attribute>
<Attribute name="libdap" type="String">
<Value>libdap-3.21.0-70</Value>
</Attribute>
This file below does have deflateLevel
metadata:
<Attribute name="build_dmrpp" type="String">
<Value>3.21.0-46</Value>
</Attribute>
<Attribute name="bes" type="String">
<Value>3.21.0-46</Value>
</Attribute>
<Attribute name="libdap" type="String">
<Value>libdap-3.21.0-27</Value>
</Attribute>
I double checked the date I added the deflateLevel to the dmrpp file. It is Sep. 5th, 2023 with #809
And the tag for this pull request is https://github.com/OPENDAP/bes/releases/tag/3.20.13-845. which is bes-3.20.13-845.
So BES 3.20.13-664, the one listed as without having the deflateLevel, was generated before the time I added this feature. The other two examples that have deflateLevels were generated after the time I added this feature.