Refactor code

[max-anu]

Since I've gone through almost every function/etc, I figured it might be an idea to write up how I think the accessvis package should be structured.

Split earth.py into three files:

• region.py - This contains all functions which plot/apply to the 3D earth
• earth.py - This contains all functions which plot on a 2D region.
• common.py - This contains functions common to both region and earth.

Functions/etc in region.py should include the word "region" in the name.
Functions/etc in earth.py should include the word "earth" in the name.
common.py shouldn't use either.

When making the lv.Viewer object, we could add a constant:

• lv.accessvis_type = "EARTH"
• lv.accessvis_type = "REGION"
  We could then have a function "2d_plot" which either calls "earth_2d_plot" or "region_2d_plot". (This interface could be implemented for all the plotting functions, raising NotImplementedError if required)
  We could also include other information used when making the viewer (e.g. the lat/lon bounds used in plot_region() could then be passed as default args for region_2d_plot).

================

I think lat/lon has all been fixed now. Here's what I had previously written (in case it is useful for anyone else).
Here's how we currently use lat/lon/alt:
f(start=(lon,lat), end=(lon,lat), alt=0.1)
f(start=(lon, lat, alt?), end = (lon, lat, alt?))
f(lat, lon) -- latlon_to_uv, latlon_to_pixel
f(lon, lat, alt)
f(cropbox=((lat, lon), (lat,lon))) -- crop_img_lat_lon
f(vertices) (vertices[::0]=lon,vertices[::1]=lat,vertices[::2]=alt) -- earth_vertices_to_3D

If you only need to provide coordinates once (or an array), then I think we should have explicit args lat, lon, alt.
If you need to provide multiple coordinates (e.g. cropbox), I think we should use tuples.
I think cropbox should be provided as two arguments (topLeft, bottomRight).
I think vertices in earth_vertices_to_3D should not be passed as one array - it should have separate arguments for each lat/lon/alt.

(I've gone off this idea since I wrote this - I don't think we should do this).
We could use a NamedTuple. We could then also have a function called LatLonAlt which creates the tuple in the correct order?
from typing import NamedTuple
class LonLatAlt(NamedTuple):
lon: float
lat: float
alt: float = 1e-6

[max-anu]

I think all of the plotting functions (e.g. earth_2d_plot) use lonlat_to_3D with flattening=0. You could add a variable to the viewer such as lv.access_flattening = ... And then we could test for this. (It probably isn't needed - I haven't come across any examples where flattening has made any difference, but it's a thought)