[CF-metadata] new standard names for flood simulation

From: Eizi TOYODA <toyoda.eizi>
Date: Thu, 13 Aug 2015 17:22:53 +0900

Dear Jonathan,

Thanks a lot for your useful comments.

>> 5) ground_altitude

I'm happy with your suggested ground_level_altitude.

>> 1) flood_depth

I'd use flood_water_thickness.

Now the river experts I'm working with understood the CF definition of
"depth", so they are flexible using other words.
Your second suggestion height_of_flood_water_surface_above_ground_level is
no problem at all, but a bit long for beginners of CF.

>> 6) flood_arrival_time
>> 7) time_at_maximum_flood_depth
>> 8) time_when_flood_water_goes_below_threshold
>> 9) time_span_with_flood_depth_above_threshold

I'm accepting your suggestions on words:

6) time_when_flood_water_rises_above_threshold
7) time_of_maximum_flood_depth
8) time_when_flood_water_falls_below_threshold
9) time_duration_with_flood_water_above_threshold

I wonder perhaps "time_duration" could be "duration", looking at
duration_of_sunshine.

Regarding 6), our planned data is only for the case of threshold=zero, but
it is no problem to generalize the concept to be symmetric with the
"falls_below" counterpart.

Regarding "duration_of_flood", thank you for considering shorthand, but I'd
keep the word "threshold" for all three variables that needs threshold
value.

>> 10) hazard_area_flags
>>
>> The hazard_area_flags is a set of flags representing
>> different types of hazards for a given point in space.
>
> This seems rather vague to me. Can you spell out what sort of hazard they
are?
> Also, I think they should probably be string-valued, and not mention
"flag"
> in the standard name. The flag attributes are a way of encoding
string-valued
> data variables.

I changed the mind to withdraw that name.

Last year I thought it necessary, since (I thought) the online CF checker
made warnings if flag variables do not have standard name, but today it
doesn't make such message.

Just for your info, I'm thinking of this sort of usage:

    byte hzone(lat, lon);
      hzone:valid_min = 0b;
      hzone:valid_max = 3b;
      hzone:flag_masks = 1b, 2b;
      hzone:flag_meanings = "swept_away undermined";

The simulation predicts various independent events: the flood water may
swipe buildings away, and/or undermine the ground under the buildings. If
we try to describe the flag variable i.e. whole set of events, the
description tends to be too vague, or if we list events it would be too
specific to this particular simulation. Now I don't believe that is
something to occupy resource of the CF community.

Best Regards,
Eizi TOYODA

P.S. for anyone interested, updated description and sample CDL are
available at:
  desc - https://gist.github.com/etoyoda/efb7ceeb010e71d0105c
  CDL - https://gist.github.com/etoyoda/1ad78c1df01126c3e731


Best Regards,

--
Eiji (aka Eizi) TOYODA
http://www.google.com/profiles/toyoda.eizi | twitter:e_toyoda | toyoda at
npd.kishou.go.jp
On Wed, Aug 12, 2015 at 1:55 AM, Jonathan Gregory <j.m.gregory at reading.ac.uk
> wrote:
> Dear Eizi
>
> I have comments on some of your names.
>
> > 5) ground_altitude
>
> I appreciate the distinction you are making from surface altitude. Yes, we
> should stick with surface meaning the bottom of the atmosphere, be it solid
> or liquid. In some existing standard names, we have the phrase ground_level
> (not just ground, like sea_level). For consistency with these, I'd suggest
> ground_level_altitude.
>
> > 1) flood_depth
> >
> > The flood_depth is the vertical distance
> > between the surface of the flood water
> > and the surface of ground,
> > as measured at a given point in space.
>
> In existing standard names, depth is a vertical coordinate, not a vertical
> distance (i.e. a difference between two vertical coordinates). For the
> vertical
> extent of a layer we generally use thickness, but I suppose that
> flood_water_
> thickness would not be comprehensible. Can you think of any other
> alternatives
> to "depth" in this case? Given the definition, a possibility would be
> height_
> of_flood_water_surface_above_ground_level.
>
> > 6) flood_arrival_time
> >
> > 7) time_at_maximum_flood_depth
> >
> > 8) time_when_flood_water_goes_below_threshold
> >
> > 9) time_span_with_flood_depth_above_threshold
>
> Could you make these more consistent? For instance, is the threshold
> involved
> in (6) as well? I guess it should be. In that case (6) and (7) could be
> symmetrical
>
> time_when_flood_water_rises_above_threshold
> time_when_flood_water_falls_below_threshold
>
> In (7) I think time_of would sound more natural than time_at. In (9) I
> would
> suggest duration instead of span, since duration is more specific to time
> and
> is used duration_of_sunshine. By analogy, yours could be simply
> duration_of_
> flood, if the definition said that this referred to the threshold. Do you
> also
> need to propose a standard name for the threshold?
>
> > 10) hazard_area_flags
> >
> > The hazard_area_flags is a set of flags representing
> > different types of hazards for a given point in space.
>
> This seems rather vague to me. Can you spell out what sort of hazard they
> are?
> Also, I think they should probably be string-valued, and not mention "flag"
> in the standard name. The flag attributes are a way of encoding
> string-valued
> data variables.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150813/89268e8a/attachment.html>

Received on Thu Aug 13 2015 - 02:22:53 BST