-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Meteorology Display #2191
Comments
Hi. First, I made this into an issue, not a discussion. That's because I regularly look at issues, as a sort of to-do list. Also, I'm tagging @richardsc and @clayton33, who might have thoughts on whether this would be useful. As for your question, that's something that I've thought of, but wasn't sure there would be enough interest. I am always thinking of new ways to plot data, and usually try them outside oce to start (see e.g. https://dankelley.github.io/dek_blog/2024/02/03/scotian-shelf-shaded.html) because then testing is a lot faster. (Building oce takes about 5 minutes on my machine, for example, and lots of users don't even have the C compilers, etc. required to build oce from source.) Question: is there a source that you consider definitive, for how to draw barbs? For example, I just searched and found a top hit as https://www.weather.gov/hfo/windbarbinfo but that is in Empirical units (mps and knots) and I wonder if that is what is used outside the US, where km/h is likely used. I would need a source that is stable, non-commercial, and of course that does not need registration or the answering of questions about cookies. (CRAN does not permit using any such web citations. Packages that cite websources that cannot be reached by their algorithm get rejected. That's quite a lot of sites that you can visit easily ... it has something to do with whether sites can answer certain queries, not whether you can see them in a browser.) If you can provide some sources for me to read, that would help. I like having something I can cite in the help for a function. For example, I might say "see page 145 of https://tc.canada.ca/sites/default/files/2020-10/aim-2020-2_met-e.pdf", which is something from the Transport Canada federal agency. Also, if I can get a list of sources I can see variants. Some will be much faster to plot than others. If it can be done with straight lines, for example, that will be a lot faster. I think it will be a slow function anyway, but waiting 20 seconds or so for a plot that is desired is better than waiting 0.5 seconds for something that is unwanted. PS. you're aware of https://dankelley.github.io/oce/reference/drawDirectionField.html I assume? The last diagram you see there might be a start. I realize it's not the same, of course. This is how ocean people usually like to plot flow fields. But there is the problem of overlap, and that is alleviated by barbs, which are of equal length. That is where I think this could be useful. PPS. it's too bad you didn't ask before Christmas. Last term I was teaching an oceanography class in which half the students were meteorologists. They could tell me in a flash things like (a) whether definitions vary across nations, (b) which is preferred in today's practice and (c) are there variants that would make sense to them, but not be expensive to plot. (This last is because things with line segments will be faster than things with curved segments. Faster by a lot.) |
https://www.weather.gov/hfo/windbarbinfo seems like a source that could be cited and is likely definitive (for an audience in the USA, anyway ... I still do wonder whether knots are used in all nations.) Below is a snapshot. So far, I see three notations for the starting location: show open circle, show filled circle or show no circle. Interestingly, I see in the below that the angles are quantized. I never realized that before. This is fun. |
Um, the image in the just-previous comment lacks barb examples for 40 and 45 knots. So it is not really rounded to nearest 5 knots, as they state. Surely something is supposed to be plotted in those categories. Can you shed light on this, @mdupilka? I imagine there is a better source out there somewhere. |
Another source http://ww2010.atmos.uiuc.edu/(Gh)/guides/maps/sfcobs/wnd.rxml is similar (apart from the ugly starting point) but it lacks some categories. |
I see that matplotlib has something (https://matplotlib.org/stable/gallery/images_contours_and_fields/barb_demo.html) and my guess is that some users will be familiar with that notation. I'll look into this, whilst waiting to see if others in this thread have any suggestions. My main concerns right now are
|
Below is a reprex of an initial test. If you rerun it, you'll get different results because it uses a random number. This just tests
This draws just 1 barb, and the feathers are not yet drawn. I would like to have clarity on the speed gaps before doing that. I think the scheme is a bit like "making change" on a cash register. Put another way, it's a bit like Roman numerals. (I realize that making change and Roman numerals are historical artifacts, but so are these weather maps, I think.) Please click the word below, to see this test. (@richardsc and @clayton33 will know that I am just doing my usual thing, of starting with something crude and simple. I do lots of little modifications of tests like this. Only when things are pretty clear do I consider putting code into oce.) met <- TRUE # set TRUE for barbs pointing to wind source
scale <- 0.5
debug <- TRUE
par(mar = c(3, 3, 4, 2)) # using top margin for notes
plot(c(-1, 1), c(-1, 1), xlab = "", ylab = "", asp = 1, type = "n")
x0 <- 0
y0 <- 0
u <- rnorm(1, sd = 10)
v <- rnorm(1, sd = 10)
uOrig <- u
vOrig <- v
if (met) {
u <- -u
v <- -v
}
angle <- 180 / pi * atan2(v, u)
# Barbs are drawn at angles on a 36-point compass
angle36 <- 10 * round(angle / 10)
# Barbs are defined in terms of knots, rounded to nearest 5
speed <- sqrt(u^2 + v^2)
knot <- speed * 1.94384
knot5 <- 5L * as.integer(round(knot / 5))
barbType <- 1 + knot5 / 5
points(x0, y0)
S <- sinpi(angle36 / 180)
C <- cospi(angle36 / 180)
speed
#> [1] 7.438785
x1 <- x0 + scale * S
y1 <- y0 + scale * C
# guiding circles to test angle and length
if (debug) {
circlex <- scale * cos(pi / 180 * seq(0, 360, 10))
circley <- scale * sin(pi / 180 * seq(0, 360, 10))
lines(circlex, circley, type = "o", pch = 20, col = 4)
}
notStill <- knot5 != 0
segments(x0[notStill], y0[notStill], x1[notStill], y1[notStill])
mtext(sprintf(
"x0=%.2g y0=%.2g u=%.2gm/s v=%.2gm/s speed=%.2gm/s knot=%.2g knot5=%g barbType=%d",
x0, y0, uOrig, vOrig, speed, knot, knot5, barbType
), line = 0)
mtext("FIXME: draw barbs", line = 1) Created on 2024-02-18 with reprex v2.1.0 |
Oh, I think the diagram above at #2191 (comment) answers my questions about wind-speed gaps. I'll take a shot at coding this. It really is like making change, drawing in the reverse order as you do the sums in your head. |
Here's a sketch of the 'making change' type algorithm. feathers <- function(u) {
pos <- 0
# Handle triangle feathers
while (u > 50) {
cat("draw 50 at", pos, "\n")
u <- u - 50
pos <- pos + 1
}
# Handle Long feathers
while (u > 10) {
cat("draw 10 at", pos, "\n")
u <- u - 10
pos <- pos + 1
}
# Handle short feathers
while (u > 5) {
cat("draw 5 at", pos, "\n")
u <- u - 5
pos <- pos + 1
}
} |
Hi all! First, because this was opened as a "discussion", I think it's worth discussing whether it makes sense to add more meteorology functionality to
There are probably more points that could be made, but that's a start. I think I'm mostly in the camp of number 3, and kind of like the idea of being able to have wind-barb maps. But I would caution about adding too many other meteorologically-specific functions beyond that (if that is what @mdupilka is proposing). |
I'll add another question to Clark's good list:
|
Re clark's item 3, it is not actually that minimal. There is that "making change" computation, for one thing. And the there is the matter of doing the trig to add the feathers. The existing I've enjoyed playing with this, but thinking of it during my run, it doesn't feel like a good fit for oce. I'd vote -0.8 on "add this feature". Perhaps @richardsc and @clayton33 can vote on the -1 to 1 scale we use for making decisions. No rush -- I think tomorrow is a holiday here anyway. |
Thanks for the discussion. I can only imagine the work required for maintain the OCE package. Thanks a lot for that. I do use the mapDirectionField functions to draw wind vectors. It works very well. I do not have any reference for the wind barbs, The https://www.weather.gov/hfo/windbarbinfo is a standard format for wind barbs. Meteorology pretty much always uses knots for speed, which is a standard for aviation. But some software does give options for km/h display. |
I don't know if this may be of any interest, back many years ago I wrote a C++ program to display wind winds. Here is the code for the wind barbs
|
I made a trial code that does something crude. Rather than get into drawing triangles and lines, I am showing a solid square for 50kt, a big circle for 10kt and a small circle for 5kt. This is just to test my "making change" thought process. The image shows faked data, with flow going around a circle and increasing with distance from the centre. Frankly, this kind of diagram does not really evoke much to my eye. (The barbs do not, either.). I prefer the convention of longer arrows for stronger fields, as we already have in oce. A trick with R is that loops etc are slow. The sine and cosine values can be precomputed because the angles are on a 10 degree grid, so that will speed things up. Redrawing the view below takes 0.13s user time but 0.37s elapsed time on my machine. I don't think it's entirely feasible to draw fields with a whole lot more points than this (because over overlap) so it seems that maybe a code in R would not be too slow even if not well vectorized. Say 2X the grid density for 4X the processing time, maybe throw in 2X to draw triangles and such, but that only gets us to about 8X, or on my machine still under 4 seconds. Still, the arguments against adding this (even cleaned up for barbs) to oce are quite strong, I think. The audience would be small, to begin with. Add to that the fact that any code that is written has to be maintained. And pretty soon we would get requests that it work on projected maps. Then options would be needed. I would want m/s instead of knots, for example. @mdupilka I don't think you'd find it too hard to translate your C code into R, if you really wanted to. The key functions you'd want are Perhaps @richardsc and @clayton33 will have comments on Tuesday, after the long weekend. |
Thanks for working on that. Meteorologists would be the ones using the barbs as that is the standard display for wind fields. Maybe that audience is not too large. I will look into adapting my code. I need it to run as fast as possible as the charts are used operationally in our forecasting. |
I decided to look at the barbs again. There are some adjustable parameters to the aesthetics (angle of barbs, length of barbs, thickness of lines) that all ought to be parameters of a function to do this work. Below is a snapshot of something I just tried. I think it looks a lot like what I see at one of the examples shown above (reproduced here too). Trial version An official diagram |
It looks very good. Just like what is on weather charts. Just a note for speeds of 3-7 units, there is just the short feather positioned one space from the end. Like the second barb you have, only without the 10 unit feather. |
Thanks @mdupilka. I'll change that. What I'm doing is to round to nearest 5 knots, so that category would be from 2.5 to 7.5 knots. Also, I've seen that Canadians (or maybe Canadian modellers) have a similar-looking set of symbols that represent km/hour. I think that scheme is useful for the public since all cars here show speeds in that unit, so you can imagine rolling down your window and feeling the wind, to get an idea what numbers mean. I guess Americans just reckon a knot is like a mile per hour ... and 10% is beyond our ability to intuit, so no problems. |
@mdupilka how does the top row look now? The image is not very clear, because I was trying to reproduce the "official" image. (I wouldn't use such a thick line width, I don't think.) Trial version An official diagram |
I have to say, despite the work involved in getting this implemented, I'm coming around that it makes sense to have wind barbs included in As an aside, a quick google suggests that you've been involved in the CMOS community in the past. I've mostly only been involved since about 2016, but I wonder if you ever crossed paths with my father, Bill Richards, who was a meteorologist with the MSC in NS and NB? |
@richardsc I agree it will be good to have in oce. I'll likely add it on the weekend, I just need to get the 50-knot triangles working, then figure a scheme to do things in km/hour for Canadians (maybe others too) and then, if that all seems ok aesthetically, I can do the next thing, which is save all the plot adornments into a vector that I can use to paint all the barbs at once, for speed. So that's a few little things, but during the week when people tend to be working, I do hope to get the aesthetics right. |
The top row looks very good. I would not worry about any units. Just make the feather values unitless and let the user decide what units they wish to use. The wind barbs history is from the aviation world where all speeds are in knots throughout the world, even in Canada. But, for my purposes, I actually use km/h as the folks we deal with in our forecasting do not really understand knots. I was a chair in CMOS for several years. I did not cross paths with your father. I will ask some other met guys I know if they have. |
@mdupilka how does this look. It's speeds 0, 5kn, 10kn, etc. in reading order from top left. I see some variability in how the triangles get draw, even in the images preceding this in this thread. I kind of like this look. The ones that have asymmetric triangles look kind of weird to me. Thanks for your help and patience. Dan. (Oh, and thanks a million for those kind words about oce. It's always nice to make something that is useful in fields beyond those initially envisioned!) |
That looks really good. The symmetric triangles are the standard. A light wind, less than the 5 barb could just be indicated as a line with no barb. |
Thanks. If wind is zero, which I imagine never happens, is just a dot shown? Or nothing at all? |
To your question about categories, yes they are all similar. A speed is a speed, whatever units the user chooses have. That is up to them to specify in a legend or whatever. Maybe someone wants to use the speed of light as a base unit :). AMS is a very good reference. I use the Glossary a lot. I downloaded the code and will do some testing. I will send some pix when I get things running. |
LOL |
While we are chatting, this is a bit off topic but I use read.coastline.shapefile to get the data for plotting with mapPolygon and mapLines which works great. But I also have a shapefile of points. read.coastline.shapefile does not give any error on this point shapefile, but mapPoints does not seem to work , it wants a longitude and latitude. This is not a problem as I use sf package to read the points shapefile and extract the lon, lat coordinates. Just wondering. |
Re your Q on |
EDIT -- I REMOVED THE GIST I made a "gist" that has an updated code and updated test code. I now use the words "pennant" etc in the code -- which won't be visible to the user, but I will likely use those words in docs, if I add this to oce. (I decided to say "pennant", "barb" and "demibarb" because I like that last term better than "shortbarb" or "halfbarb".) The difference is that now the main function, |
I tried out the code and got this error |
I think I'll give up on the "gist" idea. It turns out that the only way to edit a gist is to use the webpage and click on text. I can't stand editing without vim. I am therefore attaching two new files. Do these work -- i.e. do you get the attached PNG if you run the |
Yes, I just ran the code and I get that map. |
FYI I created a new -- temporary -- repo at https://github.com/dankelley/windbarb and that is where I'll put all updates to the code. It's just too confusing, copying filenames and uploading to github. I find gui operations to be wearisome, and I think it makes it hard on users to keep track of attached files. With this new repo, I just alter the code, type Note in that repo that I now have the param All future tests will be with respect to this repo. I am about to delete that gist, too. |
Sounds good |
I tried running the code on my data which I have been using mapDirectionField for the arrows. I used the same lons, lats, u, and v. The lons, lats are vectors and u, v are matrices. I keep getting the error: Error in rep(1, fi[["fifty"]]) : invalid 'times' argument |
I don't see how you can have that error containing NOTE: the code requires that lon, lat, u and v are all vectors. It is not the same as the |
ok. I'll get the new code when you are finished. I think making it use the same type arguments as mapDirectionField() would be much less confusing. |
Please try the updated windbarb repo, commit b24cbad38830ccf015dd7ee1a40808b7d6665740 |
Tomorrow I'll look into aligning the parameters with |
I also like the idea of merging the new capabilities into
and the overall description. I'd also need to add a new parameter, perhaps called
although I don't know if that is a good word, actually. But I won't be doing such alterations without consulting with Clark first (in meetings today and I think for a few days). And those alterations won't be done until I feel that the actual barb-drawing is good. Altering things in oce is a slow process because each build requires something like 5 minutes of clock time. I would do it in a new branch, of course, to avoid other users being stuck with code (and docs) that are changing several times in a day. |
I tried the new wb.R code. I still get an error: Error in rep(1, fi[["pennant"]]) : invalid 'times' argument |
I sent an email with what I think is the explanation. Long story short -- please pull the new |
ok. For what it is worth, I printed out the fi[["pennant"]] value and it is NA, which is why I am getting the error. |
Hi again. Can we establish a convention that you state the "hash" of the The advantage of quoting the hash is that I can know exactly what version of the code you're using. |
@mdupilka -- how about we discuss further in the issues section of the new temporary repo at https://github.com/dankelley/windbarb/issues? I'm finding the present issue has become so long that I get lost. Also, in the other I can just say "git pull" without having to say "please pull the most recent version of X" and then copying the location of the other repo into "X". |
I see a problem with the demibarb computation. I'll take a look -- likely faster to just fix it than to explain here why I see the problem. IMPORTANT I will not be discussing any barb-related issues in the www.github.com/dankelley/windbarb site, because the point there was just to explore ideas and decide whether to put wind-barbs into oce. I've decided to do the latter. |
This is now incorporated into the "develop" branch. You can see an example of usage at https://dankelley.github.io/oce/reference/mapDirectionFieldNEW.html Two notes:
Perhaps @mdupilka can try it out. It requires being able to build oce from source, of course. |
I will install and give it a whirl. |
Well, great job, it is working! I am just working on some of the scaling. |
I blogged about it at https://dankelley.github.io/dek_blog/2024/03/22/wind-barb.html |
I've added this into oce (the github version) and the "NEW" is now gone from the name. Below is the help page, and a blog example. Given this, I think this issue is ready to be closed. I see that I opened it (really, transferred it from a discussion), so I'll close it. However, if @mdupilka thinks it needs to be reopened, of course that's fine. (I like to close issues because they are a sort of "to do" list for me.) |
Discussed in #2190
Originally posted by mdupilka February 17, 2024
Hi,
I use the OCE package regularly to map meteorology fields for my work. Do you have any thoughts of possibly extending OCE to display meteorology data such as wind fields using wind barbs?
Regards,
Max
The text was updated successfully, but these errors were encountered: