clarify: Wind

[Dirk--]

TWD:

• True Wind Direction (relative to true north) environment.wind.directionTrue
• True Wind Direction (relative to magnetic north) environment.wind.directionMagnetic

AWD:

• Apparent Wind Direction (relative to true north) environment.wind.directionApparentTrue
• Apparent Wind Direction (relative to magnetic north) environment.wind.directionApparentMagnetic

TWS:

• True Wind Speed (relative to ground) environment.wind.speedOverGround
• True Wind Speed (relative to water) environment.wind.speedOverWater

[joabakk]

It might be better to fork and make a pull request, so we can see what you are proposing in code. Is it the descriptions you are lproposing to change?

[Dirk--]

reworked things, here is my proposal:
environment.wind:

• AW Apparent Wind (relative to vessel)
  • Apparent Wind Speed speedApparent
  • Apparent Wind Direction (relative to true north) directionTrue directionApparantTrue
  • Apparent Wind Direction (relative to magnetic north) directionMagnetic directionApparantMagnetic
  • Apparent Wind Angle (relative to HDG) angleApparent
• TW True Wind (relative to surface of the water)
  • True Wind Speed speedTrue speedWater
  • True Wind Direction (relative to true north) add: directionWaterTrue
  • True Wind Direction (relative to magnetic north) add: directionWaterMagnetic
  • True Wind Angle (relative to HDG) angleTrueWater angleWater
• GW Ground Wind (relative to ground) used in weather forecasts and reports
  • Ground Wind Speed speedOverGround
  • Ground Wind Direction (relative to true north) add: directionOverGroundTrue
  • Ground Wind Direction (relative to magnetic north) add: directionOverGroundMagnetic
  • Ground Wind Angle (relative to HDG) angleTrueGround angleOverGround

My (limited) knowledge is based upon
https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:opencpn_user_manual:terminology

[joabakk]

As this would be a breaking change, and any clients using the existing schema would have to be re-written, I would suggest refining the descriptions instead of the path names. Granted, the current path names can lead to confusion, but that can be resolved more easily by the descriptions. I would propose that you make a pull request with the additions and the description changes you propose

[sbender9]

You're changes make sense and too bad you weren't here before we finalized 1.0.

But as @joabakk said, we can't make breaking changes in the 1.x spec. It could be considered for 2.0, but that's probably a long way off.

[tkurki]

The different wind related figures seem to cause endless debates. Honing the descriptions would be the way to go here - no matter how you name them, they won't be crystal clear to everybody.

Plus the backwards compatibility already mentioned.

[quantenschaum]

The different wind related figures seem to cause endless debates.

Yes, of course, because the current naming it terrible and it's wrong in almost every software project I came cross.

• The naming is inconsistent
• angles and directions get mixed up
• true wind (relative to water, always!) and ground wind get mixed up ❗ This is a big one, especially in tidal waters.
• set and drift is ignored or assumed to be zero
• the term "true" is ambiguous, it may refer to "true north" or "true wind"
• magnetic and true directions get mixed up
• magnetic deviation and variation get mixed up
• calculations converting one to the other are almost always wrong, more on that here

[not all SignalK but the same/related issues: here, here, here, here, here, here]

Even expensive commercial products get it wrong.

So, this wind thing seems confusing, but actually it is very well defined. You just have to take 10 minutes to think about the definitions and use a proper naming scheme.

@Dirk--'s proposal #520 (comment) is very good to clean up that mess. 👍

• It's a clear, logical and self explaining naming scheme. ✔️
• It's very good to call the "true wind" "water wind" to emphasize that it is relative to water and it eliminates the ambiguity with "true north" ✔️
• "apparent" is spelled with an E
• I would use just "Ground" instead of "OverGround" like in "ground wind" to make it shorter
• (Who wants magnetic directions? 🤷 )

As this would be a breaking change... any clients using the existing schema would have to be re-written

Well, the current scheme is broken so it requires a breaking change to fix it.
This would make people aware of this problem and it would finally clean up this mess.

[jrversteegh]

After some debate with a co-worker once, I made this drawing. I feel it's accurate, so maybe it's of use to someone, or maybe just creating more confusion ;) Either way, what it tries to get right is:

• The relationship between vectors, angles and magnitudes
• Velocities are vectors and "speeds" the magnitude of these vectors
• Angles are relative to the boat and directions relative to the 'world'

It does not contain the concept of magnetic north... I suppose that's another topic of discussion. Considering it's 2024, I think it should no longer exist, except for converting a magnetic north measurement to true north, but that's my humble opinion.

[quantenschaum]

The drawing is good, maybe somewhat confusing due the may triangles, but all in all it's correct. I made a similar drawing and also gave the (vector) equations to perform the calculations.

What you call "drift" is usually called "leeway (angle)" in that scheme and the current (or tide) vector is composed of "set" (current direction) and "drift" (current speed), "wind" is usually called "ground wind" and "ground wind speed" and "speed" is "water speed" just to be clear.

The wind vectors are usually drawn reverse because the wind direction is the direction where the wind in coming from, where as velocity vectors and current vector point in the direction it is going into. This makes it more confusing, but this is the common definition.

It all boils down to the current triangle which is also used to work out a course to steer.
Now connect the wind vectors to the 3 vertices of that triangle and you get ground wind, true wind, apparent wind.

(source )

These drawings and some descriptions/definitions should end these discussions.

The concept of the magnetic directions does actually not belong here directly. All directions should always be relative to true north. The only place where you need a magnetic direction is when reading a magnetic compass (course or bearing) or working out a (magnetic) compass course to steer. All other calculations should be done "true" only. In the end you can convert back to a compass course using variation and deviation. This saves a lot of headache.

[jrversteegh]

@quantenschaum Thanks for the feedback!
"Drift" and "drift angle" are terms from commercial ship building, but "leeway" is indeed more accurate for sailing vessels. I'll change that. As well as adding "ground" to wind.
With respect to wind vectors: I deliberately didn't draw them inverse. That would be confusing indeed. I did however make them end at the origin rather than start, so the definition of the associated angles and directions still conforms to traditional "where the wind comes from" angles and directions.

[quantenschaum]

With respect to wind vectors: I deliberately didn't draw them inverse

That is smart. - Together with some explanatory text this is a good solution.

So, everyone participating in a discussion on this topic should study our drawings and explanations first.

[quantenschaum]

the drawing by @jrversteegh mentioned in #520 (comment)
just for the purpose of preventing the drawing from getting lost if the link dies

and my drawing

[jrversteegh]

@quantenschaum nice picture! More readable than mine. Content wise they look about the same so at least there are two people who agree on this ;) DFT and SET as speed and direction of current are new to me, but seem well established, so good, I should adopt those!
One thing that's not entirely clear to me is whether you'd define STW with respect to HDT (as you've done) or CRS (as I've done). Since the lee angle is usually small (and thus the cos of that angle close to 1), the numerical values won't differ much, but as a matter of definition still good to make clear. Why did you choose it to be the "along ship" component of the velocity through water vector, rather than the magnitude of it?

[quantenschaum]

One thing that's not entirely clear to me is whether you'd define STW with respect to HDT (as you've done) or CRS (as I've done). Since the lee angle is usually small (and thus the cos of that angle close to 1), the numerical values won't differ much, but as a matter of definition still good to make clear. Why did you choose it to be the "along ship" component of the velocity through water vector, rather than the magnitude of it?

That is a good point, I left this open just due to the reason you mentioned, the angle is small (usually).

STW in this scheme is the velocity measured by the paddle wheel log, so it is the component along the keel. I did not include this in the formulas since I suspect the measurement error to be greater than the effect of cos(LEE), but could be added easily. STW could also be defined along CRS, there is no common definition afaik, it depends on the use case.

[jrversteegh]

velocity measured by the paddle wheel log, so it is the component along the keel.

@quantenschaum Yes, I thought of that as well. The velocity measured by the paddle wheel is usually equated to STW and hence the 'forward' velocity of the boat. My statement would be that it doesn't measure STW exactly by definition, just the forward component of it and this is then again no issue, because it didn't measure anything exactly anyway as you also mentioned and every sailor knows.

However, a more advance speed log, like an acoustic doppler log would also measure the forward speed.
About for example this electromagnetic log I am not sure. The installation manual says nothing about orientation when installing, so not directional? I want one!

Your code, contrary to your drawing, also appears to consider STW with respect to CRS ;)

In my book whatever a sensor measures should not muddle definitions, but I'm a coder and not a pragmatic ;D

[Asw1n]

I think the best way to get rid of all naming conventions for wind is to recognise that the different wind definitions all use a different frame of reference (FoR). Apparent wind uses the vessel as a FoR, True wind uses the water as a FoR, ground wind the earth, etc.

So the best way to get rid of the current mess in naming is to add the frame of reference to the path. Once that is done we would just need windspeed and windangle.
The same principle applies to boat speed where we have speed over ground (FoR being earth) and speed through water (FoR being water).

In my opinion apparent and true wind are nice for labeling but not for a data model.

[quantenschaum]

@Asw1n absolutely, that would make it very concise. How would these paths look like?

[Asw1n]

@quantenschaum Well, I did not think that trough :-). I do think that ROS (Robotic Operating System) has worked this out really nice. Maybe that could serve as an ispiration.
What you would need is a chain of physical objects, each object in the chain has one or more (?) predecessors as a frame of reference. Each object has a position, speed, attitide and angular speed in respect to its frame of reference. Measurements should be made by a physical object, so that measurements do get a position and attitude via its object.
You would need something like world, water, vessel, mast, windmeter as a chain of objects. A wind measurement can then be calculated to water as frame of reference to get true wind. While doing so wind speed would not only be corrected for boat speed but also for misalignment in the mast, mast rotation and boat heel.

[Asw1n]

@quantenschaum. I gave it a bit more thought.
How about environment.wind.<reference>.speed and environment.wind.<reference>.angle
Reference for example can be ground, water, vessel, mast or even sensor.
So true wind speed would become environment.wind.water.speed, apparent wind would become environment.wind.vessel.speed. Unless, you would have a rotating mast, then the apparent wind should be environment.wind.mast.speed.

[jrversteegh]

@Asw1n

How about environment.wind.<reference>.speed

Sounds very good to me. I would consider maybe wind.ref_water instead of wind.water for clarity, but this kind of scheme would make it trivial to use for example a json path expression to select all available speed values.