Events can be associated either with a timestamp *or* with a
sequence + shotpoint (but not both, for data integrity reasons).
Events and shotpoints can also have “labels” associated with them.
The difference between a comment and a label is that the former
is free text while the latter is predefined and has associated
properties (currently only for display, but could also have QC
related properties such as ensuring that there is only one “FSP”
label per sequence and so on).
The `events` view puts everything together into a coherent view.
Note that this view may produce multiple rows for the same
timestamp or shotpoint, for instance when the event has both
a text comment and one or more labels.
The raw_lines_summary and raw_lines_summary_geometry
views are analogous to final_lines_summary and
final_lines_summary_geometry respectively.
One difference of note is that the final_ version
may report negative missing shots, while the raw_
versions assume that the user is not interested in
anything outside the preplot.
This is a super-simple library that does the minimum required
to get things going for the specific operations where this
code is foreseen to be used in the immediate future. It is not
and it does not aim to be a complete, generic or universal P1/11
parsing solution.
- The raw_shots and final_shots tables contain *shots*,
as the name says, and nothing else.
- The objref is made an integer. This is consistent with
P1/11 usage and for anything else a relation can be used.
- Raw and final shot tables also include the corresponding
preplot line as well as the shot number. The preplot line
is explicit in the P1/11s that we have seen and can otherwise
be derived from the source geometry in the P1/11 or P1/90
headers (provided those headers are correct). It is the
import process' business to figure out what the preplot
lines are if those are not explicitly given in the data.
- As a result of the above, some of the views have been
re-written, hopefully in a simpler way.
- The shot_count view has been removed as it was neither used
nor useful.
If the configuration file is not found, either at its
default place ($HOME/etc/www/config.json) or wherever
indicated by the DOUGAL_API_CONFIG environment variable,
create a temporary default config and try to run with it.
On the other hand, if we are in production (NODE_ENV == production)
we exit with non-zero in the absence of a real configuration file.
