Custom Query (125 matches)
Results (46  48 of 125)
Ticket  Resolution  Summary  Owner  Reporter 

#100  fixed  Clarifications to the preamble of sections 4 and 5  davidhassell  jonathan 
Description 
Dear all I have the honour of opening ticket number 100. In this ticket, Steve Hankin and I have a number of changes to propose to the text of section 5, with the intention of clarifying it, not changing what it means. Therefore this is a defect ticket, but please object if you think it is changing the meaning, or making it any less clear! Cheers Jonathan Replace this text in the first paragraph
with
These changes clarify that coordinate systems belong to data variables (rather than any other type of variable in a CFnetCDF file) and recognise the use of nonspatiotemporal dimensions. Replace this text in the second paragraph
with
These changes remove the implication that spatiotemporal scalar coordinates might be prohibited, and allow for discrete axes (section 4.5, used extensively in section 9). Replace this text in the third paragraph
with
This change is for clarity. Replace this text in the fifth paragraph
with
This change is for simplicity and clarity. The use of coordinate variables where applicable is already required by the second paragraph. Append to the fifth paragraph
This change recognises the use of spatiotemporal scalar coordinates. 

#93  fixed  Two new dimensionless vertical coordinate specifications for s coordinate ocean models  cfconventions@…  rsignell 
Description 
1. TitleTwo new dimensionless vertical coordinates to support ocean models 2. ModeratorRich Signell 3. RequirementThe ocean modeling community needs two additional vertical coordinate specifications to allow modern scoordinate model output to be CFcompliant and allow more general specification of scoordinate model output for future development. 4. Initial Statement of Technical ProposalThe existing ocean_s_coordinate dimensionless vertical coordinate specification in CF is limited to a specific vertical stretching function and set of control parameters, while modern versions of ROMS allow for more flexible specification. Additional of these two new generalized vertical coordinate specifications would allow output from existing ROMSderived models (and other s coordinate models) to be CFcompliant, as well as allowing more flexibility for future s_coordinate model developers and users to write and read CFcompliant model output. Here are the proposed additions to Appendix D. Dimensionless Vertical Coordinates Ocean scoordinate, generic form 1 standard_name = "ocean_s_coordinate_g1"
and where z(n,k,j,i) is the height, positive upwards, relative to ocean datum (e.g. mean sea level) at gridpoint (n,k,j,i); eta(n,j,i) is the height of the ocean surface, positive upwards, relative to ocean datum at gridpoint (n,j,i); s(k) is the dimensionless coordinate at vertical gridpoint (k) with a range of 1 <= s(k) <= 0, s(0) corresponds to eta(n,j,i) whereas s(1) corresponds to depth(j,i); C(k) is the dimensionless vertical coordinate stretching function at gridpoint (k) with a range of 1 <= C(k) <= 0, C(0) corresponds to eta(n,j,i) whereas C(1) corresponds to depth(j,i); and the constant depth_c, (positive value), is a critical depth controlling the stretching. The format for the formula_terms attribute is formula_terms = "s: var1 C: var2 eta: var3 depth: var4 depth_c: var5" Ocean scoordinate, generic form 2 standard_name = "ocean_s_coordinate_g2"
and where z(n,k,j,i) is the height, positive upwards, relative to ocean datum (e.g. mean sea level) at gridpoint (n,k,j,i); eta(n,j,i) is the height of the ocean surface, positive upwards, relative to ocean datum at gridpoint (n,j,i); s(k) is the dimensionless coordinate at vertical gridpoint (k) with a range of 1 <= s(k) <= 0, s(0) corresponds to eta(n,j,i) whereas s(1) corresponds to depth(j,i); C(k) is the dimensionless vertical coordinate stretching function at gridpoint (k) with a range of 1 <= C(k) <= 0, C(0) corresponds to eta(n,j,i) whereas C(1) correspond to depth(j,i); and the constant depth_c, (positive value) is a critical depth controlling the stretching. The format for the formula_terms attribute is formula_terms = "s: var1 C: var2 eta: var3 depth: var4 depth_c: var5" 5. Benefits
6. Status Quo


#92  fixed  Add oblique mercator projection  davidhassell  mcginnis 
Description 
The Oblique Mercator projection is used by at least one regional climate model, RegCM3, which is part of the NARCCAP climate modeling program. Currently we record its map projection information using the transverse_mercator projection, which I have learned is very similar but not quite the same. I propose to add this map projection so we can get it right. Proposed text: Oblique Mercator
Map parameters:
Map coordinates:
Notes:
If adding a new attribute for azimuth is problematic, this proposal could be modified to add the rotated_mercator projection instead, which is a special case of Oblique Mercator with azimuth = 90. Note that apparently there is a subtle technical difference between an Oblique Mercator projection and a Hotine Oblique Mercator projection that depends on when the rectification from skew grid to map grid is applied. Since most mapping packages don't support a rectified grid angle parameter at all (effectively giving it a default value of 90 degrees, such that it has no effect), to avoid unnecessary proliferation of attributes I propose to omit this parameter and elide this distinction until such time as it proves necessary. My knowledge of this topic is quite limited; I have made this proposal based on what understanding I have gleaned from the geotiff website and communications with colleagues working with our RegCM3 output in GIS. Commentary from experts would be very welcome. 