compass import into cavern

[Olly Betts]

On Thu, Oct 07, 2004 at 10:07:16AM -0400, Simeon Warner wrote:
> I'm working with the Lechuguilla Compass dataset and have a problem
> importing this into survex because of 999.00 (and sometimes -999.00)
> values used to indicate no-value (e.g. a backsite only reading has 999.00
> for foresight comp and clino). I assume this is a standard feature of
> Compass and should thus be incorporated in the data import.

Sounds like it must be.  It might be worth checking with Larry Fish as
to exactly what values Compass treats as "no value" for a compass or
clino reading.  He was very helpful about clarifying little details when
I wrote the code originally.

> I tweaked datain.c to check for this but note that data_normal() doesn't
> know what the input data format is so I'm recklessly checking for a
> 'special' (-)999.0 value for both compass and survex input data. To do
> this well I think one needs to make data_normal() aware of the format so
> one can write tests like:
> 
>    if (fmt == FMT_DAT && is_compass_NaN(VAL(Comp)) {
>      VAL(Comp)=HUGE_REAL;
>    }
> 
> in each affected case. I'd like to be able to contribute these fixes so I
> ask for guidance on whether it is reasonable to pass the format in to
> data_normal (and promote the enum for FMT_* to the file level) or whether
> I should look at some other approach.

That seems a reasonable approach, though it would get messy if there
were more bits of special handling for other file formats.

I'd be tempted to add special variants of Compass and Clino field types
(like there's already a CompassDATFlags field type which is only used
when reading Compass .DAT files).  Then we'd have extra cases like:

       case CompassDATComp:
       	  read_bearing_or_omit(Comp);
	  if (is_compass_NaN(VAL(Comp))) VAL(Comp) = HUGE_REAL;
	  break;

That would also facilitate using something simpler than
read_bearing_or_omit(), which does do rather more than we actually want
to for Compass .DAT files.

Cheers,
    Olly