Advanced Search
Search Results
91 total results found
QuickEarth
QuickEarth是象辑科技自研的二三维气象类数据渲染引擎,支持对接多种开源地图框架,目前已经正式面向外部用户开放使用
渲染点线面
如果是开发完整项目,强烈建议您使用Webpack结合TypeScript进行开发。 本小节的最终演示效果 关于示例代码 以下代码以二维做讲解,三维思路和用法几乎一致。 添加一个基础在线地图 <script> const map = new QE.LMap("map", {crs: L.CRS.EPSG3857,fadeAnimation: false}).setView([35, 110], 5); QE.createTileLayer(QE.predefinedImageT...
原生JS环境
QuickEarth提供了原生JS开发的支持,通过script标签引入即可使用 如果是开发完整项目,强烈建议您使用Webpack结合TypeScript进行开发。 下载或者使用在线UMD包 UMD包支持直接通过script标签进行引入,在这种模式下可以通过全局的QE变量对QuickEarth中的各个功能进行引用。 您可以前往gitee下载: https://gitee.com/mofangbao/quick-earth-free 在html文件中引入 QuickEarth引擎目前支持的二维基础地图库是Leafl...
使用webpack脚手架快速开始
使用建议 虽然原生JS开发上手很容易,使用起来也较为方便,但是并不适用于较为复杂的项目开发,正式项目开发建议使用webpack或者类似的打包工具。 如果您是刚开始一个新的项目,建议您直接使用我们准备好的Webpack脚手架来快速开始,这样只需要在这个基础上继续安装项目中所需要的库即可。 在脚手架中,除了QE所必须的外部依赖之外,我们没有引入任何第三方依赖,以确保开发环境的纯净。 脚手架下载 目前免费版本正在计划发布中,如果还不能下载,请保持关注 https://gitee.com/mofangbao/quick...
在现有webpack项目中引入QE
QuickEarth与普通的第三发依赖包的使用方式类似,但是由于目前还没有发布到npm,因此需要手动进行引入。QE在webpack中dev模式启动的根目录建议设置为.而不是dist,这样就不用把public目录实时复制到dist目录中,只需要最后发布的时候拷贝即可。 复制依赖包到项目 在项目的src目录下创建一个名为qe的文件夹,然后把quickearth.js以及quickearth.d.ts拷贝到该文件夹。 安装依赖 QE依赖一些外部库,需要在使用前安装: "@turf/turf": "^6.3.0", "...
使用TypeScript
为什么推荐TypeScript 如果是开发个人页面,一般代码量比较小,这时候无论使用TS和JS都能比较好的完成工作。 由于原生JS是弱类型语言,无法直接进行编译时的语法检查,对于代码量较大的工程项目,不小心写错单词,传递错误的类型只能在运行时才会发现报错。因此我们建议使用TS进行开发,以便在开发工程项目时能够获得更好的体验以及开发和编译时的类型检查。 使用推荐的脚手架 如果您是使用webpack脚手架快速开始,那么恭喜,我们已经默认就开启了TypeScript模式。您现在可以继续其他章节了! 自己配置的环境 如果您...
在React中使用(内含实战)
React是一个优秀的前端开发框架,即使您只是开发一些简单的个人页面,也非常推荐您使用React进行开发,在QuickEarth项目中启用TypeScript与普通项目无异,如果您还没有使用经验,您可以先学习React相关知识: https://zh-hans.reactjs.org/docs/getting-started.html 本教程最终效果 使用环境 本章节假定使用的是TypeScript进行开发,JS可按照逻辑进行类比。 在React项目中初始化地图 QE地图的初始化有多种方式,可以直接将Dom放在i...
在Vue中使用(内含实战)
使用前提 如果您还没有Vue的使用经验,您需要先学习Vue的使用: https://v3.cn.vuejs.org/ 使用Vue加载地图 首先在html中引入Vue开发包(正式使用建议使用import方式引入,具体请参考Vue网站): <script src="https://unpkg.com/vue@next"></script> 然后构建App并渲染,在组件mount时创建地图 完整代码
关于云平台中的SystemJS环境
也许您会发现,在QuickEarth的云平台中,很多项目的index.html文件中存在systemjs的外部依赖,这是因为我们在开发云平台时,为了更方便的进行动态代码的加载,使用了实时解译的SystemJS库,在实际项目中,不推荐使用,因此我们这里不做介绍,如有需要具体可以参考SystemJS官方文档。 注意:云平台中的SystemJS是我们的定制版本,请勿直接使用在您的项目中,以免出现未能预料的报错。 将云平台的代码在项目中应用 main.tsx中的代码 该文件中的代码使用TypeScript进行开发,您可...
渲染格点数据
本示例的最终完成效果 示例说明 以下代码以二维讲解,三维几乎一致,可以参考最后的完整代码。 将script标签引入,并创建基础地图 <!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <title>QuickEarth-气象数据渲染引擎</title> <link rel="stylesheet" href="https://unpkg.com/leaflet@1.7.1/dist/leaflet.css" /> <scr...
CIMISS/天擎JSON格式
在框架中我们内置了天擎和CIMISS的JSON格式数据解析器,可以直接在项目中使用。(以下只以天擎为例,二者返回的接口层格式相同)。 站点数据 在天擎中,站点格式的返回结果如下所示: { "returnCode": "0", "returnMessage": "Query Succeed", "rowCount": "212", "colCount": "44", "requestParams": "times=20200215000000&datacode=SURF_CHN...
开始之前:系统分析和设计
开始之前 本项目默认您使用的是云平台或者Webpack打包方式(如有疑问请参考使用webpack脚手架快速开始或者在现有webpack项目中引入QE)。 本实战内容将涵盖QE引擎的诸多功能特性,但是在开始之前,您需要掌握以下知识: TypeScript基本语法 实战-矢量和栅格数据渲染 中的基本功能 需求分析 本系统仅供熟悉QE开发框架使用,请勿作为真实业务参考系统,否则您将对由此产生的任何后果负责。 本系统以机场气象用户作为假定使用对象,对其可能需要的数据进行可视化呈现,并提供一系列交互分析功能,以下为本系...
第一节:初始化地图,渲染页面组件
云平台和本地开发的区别 如果您是尝试QE功能,建议您直接在云平台开始根据教程来编码,要注意的是需要在您自己的空间里面创建新项目并保存,否则页面刷新后您的代码将会丢失。 您也可以参考快速入门中的方法,在本地进行编码,这时候本教程中的入口代码对应的是您webpack的入口文件,为了方便演示,我们所有的代码都在这个函数中编写,实际应用中,您应该进行UI组件和业务逻辑代码的拆分。 如果您使用了本地开发环境,请先安装antd,本示例使用antd作为UI框架。 初始化QE引擎状态 QE二维部分依赖Leaflet,因此我们需要先...
第二节:创建图层菜单,定义图层管理器
上一节完成后,我们已经创建了地图,根组件,并且在根组件中渲染了测试的图层菜单以及工具按钮,这一节我们将创建一个完整的图层菜单,并且对如何创建、删除图层做一些思考,最终设计一个用于管理这个项目图层的图层管理器。 创建图层菜单 接下来,我们先把图层菜单构建出来,我们只需要对我们需要实现的图层进行分析,即可通过配置文件配置出菜单。 从上一节的菜单数据源的定义可以看出,我们只要一个IMenuItem数组就可以,目前可以明确的是有气象实况和GFS预报两部分,因此我们分别进行创建。 在哪里创建配置信息 最简单的方式就是直接...
第三节:实现图层管理器逻辑
在上一节中,我们已经实现了按钮的取消和选中,并且与创建和删除图层做了绑定,这一节,我们来实现图层管理器的通用逻辑。 图层缓存 既然我们要能够删除图层,说明我们已经将图层缓存起来,当然Map本身就有对图层的缓存,这个是存储了地图上所有的图层,如果有时候我们只要针对一部分图层做缓存(比如我们的气象图层),这时候就可以自己使用一个key-value对象进行缓存,在本例中,我们增加一个_layers对象用于缓存图层。 private _layers: { [key: string]: L.Layer } = {}; ...
第四节:气象实时数据加载
前几节一直在做铺垫,到此终于开始写数据加载和渲染了。一定有迫不及待的小伙伴直接从这一章节开始看,但是我们强烈建议您每一节都看一下,尤其是没有太多开发经验的同学。 实现Metar观测数据的显示 本小节将实现航空观测报文数据的加载,该数据是站点观测数据,因此我们会使用矢量图层进行加载。 构建数据解析器 构成图层的两要素是数据和样式,我们首先来获取数据。 Metar报文数据源 Metar报文数据可以从NOAA的https://www.aviationweather.gov网站获取,如以下接口用于获取指定范围的3小时内...
第五节:气象预报数据加载
这一节我们主要加载GFS预报数据,数据源来自ucar的在线OPeNDAP服务。 获取GFS数据 一个正常系统一般数据来源于后端的业务接口,本系统本着尽可能利用外部接口,重点演示QE系统使用的原则,尽量从外部获取数据进行演示。在这里,我们发现了ucar的thredds服务下的GFS数据,是可以薅羊毛的!本教程本着教学目的使用此数据! https://thredds.ucar.edu/thredds/catalog.html 从这里,我们可以看到 Forecast Model Data/下面,就是GFS模式的预报...
第六节:实时航班及航班详情显示
前几节我们介绍了如何加载气象的实况和预报数据,本节我们将实现实时航班信息的显示,核心也是渲染矢量数据,但加入了定时刷新的功能。 添加相关菜单和业务逻辑 之前我们并没有在图层菜单上添加航班相关的信息,也没有创建相关占位的图层创建方法,现在我们先把这些加上去。 更新菜单 在菜单中加入航班相关的按钮项即可: public menuData:IMenuItem[]=[ ..., { name: "实时航班", id: "flight", userData: { overlay: true } ...
Micaps文本格式
支持的类型 Micaps的文本数据格式众多,我们会根据用户的反馈来支持更多的格式,当前支持的类型有: 4类格点数据 使用示例 关于文本格式的使用 文本格式的优势是简单易读,缺点是文件尺寸较大,不便网络传输,实际业务中应该根据场景进行合理选择。
自定义四维二进制格式
现有格式存在的问题 经常被用来保存气象数据的格式已经非常多,如nc、grib、hdf、micaps等等,为何我们我们还要定义新的数据存储格式呢? 这主要是因为咱们的应用通常运行于浏览器端,数据从服务器到看到要经过后端解码筛选、网络传输、前端解析、前端渲染这几个阶段,这样的场景要求我们的数据必须要能够快速的被获取、快速的传输、快速的解码,而传统的数据格式定义在很多时候无法同时满足这些要求,如: GRIB/NC格式被大量用于存储数值模式输出结果,而这个格式定义非常灵活,目前还没有解码器能够直接在浏览器对该格式进行...
开发规范
开发环境搭建
QuickEarth提供了开箱即用的开发环境,也支持手动安装到已有项目中,如果是没有太多前端开发经验的人员,还可以使用云平台快速体验。本章节介绍了各类情况下开发环境的搭建,包括原生JS环境和Webpack环境。
核心概念
介绍了QuickEarth相关的核心概念,理解这些概念能够更好的使用QE。
图层清单
详细介绍QuickEarth的各类图层用法。
快速入门
有前端知识就可以,快速掌握QuickEarth二三维开发的基本技能。 建议使用TypeScript进行开发。
实战:监测预报系统
使用免费的气象数据构建一个包含站点实况、卫星云图、GFS预报、实时航线等功能的交互系统
Git使用规范
系统管理
基于kuzzle的用户管理系统,包括用户管理、角色管理、部门管理、资源管理以及权限设置。
内置数据格式支持
QuickEarth内置支持了一些适于网络传输的气象数据格式,以便在项目中开箱即用。
现代化前端开发支持
剖面
本章节主要介绍了如何在三维引擎中进行剖面显示,同时提供了时间层动画实例。
实战-矢量和栅格数据渲染
基于script标签和原生JS,演示最简单的矢量和栅格渲染方式。
矢量图层
矢量数据渲染图层。气象数据在地图上以点,线,面的形式呈现的,三维下还可以使用体的方式呈现,都可以使用该图层。例如:站点填值,国界显示,区域填色等。
栅格平面填色图层
使用栅格数据进行平面渲染的图层。应用:格点填色,渐变填色,色斑图等。
格点标签图层(二维)
二维格点标签图层。应用:格点填值,格点风杆等。
动态风场图层
在二维或者三维下渲染动态风场,三维还支持加入垂直风场。
二维栅格平面填色兼容图层
canvas方式渲染的二维格点填色图层。功能与LPixelLayer图层类似,LCanvasPixelLayer图层是为了兼容没有独显的电脑。
数据解析器
数据解析器,也称数据访问器,也称provider。作用是将原始气象数据解析为具有统一格式的,适用于本框架的结构数据。这里详细介绍每个provider。
样式
QE中的图层样式是可灵活配置的,支持常量、使用分级规则分级渲染、使用函数动态设置、从配置文件加载、使用loader进行预处理和后处理等等很多方式。这里我们按照矢量、格点、风流场三大类分别详细介绍。
第七节:交互工具管理器设计和实现
对于地图上直接的数据展示,我们已经都完成了,现在要做的就是交互工具的开发。 UI支持配置的交互工具 在第一节中,我们放入了占位的工具栏UI组件,实际上对于简单的工具,我们完全可以直接在UI中把用到的工具都写上,但是这里我们为了与图层管理器的逻辑相匹配,也把交互工具的业务逻辑作为一个ViewModel提取出来,通过配置驱动UI,然后ViewModel响应UI的变化。 定义交互工具对象模型 在最简单的情况下,一个交互工具至少需要有一个名称,和一个唯一ID用来标记这个工具,因此定义如下: interface IToo...