#168: Addition of grid mapping for radar and lidar data in radial coordinates
-----------------------------+--------------------------------------
Reporter: mikedixon | Owner: cf-conventions@…
Type: enhancement | Status: new
Priority: medium | Milestone:
Component: cf-conventions | Version:
Resolution: | Keywords: radar lidar grid mapping
-----------------------------+--------------------------------------
Comment (by mikedixon):
Dear Jonathan
I apologize - you are correct, the initial wording was confusing, and
suggested that we make use of atmospheric measurements when computing the
location of a radar gate in the z coordinate. In fact this is almost never
done, and a standard refraction model is used for almost all radars. Hence
a standard grid mapping method is applied to radars in general to compute
the location of the measurements in space.
I have modified the text to indicate this more clearly.
It is true that we could include the lat/lon/height of each gate in the
data. The drawback of this is that it would significantly increase the
size of the files - many radar fields are stored using just 1 or 2 bytes
per gate, specifically to keep the size under control and to facilitate
good compression. Lat/lon/height would need to use 4-byte floats at a
minimum - i.e. and extra 12 bytes per gate. Often radar volumes are
produced every 5 minutes or so, and for many radars across a country, so
the data volume grows quickly. And often the data files must be
transferred across slow communication lines in remote locations. So it is
not likely that the radar/lidar community would support the extra size
involved.
Radar users are generally familiar with the geometric calculations
required to compute the gate locations, and these procedures are well
documented in the literature.
Having a grid mapping specifically for this type of data would, I believe,
help us to get CfRadial adopted by the CF community. Organizations such as
CEDA in the UK are requiring that the radar data submitted to the archive
be CF compliant, and we are working hard to try to meet that requirement.
Along with this proposal we are submitting 2 other proposals - #169 for
complex number support, and a proposal for standard names that will
include the quantities (such as azimuth and elevation angles) that
describe the geometry referred to in this grid mapping proposal.
It would be very helpful to us, and our user community, to be able to get
this approved, with any required changes that are needed.
Thank you very much for your thoughtful comments, and for your quick
response.
Kind regards
Mike
--
Ticket URL: <https://cf-trac.llnl.gov/trac/ticket/168#comment:10>
CF Metadata <http://cf-convention.github.io/>
CF Metadata
