You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The settings page calls the datastore route GET /datasets/:organizationName/:dataSetName (DataSourceController.suggestDatasourceJson) which traverses the files and makes automatic suggestions for the datasource-properties.json. This works only for WKW and was originally designed also as an import step (when dataset creators didn’t write their own datasource-properties.jsons).
#7475 skips this step for Zarr and presents a warning instead of a ton of errors (that were there before because the data didn’t match the WKW format).
We should decide if we want to implement this also for other dataformats like zarr. It could reuse the explore code that is used for remote datasets. However, the suggestions might be imperfect there, as the original datasource-properties.jsons might contain more relevant information that can be inferred from just the zarr array files.
We might also want to discontinue this feature altogether, as zarr becomes more common and datasets are usually either explored remotely (uses the explore code), created via the libs (should already have good datasource-properties.json) or uploaded using the web upload (has its own version of this feature as of #7397).
The text was updated successfully, but these errors were encountered:
The settings page calls the datastore route
GET /datasets/:organizationName/:dataSetName
(DataSourceController.suggestDatasourceJson
) which traverses the files and makes automatic suggestions for the datasource-properties.json. This works only for WKW and was originally designed also as an import step (when dataset creators didn’t write their own datasource-properties.jsons).#7475 skips this step for Zarr and presents a warning instead of a ton of errors (that were there before because the data didn’t match the WKW format).
We should decide if we want to implement this also for other dataformats like zarr. It could reuse the explore code that is used for remote datasets. However, the suggestions might be imperfect there, as the original datasource-properties.jsons might contain more relevant information that can be inferred from just the zarr array files.
We might also want to discontinue this feature altogether, as zarr becomes more common and datasets are usually either explored remotely (uses the explore code), created via the libs (should already have good datasource-properties.json) or uploaded using the web upload (has its own version of this feature as of #7397).
The text was updated successfully, but these errors were encountered: