Dear Mike
I only know about UTM what I've just read in wikipedia. Having read that, my
understanding is that a location in UTM is fully specified by projection zone,
easting and northing. Those three numbers will give you a unique latitude and
longitude wrt to an ellipsoid which is defined by UTM as well. Is that right?
If so, I agree with your earlier suggestion that it would make sense to
define a grid_mapping_name of universal_transverse_mercator. This would have no
parameters at all, since there are no "free" parameters if you know it's UTM.
You're right, you'd also need a new standard_name for your coordinates along
the trajectory. I would suggest universal_transverse_mercator_projection_zone,
since we spell out most things in standard names, but I suppose "UTM" is a
well-known enough acronym that utm_projection_zone would be OK too. Then your
trajectory has three spatial coordinates, of projection_x_coordinate (easting),
projection_y_coordinate (northing) and utm_projection_zone. Is that right?
In addition, to satisfy CF, you should include aux coords of longitude and
latitude along the trajectory.
If the above is what you would need, it looks like quite a minor change to
the convention.
Best wishes
Jonathan
On Thu, Oct 27, 2011 at 09:16:09AM -0700, Godin, Michael wrote:
> Date: Thu, 27 Oct 2011 09:16:09 -0700
> From: "Godin, Michael" <godin at mbari.org>
> To: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] FW: Proposed new standard name:
> projection_zone
>
> 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: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Hedley, Mark
> Sent: Wednesday, October 26, 2011 09:48
> To: cf-metadata at cgd.ucar.edu
> 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: cf-metadata-bounces at cgd.ucar.edu on behalf of Kennedy, Paul
> Sent: Tue 25/10/2011 16:12
> To: cf-metadata at cgd.ucar.edu
> 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: cf-metadata-bounces at cgd.ucar.edu
> [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Godin, Michael
> Sent: Tuesday, 25 October 2011 10:32 PM
> To: cf-metadata at cgd.ucar.edu
> 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:mark.hedley at metoffice.gov.uk]
> Sent: Monday, October 17, 2011 04:20
> To: Godin, Michael; cf-metadata at cgd.ucar.edu
> 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: cf-metadata-bounces at cgd.ucar.edu on behalf of Godin, Michael
> Sent: Tue 11/10/2011 14:35
> To: cf-metadata at cgd.ucar.edu
> 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
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Thu Oct 27 2011 - 20:23:30 BST
