Question on variable "date"

[woodbri]

@sakitam-fdd I notice you have a variable "date" seen here:

https://github.com/sakitam-fdd/wind-layer/blob/master/dist/OlWindy.esm.js#L73
https://github.com/sakitam-fdd/wind-layer/blob/master/dist/OlWindy.esm.js#L138
https://github.com/sakitam-fdd/wind-layer/blob/master/dist/OlWindy.esm.js#L160

This does not seem to be used anywhere. Is this correct?

At L138, you expect header.refTime and header.forecastTime so I need to have them in my header in the json file. I'm asking because I am writing a python script to fetch gfs data from:

RES = '1p00'
YYYMMDD = utcnow.strftime("%Y%m%d")
HH = '{0:0>2}.format(int(int(utcnow.strftime("%H"))/6)*6)

URL = 'https://nomads.ncep.noaa.gov:9090/dods/gfs_{0}/gfs{1}/gfs_{0}_{2}z'.format(RES, YYYMMDD, HH)

And then generating the windy.json file so I can run in a crontab to generate an file that can be used to load the animation layer.

[woodbri]

Regarding generating the json file, the gfs data looks like:

>>> file.variables['lat'][0]
masked_array(data=-90.,
             mask=False,
       fill_value=1e+20)
>>> file.variables['lat'][-1]
masked_array(data=90.,
             mask=False,
       fill_value=1e+20)
>>>

the latitude values are ordered from -90 to 90, in you json file you have la1=90, la2=-90. Does this mean I need to reverse my array before dumping it to json, OR can I just set la1=-90.0, la2=90.0 and your code will handle it correctly?

What value should I place in the data for the fill_value? EDIT: ignore fill_value as it looks like filling is off for this variable.

[sakitam-fdd]

@woodbri

1. As for variable "date", it's really useless at present. The reason why the code exists here is the time-dependent processing of the original code,You can see them in the warehouse code of ESRI and earth; And the current data conversion program contains relevant time fields. If your program cannot convert these fields, you can temporarily give a random time value.
2. With regard to latitude values, you don't need to deal with it, because it will be judged internally by default, and you can see it here

[woodbri]

@sakitam-fdd

1. Ahh, I thought that might be the case. I also figured out how to set them based on data in my grib.
2. Yes, so you pick the max but don't you also need to change the sign on dy if the max inverts the data?

I'm asking because when I display the animated winds over the NOAA surface winds they are not at all correlated.

NOAA Winds

[woodbri]

Here is my Python3 script to fetch and generate a wind json file:
https://gist.github.com/woodbri/f763eef36c26fb6bfa07e447a01cf082
EDIT: updated script to flip data up/down so 90 > lat > -90 as this is what wind-layer expects. This probably needs more checks to make it generic and there is a question whether dx should be negative or positive. Currently I left it positive in spite of the fact it should be negative to iterate from 90 to -90.

So this fixes the issue of the rotated particle trails mentioned above.

Also in case you have not seen this post:
https://blog.mapbox.com/how-i-built-a-wind-map-with-webgl-b63022b5537f
I thought this was interesting based on encoding the wind data into a png image and processing it in the GPU rather than cpu.

[woodbri]

Can you point out where in the code I can control the density of or number of particles that are displayed?
And where to control the speed of the animation?

EDIT: Well, after looking around some , it looks like it can be set via the input params when the layer is created. I'll need to play around with the values to see how it changes stuff. Also not sure which parameter does what.

[woodbri]

I have been comparing https://windy.com using the GFS layer against the same data loaded into your animator and it seems that most of your animation is roughly rotated 90 deg clockwise from the Windy vectors. IE: if the windy particles are moving SW your particles are moving NW. This could be caused by inverting the data in latitude because of your max(la1, la2) and not changing the sign on dy.
EDIT: I can confirm that dy = -1.0 breaks the wind-layer processing. And flipping the data so lat 90 is on top and -90 on the bottom resolves the rotated particle trails.

[woodbri]

Ok, sorry to pester you with lots of questions.
Any thoughts on how we might be able to do wave animation like this?
https://www.windy.com/-Waves-waves?gfsWaves,waves,36.227,-87.407,5
the data comes from:
https://nomads.ncep.noaa.gov/dods/wave/nww3https://nomads.ncep.noaa.gov/dods/wave/nww3
I'm happy to come up with a python script to generate json files for this, if we can figure out how to animate it.

I have thought about this a little and the wave data has period, height and direction at each lat/lon. I think we could represent this in the animation by creating rectangles where the period is mapped to the thickness of the rectangle, the height is mapped to the color of the rectangle, and direction is mapped to the orientation of the rectangle. Alternatively, period could be mapped to how long the rectangle is displayed, for example long period waves would blink on/off slower than the short period waves. Does this make sense from the point of view of building the display to animate?

[sakitam-fdd]

@woodbri Hi~~~

1. For data, in fact, you only need a few parameters：
   

dx: Increment in X direction, cannot be negative
dy: Increment in Y direction, cannot be negative
nx: cols
ny: rows
lo1: xmin
lo2: xmax
la1: ymin
la2: ymax
parameterCategory: 主要用于表示类型
parameterNumber: https://github.com/sakitam-fdd/wind-layer/blob/master/src/windy/windy.js#L92

2. About options：

colorScale: [ // Color configuration. The rendered color is based on the wind speed range and the given color array. You can see the [code](https://github.com/sakitam-fdd/wind-layer/blob/95368f9433/src/windy/windy.js#L385) for this
    "rgb(36,104, 180)",
],
  minVelocity: 0, // velocity at which particle intensity is minimum (m/s)
  maxVelocity: 10, // velocity at which particle intensity is maximum (m/s)
  velocityScale: 0.005, // scale for wind velocity,In fact, it's ultimately related to the scope of the view (https://github.com/sakitam-fdd/wind-layer/blob/95368f9433/src/windy/windy.js#L342)
  particleAge: 90, // max number of frames a particle is drawn before regeneration
  lineWidth: 1, // line width of a drawn particle
  particleMultiplier: 1 / 300, // particle count scalar, In fact, it just calculates the number of particles as a coefficient(https://github.com/sakitam-fdd/wind-layer/blob/95368f9433/src/windy/windy.js#L399)

3. For webgl rendering, I have studied some of them, but they did not achieve good results in the end, You can see them here and maptalks。

4. But in fact, I don't have a more in-depth study of webgl, and the effects used by windy are all built by webl technology; for me, I'm also interested in this. It may take a lot of work to realize these, so there may be no more plans in a short time. Of course, we welcome more discussion about these。

[woodbri]

1., 2. Thank you for the documentation. That is very helpful.

3. I also looked at a lot of these but since I am using OpenLayers and do not understand webgl I was lost on how to proceed, but wind-layer was excellent. I am more a user of libraries, than a developer of libraries, but I have a good abstract understnding of technology and how to apply it even if my coding skills lack in the OO world.

4. I understand that every idea needs someone to do hard work to make it reality, and that you have other things to do besides work on my suggestions and this is ok. I enjoy a good technical discussion.

So back to the wave implementation ideas, I will try to explain how I think the data can be mapped into the current animation engine, with only a high-level understanding the details of that engine.

• We have a grid of points where each point has period, height, direction.
• We can bi-linear interpolate points between the coarse grid like with winds
• How to render and animate this data
  • render a wave as a short line normal to the direction and about 9 pixels long
  • set the color as a function of the height
  • set the thickness as a function of period 1-5 pixels wide
  • animate by moving it forward in direction for about 2 sec with very little trail behind it (maybe 3-7 frames) its hard to tell but adjusting it to what looks good should be easy.
• height color
  • 30ft rgb(192,175,172)
  • 25ft rgb(192,117,104)
  • 20ft rgb(194,76,91)
  • 16ft rgb(181,50,86)
  • 13ft rgb(139,48,52)
  • 11ft rgb(154,44,116)
  • 9ft rgb(170,68,170)
  • 7ft rgb(139,74,181)
  • 5ft rgb(55,104,187)
  • 3ft rgb(48,117,156)
  • 0ft rgb(117,171,185)

These parameters are based on observing windy.com

So one question is my mind is what is the best format to encode the wave data into json to make it easy to work with and keeps the json file a reasonable size.

Another interesting thing I noticed on windy, is that they use a background fill color and render their particles in white. This is a very nice effect. I guess, I need to find a good webgl tutorial so I can read up on it.

[sakitam-fdd]

@woodbri As for the new functions, I'd like to try to implement them. And here are some interesting projects that you can play 😄 .

1. https://github.com/astrosat/windgl
2. https://github.com/IHCantabria/Leaflet.CanvasLayer.Field
3. https://github.com/gberaudo/olwind
4. https://github.com/sakitam-fdd/wind-layer/tree/next

[woodbri]

FYI, Openlayers 6 now has some basic support for webgl in its API, but rewriting this to work in webgl would be a TOTAL rewrite and is probably a separate project all together. I'm looking at astrosat/windgl and seeing if I can map some of those ideas into OL6 but it might be beyond my current skills.