Handle CSV datasets & better handle updates to existing MCF

[davemfish]

This PR adds support for .csv files, by treating them like other vector datasets that GDAL supports.

A couple other things here:

• Debugged some issues with overwriting existing MCF data when a MetadataControl is initialized. The goal is to preserve any metadata that might already exist, except for properties that are intrinsic to the dataset (i.e. CRS, bounding box, field names & datatypes).
• changed some function keyword arg names to match the names of the MCF properties they represent. This makes it easy to use a pattern like mc_a.set_license(**mc_b.get_license())

[davemfish]

Making sure to call this whether or not an MCF already exists, in case properties of the dataset have changed.

[davemfish]

I don't like using type as the argname, since it's a builtin function name, but that is the name of the MCF property, and making the setter's argnames match makes it convenient to do things like

mc_a.set_band_description(1, **mc_b.get_band_description(1)).

[empavia]

On this note, is it possible to automatically populate the band's min/max in the dimensions section? Dimensions correspond to this feature and seem to be required in the MCF, but not for ISO. I know there is a way to get this information in GDAL.

[phargogh]

@empavia do you mean the min/max pixel values, or the number of rows and columns?

[empavia]

@phargogh the min/max pixels

[empavia]

@phargogh actually I believe I am referring to the min/max of the band measurement. For example, the min/max elevation in meters for a DEM. An example is found in this document on Oak: "Z:\global-dataset-cache\awc-isric-soilgrids\awc.tif.ovr.aux.xml"

[davemfish]

Thanks for bringing this up @empavia , I created a separate issue to address it. Please see #15

[phargogh]

🎸

[phargogh]

Nice! I appreciate that we can just throw a CSV at GDAL and then use the same API.

Have you tested what happens if we pass GDAL a malformed CSV, like one with too many records on a line or something like that?

[davemfish]

Nice! I appreciate that we can just throw a CSV at GDAL and then use the same API.

Have you tested what happens if we pass GDAL a malformed CSV, like one with too many records on a line or something like that?

Good question! It seems like GDAL uses the header row as the source of truth for number of fields, and then it ignores extra records in other lines. That seems totally fine. I don't feel like we need a test to ensure this.