Add File Info Extension v1.0.0 -> v2.0.0 migration

[duckontheweb]

Support for v2.0.0 of the File Info Extension was added in #442, but the migrate hook was not updated to include a migration from v1.0.0 to the new version. That hook should be updated to include the migration.

Based on my understanding of the changes between versions, the following fields should be migrated to Raster Bands Object fields (dropping the file: prefix as well):

• file:bits_per_sample
• file:data_type
• file:nodata
• file:unit

@emmanuelmathot @matthewhanson @m-mohr Feel free to correct this if I got anything wrong.

[emmanuelmathot]

I am not sure we can easily transfer those information that were describing the file to one or more raster bands. There are several cases that should be supported and thus several implementation rules must be defined. A basic rule could be to apply the file fields to all raster bands corresponding fields. If the assets of the original item does not describe any raster band, is a default raster band created?

[duckontheweb]

A basic rule could be to apply the file fields to all raster bands corresponding fields.

I was thinking that if raster:bands is defined we would check if the field is already defined in any of the Raster Band Objects. If it is, we would take no action since we would not want to overwrite a value defined by the Raster Extension. If it is not defined, then we would populate that field with the file:* value.

If the assets of the original item does not describe any raster band, is a default raster band created?

Yeah, this is a tricky. I was thinking that we should create a default Raster Band Object so that we don't lose the information. However, that could be misleading if an asset has more than 1 band but we create only a single Raster Band Object. It also doesn't seem possible to discover the number of Raster Band Objects that should be created without opening the file, which is not something we want to do here. What is your opinion on this @emmanuelmathot?

[emmanuelmathot]

That is really tricky. We should avoid add raster bands to non raster assets. I would create a default raster band so that we do not loose the information . But I would add some kind of filters to be sure that the asset is a potential raster (e.g. mime-type, file extension)

[duckontheweb]

We should avoid add raster bands to non raster assets. I would create a default raster band so that we do not loose the information . But I would add some kind of filters to be sure that the asset is a potential raster (e.g. mime-type, file extension)

Are there legitimate cases in File Info Extension v1.0.0 where someone would have used these fields for something besides a raster? It seems like these fields were always implicitly intended for raster files and that we just made that more explicit by splitting the extensions (I may not be aware of the full evolution of these, though, so this could be off-base). If this is true, we may just want to give the publisher the benefit of the doubt and always create the Raster Band rather than trying to filter on all of the possible MIME types and extensions. However, if there are other legitimate uses this may be our only viable option.

cc @m-mohr

[m-mohr]

I guess I could construct use cases, but I doubt someone has actually implemented file for anything other than raster.

I'm not sure though how to convert to raster:bands. Is it always the case that a global e.g. file:nodata, can be converted to a "single band" raster:bands containing file:nodata? We are assuming it is one band, but that may not be true.

[duckontheweb]

Given some of the uncertainties around handling the case where no Raster Band exist it might be best not to attempt any migration in that case.

In that case, the logic would be to migrate file:bits_per_sample, file:data_type, file:nodata, file:unit as follows:

1. If no Raster Bands already exist on the object, do nothing
2. If Raster Bands do exist, then for each of these properties:
   i) If any of the Raster Band objects contain the field already, do nothing
   ii) If none of the Raster Band object contain the field, add it to each existing Raster Band

@m-mohr @emmanuelmathot How do you feel about this approach?

[m-mohr]

Maybe additionally: If no Raster Bands already exist, create as many as eo:bands exist and add the field to each of them.

But maybe I may not even try to migrate it in JS and just handle leave implementation on v1.0.0.