In my application, vehicle navigation is done in the WGS84 frame of reference, and the latitude and longitude of every data point is logged. So there's no problem being CF-compliant in the primary data product. I was seeking to generate am auxiliary data product compatible with a legacy plotting package that relied upon UTM coordinates. Since it seems I'm getting no traction on projection_zone, and the auxiliary data products are not widely broadcast -- I'll just make non-CF conforming files. BTW, I do not believe there is any monotonic constraint on the coordinates of a trajectory.
Best, Mike -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Hedley, Mark Sent: Wednesday, October 26, 2011 09:48 To: [email protected] Subject: [CF-metadata] FW: Proposed new standard name: projection_zone Another potential approach would be to split your data into different data variables, and link each data variable to the required coordinate reference system. Each data variable could have the same standard_name, unit, etc; an extra custom attribute could be used to indicate the chaining process. If you use one data variable, it seems to me you run the risk of having major jumps and repetitions in the coordinates, such that coordinate variables, with their monotonic constraint, cannot be used. mark -----Original Message----- From: [email protected] on behalf of Kennedy, Paul Sent: Tue 25/10/2011 16:12 To: [email protected] Subject: Re: [CF-metadata] Proposed new standard name: projection_zone Hi Mike, We regularly have this issue at our shop. We attempted to preserve UTM coordinates across long distances such as fibre cables across the pacific, but if you have a very large spatial set, which spans multiple CRS' it really is better to use a global CRS such as WGS geographicals. UTM Projections are great for local grids but really do not scale well. Hope this helps pk -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Godin, Michael Sent: Tuesday, 25 October 2011 10:32 PM To: [email protected] Subject: Re: [CF-metadata] Proposed new standard name: projection_zone Hello Mark, While the WKT format certainly can describe the mapping of one zone well, I am trying to represent trajectories that cross multiple zones. It's not clear how that can be done in the context of the proposal. It's the same difficulty encountered with the current set of mapping attributes: they define one and only one projection for the dataset. Hence, I am proposing the new standard name "projection_zone" to allow a trajectory to exist in multiple UTM zones, each of which has its own well known and universally understood definition. I had earlier suggested a new grid_mapping_name attribute value: universal_transverse_mercator -- this may not be necessary since a value of "transverse_mercator" in a trajectory file that includes the triplets of projection_zone, projection_x_coordinate, and projection_y_coordinate should be adequate for indicating a UTM trajectory. Mike -----Original Message----- From: Hedley, Mark [mailto:[email protected]] Sent: Monday, October 17, 2011 04:20 To: Godin, Michael; [email protected] Subject: RE: [CF-metadata] Proposed new standard name: projection_zone Hello Mike there is a ticket open on the TRAC system proposing the use of OGC WKT to describe coordinate reference systems: https://cf-pcmdi.llnl.gov/trac/ticket/69 Would this give you the vocabulary you require? mark -----Original Message----- From: [email protected] on behalf of Godin, Michael Sent: Tue 11/10/2011 14:35 To: [email protected] Subject: [CF-metadata] Proposed new standard name: projection_zone This has a corresponding new grid_mapping_name attribute value: universal_transverse_mercator This was last discussed in depth in 2005, and I believe the resolution was that the attributes corresponding to the "transverse_mercator" mapping were perfectly adequate to describe the projection within any given zone. However, I am trying to represent the trajectory of a vehicle that typically crosses zones, and there does not seem to be a satisfactory means for documenting a multi-zone trajectory with the current attribute set. Granted, specifying only the UTM zone is much less descriptive than the full set of transverse mercator mappring attributes, but UTM really is pretty well universally understood, and I'd be surprised to find a mapping library that can't handle a UTM zone integer as the full description of the mapping. Hence, I propose: standard_name: projection_zone, units: 1 Best, Mike _____________________________________________ Michael A. Godin Software Engineer Monterey Bay Aquarium Research Institute Phone: 413-206-6444 http://www.mbari.org <http://www.mbari.org> _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
