Dapper in-situ conventions spec available

[Ted Habermann]

Hello all,

Great discussion. In the last installment Joe suggested that there 
should always be two sequences. This reflects a division of the model 
into two sections: a station section (outer sequence) and data section 
(inner sequence). This is certainly the classic approach, but it has 
some limitations.

I am working with some SSTs that are calculated from NOAA POES 
satellites. We would like to make these data available using these 
conventions. These are Level 2 data that are stored as points. In this 
case, there is no clear station section, although I might construct one 
that corresponds to the algorithms used to calculate the SSTs or who 
calculated them. These would be constructed using a string (NESDIS or 
NAVY) and several integer flags (152, 151, and 159). Each observation 
would then have a lat, lon, z=0, and t.

On another topic, the spec limits the _id field to being an integer. 
John C. asked why? I have a database that includes roughly 80-100 
Observing Systems. In those cases the id's (provided by the observing 
system managers) are almost equally divided between ints and strings. 
Seems worth thinking about being more flexible when it comes to station 
identifiers. We also might think about how to handle stations that are 
included in multiple networks and, therefore, have multiple 
identifiers... There are lots of these around. I realize that the 
strings can fit into the current spec as attributes. Can those generally 
be searched in the same way as the _id field?

Ted

==== Ted Habermann ==========================
     Enterprise Data Systems Group Leader
     NOAA, National Geophysical Data Center
     V: 303.497.6472   F: 303.497.6513
     "It is difficult to get a man to understand
     something when his job depends on not
     understanding it." Upton Sinclair
==== Ted.Habermann at noaa.gov =================