Our topography data should probably be referenced to the geoid #29
Comments
leouieda
added a commit
that referenced
this issue
Dec 13, 2018
ETOPO1 is referenced to sea level. I had used a geoid model to convert it to geometric heights but this is not a great idea. Revert back to the original. The data were stored as ints to save space but this can cause problems with divisions and other operations. Cast them back to float after loading with our functions. Fixes #29 Fixes #30
leouieda
added a commit
that referenced
this issue
Dec 14, 2018
ETOPO1 is referenced to sea level. I had used a geoid model to convert it to geometric heights but this is not a great idea. Revert back to the original. The data were stored as ints to save space but this can cause problems with divisions and other operations. Cast them back to float after loading with our functions. Fixes #29 Fixes #30
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the problem
Currently, our sample topography data based on ETOPO1 was converted to be referenced to the WGS84 ellipsoid by adding a geoid model based on EIGEN-6c4. For some applications, like Bouguer corrections on land, this is best. But Bouguer corrections in the oceans require knowing the geoid to account for the water mass between the ellipsoid and the geoid. This also plays a role in Airy isostatic calculations (so it might be best to use geoid reference topography for this).
Since ETOPO1 is originally referenced to "mean sea level", we should probably keep it as is and include a geoid grid as well. Docstrings for the
fetch_*functions should be explicit as to which reference is used. Examples of calculating Bouguer anomalies or Airy isostatic roots should also be explicit in which heights they are using and why.The text was updated successfully, but these errors were encountered: