改错

我在之前的文章ASP .Net Core实现动态文件服务器中的有些内容是错误的，这篇文章主要也是为了纠正其中的内容。

需求

我这边有一些3DTiles数据需要动态发布，3DTiles数据简单来说是把大规模的三维地理模型切成很多小片，在展示的时候按精度按范围调取需要的数据，以减轻网络和渲染压力，加快渲染速度的一个方案。因此他是有记录切片配置的json文件和b3dm格式的数据文件构成的，在数据的根目录下有一个根的配置文件，每个子目录下通常也会有子配置文件。

下面总结几条在网上抬杠和带节奏的技巧

GPS是成熟很久的技术，智能手机发展起来之后GPS成了手机手机的必备模块之一，但室内没有GPS信号，使得室内定位到目前为止都是难点之一。但理论上技术倒真没难到什么程度，只要有可以在室内用的定位信号基站，手机端可以接收并解析就行了。但也有如下难点：

使用Cesium做三维特别是房屋白模啥的，通常会用3DTiles，这种情况我通常用FME来生成，不管我的数据是什么坐标系，他都会自己处理好坐标系的问题。直到我需添加单个房屋模型时，glb模型文件就成了比较好的选择，但是在加的过程中遇到了很多问题，特别是建模的时候基础线框使用了比较通用的墨卡托投影坐标系的数据导致模型大小不对的问题，亏自己搞了十年GIS了，刚遇到的时候竟然没意识到这个问题，真是蠢透了。

项目中遇到一组数据既有可能是图片，也有可能是视频，需要同时预览的情况，搜了一下，找到了vue-gallery，试了一下之后发现没法在VUE3下没法用，不知道是真的完全没法用，还是因为我用的Composition API才没法用，没去纠结。

使用Yeoman web 脚手架生成web应用后，如果使用所谓的异步终极解决方案async/await，会遇到一系列的问题。

好久没写博客了，记录一个折腾。

因为在国内测绘数据属于保密数据，我们做项目的时候很多时候只能拿到很小很小的一部分测试数据，有时候这部分测试数据都不是真实数据而是造的假数据。因为造数据实际上挺费事的，所以通常这个数据不会太多，可能就几十条上百条了不起，有的甚至就几条。然而真实世界的地理数据通常是几万条几十万条几百万条的。也许处理几十条数据的系统和处理几千条数据的系统不会有啥区别，但是处理几十条数据的系统和处理几十万条数据的系统的差别绝对是巨大的。以我上一篇博文为例，看起来可以在几百几千条数据上运行的代码，在几十万条数据上运行就需要十几分钟甚至可能导致系统卡死，因此造出大量的测试数据就很有必要。

在Arcgis Engine 开发查询且高亮的功能时，通常查到的代码是这样的：