Opened 2 years ago

Last modified 2 years ago

#168 new enhancement

Addition of grid mapping for radar and lidar data in radial coordinates — at Version 9

Reported by: mikedixon Owned by: cf-conventions@…
Priority: medium Milestone:
Component: cf-conventions Version:
Keywords: radar lidar grid mapping Cc:

Description (last modified by mikedixon)


Radars and Lidars sample the atmosphere using a pulse of energy transmitted from an instrument along a line of sight away from the instrument, with a specified beam width (solid angle). The received signal is sampled over time, which allows for the estimation of the distance of the target from the instrument. The samples in range are frequently referred to as 'gates'.

The raw data is stored in radial (polar) coordinates. The (x,y) location of a gate may be determined using traditional great-circle techniques, since these are line-of-sight instruments and the propagation is assumed to be along a straight line in (x,y). In the vertical (z) dimension, a standard model of atmospheric refractive index is generally assumed for locating the height of the gate.

The organization and interpretation of radial data of this type is not supported by any of the standard grid mapping types currently accepted by CF.

Therefore, in order for the CfRadial? radar and lidar format to be formally recognized by the CF user community, we are proposing the addition of a grid mapping specifically for radar and lidar data.

Proposed grid mapping name

We propose the use of the name “radar_lidar_radial_scan”.

Grid mapping parameters

The following example from a CfRadial? file shows the proposed parameters:

grid_mapping:grid_mapping_name = "radar_lidar_radial_scan" ;
grid_mapping:longitude_of_projection_origin = -104.545806884766 ;
grid_mapping:latitude_of_projection_origin = 39.7866401672363 ;
grid_mapping:height_of_projection_origin = 1709. ;

The latitude and longitude are in degrees.

The height is in meters MSL.

The height_of_projection_origin parameter is analogous to the perspective_point_height in the vertical perspective projection.

The supporting documents are maintained at:

Change History (10)

Changed 2 years ago by mikedixon

Radar Lidar Radial Scan Grid Mapping Proposal

comment:1 Changed 2 years ago by mikedixon

  • Description modified (diff)
  • Keywords radar lidar grid mapping added

comment:2 Changed 2 years ago by mikedixon

  • Priority changed from high to medium

comment:3 Changed 2 years ago by mikedixon

  • Priority changed from medium to high

comment:4 Changed 2 years ago by mikedixon

  • Priority changed from high to medium

comment:5 Changed 2 years ago by jonathan

Dear Mike

Thanks for your proposal. It would probably encourage discussion if you could put the text in this ticket. That's more accessible than a linked PDF or GitHub, because the ticket is distributed to everyone by email in plain text. We may change to using GitHub instead of trac, but we're not yet technically set up for that. It's being worked on.

If I understand correctly, this proposal is about recording the conversion of polar coordinates (range and angle) to geolocated XYZ coordinates. Is that right? The conversion depends on measured and variable physical quantities, so it's not like other conversions, which depend on geometry. Therefore I'm not sure it's really like a grid mapping. However I understand that you do need to record the geolocating coordinates. Can they be stored as 2D auxiliary coordinates which are functions of range and angle? That's a general CF mechanism which doesn't depend on grid mapping.

Best wishes


comment:6 Changed 2 years ago by mikedixon

  • Description modified (diff)

comment:7 Changed 2 years ago by mikedixon

Dear Jonathan

Thanks for your feedback.

I have pasted the text from the proposal document into this ticket as you suggest.

I don't really follow your assertion that the mapping of a radar return to a location in space is dependent on measured and variable physical quantities. Rather, the mapping does depend on geometries: the pointing angle of the antenna and the location of the antenna in space. The mapping also depends on an assumed standard model of atmospheric refraction, which is analagous to the 'great circle' construct in 3D projections.

As such, I believe this proposed grid mapping is similar to the 'vertical perspective' and 'geostationary' grid mappings already supported in CF. Both of these mappings depend on the measured position and orientation of the observing platform. The same is true of radar and lidar data.

In September I attended a workshop here in Boulder on NetCDF CF. At that workshop it was recommended that I propose a grid mapping for radars and lidars. Hence this proposal.

We already store the location of the radar, and the pointing angles, in the CfRadial? file. However, it was pointed out at the workshop that to be more consistent with CF we ought to document our grid mapping formally.

Kind regards


comment:8 Changed 2 years ago by jonathan

Dear Mike

Thanks for pasting in the proposal. That's very helpful.

I don't really follow your assertion that the mapping of a radar return to a location in space is dependent on measured and variable physical quantities.

That was what I understood by your text, "The location in space, especially in the vertical, is dependent on the propagation of the energy through the atmosphere. Vertical gradients of the index of refraction lead to complexities in determining the height of the target." That sounds like some physics is needed to work out the xyz locations, not just geometry - I agree that geometry is needed too, of course. Did I misunderstand this?

To be consistent with CF it would be good to include the latitude, longitude and height coordinates in the file, as well as the polar coordinates. That makes the data more easily usable by generic applications. It's the reason why CF requires 2D latitude and longitude auxiliary coordinate variables for data variables which are on map projection planes. Auxiliary coordinates can be understood without a grid_mapping. The grid_mapping additionally provides the information to compute the relationship between the grid coordinates (the polar coordinates, in your case) and the geolocated (auxiliary) coordinates, for software which is able to do that. Perhaps that's your aim. Are your grid_mapping attributes specifying the location of the radar/lidar source? What else is needed to compute the geolocated coordinates from the polar coordinates?

Best wishes


comment:9 Changed 2 years ago by mikedixon

  • Description modified (diff)
Note: See TracTickets for help on using tickets.