Questions tagged «postgis»

PostGIS是PostgreSQL对象关系数据库的扩展,增加了对地理对象的支持。

5
优化OSM数据的osm2pgsql导入
我目前正在EC2上构建一个实例,在该实例上导入我们正在研究的某些项目的整个Planet.osm快照,其中包含了整个地球数据的价值。我已经启动了一个大型的Ubuntu x64实例,并在Postgres数据库的EBS卷上附加了大量单独的存储,并对其进行了修改以在其中容纳PGSQL数据。 现在服务器osm2pgsql在导入快照时遇到了麻烦。在尝试了几次不同的内存配置和其他操作之后,该过程在完成大部分操作后仍然输出“ Killed”。一旦它在“遍历未决方式”时被杀死,下一次,在稍微调整了细长缓存之后,它到达了“处理方式”,然后崩溃了。根据我的阅读,这通常是由于内存问题造成的。 这是我最近一次运行导入的尝试: osm2pgsql -v -U osm -s -C 4096 -S default.style -d osm /data/osm/planet-latest.osm.bz2 以下是EC2上大型实例的规格: 大型实例7.5 GB内存,4个EC2计算单元(2个虚拟内核,每个虚拟内核各具有2个EC2计算单元),850 GB本地实例存储,64位平台 我的问题是-是否有一些好的基准测试资源来确定osm2pgsql和Postgres的调优要求?导入速度对我来说并不那么重要,我只是想确保过程安全完成,即使需要4到5天...我已经阅读了Frederick Ramm的“ 优化渲染”去年的SOTM中的“ 链 ”(PDF)文件,但是还有其他好的意见/资源吗?

9
使用R中的PostGIS数据?
我几乎一直都在使用R,现在我正在使用它进行空间数据挖掘。 我有一个(显然)GIS数据的PostGIS数据库。 如果我想进行统计空间分析和绘图,则是以下更好的方法: 将表格导出为shapefile或; 直接工作到数据库?
27 postgis  postgresql  r 

2
地理数据跨越antimeridian的数据库和API的最佳做法
当这些地理特征(线,面和它们的多部分等价物)跨越时线(经度±180°)并且需要作为GeoJSON发送到客户端Web应用程序并从客户端Web应用程序接收时,最佳做法是什么? 我将开始在服务器端Web API上进行工作,并获得Postgres / PostGIS数据库的支持,以处理历史和预报的热带气旋轨道和风半径。不幸的是,太平洋上的许多气旋都有越过沙漏的趋势,有时在生命周期内多次发生: 作为居住在后脚区附近的新西兰人,我经常在区域数据中经常遇到此问题,以制定一些应对策略,但是我想实际找出什么是最佳实践。不幸的是,目前没有标记为antimeridian的问题,因此很难搜索相关问题。我所看到的那些困扰该问题的问题似乎都在寻求针对特定应用的建议。这个问题简要讨论了跨越地球的GeoJSON多边形无边界情况下的反子午线。这个问题很接近我的要求。 我需要将历史和预报的气旋存储在空间数据库中,但我希望反高度子集会出现问题。例如,一条线从纬度/经度开始,在其方向(0,179)结束时(0,-179)是不明确的:无论是经过小子午线的短路径,还是“包裹”整个星球。这样的路径应如何存储在空间数据库中(特别是我正在使用PostGIS,但我希望解决方案足够通用)?我有一些想法: 无需更改要素几何并将模糊性转移到客户端应用程序。 将跨越子午线的任何特征分割为多部分几何,并在子午线处断开。(GeoJSON规范支持命名的CRS。) 使用不具有这种不连续性的不同旋风盆地或海洋区域的非全局投影 利用从未观察到旋风绕着整个行星传播这一事实,存储旋风的坐标,该旋风的坐标从纬度范围开始(90,-90) 偏移了360°相位(保持其他-180-180°) 利用一个事实,即在非洲南端以南极不可能发生气旋,请使用经度为30°的中断(如上图所示)。 允许坐标超出EPSG 4326的有效范围,例如,对于任何通过后向子午线的要素,> 180°且<-180°。 Delta编码,例如在TopoJSON中(例如,始于,(0,-179)然后下一个坐标为-3西纬)。我不知道在PostGIS中存储数据时是否或如何实现此功能,但这是将数据发送到客户端应用程序的绝佳解决方案。 矢量符号或极坐标的某种形式。(似乎相当困难和不寻常。) 其中,我不喜欢想法2–5,因为它们不是通用的,但是我喜欢它们,因为它们对我的特定应用程序有意义。对于仅在太平洋中处理数据的应用程序,它们可能很有意义,因此我不希望完全打折。 想法6和7是从汤姆·麦克赖特(Tom MacWright)的博客中提出的,该博客值得一读,但对于antimeridian而言并不确定。 Idea 4由GeographicaGS'使用GeodesicLinesToGISPython,而后者又使用fiona.transform.transform_geom了360°的时间偏移。反过来,Fiona正在使用OGR的-wrapdateline。我认为这是一个非常坚实的先例,实际上是相当普遍的。 结合存储问题,我需要考虑应如何将此类功能发送到客户端应用程序,以及我的应用程序应如何考虑回传到该应用程序的数据(例如,人类预报员更改了太平洋气旋的预报轨迹)。交换格式可能是GeoJSON,但不是必须的。 不幸的是,GeoJSON规范并未明确涉及时间轴问题。来自维基百科: 许多地理软件库或数据格式将世界投影到一个矩形。通常,此矩形正好在第180个子午线上精确地分割。这通常使得不可能在第180个子午线上执行简单的任务(例如表示一个区域或一条线)。一些例子: GeoJSON规范在其规范中并未提及对第180条子午线的处理,因此,跨越第180条子午线的线的表示也可以解释为遍历世界。 在OpenStreetMap中,区域(例如俄罗斯边界)在第180个子午线上被分割。 我的理解是,GeoJSON没有特定的跨时间跨度特征的标准表示形式,并且故意将其含糊不清(多部分几何形状可能会解决此问题)。类似地,在OpenStreetMap中,后子午线处有几何划分,尽管我不知道这样的拆分要素是多部分的还是实际上是离散的记录。 这带来了相当大的问题,尤其是从提出跨越此线的边界框或其他空间请求的角度而言,而且在解析和清理输入以及对要素几何的任何更新方面也是如此。这就是为什么我试图确定我可以寻求遵循的最佳实践的原因。

2
ST_Distance()中使用的单位是什么?
我想知道从中返回浮点数的单位是什么ST_Distance。 在文档中说: ...以投影单位表示的两个几何之间的笛卡尔最小距离(基于空间参考)。 这些预计单位是什么? 几何存储在一个字段中:geometry(Point,4326)。

3
如何在PostGIS中创建新的“ gis”数据库?
我想在PostGIS中创建一个新数据库,以便可以在使用当前数据库时将内容加载到其中。根据文档 一些PostGIS的打包发行版(特别是WinGIS安装程序> = 1.1.5)将PostGIS函数加载到名为template_postgis的模板数据库中。如果您的PostgreSQL安装中存在template_postgis数据库,则用户和/或应用程序可以使用单个命令创建启用空间的数据库。 在我看来,情况并非如此: $ createdb -T template_postgis my_spatial_db createdb: database creation failed: ERROR: template database "template_postgis" does not exist 过去,我一直在搞怪复制主gis数据库,然后删除所有表的内容。肯定有更好的办法。如果不小心掉了怎么办?

2
寻求算法来检测圆以及圆的起点和终点?
我从固定滑翔机飞行员那里获得了许多飞行数据,这些数据以固定间隔的gps修复的形式出现。我想分析飞行路径,并检测滑翔机飞行员在发现热量时将进行的“绕圈”的开始和结束。 理想情况下,一种算法将为我提供直线上的起点和终点,从而定义一个“圆”。这些点可以等于gps修复之一,不需要插值。 我只是可以沿着飞行路线行走,检查转弯速率,并有一些标准来确定滑翔机是否在盘旋。 当我使用带有PostGIS扩展名的PostgreSQL时,我很好奇是否有更好的方法可以解决此问题。我已经有一个过程来计算两个线段的角度: CREATE OR REPLACE FUNCTION angle_between( _p1 GEOMETRY(PointZ,4326), _p2 GEOMETRY(PointZ,4326), _p3 GEOMETRY(PointZ,4326) ) RETURNS DECIMAL AS $$ DECLARE az1 FLOAT; az3 FLOAT; BEGIN az1 = st_azimuth(_p2,_p1); az3 = st_azimuth(_p2,_p3); IF az3 > az1 THEN RETURN ( degrees(az3 - az1)::decimal - 180 ); ELSE RETURN ( degrees(az3 - …

2
在一个PostGIS表中混合几何类型
我面临以下问题。我必须从Oracle数据库迁移到PostgreSQL + PostGIS。当前,所有类型的所有几何形状都存储在一个表中,并且每个记录都包含一个“盖”字段,该字段指示同一图层的要素。 使用这种方法的优缺点是什么?如果不需要将数据库与第三方软件一起使用,是否应该将数据分成多个表?空间查询的性能如何,索引对我有帮助吗?


5
ogr2ogr的替代方案,用于将大型GeoJson文件加载到PostGIS
我有一个7GB的GeoJson文件,我想将其加载到PostGIS数据库中。我曾尝试使用ogr2​​ogr,但由于文件太大而无法加载到内存中然后进行处理,因此失败了。 是否有其他替代方法可以将此geojson文件加载到PostGIS中? 我收到的ogr2ogr错误是: 错误2:CPLMalloc():内存不足,分配-611145182字节。该应用程序已请求运行时以一种异常方式终止它。请与应用程序的支持团队联系以获取更多信息。

5
如何简化可路由网络?
从减少边数的角度来看,我有一个网络图需要简化。想法是合并位于一起的节点并删除连接的短边。 在PostGIS或GRASS中如何实现?还是有更好的方法来自动简化这样的网络? 我已经尝试过ST_SnapToGrid函数,但对结果不满意(灰色=原始,黑色=贴紧):

4
使用PostGIS简化相邻的多边形?
我在简化一组相邻的多边形时遇到了一个问题。如果我使用Douglas-Peucker算法(许多开放源代码工具都使用过的算法)分别简化每个多边形,则生成的多边形通常不再相邻。例如,在简化国家/省的边界时会出现此问题。 有人使用PostGIS有解决方案吗?

1
使用PostGIS拓扑将各层与各个元素结合在一起
我目前正在使用PostGIS拓扑扩展,但是在理解结构的工作方式方面有些困难: 关键点之一是“层”的使用:据我所知,要素属性应该存储在拓扑架构(称为topo_actualname)之外的表中,并使用进行注册为该拓扑的一层AddTopoGeometryColumn。 然而,有一个简单的方式加入与相应的特征(在元件中的属性(存储在表层)node,face或edge_data)? 现在,我要做的是: SELECT whatever FROM layer_tb l JOIN topo_topologyname.edge_data e ON (l.topo).id=edge_id; 但是我想layer如果我必须同时了解拓扑架构名称和层名称来获取所需信息,那么整个概念将毫无用处。 实际上,我认为我理解topo该层上的列具有足够的信息来了解各个拓扑的位置,并且该topology模式还存储了对每个拓扑的每个层表的引用。 是否有简短/简单/正确的方式将信息连接在一起?我在拓扑扩展功能中寻找某些东西,但是找不到有用的东西。


4
对于农产品农场应用而言,PostGIS是否会比MySQL提供优势?
我有一个Web应用程序,用于存储西密歇根州农场的位置。您可以搜索产品(例如“西兰花”),它将向您显示所有种植该产品的农场。 现在,我正在使用MySQL并使用三角函数来计算用户位置和每个服务器场的位置之间的差异。这不是一个坏方法,但确实需要做一些事情。 我很快想做的另一件事是为不同地区的不同产品制定生长季节。(例如,我想证明鳄梨在加利福尼亚的某个特定时间生长,但在俄亥俄州却没有。) 我意识到这是一个开放性的问题,并且可能是幼稚的问题,但是对我来说,转向PostgreSQL / PostGIS以利用其空间功能是否值得?

3
在PostGIS中存储大型栅格并在QGIS中进行可视化会降低性能
我的问题是与PostgreSQL,PostGIS,QGIS和GDAL一起使用的几种软件工具的使用和性能有关。 我是ArcGIS,Python和R的长期用户,他对使免费开源GIS生态系统和Linux多样化感兴趣。最近,我对将QGIS(版本2.8)与PostgreSQL(版本9.4)和PostGIS(版本2.1)一起使用非常感兴趣,并且我已在装有Windows 8.1 x64的计算机上安装了该软件(简要的计算机规格:ThinkPad配备2.1GHz核心2、8GB RAM和240GB SSD的X200)。学习了如何管理空间数据(价值约100GB)后,我想在此计算机上运行Ubuntu。 目前,我只是试图可靠地存储和检索shapefile和栅格。到目前为止,我已经成功地将shapefile加载到PostGIS中,但是栅格被证明存在更多问题。我已经成功完成了小的geoTIFF和GRID文件的单次和批量导入,但是较大的栅格(例如,磁盘上大小为870MB的15619x14655单元IMG或TIFF文件)需要永久加载到PostGIS中。我已经阅读并配置了raster2pgsql工具,以使用以下参数构建空间索引并通过图块加载栅格: raster2pgsql -s 3161 -C -I D:\PostGIS_data\dem.img -t auto raster.dem | psql -h localhost -U postgres -p 5432 -d postgres 导入性能仍然很差,并且硬件不是问题。QGIS中PostGIS栅格的可视化甚至更糟,充其量只能缓慢加载小栅格或完全冻结。像我提到的那样的大型栅格无法在QGIS中可视化。从文档和论坛讨论中,该缺陷似乎是由于GDAL的PostGIS栅格驱动程序而不是QGIS本身引起的。论坛讨论中简要提到了这个问题,甚至有人建议不应将栅格存储在PostGIS中(空间数据库中不能平滑处理栅格的意义是什么?)。但是,我通常使用ESRI的文件地理数据库来快速,轻松地存储,可视化和分析相当大的栅格(〜70GB),而ArcGIS 10.1绝不会因这种常规操作而冻结或变慢。 这里有我想念的东西吗?我还没有解决瓶颈?PostgreSQL是否需要进行调整以实现PostGIS的性能优势?我是否缺少寻找和编译所需的GDAL版本?如何改善Shapefile和栅格的QGIS中的PostGIS性能和可视化?如何通过Linux终端享受全面,快速的空间数据管理的荣耀?在这个问题上的任何帮助都将受到欢迎! 我按照Duncan Golicher的指南进行操作:https://duncanjg.wordpress.com/2012/11/20/the-basics-of-postgis-raster/ 我最初使用的是具有自动设置的图块,但我将图块重置为每行100x100个像元,然后按照指南中的说明添加了金字塔,如下所示: raster2pgsql -s 3161 -d -C -I -M -l 4 D:\PostGIS_data\dem.img -t 100x100 raster.dem100 | psql -h localhost -U …

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.