It isn’t a stream so it shouldn’t be called one. I knew this even when I first wrote it, but I didn’t know what else to call it and figured I’d change it later.
Maybe call it Seismogram, or for less typing Trace. Then it’d be SAC::Trace
which is nice.
Tried the n-vector stuff, didn’t work. Moving on for now.
Assumes spherical earth
Use Haversine formula to start. Later can move on to Lambert’s formula for long lines (Wikipedia)
Assumes spherical earth
This would aid the user in avoiding writing out sac-files that could then not be read in. The issue is, let’s say the user wants to include data2, I cannot simply assume level(false) or iftype(value>1). There needs to be a mechanism that enforces a specification change in the data2 setter.
That also means that the leven and iftype() setters need a mechanism whereby leven must be true for iftype(>1), and if leven is false then iftype(<=1). If leven(false) and iftype(<1), but data2 exists, clear it.
Same rules apply as for the strings themselves.
The only reason I need boost is for boost::algorithm::trim(); to remove leading and trailing white spaces. I feel like that is not a great reason to require boost (which is a HUGE library)
Lookup table to keep track of where data is stored.
The only time this matters is at read/write. On read, we can read it in as a
float and immediately static_cast<double>. On writing, we just
static_cast<float> prior to writing. This will get rid of the need to deal with
simultaneously updating the double and float versions (hard to remember which is
which).
Will fail if don’t comply.
I think ReviewDog has a yml that could work as an example for this action
Short and succinct
Use ReadTheOrg Inline (GitHub)
This involves setting up the export settings for the website for LaTeX.
- convert between v6 and v7
- convert between binary and ascii