Hi Martin and all:
Im wondering what essential methods a calendar library needs to have to
support, eg 360 day calendars? The only one that comes to mind is to
calculate the difference between two dates in, say, seconds? What else?
John
On 4/1/2011 12:55 AM, Schultz, Martin wrote:
Hi Chris
On 4/1/2011 5:09 AM, Jon Blower wrote:
I guess such a library also needs the ability to add and subtract fixed
durations to and from reference date/times.
where the duration is in a fixed number of seconds, i assume?
so we have:
CalendarDate d1, d2;
long secs = d1.diff(d2);
d1 = d2.add(
udunits is a dimensional units library, for manipulating powers of the
fundamental dimensions (length, mass, time, charge, temperature). this
is necessary but not complete for capturing the meaning of the physical
units of our data.
We also need units like kg/kg, for which the udunit
, but it does add
perhaps unneeded complexity.
John
On 3/26/2011 7:46 AM, Don Murray wrote:
John-
On 3/25/11 4:54 PM, John Caron wrote:
On 3/22/2011 6:53 AM, John Caron wrote:
Consider:
int time(sample=1001);
:long_name = Measurement time;
:standard_name = time;
:units = days since 1970-01-01;
vs
On 3/22/2011 6:53 AM, John Caron wrote:
Consider:
int time(sample=1001);
:long_name = Measurement time;
:standard_name = time;
:units = days since 1970-01-01;
vs
int time(sample=1001);
:long_name = Measurement time;
:standard_name = time;
:units = 3 days
On 3/22/2011 12:56 PM, Steve Hankin wrote:
On 3/22/2011 5:40 AM, John Caron wrote:
On 3/21/2011 11:55 AM, Karl Taylor wrote:
Dear all,
I haven't had time to follow all the discussion in detail, but in
general I think CF should not add additional complexity unless the
current way
On 3/21/2011 11:14 AM, Steve Hankin wrote:
On 3/17/2011 5:20 PM, John Caron wrote:
On 3/17/2011 12:19 PM, Steve Hankin wrote:
On 3/17/2011 9:50 AM, Christopher Barker wrote:
On 3/16/11 8:47 AM, John Caron wrote:
1. time instants vs time duration
- one must distinguish between
On 3/21/2011 11:55 AM, Karl Taylor wrote:
Dear all,
I haven't had time to follow all the discussion in detail, but in
general I think CF should not add additional complexity unless the
current way of encoding time is incomplete. As far as I know the
encoding is indeed complete and given
On 3/22/2011 6:40 AM, John Caron wrote:
Anyway, I think the reliance that CF has on udunits is, um, suboptimal.
but only for calendar time units - for dimensional units its the right stuff
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http
hmm, where do you see that part about the iso8601 string implies a
moment and a width a.k.a resolution. i was reading it that the duration
= width spec was separate.
in any case, this probably highlights the need to be specific about what
CF semantics are.
On 3/18/2011 12:27 PM, Benno
On 3/17/2011 10:50 AM, Christopher Barker wrote:
2. calendar time
- calendar time representation needs to be clarified
- udunits should no longer be the reference library for calendar time. a
new reference library is needed, which handles non-standard calendars.
again, the lib is not the
On 3/18/2011 4:11 AM, Schultz, Martin wrote:
Dear all,
in our work, we have often been confronted with the current limitations where the only times allowed by
CF are real times using the days since date syntax and assuming the Gregorian
calendar. We often have climatological fields as
On 3/18/2011 9:17 AM, Bob Simons wrote:
On 3/17/2011 5:20 PM, cf-metadata-requ...@cgd.ucar.edu wrote:
From my POV, the problem is that users need more expressiveness
for the
calendar time. I certainly do. For yearly data, years since base_date
by calendar field (or whatever) is consistent,
On 3/18/2011 10:21 AM, Christopher Barker wrote:
John -- I'm wondering if you have any idea about what the API of a
reference lib should look like? If a time axis is defines as:
calendar months since January, 2008, what sort of functions do you
image would exist to deal with that?
i am
On 3/15/2011 1:30 PM, tim.nighting...@stfc.ac.uk wrote:
Dear All,
At the nit-picking level, day (and hour and minute) are not
necessarily stable units either, because of the occasional appearance
of leap seconds. While this won't be of much concern for many users,
it can be important for
On 3/16/2011 9:39 AM, John Caron wrote:
On 3/15/2011 1:30 PM, tim.nighting...@stfc.ac.uk wrote:
Dear All,
At the nit-picking level, day (and hour and minute) are not
necessarily stable units either, because of the occasional appearance
of leap seconds. While this won't be of much concern
Hi Jonathan:
On 3/16/2011 10:46 AM, Jonathan Gregory wrote:
Dear John
Thanks for your useful summary.
thanks!
- udunits should no longer be the reference library for calendar
time. a new reference library is needed, which handles non-standard
calendars.
If udunits itself were extended
-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Caron
Sent: 16 March 2011 17:00
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] udunits handling of fuzzy time units
On 3/16/2011 9:39 AM, John Caron wrote:
On 3/15/2011 1:30 PM, tim.nighting...@stfc.ac.uk
On 3/16/2011 11:15 AM, Jonathan Gregory wrote:
Dear John
Suppose we added the UTC_Calendar to CF, which tracks leap seconds
etc. So if one had the time coordinate days since 1800-01-01 with
values = 0,1,2,3... and we need the resulting coordinates to be
1800-01-01, 1800-01-02, 1800-01-03,
spaced.)
fuzzy in the sense that they are not really constant, though udunits
assumes they are.
Jon
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Caron
Sent: 15 March 2011 00:31
To: cf-metadata@cgd.ucar.edu
Subject
On 3/15/2011 5:03 AM, Karl Taylor wrote:
I agree with Jon.
By definition, I think, a unit of measure must not vary; hence month
is not a proper unit and not only depends on month of year, but also
on assumed calendar (and similarly for year). Therefore, I think
months since and years since
] On Behalf Of John Caron
Sent: 15 March 2011 13:02
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] udunits handling of fuzzy time units
On 3/15/2011 5:03 AM, Karl Taylor wrote:
I agree with Jon.
By definition, I think, a unit of measure must not vary; hence month
is not a proper unit
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu
mailto:cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu
mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Caron
Sent: 15 March 2011 13:02
To: cf-metadata@cgd.ucar.edu
Hi Steve:
On 3/15/2011 10:13 AM, Steve Hankin wrote:
John et. al.,
It looks like this thread has reached reasonable conclusions:
1. units of days (or secs or mins) can provide an accurate encoding
for months (days since 1930-01-01)
2. units of measure should not be quantities that
On 3/15/2011 12:07 PM, Steve Hankin wrote:
On 3/15/2011 9:28 AM, John Caron wrote:
On 3/15/2011 9:19 AM, Benno Blumenthal wrote:
I am sorry, but this conversation is more confusing that it needs to
be -- once calendar 360_day is chosen, there is nothing fuzzy
about month or year, and once
because udunits converts units like months and years to a fixed number
of seconds, one cant really use things like months and years as units,
since you get things like this:
0 months since 1930-01-01 == 1930-01-01T00:00:00Z
1 months since 1930-01-01 == 1930-01-31T10:29:03Z
2 months since
Hi Yilmaz :
On 3/11/2011 8:55 AM, Yilmaz Arslanoglu wrote:
Hi;
I was wondering the following points regarding dimensionless vertical
coordinates:
1) Assume that we have a variable U (let's say ocean current eastward)
and is defined on a dimensionless vertical coordinate (for example
ocean-s
On 2/3/2011 1:54 AM, Heiko Klein wrote:
I can confirm Davids observation. The European atmospheric models I'm
working with use also unchanged WGS84 (geodetic) coordinates with a
spherical earth.
The proj4 projection library (starting with 4.5, I think) tries to
solve this in the following
On 1/4/2011 11:49 AM, Christopher Barker wrote:
On 1/4/11 10:15 AM, John Caron wrote:
So exactly how much does NetCDF-Java do for you? Can I ask it for a
land-sea mask and it will look for the multiple ways that might be
stored and give it back to me? If so, pretty cool!
It cant do that right
Apparently ESRI is willing to add support for CF 1.5 grid_mapping attributes
for ellipsoidal-earth/geodetic-datum definitions in the Grid Mappings and
Projections specification.
They are looking for sample data, especially using ellipsoidal parameters
in
this vocabulary, without having to distort the data into something else.
Thanks -
Nan
On 12/23/10 11:06 AM, John Caron wrote:
Attached is a message from Bob Simon at ERD/NOAA pointing out the
inconsistencies in data type and feature type names in various
Unidata related efforts. The almost
it will be added to and clarified over time.
John
Original Message
Subject:Re: [netcdf-java] CDM names
Date: Thu, 23 Dec 2010 08:48:41 -0700
From: John Caron ca...@unidata.ucar.edu
To: netcdf-j...@unidata.ucar.edu
Hi Bob:
Yes, you are right, there are too many
im looking at an grib1 file from Canadian Centre for Climate Modelling,
downloaded here:
http://cera-www.dkrz.de/WDCC/ui/Compact.jsp?acronym=CCCma_CGCM2_SRES_A2
the docs on that page says that
The atmospheric component AGCM2 is a spectral model with
triangular truncation at wave no. 32 and 10
Im thinking that we need a new feature type for this. Im calling it
particleTrack but theres probably a better name.
My reasoning is that the nested table representation of trajectories is:
Table {
traj_id;
Table {
time;
lat, lon, z;
data;
}
}
but this case has the inner
03:19, John Caron wrote:
1) It seems clear that at each time step, you need to write out the
data for whatever particles currently exist.
This is a very fair assessment in our case. One could generalize a bit
more: We have data organized as a series of time steps (as the primary
dimension
On 11/2/2010 2:45 PM, Christopher Barker wrote:
On 11/2/10 6:09 AM, Wright, Bruce wrote:
Sorry for a late follow-up (and once again breaking the thread), but
below is some feedback from our guys running the particle trajectory
models at the Met Office, which I think highlight the difficulties
On 10/19/2010 12:55 PM, Mike Grant wrote:
On 19/10/10 14:21, Aleksandar Jelenak wrote:
Actually, I don't think it is possible to use 'time' standard name in
such cases. If I correctly interpret CF rules for using standard names,
'time' data can be only in the physically-equivalent units to
On 10/18/2010 2:40 PM, stephane.poir...@oifii.org wrote:
Hi All,
I am new to meeting CF-1.0/1.4 compliance in netCDF file. Is there
some samples of netCDF CF-1.0/1.4 for polar stereographic and other
non-lat lon geo-grided data? We are having trouble having the
UNIDATA.UCAR.EDU
/marine_environment
Consider the environment before printing
-Original Message-
From: rsign...@gmail.com [mailto:rsign...@gmail.com] On Behalf Of Rich Signell
Sent: Freitag, 8. Oktober 2010 13:59
To: Ute Brönner
Cc: Jonathan Gregory; cf-metadata@cgd.ucar.edu; John Caron
Subject: Re: [CF-metadata
i agree that satellite data needs to be a seperate convention.
you can join the conversation by subscribing to cf-satellite at
http://www.unidata.ucar.edu/support/help/
On 10/7/2010 3:08 PM, Steve Hankin wrote:
Hi Aleksandar,
Satellite datasets have a range of needs that the
On 9/16/2010 11:04 AM, Jonathan Gregory wrote:
Dear Upendra
add_offset is included in CF for data variables, but not coordinate variables.
Its intention is to help with packing data (CF section 8.1).
For time coordinate variables, however, an offset can effectively be included
in the units,
the units appear ok. is the CF checker case sensitive on the t ?
On 7/23/2010 12:27 PM, Karl Taylor wrote:
Stephane,
axis=T is correct. I'm guessing, the units on your time coordinate
aren't recognized by udunits.
Karl
On 7/23/10 11:02 AM, Stephane Poirier wrote:
Hi All,
I am trying to
Rosalyn Hatcher wrote:
My grid mapping is Equidistant Cylindrical. SO in the nc I set as
GLOBAL ATTRIBUTE
--
attname=Conventions
value=CF-1.4
attname=grid_mapping
value=Cylindrical
Some question:
1) A collegue of mine told
into spherical geocentric coordinates? If not, should
model results be assumed to exist on the spherical datum or the original spheroidal
one?
We are wondering if others have pondered this question and would be willing to
share their thoughts?
John Caron
___
CF
Dear Jonathan:
Wow! That's a bit of work there. Ill let others comment on the technical
details, but Ill just say thanks for all your time and deep effort.
John
On 5/3/2010 10:55 AM, Jonathan Gregory wrote:
Dear all
Stimulated by Robert Muetzelfeldt's initiative to produce a grammar for CF
On 4/28/2010 8:14 AM, Stephen Emsley wrote:
We have multiple satellite geophysical data products which share the
same set of geo-location and timing co-ordinates. To avoid product
bloat (e.g. from approx. 30GB to 90GB per orbit) we are considering
the possibility of having a single file
In the CDM, we assume a spherical earth when no other info is given.
This reflects the early history of CF and CDM in dealing mostly with
global models.
WGS84 is the default ellipsoid used eg for UTM projection.
It would be well worth CF specifying default assumptions as well as how
to do
Jonathan Gregory wrote:
Dear all
realization is fine as a standard name. I had forgotten we had introduced it.
I withdraw my suggestion of ensemble_member_identifier.
Thus, the standard name (of realization) can be used to identify an ensemble
axis. I think that providing an axis attribute as
Hi Jennifer, in this instance, how do you know its an ensemble
dimension, as opposed to say, a wavelength ? is it
ens:long_name = ensemble member
??
On 3/16/2010 12:36 PM, Jennifer Adams wrote:
In the absence of a standard, I have also made some choices about how
to handle ensemble metadata
Hi Doug:
Looks to be the same as Paco's. Do you know what was modified?
On 3/16/2010 1:46 PM, Doug Schuster wrote:
NCAR uses a modified version of Paco's file structure for TIGGE output.
All ensemble members found in the file require the same single model
initialization time, the same
On 3/16/2010 11:22 AM, Jonathan Gregory wrote:
Dear John
Im not sure if we ever converged on how to write ensemble files.
No, we didn't. If I remember correctly, we couldn't agree on the relationship
between attributes and coordinates, and that was a sticking-point. I thought
that
Im not sure if we ever converged on how to write ensemble files.
Particularly, how does software recognize the ensemble dimension?
I have an example file:
netcdf C:/data/CMIP3_Rank_Qensemble_4D.nc {
dimensions:
model = 2;
latitude = 97;
longitude = 93;
time = 13;
variables:
John Caron, I am mildly curious what the 3-dimensions represent.
regards,
Karl
On 05-Mar-10 12:30 PM, H. Joe Lee wrote:
Hi,
I have a satellite data that stores lat / lon information in 3-D
array and I'm wondering how such data can meet the CF convention.
Following the
http://*cf
what does the 3rd dimension represent ?
On 3/5/2010 1:30 PM, H. Joe Lee wrote:
Hi,
I have a satellite data that stores lat / lon information in 3-D
array and I'm wondering how such data can meet the CF convention.
Following the
Jonathan Gregory wrote:
Dear Steve et al.
We can distinguish udunits-2 as a standard for units strings, and udunits-2
as software. If we say that CF uses udunits-2 as its reference, programs in
Fortran can still use udunits-1 to process the units strings, in nearly all
cases, though obviously a
Jonathan Blower wrote:
4) Finally on practical note: I seem to remember that someone has
implemented the 360-day calendar using the Java library joda-time? Is
this code available for re-use?
roland schweitzer has extended joda for 360 day calendar. I am planning
to use joda time or its JSR
Hi Andrea:
To figure out if you are using the right form, its best to send CDL to
this group.
To debug your use of the netcdf-java library, its best to send code,
error messages and a sample file to netcdf-j...@unidata.ucar.edu.
Regards,
John
andrea antonello wrote:
Dear Jonathan,
thanks
Robert Muetzelfeldt wrote:
As part of an exercise looking at the grammatical structure of
CF-metadata Standard Names, I have produced a list of all occurrences
of all keywords, with the full Standard Name arranged to the left and
right of the page-centred keyword. All the remaining words in
to the corresponding
row in the HTML Standard Name table on the CF Metadata web site -
would that be useful? Amongst other benefits, anyone who wanted to
cut-and-paste the name could get it from there.
yes, thats what i was using it for, so a link would be great.
Cheers,
Robert
John Caron
Hi Jonathan, Steve, et al:
Question:
Do we use cross referencing variables just in the coordinates
attribute or are there other places?
Comment:
Not having the files explicitly named means that the collection of files
is defined externally. NcML does this, as apparently does the cdms
tjn98 wrote:
Dear All,
I think there may be two distinct cases here:
1) Local cross-referencing, where it is only necessary to establish
a relationship within a well-defined grouping of files,
2) Referencing to a universal resource, such as a specific file
held on a server.
For the
Raskin, Rob (388M) wrote:
While the Point observational conventions document is undergoing final review,
I want to initiate a discussion on a complementary topic - Swath observational
conventions. This model addresses satellite observational measurements and
potentially airborne measurements.
This topic deserves its own heading, so here it is.
Perhaps we should gather current practices and ideas. I think Balaji's gridspec
has a proposal about this. Can anyone summarize what SAFE does?
Im imagining how this is actually used, eg:
float data(y,x);
data:coordinates = l...@file1
Martina Stockhause wrote:
Hi John,
right thanks, we could describe several z coordinates. In our case with
z dimensions:
dimensions:
station = 8 ;
time = UNLIMITED ;
lon = 1;
lat = 1;
z0 = 1;// e.g. VTP in 110 m
z1 = 7;// MINERVA
z2 = 1050; // MRR (rain radar)
The
Stephen Emsley wrote:
Can anyone summarize what SAFE does?
I will give it a shot as I brought it up in the first place!
The Standard Archive Format for Europe (SAFE) was developed as a common format
for archiving to ensure long-term preservation of EO data holdings, both
historical and
Nan Galbraith wrote:
Benno Blumenthal wrote:
This is not just a model problem -- current meters once upon a time
calculated average speed and instantaneous direction, which messed up
calculations of component velocities. Also, thermisters have thermal
mass, also introducing a lag with
Hi Sara:
Thanks for adding your example to the mix. This appears to be a timeseries at a
single x,y location with all the measurements on single, but different levels
(?)
Because these are single level, I would be inclined to use a variation of the station
representation. One possibility is
Hi Roy, Nan:
Let me try to see where the mapping between the two classifications is
currently at:
Lowry, Roy K wrote:
Dear All,
I come from Nan's community with the added complication of exposure to CSML
through working with NDG. From this position in BODC we have developed a
collection
information on the continuous integral data variables, rather than on the time coordinate. Otherwise we have this proliferation of time coordinates, which confuses things.
Steve Hankin wrote:
John Caron wrote:
1. The CDM library uses the bounds if they are present. If only the
coordinate values
Nan Galbraith wrote:
Hi John -
This file has a single variable from a single mooring deployment. A
complete mooring deployment file would have 3 (or 4) depth coordinate
variables, one each for temperature, velocity, and salinity measurements,
since we measure temperature everywhere and add
Nan Galbraith wrote:
Steve Hankin wrote:
Its approaching two weeks (Oct 27) since a revised CF point
observation Conventions proposal was made:
https://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions
https://cf-pcmdi.llnl.gov/trac/ticket/37
Given the complexity of the
1. The CDM library uses the bounds if they are present. If only the
coordinate values are present, the CDM generates bounds. These grids
bounds are used by ncWMS and other visualization software to draw color
filled images. The IDV (I think) uses a contouring algorithm with just
the
Martina Stockhause wrote:
Dear John, dear Heinke,
I would support Heinke's idea of generalizing the definition for 'profiles', so
that it can be applied to microscale measurements as well. Apart from
scintillometer data, data from optical methods like DOAS or FTIR can be
delivered as
Domenico
*Sent:* 09 November 2009 15:59
*To:* CF-netCDF SWG
*Subject:* [CF-NetCDF-1.0.swg] Fwd: [CF-metadata] CF point
observationConventions ready for review
Hello,
The message below from John Caron points to a revised version of the
proposed CF Conventions for point observations. Note
martin.juc...@stfc.ac.uk wrote:
Thanks for the responses.
Seth is right, I was looking for an alternative to having a gigantic flag_meanings attribute.
I have tried Seth's approach, but can’t get it past the cf-checker. There appears to be a character set
restriction: I can get the first
Lowry, Roy K wrote:
Hello Martin,
There is another possible solution to your problem, which we are looking at for
dealing with a data source flag to be used with the GEBCO bathymetric grid.
This is to put a URI base into an attribute that when concatenated with a flag
values gives the flag
I have complete a new version of the CF point observation Conventions at:
https://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions
Discussion is at:
https://cf-pcmdi.llnl.gov/trac/ticket/37
I have incorporated various feedback from the past year, and made a
preliminary
martin.juc...@stfc.ac.uk wrote:
Hello,
I wonder if anyone can help with this problem:
I have a file with a map of index values, ranging from 1 to 827. The
flag meanings range from “Admiralty Islands lowland rain forests” to
“Zambezian halophytics”. I’m reluctant to combine all 827 flag
||whats the difference between these two standard names:
geoid_height_above_reference_ellipsoid javascript:void(0)
||height_above_reference_ellipsoid javascript:void(0)
??
is there a discussion about this somewhere? I just noticed that the mail
archives don't seem to be searchable ??
to iron out also.
John Caron
Unidata
Karl Taylor wrote:
Hi all,
Here is an inquiry from Kevin Hodges. I think CF would treat these
something like weather balloons. Can anyone help?
thanks,
Karl
p.s. please copy Kevin k...@mail.nerc-essc.ac.uk because I think he's not
on our list
Derrick Snowden wrote:
Hello,
I am interested in creating a new file format for use in an
operational data collection scheme. The file will contain XBT
profiles collected under the auspices of the JCOMM Ship Observations
Team so will have many international users. I'd like to use CF
Maarten Plieger wrote:
Hi All,
I was wondering whether it is allowed to use scale and offset
attributes in coordinate variables? Or is this feature only to be used
with normal variables?
Thanks in advance,
Maarten Plieger
Netcdf-Java library does recognize scale/offset on coordinate
A few more cents:
1. Its more powerful for the client to know the projection transformation than
to know only the 2D lat/lon values. For that reason I always encourage
providers to include the projection info. When the client doesnt know what to
do with the projection info, having the 2D
As Steve says, the FMRC Aggregation helps to bridge between a complex 2-time
dimension collection, and applications that can only deal with one time
dimension. A pretty poster is here:
http://www.unidata.ucar.edu/staff/caron/presentations/FmrcPoster.pdf
Still, we need to decide how to encode
Hi Jonathan, Tim, Doug, et al:
Jonathan Gregory wrote:
Dear Tim
So for the case of multiple analysis and forecast times, where all
combinations
exist, you have two multivalued time dimensions, one for forecast reference
time (= base time, analysis time, initialisation time) and one for
I would propose that we dont replace the current standard_name attribute, but explore alternative representations of their semantics. The goal would be to clarify the relationships of the various semantic components of a standard quantity, and to explore possible grammers for generating the name.
Hi Karl:
I think this is a very important idea thats worth exploring further. An important step would be to try to retrofit the existing set of standard names, and see what issues arise. It would be interesting, in fast, for more than one person to independently try that, making up their own set
CF Section 8.2 compression by gathering has this example:
dimensions:
lat=73;
lon=96;
landpoint=2381;
depth=4;
variables:
int landpoint(landpoint);
landpoint:compress=lat lon;
float landsoilt(depth,landpoint);
landsoilt:long_name=soil temperature;
landsoilt:units=K;
One thing i forgot to mention, in the 5.3 example:
Example 5.3. Reduced horizontal grid
dimensions:
londim = 128 ;
latdim = 64 ;
rgrid = 6144 ;
variables:
float PS(rgrid) ;
PS:long_name = surface pressure ;
PS:units = Pa ;
PS:coordinates = lon lat ;
float
I was looking at the reduced horizontal grid feature because its really a way
to store ragged arrays rather than the somewhat more general compression by
gathering. Its possible that a convention to store ragged arrays might be
quite useful in point observation conventions that ive been trying
101 - 190 of 190 matches
Mail list logo
