r.ros uses arbitrary direction convention

[madi]

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.

[wenzeslaus]

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)

​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 ​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?).

[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.

[hamish]

see also #2007

[wenzeslaus]

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.

[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?

[neteler]

Milestone renamed

[neteler]

Ticket retargeted after milestone closed

[neteler]

Ticket retargeted after milestone closed

[martinl]

Ticket retargeted after milestone closed

[martinl]

Still relevant?