[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NetCDF conventions for mobile stations





Janine Goldstein wrote:
John,

Thanks for the link. I wasn't aware you had added conventions for observation data. I don't see this page linked off the main "NetCD conventions" page. I am glad you are working on them!

I *am* planning to put all of these variations into a single file. We create "composite" datasets, and advertise them to the users as having all the date in the same format in a single file.

In that case, you'll be forging new ground.

You can put multiple coordinate systems in the same file, so I would approach it that way; a file that contains multiple sets of data, each with its own coordinate system.
Do your observations have multiple parameters (temperature, pressure, etc) at 
the same time and point? If so, you want to group these together.

For station data:

 id(station)
 lat(station)
 lon(station)
 alt(station)
 firstChild(station) // index into stationObs
 numChildred(station)

 time(stationObs)
 param1(stationObs)
 param2(stationObs)
 ...

For trajectory data:

 id(trajectory)
 firstChild(trajectory) // index into trajectoryObs
 numChildred(trajectory)

 lat(trajectoryObs)
 lon(trajectoryObs)
 alt(trajectoryObs)
 time(trajectoryObs)
 param3(trajectoryObs)
 param4(trajectoryObs)

For station data that occasionally moves, perhaps you should just break it up into 
seperate "stations" whenever it moves. You can add another variable that stays 
constant across the move:

 id(station)
 name(station); // may be the same for different "stations" indicating that the 
station moved.



I read the new conventions and I see two options.

1) Use the multiple trajectory format, for true trajectories make lat(time), and for fixed location stations make lat a scalar variable so that the scalar value will be applied to all observations.

Would that meet the convention? Do you foresee any problems doing it this way?


2) Use the station observation format, and break trajectories into a series of individual stations (i.e. for a 100 observation long trajectory I would define 100 stations each with a unique lat/lon and numChildren=1 (i.e. one report per station).

This option is less optimal because you loose the information that those 100 stations are actually a trajectory. But would it work otherwise? Do you foresee any problems?

Which do you think is the better way to go, if either?

Thanks!

Janine


John Caron wrote:
Hi Janine:

Im unclear if you plan on putting all of these variations in the same file? My first choice might be to put them in multiple files. The formats that you seem to have:

1) station data
2) track data
3) station data that occasionally moves.

Our format for this kind of data is here:

http://www.unidata.ucar.edu/software/netcdf-java/formats/UnidataObsConvention.html

which covers 1 and 2. we havent dealt with 3 before, but we can come up with some variant. these are not part of the CF spec, but we plan to submit them.

perhaps you should look at the above spec, then we can talk some more.

Janine Goldstein wrote:
Hi John,

I am over at EOL and am wondering if you are the right person to help me. I am developing a netCDF file to contain data from irregularly spaced surface stations. Most of these are fixed with respect to time (i.e. ASOS stations, etc) but some move continuously with time (ships) or move intermittently, maybe even just once (as in stations that are relocated but keep the same station id, or truck mounted stations used during field deployments which are stationary for a few hours to a few days, and then move and are stationary again.

I am wondering how best to implement this within a CF compliant netCDF file. For fixed stations, I currently have:

parameter(time, station)
time(time)
lat(station)
lon(station)

I can change this to:

lat(time, station)
lon(time, station)

but less that 1% of the stations are mobile, so this seems like a huge waste of space. For example, 2 months worth of 5 minute data = 17280 repetitions of the lat/lon for each fixed station, compared to one instance of lat/lon in my current model, and I have hundreds of stations per file.

Do you have any suggestions as to how to implement this? Can you point me at any resources that try to tackle this problem?

I just wanted to check before I reinvent the wheel (-:

Thanks so much,

Janine Goldstein
NCAR/EOL