Meteorology Display

[dankelley]

Discussed in https://github.com/dankelley/oce/discussions/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

[dankelley]

Yes, that's the scale argument. Think of it as the number of latitude degrees the line would span, if the flow were either to the north or south. I haven't played with other projections and map spans to see if my code actually does it that way, but I think it does. If I put it into oce, I'll of course document the parameters, and I'll explain these things.

I like the idea of letting the user decide on the barb categories.

A question: do you think all categories are similar in the sense of being multiples of a particular speed?

If the answer is yes, then altering the code will not be too difficult. That's just because I compute the categories by doing e.g. 50*floor(u/50) to get the number of triangles (I guess I ought to say "flags"?) and then similar -- it's what I called above a "making change" procedure.

[dankelley]

I just did a bit of searching and found https://glossary.ametsoc.org/wiki/Barb which I like because it is run by the Am. Met. Soc., which I feel is less likely to be altered erroneously than a wikipedia page. Also, I see the words "half barb", "barb", "pennant", and "five-and-ten", which I like and will use if I put this into oce.

This page also says the barbs used to refer to Beaufort scale.

[mdupilka]

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.

[dankelley]

Re units, I am pretty keen on the units invented by one Donald Knuth when he was a teenager:

[mdupilka]

LOL

[mdupilka]

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.

[dankelley]

Re your Q on mapPoints(), no it cannot work with shapefile objects. To find what it needs, type ?mapPoints. I don't think there is much point (no pun intended) in making oce handle other objects for all these map functions (and perhaps other functions) since it's not hard for the user to do that. Basically, everything that gets added to oce leads to new ripple effects, and a larger chance of bugs. (It's best to ask such questions in new issue, because other users would not to think to look here to find this Q/A. No problem -- just for the future.)

[dankelley]

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, mapDirectionFieldBarbs(), has a parameter called step that defaults to 5. As I write this, I think I ought to make it 10 by default, altering the code. That way, it means the speed of a "barb". I am not sure I like the word step, and might change that. This would not matter to somebody using knots, because the default will be to adhere to that notation.

[mdupilka]

I tried out the code and got this error Error in rep(1, fi[["fifty"]]) : invalid 'times' argument

[dankelley]

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 test file (after renaming the md files)?

barbgeo05.R.md barbgeo05-test.R.md

[mdupilka]

Yes, I just ran the code and I get that map.

[dankelley]

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 make to see if I like the results, then git add . etc. Easy peasy.

Note in that repo that I now have the param length for the length of the lines, not scale as before. That's because I think scale might make people think of the knots vs km/h etc scale, or maybe even ye old Beaufort scale.

All future tests will be with respect to this repo. I am about to delete that gist, too.

[mdupilka]

Sounds good

[mdupilka]

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

[dankelley]

I don't see how you can have that error containing fi[["fifty"]]. If you look at https://github.com/dankelley/windbarb you'll see that the word fifty is not found. Please update your code to whatever is on the URL I just mentioned and try again.

NOTE: the code requires that lon, lat, u and v are all vectors. It is not the same as the mapDirectionField() code. However, I'll tweak it to match. Give me 5 min.

[mdupilka]

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.

[dankelley]

Please try the updated windbarb repo, commit b24cbad38830ccf015dd7ee1a40808b7d6665740

[dankelley]

Tomorrow I'll look into aligning the parameters with mapDirectionField(). For now, the question is whether the drawing is broken.

[dankelley]

I also like the idea of merging the new capabilities into mapDirectionField(). The user would not be calling the new code directly. Instead, mapDirectionField() would check to see if code == "windbarb" and, if so, it would dispatch to new code. I would need to update the docs for parameters

• scale
• length
• code
• ...

and the overall description. I'd also need to add a new parameter, perhaps called

• step

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.

[mdupilka]

I tried the new wb.R code. I still get an error: Error in rep(1, fi[["pennant"]]) : invalid 'times' argument

[dankelley]

I sent an email with what I think is the explanation. Long story short -- please pull the new windbarb repo again and try.

[mdupilka]

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.

[dankelley]

Hi again. Can we establish a convention that you state the "hash" of the windbarb repo that you're using? The present hash is https://github.com/dankelley/windbarb/commit/2cc7537887d4498bc19fb0d0244719c236177ec7

The advantage of quoting the hash is that I can know exactly what version of the code you're using.

[dankelley]

@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".

[dankelley]

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.

[dankelley]

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:

1. The parameters are changed form the test code I wrote previously.
2. This function is named mapDirectionFieldNEW(). If it seems OK for this new plot type, I will comment out the old code and rename this as mapDirectionField().

Perhaps @mdupilka can try it out. It requires being able to build oce from source, of course.

[mdupilka]

I will install and give it a whirl.

[mdupilka]

Well, great job, it is working! I am just working on some of the scaling.

[dankelley]

I blogged about it at https://dankelley.github.io/dek_blog/2024/03/22/wind-barb.html

[dankelley]

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

• https://dankelley.github.io/oce/reference/mapDirectionField.html
• https://dankelley.github.io/dek_blog/2024/03/22/wind-barb.html