Remove deprecations, remove crs, rename ARCOERA5

[zebengberg]

Closes #180
Closes #151
Closes #238

Breaking changes

• Remove attrs["crs"] usage from GeoVectorDataset and child classes (Flight, Fleet). All spatial data is assumed to be EPSG:4326 (WGS84). This was previously assumed implicitly, but now the crs attribute is removed from the attrs dictionary.
• Remove deprecated MetDataset.variables property in favor of MetDataset.indexes.
• Remove **kwargs in MetDataArray constructor.
• Rename ARCOERA5 to ERA5ARCO for consistency with the ERA5 and ERA5ModelLevel interfaces.

Features

• Implement PSFlight.eval on a Fleet source.

Tests

• QC test passes locally (make test)
• CI tests pass

Reviewer

Select @ reviewer

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[mlshapiro]

This looks good @zebengberg! Thanks for taking the time to do the cleanup.

[mlshapiro]

This is a more generic Fleet question:

I had a question here recently about how Fleet objects handle attrs. Would we be able to have a test here the shows how the attrs show up in "out"?

I would expect to find aircraft_type somewhere in the output.

assert "flight_id" in out.data and "aircraft_type" in out.data

or is there another place these attrs get stored?

[zebengberg]

There's not a great way to handle attrs on Fleet instances. The current paradigm is to include global properties in Fleet.attrs and individual flight properties in Fleet.fl_attrs. I expanded the test a bit to check these out: 5602a03

We haven't made consistent use of Fleet.attrs throughout pycontrails. I think the best practice would be to check for a scalar quantity in Fleet.attrs first, then to look within Fleet.fl_attrs next ... you can see how this gets complicated tricky.

[mlshapiro]

oh great! this answers my question.

Is there any reason not to use Fleet.attrs instead of Fleet.fl_attrs? Was it a compatibility or serialization question?

[mlshapiro]

(Looks like Flight.attrs have type dict[str, Any] so could handle a dict[str, dict[str, Any]])

[zebengberg]

We definitely could have used Fleet.attrs instead. We always end up creating a dictionary of the form flight_id: fl.attrs for each fl in fleet, and we make use of it in various Fleet methods, so I attached it as an explicit property on the instance rather than assuming fleet.attrs included separate keys for each flight_id.

[zebengberg]

Okay -- so you're suggesting we overload Fleet.attrs to hold {flight_id: flight_properties}. I think could be a reasonable way to proceed. I think I avoided this in the past because attrs["crs"] was getting in my way.

I think I'll hold off for now, but may do this whenever I iterate again on Fleet.