[GRASS-dev] [GRASS GIS] #2347: r.ros uses arbitrary direction convention

#2347: r.ros uses arbitrary direction convention
-------------------------+--------------------------------------------------
Reporter: madi | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: Default | Version: unspecified
Keywords: r.ros | Platform: Unspecified
      Cpu: Unspecified |
-------------------------+--------------------------------------------------
Hi,

apparently r.ros uses wind convention different either from the grass' one
(used by other functions such as aspect or flow direction) or from the one
used by main meteo data providers (see
http://grasswiki.osgeo.org/wiki/Meteorology#Conventions). This is totally
unexpected behaviour as in the documentation I couldn't find the slightest
track.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2347&gt;
GRASS GIS <http://grass.osgeo.org>

#2347: r.ros uses arbitrary direction convention
-------------------------------------+--------------------------------------
Reporter: madi | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: Default | Version: unspecified
Keywords: r.ros, r.spread, angles | Platform: Unspecified
      Cpu: Unspecified |
-------------------------------------+--------------------------------------
Changes (by wenzeslaus):

  * keywords: r.ros => r.ros, r.spread, angles

Comment:

There is not only wind direction but also direction of maximal rate of
spread and aspect.

G7:r.ros:

  * ''direction'': wind directions (degree), CW from N
  * ''aspect'': aspect (degree, CCW from E) - GRASS convention, not tested
  * ''output'': `.maxdir`: directions of maximal ROS, CW from N
  * ''velocity'': wind velocities at half of the average flame height
(feet/minute)

G7:r.spread:

  * ''dir'': directions of maximal ROS (degree), CW from N
  * ''w_speed'': midflame wind speed (ft/min)

[http://en.wikipedia.org/wiki/Wind_direction Wikipedia says]:

> Wind direction is reported by the direction from which it originates.
For example, a northerly wind blows from the north to the south. Wind
direction is usually reported in cardinal directions or in azimuth
degrees. For example, a wind coming from the south is given as 180
degrees; one from the east is 90 degrees.

Which is CW from N but defining the direction ''from'' wind blows, not the
direction of ''vector field'' defined by wind directions and wind speeds.

This is also what [http://grasswiki.osgeo.org/wiki/Meteorology#Conventions
GRASS Wiki says] about "main wind data providers". (If you put together
the images and the text you get that:) GRASS convention is CCW from E and
pointing ''to'' the direction (aspect, flow) while wind is usually CW from
N and pointing ''from'' where wind blows.

What is unclear to me why the GRASS Wiki says that GRASS convention is 0
for vector of zero magnitude (e.g. no wind) and 360 for the reference axis
direction. I don't remember this behavior from G7:r.slope.aspect,
G7:d.rast.arrow, or G7:r.flow. But this is not particularly important now.

Again, `r.ros` is using wind direction clockwise from north. And it is
right in its own sense since direction is pointing ''to'' but as Madi
says, it is not a GRASS nor meteorological convention. However, it is not
uncommon convention, it is an azimuth of wind (''to'') direction (e.g.
ArcGIS defines aspect in the same way).

I seems that there is several applicable conventions for wind. Perhaps, we
should support more than one. Supporting the GRASS one is good for
consistency (and other usages of `r.ros` and `r.spread` than fire), the
meteorologic one can be practical and the current is useful default for
backward compatibility.

Also, the maximum ROS direction map passed from `r.ros` to `r.spread`
follows `r.ros`'s wind direction convention, so it is wrong from GRASS
point of view. We should probably change this too, although it is
basically not part of the interface, so it is not critical.

I was not looking to the source code, so I don't know how difficult it
would be to change this (e.g., are angles out of ``[0, 360]`` interval
allowed?).

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2347#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

#2347: r.ros uses arbitrary direction convention
-------------------------------------+--------------------------------------
Reporter: madi | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: Default | Version: unspecified
Keywords: r.ros, r.spread, angles | Platform: Unspecified
      Cpu: Unspecified |
-------------------------------------+--------------------------------------

Comment(by hamish):

fwiw flow direction from/to is often called meteorological versus
oceanographic convention, different ones are used in different fields of
study, which is fun when dealing with coupled wind-ocean models. (but not
as frustrating as GRIB wind data not noting if its u,v wind velo
components are relative to grid north or geographic north! remember to
make that correction too: `g.region -n` and the r.convergence_angle addon)

also I think it is useful to call the "GRASS" convention 'theta CCW from
the +x axis' (i.e. mathematical|Cartesian convention), instead of 'CCW
from east'. Most people will not know what the "GRASS way" means, but they
will know what Cartesian theta will be like.
(all this versus the navigational convention of degrees CW from north)

In the d.barb module (G6 addons) I try to cover all ways, polar and
component too:
{{{
Flags:
   -r Rotate direction 180 degrees
         Useful for switching between atmospheric and oceanographic
conventions
...

Parameters:
         direction Raster map (or attribute column) containing velocity
direction
         magnitude Raster map (or attribute column) containing velocity
magnitude
                 u Raster map (or attribute column) containing
u-component of velocity
                 v Raster map (or attribute column) containing
v-component of velocity
...
       aspect_type Direction map aspect type
                     options: cartesian,compass
                     default: cartesian
}}}

best to try some obvious cases with strong wind from one direction to
double check assumptions, and always note in the option descriptions which
one is used. And hopefully there is a prevailing wind direction where you
work to double check against.

For r.ros I can understand some logic in wind direction using the
meteorological convention ("from", a northerly wind blows from the north),
while maximum spread output being "to" as in that's the direction the
front is traveling.

Anyway, for backwards compatibility it should only be well documented in
G6, not changed.

Hamish

ps, to convert: `r.mapcalc "cartesian = 90 - compass"`, or vice versa;
from/to is just +180.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2347#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

#2347: r.ros uses arbitrary direction convention
-------------------------------------+--------------------------------------
Reporter: madi | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: Default | Version: unspecified
Keywords: r.ros, r.spread, angles | Platform: Unspecified
      Cpu: Unspecified |
-------------------------------------+--------------------------------------

Comment(by hamish):

see also #2007

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2347#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

#2347: r.ros uses arbitrary direction convention
-------------------------------------+--------------------------------------
Reporter: madi | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.1.0
Component: Default | Version: unspecified
Keywords: r.ros, r.spread, angles | Platform: Unspecified
      Cpu: Unspecified |
-------------------------------------+--------------------------------------
Changes (by wenzeslaus):

  * milestone: 6.4.4 => 7.1.0

Comment:

If we would like to have this resolved in a way of choosing one direction,
we would have to mark it as blocker for 7.0.0. However, I think this is
not feasible and perhaps the better idea actually is to create a new
option (for `r.ros` and `r.spread`) which will allow to choose between
different conventions. If the default will be the same as the current it
will not change the API and everything will be fine. So, increasing the
milestone.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2347#comment:4&gt;
GRASS GIS <http://grass.osgeo.org>

#2347: r.ros uses arbitrary direction convention
--------------------------+-------------------------------------
  Reporter: madi | Owner: grass-dev@…
      Type: defect | Status: new
  Priority: normal | Milestone: 7.1.0
Component: Default | Version: unspecified
Resolution: | Keywords: r.ros, r.spread, angles
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------------------

Comment (by madi):

As apparently a robust solution is not feasible at present without a major
effort, I propose to better address this issue in the documentation of the
modules that might be also affected. Perhaps we should gather all these
info in a wiki page, and linking it from/to the various modules that are
somehow related to "direction" maps?

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2347#comment:5&gt;
GRASS GIS <http://grass.osgeo.org>