大批量影像瓦片优化 在很多场景中，需要用的影像瓦片，常规的思路是将tif进行切图，做成分层的瓦片：但是，如果层级太高，产生的文件将十分庞大，据测试，某地级市18层级切片，内存占用高达200多G，在部署和传输的过程中，都很不利。
vite.config引入插件报错：无法找到模块“vite-plugin-optimizer”的声明文件。“d:/myProject/electron-juejin/node_modules/vite 原因：错误表明 TypeScript 无法正确解析 vite-plugin-optimizer 包的类型声明。这是由于包的 package.json 中的 exports 字段配置不当，或者类型声明文件的位置不正确。
Java调用GDAL实现postgresql数据生成shp和dxf 由于shp数据存储到postgresql数据库中，前端调用数据库实现数据的渲染，最近有一个新的需求，前端圈选数据，实现数据的下载，数据可以是shp、dxf、excel格式，这里主要记录在后端通过调用gdal来实现这个需求
基于苹果手机采集数据实现RGBD三维重建 项目使用tsdf的方式进行三维重建，借助open3D实现可视化和模型生成，其首先根据置信度将深度图进行筛选，小于限定置信度的深度值设置为0，其次将视频处理成rgb帧，融合深度图里，借助相机内参和姿态进行三维重建。
基于kml线路生成路线规划文档 在野外工程采集中，一线工作人员为了记录所在方位与坐标，一般会对相关点做标记，最终导出成一个kml格式的文件，该文件记录了一系列工程点和路线，很多工程报告需要根据这些线路来对周边环境进行描述，如高压线路的铺设，野外测绘等，比较严谨的方案是结合最新的影像地图以及其它实测数据和规划数据，由相关人员进行撰写，最近在研究自动化的过程，手里的数据比较少，因此仅仅实现一个思路。一个测量点也可以被看作一个拐点，即线路走到这里会发生改变，因此需要找到附近的地物点及方向，以便加以描述。目的是将kml读取成可以解析的坐标。
模型单体化的顶点精简和空洞修复 针对上述问题，考虑对边缘的格网进行切割处理，使在模型内的部分保留，不在模型内的部分舍弃，由此可以推断，这种方式格网至少会和多边形边缘产生2个交点，由于2个以上交点的情况太过复杂，这里只针对普遍的两个交点的情况进行分析。由于分割点分布在模型的边缘，因此想要构建模型的四周墙面，需要利用分割点和建筑底部点，由于底部点不清晰，因此可以借助多边形的点，由于多边形在xy平面内，将该多边形沿Z轴平移到模型最底部，即可成为模型底部的范围点。这样导致的问题就是，处于分割边缘的三角格网，可能不会包含进来；
基于shp数据实现obj模型的切割（模型单体化思路） 由于obj模型包含顶点和纹理，而shp数据基本处于二维平面，那么需要考虑顶点落在shp面数据xy平面内的数据，同时，一个面最少由三个顶点构成，如果一个面的部分在shp范围内，部分在范围外，则需要重新分割，生成新的顶点并构建网格。由于每个材质对应了一部分三角格网数据，格网数据对应了相应的顶点和纹理坐标数据，因此在解析数据的时候以材质进行分类，先记录每个材质的相关信息，在根据材质读取对应的顶点坐标和纹理坐标，进行裁剪和划分。通常简单的obj数据包含顶点信息，纹理信息，面信息，有的obj还包含一个mtl文件。
arcEngine修改字段标注 在arcEngine中，有时候需要修改图层要素的标注值，而且每个字段值对应了要修改的内容，如字段值”1“替换成”A“，字段值”2“替换成”B“等，这就需要在替换的图层中，遍历每个要素，查到每个要素的原有标签值是多少，然后再根据标签值修改。实际上，这是在一个新的文件里建立了一个字典，字典里面编辑了原有标签和新标签的对应关系，至于为什么是要新建一个独立的文件，是因为后期好维护，要修改字典的话只需要在这个文件里进行编辑就行，不涉及其它逻辑代码，加上任意问价都可以引入调用。拿到原来标签的内容后，调用了一个。
指定要素高亮 arcEngine开发中，经常面临一个情况，就是查询到一个要素或指定一个要素的id，去让这个要素高亮，其实实现这个功能很简单，只不过基于arcEngine二次开发，需要熟悉它的官方文档才能找到这个方法，这里简单记录一下。
2.C程序和GCC编译器 退出保存之后，执行gcc hello.c 即可得到一个a.out文件，这是一个二进制可执行程序，将当前所写代码经过翻译得到计算器能够理解的代码，这个过程叫编译，过程所用到的工具叫编译器。
关注
