常用的GIS空间索引包括但不限于以下几种：R树（R-tree）：用于多维数据的空间索引，适用于范围查询和近邻查询等操作。Quadtree（四叉树）：将空间划分为四个象限，适用于二维空间数据的索引。KD树（KD-tree）：将多维空间数据递归地划分为𝑘k维空间的子空间，适用于𝑘k维空间数据的索引。Grid索引：将空间数据划分为规则网格进行索引，适用于简单地理区域划分和索引。Z树（Z-order curve）：将多维数据映射到一维空间的索引结构，适用于提高空间数据访问性能。
数据支持栅格数据arcgridgeotiffgrassrasterimage ( JPEG TIFF GIF PNG)imageio-ext-gdalimagemosaicimagepyramidJP2Kmatlab矢量数据格式wktcsvwkbgeojsonshapefile数据库支持db2hanah2mysqloraclepostgissqlserverelastic searchGEOSERVER输出格式图层预览页面支持多种输出格式，以供进一步使用或数据共享。可以预览公共Openlayers和KML格式中的所有三种图层类型。同样，使用“所有格式”菜单，您可以以七种附加输出格式预览所有图层类型：atompub、gif、georss、jpeg、kml（压缩）、pdf、png、svg和tiff。只有向量层提供WFS输出预览，包括通用GML以及csv、gml3、geojson和shapefile格式。下表简要说明了按输出类型（图像、文本或数据）组织的所有支持的输出格式。图像输出所有图像输出都可以从WMS GETMAP请求对栅格、矢量或覆盖数据启动。WMS是一种方法，它允许可视化地
DE-9IM 空间关系模型转：https://www.cnblogs.com/oloroso/p/14298258.html目录DE-9IM 空间关系模型简述空间关系相交（Intersects）关系图解包含（Contains ）横跨（Crosses）等于（Equals）重叠（Overlaps）触碰（Touches）被包含（Within）DE-9IM 模型简述#DE-9IM 是Dimensionally Extended 9-Intersection Model 的缩写，直接翻译为 维度扩展的 9 相交模型好像比较别扭，但一时也找不到比较好的翻译。DE-9IM 模型是用于描述两个 二维几何对象（点、线、面） 之间的空间关系的一种模型，它使用一个 3 x 3 的矩阵来描述几何关系类别（相交部分的维度）。网上很多关于 DE-9IM 的介绍都是翻译自 https://en.wikipedia.org/wiki/DE-9IM 或者 GeoTools/userguide/dim9 等文档的，我这里就不做这些翻译了。因为要给别人讲述清楚这个东西，所以自己总结了下，在这里做个记录。空间关系#这里主要是
备份特定范围数据备份schemapg_dump -U postgres -d postgres --schema=public > back1.sql备份指定表pg_dump -U postgres -d postgres -t public.t_oil >t_oil.sql另外还有其他几个常用参数：pg_dump -U postgres -W -F t dvdrental > c:\pgbackup\dvdrental.tar-U postgres 指定用户连接数据库服务器，这里是 postgres-W 强制 pg_dump 在连接数据库服务器之前提示密码-F 指定输入文件格式：c: 自定义归档文件格式d: 目录方式归档，创建目录包括每个表对应一个文件t: tar压缩文件格式p: 普通SQL文本备份其他数据库对象通过 pg_dumpall 命令备份全部数据库对象：pg_dumpall -U postgres > c:\pgbackup\all.sql仅备份scheam定义：pg_dumpall --schema-only > c:\pgdump\defi
go语言一个大的语言特色就是goroutine协程，而和很多同事沟通的时候，他们都认为goroutine很快，今天我们就来看一看goroutine是如何运行的。MPG模型go使用的是MPG模型，意思是通过一个全局的调度器来实现goroutine协程的调度，来达到通过分配平均使用CPU资源。go的调度器有3个重要的结构，M(OS线程)、P(协程调度器),G(goroutine协程)M(OS线程)：是操作系统的线程，一个程序可以模拟出多个线程。P(逻辑处理器or协程调度器)：这个一个专门调度goroutine协程的逻辑处理器，或者称为协程调度器都可以。G(goroutine协程)：goroutine协程。用户空间线程和内核空间线程之间的映射关系有：N:1、1:1和M:NN:1，多个（N）用户线程始终在一个内核线程上跑，context上下文切换确实很快，但是无法真正的利用多核。1:1，一个用户线程就只在一个内核线程上跑，这时可以利用多核，但是上下文switch很慢。M:N，多个goroutine在多个内核线程上跑，这个看似可以集齐上面两者的优势，但是无疑增加了调度的难度。而go使用的就是M:
Xinbo
