As Robin says, visualized wind data are 100m height from surface. That's what we've selected as the most appropriate average for wind farms. GFS contains different heights that we could allow choosing from.
I admit that earth.nullschool.net and other similar sites have pioneered the visualisation style.
However, their main drawback is that they are standalone, can’t be integrated to another application (besides an iframe).
WeatherLayers is built as a tool for developers, to allow for a seamless integration to other applications and allow overlaying with custom data such as wind power plants in this case, to support end-users with understanding the data in natural context.
I'm here to answer for WeatherLayers, AMA! I'm super happy to help @robhawkes with this project.
WeatherLayers consists of two products, that can be used either together or separately:
- WeatherLayers GL is a frontend visualisation library with deck.gl layers which can be integrated with common map libraries. The library can be used either with custom self-hosted data or with WeatherLayers Cloud.
- WeatherLayers Cloud is a cloud service providing pre-processed data for visualization from common public weather data sources (NOAA, Copernicus).
Athough it’s a commercial project, there are ways to discuss a potential discount or even a free usage for a non-commercial project such as Robin’s.
Amazing piece of data visualization. I work with deck.gl at my day job, and it's really cool to see how far people can push it.
I have a random question - what layer are you using to draw the country borders on the base map? It really stands out, and helps tie the styling together.
Thanks! All the Deck.gl parts are thanks to the work by Jan and WeatherLayers.
The countries layer is using this dataset from MapTiler [1] which is also the service I'm using for all the base maps and vector tile data. I then used interleaved layers [2] in Deck.gl / MapLibre to place the wind layers behind the country outlines.
deck.gl focuses on vector data, whereas WeatherLayers GL adds raster capabilities. Actually, WeatherLayers GL is mostly custom WebGL shaders that could be implemented outside of deck.gl as well. The major reason why deck.gl is used is that it serves as an integration layer for popular map libraries. I've written deck.gl-leaflet [1] plugin myself.
I'm not sure what you think Docker on a Mac does. Docker is a Linux-specific piece of software, and the only way to use it within macOS is to run a Linux virtual machine, with Docker running inside the Linux VM.
If the containers you want to run with Docker are x86 software, that Linux VM either needs to be an x86 Linux distro running in qemu emulation of a full x86 machine, or an ARM Linux distro using the new (not yet released in stable macOS) Rosetta for Linux translation.
Well, kind of. Docker is a product, with official support for Linux containers on Mac (and Windows containers on Windows!). Docker for Mac comes with a Linux VM as a feature of the product; you don't need to install it yourself inside a VM (though that works, too).
It does sound like adding Rosetta binfmt_misc support would allow Docker for Mac to ship an ARM64 kernel/VM image instead of an amd64 one and benefit from some performance boost, but potentially at the risk of reliability/fidelity. The entire idea of Docker is that the kernel ABI is a (supposedly) stable interface, and even if your userspace changed around it, a Docker container would have its own userspace and wouldn't care. Running a different-architecture kernel and dynamically translating it necessarily means that there will be visible differences in the kernel ABI. Sure, you can translate those differences, but that gets you farther from the promise.
Sure, there is a VM in Docker as well. I'm sorry if it wasn't clear, I'm looking for the most straightforward way. With Docker it's a single command, it helps with documenting the steps for other coworkers. It feels slow though. I'm wondering if the new way with Rosetta is going to be better in performance.
> Docker is a Linux-specific piece of software, and the only way to use it within macOS is to run a Linux virtual machine, with Docker running inside the Linux VM.
In all cases, the Docker daemon is running under Linux. The Mac and Windows versions are merely bundling up a Linux VM containing Docker with a frontend that's as transparent as possible, but still with Linux as a hard requirement.
Pretending that the Mac and Windows versions somehow aren't using Linux VMs behind the scenes is of no use to anyone. It's a convenience for users when they can get by with ignoring the VM layer, but a detriment when we see people start talking as though Docker for Mac is functionally different from a Linux VM running Docker, and start assuming that enhancements to running Linux VMs under macOS would be inapplicable to and incompatible with "Docker for Mac".
> In all cases, the Docker daemon is running under Linux. The Mac and Windows versions are merely bundling up a Linux VM containing Docker with a frontend that's as transparent as possible, but still with Linux as a hard requirement.
I really doubt that's the case if you run native Windows containers on Windows.
Thanks for pointing that out. I hadn't realized Microsoft had jumped on the Docker bandwagon to that extent; it's far enough from the topic at hand and from anything I'd ever use that I overlooked it.
So while there is in fact an exception to my previous generalization, there's still no cross-platform compatibility magic to Docker aside from that of virtual machines. If the container OS is different from the host OS (or a different version of the OS, for Windows containers), then using Docker is an instance of using VMs, not an alternative to VMs.
In my benchmarks running Geekbench via docker, Rosetta performed about 3x faster than QEMU's binfmt_misc translation. On certain microbenchmarks it was 10x-50x faster.
This is developer documentation, it's for people who want the internals.
For example, docker-desktop on arm-mac can run x86_64 images by leveraging binfmt-qemu within docker's VM. Changing that to use binfmt-rosetta should have huge gains (as there's specific hardware support to enable rosetta).
Yes it's easier to use docker. Hopefully this trickles down so that you get the benefits of this while not changing your usage at all.
UTM can use both native Apple Virtualisation and QEMU virtualisaion+emulation. The QEMU one can't make use of the M1/M2 Intel memory translation acceleration the same way native virtualisation can, but it can make use of acceleration on ARM64 workloads.
