[data-issues] Fwd: NL.HGN. .BHZ as ascii data???

[Philip Crotwell]

Hi

Here is another one that might have slipped through the cracks. I am  
still getting "compression type 0" from the pond for NL.HGN. This  
emails below would seem to indicate that this was a data problem and  
were working on getting the data resubmitted. It is possible that the  
data has been corrected in the archive, but never updated in the  
pond. Or perhaps it was never resubmitted, I suppose.

Event: Kodiak Island Region, Alaska | 11/06/2000 11:40:26 GMT | Mag:  
5.5 | Depth 20.00 km | (56.15, -153.456) NL. 
19940101T00:00:00.000Z.HGN.  .BHZ.19940101T00:00:00.000Z , NL. 
19940101T00:00:00.000Z.HGN.  .BHN.19940101T00:00:00.000Z , NL. 
19940101T00:00:00.000Z.HGN.  .BHE.19940101T00:00:00.000Z ,  Processor  
had a system failure
edu.iris.Fissures.FissuresException: IDL:iris.edu/Fissures/ 
FissuresException:1.0 Codec Exception: Type 0 is not supported at  
this time.

I have also opened a jira bug,
http://www.iris.edu/jira/browse/DHI-19
for the pong server returning 0 as the compression type when it can't  
figure it out. I think the server using 0 as a magic value is a  
separate issue, so related but different.

Anyway, perhaps you could look into this one as well in your copious  
spare time. :)

thanks,
Philip

Begin forwarded message:

> From: Philip Crotwell <crotwell at seis.sc.edu>
> Date: March 9, 2005 4:32:53 PM EST
> To: Robert Casey <rob at iris.washington.edu>
> Subject: Re: NL.HGN.  .BHZ as ascii data???
>
>
> I think Chris had responded to this (although maybe not to the  
> list) that there was some bogus mseed from NL and they were working  
> on getting it resubmitted. The only unfortunate part is that  
> instead of throwing an exception, Chris sticks a compression type =  
> 0 in the seismograms he sends back, supposedly marking them as  
> unknown compression. If the data is not decompressable, I am not  
> sure why I would want it, and also type 0 is a valid mseed  
> compression type (ASCII). So, several issues, but not such a big  
> deal to me as I can just skip that one station. There are plenty  
> more to pick on.
>
> thanks,
> Philip
>
> On Mar 9, 2005, at 1:41 PM, Robert Casey wrote:
>
>>
>> 	Hi Philip-
>>
>> 	Sorry about the late reply.  I have been out of town.
>>
>> 	For the NL miniSEED, the data records themselves do not possess a  
>> blockette 1000, so from a miniSEED perspective, the compression  
>> type is ambiguous.  If you assume it's Steim1, you'd probably not  
>> get a good result either.  Doing a lookup in our database for the  
>> station HGN from that period, the compression key comes back as:
>>
>> ID FAMILY NUMKEYS NAME  
>> KEY                                                                   
>> KEY2
>> 99 1      4       KNMI M0~W3,0,2,1 D0-15:1:0:-16384~D16-23~P0:  
>> 0,1: 256,2: 64,3: 8,4: 1~   (null)
>>
>>
>> 	This doesn't look like Steim 1.  Just offhand, since I don't read  
>> DLL's in my spare time, it looks like some sort of 16-bit signed  
>> data format.  It's apparently unique to KNMI networks, pre-2001.   
>> The fact that you got a 0 back from DHI would suggest that the  
>> POND server couldn't resolve just what the compression type was,  
>> so I sent back a default of 0.
>>
>> 	-Rob
>>
>>
>> On Feb 24, 2005, at 8:09 AM, Philip Crotwell wrote:
>>
>>>
>>> Hi
>>>
>>> I just got a seismogram (via DHI from the POND) with the  
>>> compression type set to zero. Do you really have data in the POND  
>>> stored as ascii text or is there a hiccup somewhere?
>>>
>>> Here are the details:
>>> Channel      NL.HGN.  .BHZ
>>> Begin Time   AD 2000.01.06 10:51:16.800 GMT
>>> End Time      AD 2000.01.06 11:12:33.575 GMT
>>>
>>> thanks,
>>> Philip
>