本文介绍了如何利用gl3520和gl3510进行跨平台的地理空间数据可视化，翻译自Google Earth的文章。gl3520 gl3510为实现这一目标提供了有效的解决方案。
gl3520 gl3510
Editor’s note: Today’s post is by Ib Green, CTO, and Ilija Puaca, Founding Engineer, both at Unfolded, an “open core” company that builds products and services on the open source deck.gl / vis.gl technology stack, and is also a major contributor to these frameworks. Green and Puaca explain how Google and Unfolded have partnered to develop an open source C++ version of deck.gl. An initial version supporting a limited subset of deck.gl layers and features is now freely available on GitHub.
编者按： 今天的博客是 磅绿色 ，CTO和伊利亚·Puaca创始工程师，无论是在 未折叠 的，“开核”的公司，建立产品和服务的开源deck.gl / vis.gl技术堆栈，并也是这些框架的主要贡献者。 Green和Puaca解释了Google和Unfolded如何合作开发eck.gl的开源C ++版本。 支持deck.gl图层和功能的有限子集的初始版本现已在 GitHub上 免费提供 。
Deck.gl is a widely used large-scale geospatial data visualization framework that has its roots in JavaScript and WebGL. The choice of JavaScript has served the deck.gl community well: Visualization is front-end computing and thus the browser is often the natural vehicle to reach users.
Deck.gl是广泛使用的大规模地理空间数据可视化框架，其根源于JavaScript和WebGL。 JavaScript的选择已经很好地满足了eck.gl社区的需求：可视化是前端计算，因此浏览器通常是吸引用户的天然工具。
But there are cases where native implementation can provide better performance, user experience, and architectural fit, primarily in native mobile applications but also for certain high-performance computing use cases. It’s always been clear that a C++ version would enable new opportunities.
但是在某些情况下，本机实现可以提供更好的性能，用户体验和体系结构适应性，主要是在本机移动应用程序中，但在某些高性能计算用例中也是如此。 一直很清楚，C ++版本将带来新的机遇。
A few months ago, a collaboration with engineers working on Google Earth allowed us to fine-tune the architectural vision for deck.gl-native. The goal was to prototype new deck.gl-powered visualization experiences in Google Earth across web (using WebAssembly), iOS, and Android platforms. A native solution was required to enable a high-performance integration with Google Earth’s rendering engine on all platforms. With our designs solidified, and a concrete use case in hand, we were ready to start building deck.gl in C++.
几个月前，与从事Google Earth的工程师的合作使我们能够微调一下deck.gl-native的架构构想。 我们的目标是在网络( 使用WebAssembly )，iOS和Android平台的Google Earth中为基于eck.gl的新可视化体验提供原型。 需要使用本机解决方案才能在所有平台上实现与Google Earth渲染引擎的高性能集成。 巩固我们的设计并准备好具体用例之后，我们就可以开始用C ++构建deck.gl了。
既熟悉又高效的新API (A new API that’s both familiar and efficient)
The new deck.gl C++ API has been designed to correspond closely to the JavaScript API whenever that makes sense and performance is not sacrificed.
新的deck.gl C ++ API被设计为在不影响性能和性能的情况下与JavaScript API紧密对应。
As can be seen in the sample code, familiar classes such as Deck, ScatterplotLayer, MapView and ViewState work just as a JavaScript deck.gl user would expect. At the same time, layer accessor methods (getPosition and getFillColor) that enable data-driven styling are now based on C++ lambda functions for maximum flexibility and performance.
从示例代码中可以看出，熟悉的类(如Deck ， ScatterplotLayer ， MapView和ViewState可以像JavaScripteck.gl用户所期望的那样工作。 同时，启用数据驱动样式的图层访问器方法( getPosition和getFillColor )现在基于C ++ lambda函数，以实现最大的灵活性和性能。
auto layerProps = std::make_shared<ScatterplotLayer::Props>();
layerProps>getPosition = [](const Row &row) {
return row.getVector3<float>("position");
};
layerProps>getFillColor = [](const Row &row) {
return mathgl::Vector4<float>{255, 0, 0, 255};
};
layerProps>data = /* your dataset (arrow::Table) goes here */;
auto deckProps = std::make_shared<Deck::Props>();
deckProps->layers = {layerProps};
deckProps->initialViewState = std::make_shared<ViewState>();
deckProps->views = {std::make_shared<MapView>()};
auto deck = std::make_shared<Deck>(deckProps);
deck->run();deck.gl-native C++ code that renders a ScatterplotLayer with data-driven styling.
deck.gl天然C ++ 呈现一个代码 ScatterplotLayer 与数据驱动样式。
deck.gl-native的软件架构 (Software architecture of deck.gl-native)
Implementing a sophisticated WebGL framework such as deck.gl from scratch in a new programming language (without the need to support backwards compatibility and all the specialized features deck.gl has accumulated on the JavaScript side) gave us the ability to take a fresh look at a number of foundational architectural choices.
使用新的编程语言从头开始实现一个复杂的WebGL框架，例如deck.gl(无需支持向后兼容性，并且deck.gl的所有专门功能都已累积在JavaScript方面)使我们能够重新审视许多基础架构选择。
For more information on deck.gl architecture, the deck.gl Technical Deep-Dive is a good read. While written for the JavaScript version of deck.gl, many concepts apply to the C++ port as well.
有关deck.gl体系结构的更多信息，请阅读deck.gl技术深度学习 。 虽然是为deck.glJavaScript版本编写的，但许多概念也适用于C ++端口。
阿帕奇箭 (Apache Arrow)
All in-memory table processing is based on the Apache Arrow C++ API, which provided significant performance advantages because tables are stored in a GPU-friendly columnar binary data layout.
所有内存中表处理均基于Apache Arrow C ++ API，该表具有显着的性能优势，因为表存储在GPU友好的列式二进制数据布局中。
Note that while Apache Arrow has a fairly sophisticated API, this will be almost invisible to deck.gl-native applications as long they use the loaders provided by deck.gl. CSV and JSON table loaders are provided as part of the deck.gl library in the initial version, and .arrow tables can be loaded with the Arrow API.
请注意，尽管Apache Arrow具有相当复杂的API，但只要使用deck.gl提供的加载程序，这对于eck.gl本机应用程序几乎是看不见的。 CSV和JSON表加载程序在初始版本中作为deck.gl库的一部分提供，并且.arrow表可以使用Arrow API加载。
Naturally, for advanced table processing use cases, applications are free to work directly with the Arrow API to build and process tables, and then pass resulting Arrow tables to deck.gl.
自然地，对于高级表处理用例，应用程序可以自由直接与Arrow API一起使用来构建和处理表，然后将生成的Arrow表传递给deck.gl。
To get started with Arrow, useful resources might be:
要开始使用Arrow，有用的资源可能是：
Arrow Test Suite for examples of working code
Arrow Test Suite提供了工作代码示例
图形后端：通过Dawn的本地WebGPU (Graphics backend: native WebGPU via Dawn)
Deck.gl-native is being built on top of WebGPU API using the Dawn framework.
Deck.gl-native正在使用Dawn框架在WebGPU API之上构建 。
The Dawn framework is a C++ implementation of the WebGPU API and is a compelling choice for deck.gl-native:
Dawn框架是WebGPU API的C ++实现，并且是deck.gl-native的理想选择：
- The JavaScript version of deck.gl will inevitably move from WebGL to WebGPU, so having both C++ and JavaScript work against a common 3D API will significantly increase the ease of aligning the JavaScript and C++ code bases. ceck.glJavaScript版本将不可避免地从WebGL迁移到WebGPU，因此将C ++和JavaScript都与通用的3D API结合使用将显着提高对齐JavaScript和C ++代码库的便利性。
- The Dawn project has the ambition to provide backends on basically all platforms/rendering APIs of interest, including Vulkan, Metal, D3D12, and OpenGL. This ideally means that deck.gl-native itself will only have to implement a single backend, namely Dawn. Dawn项目的目标是在所有感兴趣的平台/渲染API上提供后端，包括Vulkan，Metal，D3D12和OpenGL。 理想情况下，这意味着deck.gl-native本身仅需实现一个后端，即Dawn。
Note that Dawn is still a work in progress (with different levels of support for different platforms; the prototype is only being tested on iOS), and there is some risk with this technology choice. However, given the momentum behind WebGPU in browsers, we feel that the prospects are currently looking good.
请注意，Dawn仍在开发中(对不同平台的支持水平不同；仅在iOS上对原型进行了测试)，选择此技术存在一定的风险。 但是，鉴于浏览器中WebGPU的发展势头，我们认为当前的前景很好。
未来发展方向 (Future directions)
超越移动设备：工作站和服务器 (Beyond mobile: workstations and servers)
While deck.gl runs well in a mobile web view, this cannot share the context with other rendering engines. A “native” C++ implementation of deck.gl is not only required to provide optimal user experience on mobile devices and through integrations with apps such as Google Earth for mobile; it also provides exciting integration opportunities with a number of advanced, high-performance (usually C++ based) software packages that are not available or performant in browsers. These could be math libraries, computer vision libraries, etc.
虽然deck.gl在移动Web视图中运行良好，但无法与其他渲染引擎共享上下文。 不仅需要“ deck.gl”的“本地” C ++实现，以在移动设备上以及与诸如Google Earth for mobile之类的应用程序集成来提供最佳用户体验，还需要 它还提供了许多高级，高性能(通常基于C ++)的软件包提供激动人心的集成机会，这些软件包在浏览器中不可用或性能不佳。 这些可能是数学库，计算机视觉库等。
Workstations and servers sometimes provide better GPU capabilities than browsers can expose through WebGL, and a C++ deck.gl implementation opens the option to use more advanced GPU acceleration when specialized hardware is available, such as nVidia’s CUDA technology. The ideal setup would be that vis.gl automatically takes maximum advantage of the best hardware that it is available at run-time (whether WebGL, WebGPU or CUDA).
工作站和服务器有时提供比浏览器通过WebGL可以提供的GPU功能更好的功能，并且C ++ deck.gl实现打开了在拥有专用硬件(例如nVidia的CUDA技术)时使用更高级的GPU加速的选项。 理想的设置是vis.gl自动利用运行时可用的最佳硬件(无论是WebGL，WebGPU还是CUDA)的最大优势。
deck.gl作为跨程序语言框架 (deck.gl as a cross-programming-language framework)
With the addition of a native C++ implementation, deck.gl is taking another big step away from being a JavaScript first framework, moving towards becoming a multi-language visualization architecture, complementing pydeck (Python deck.gl bindings) and the completely declarative deck.gl JSON API.
通过添加本机C ++实现，deck.gl从成为JavaScript第一框架迈出了一大步，朝着成为多语言可视化体系结构的方向发展，对pydeck (Python deck.gl绑定)和完全声明性的deck进行了补充。 gl JSON API。
For more information, see the deck.gl cross-platform architecture that describes approaches to keeping multi-language implementations of deck.gl compatible. It’s still a work-in-progress, but gives a sense of the higher level direction.
有关更多信息，请参阅deck.gl跨平台体系结构 ，该体系结构描述了使deck.gl的多语言实现保持兼容的方法。 它仍在进行中，但可以提供更高层次的指导。
附加装载机 (Additional loaders)
CSV and JSON table loaders are provided as part of the deck.gl library. To support additional table formats, additional “loaders” can be implemented that load various formats and “convert” the loaded tables to Arrow representation. Integrations with other C++ libraries, such as GDAL for geospatial and imaging formats, are also interesting.
CSV和JSON表加载程序作为deck.gl库的一部分提供。 为了支持其他表格格式，可以实施其他“加载程序”来加载各种格式并将加载的表“转换”为Arrow表示。 与其他C ++库的集成(例如用于地理空间和影像格式的GDAL)也很有趣。
致谢 (Acknowledgements)
Unfolded would like to thank Google for support and encouragement in getting the deck.gl-native development started.
Unfolded非常感谢Google在开始执行deck.gl本机开发方面的支持和鼓励。
Links
链接
gl3520 gl3510
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
