Which coverage is required to make a composite res public? Resource-level coverage VS File-level coverage

[zhiyuli]

I created a composite res with one netcdf file type and one ref content type. I manually set resource-level coverage and file-level coverage for that ref content type. Netcdf file-type harvested metadata automatically including Extent in a local coordinate system (not WGS84), but its file-level Coverage is empty.
Landing page shows this warning and I can't make this resource public
"The following aggregation level metadata are still required to make this resource public or discoverable:
Aggregation name: sample
Spatial Coverage"

I would suggest dropping the requirement on file-level coverage if resource-level coverage already exists
(Or a more complex solution: hydroshare is smart enough to automatically reproject a local Extent with projection string into WSG84 and fill in file-level Coverage for me.)

[zhiyuli]

This issue caused another issue in hs_restclient hydroshare/hs_restclient#95 but the root is here.

[horsburgh]

The order in which you did things matters. If you didn't have any other content in your resource and you added a netcdf file, it should have auto-extracted the coverage metadata and set it at the file level and the resource level. If you had already set the coverage at the resource level before you added the netcdf file, the file-level metadata won't overwrite what you've done at the resource level.

But, I'm confused about this part:

Netcdf file-type harvested metadata automatically including Extent in a local coordinate system (not WGS84), but its file-level Coverage is empty.

If the netcdf file-level metadata was extracted automatically, it should have set the file-level coverage automatically, and if it didn't, I think this is a bug. @dtarb and @gantian127 may have to verify what is supposed to happen with coverage of a netcdf file.

[zhiyuli]

@horsburgh
Yes, I created resource-level coverage first and then uploaded netcdf file
Not sure if netcdf file type can (or is it possible to ) reproject any local and strange projection into WGS84 and fill in file-level coverage for user.

[dtarb]

The sample data used to reproduce this problem is sample.zip.

Spatial Reference - the content illustrated top right above is the local coordinate system of the netCDF file. Spatial Coverage is the translation of this to WGS84 coordinates. This translation is failing for this file. This functionality works for other files, so is a problem that appears isolated to the coordinate system of this file (not that this is unimportant because this is a file produced from the national water model it seems). This problem does not seem to be a regression associated with composite resources, because when this file is added to the older netcdfresource type the WGS 84 spatial coverage is also not extracted. @zhiyuli I suggest you look into the code that extracts spatial coverage for netCDF resources/aggregation types and see if you can figure out why this particular file does not work.

As a work around you can set the spatial coverage for the multidimensional content aggregation manually. Note that this has to be done at the content aggregation level. Setting it at the resource level only does not satisfy the requirement that multidimensional content aggregations need spatial coverage.

Note that HydroShare is enforcing the requirement (decided as policy at the time of design) that for composite resources to be made public, their content aggregations have to have required metadata, and spatial coverage is currently required as metadata for multidimensional content. This policy could be changed, but how strong is the case that it is appropriate to share publicly multidimensional content that does not have spatial coverage.

[gantian127]

For this resource, the system is extracting the "esri_pe_string" to convert the "Lambert_Conformal_Conic" to WGS84. But GDAL has an issue with converting the ESRI wkt string of "Lambert_Conformal_Conic" to other projection, which shows error “ERROR 6: No translation for Lambert_Conformal_Conic to PROJ.4 format is known.”

A quick fix would be extracting the "proj4" string from the netCDF file to do the conversion instead of esri wkt (see info above). Initial test on local PC showed that the projection conversion works with this file. Just update the "nc_utils.py" file in line 437 and line 443 as the following, which extracts the "proj4" as the projection info for conversion.

[devincowan]

@pkdash looks like you maybe resolved this issue?