답변:
지리 기능은 PostGIS 2.2 이전의 WGS84에 항상 저장됩니다. 이후 임의의 lon / lat 기반 공간 참조 시스템이 사용될 수있다. 지리 피쳐 기반 측정은 CRS 단위 대신 미터 단위이며 PostGIS는 평면 형상 대신 측지 계산을 사용합니다.
모든 함수가 지오메트리를 지원하는 것은 아니지만 지오메트리와 지리간에 캐스트 할 수 있습니다. 현재 기능 목록은 https://postgis.net/docs/PostGIS_Special_Functions_Index.html#PostGIS_GeographyFunctions를 참조하십시오.
큰 데이터베이스에 지리 또는 기하학을 권장하는 것은 불가능하다고 생각합니다. 데이터로 무엇을하고 있는지에 따라 다릅니다. 구에 대한 계산이 더 복잡하기 때문에 지리 기능에 대한 분석 속도가 느려질 것으로 예상됩니다. 또한 지리를 사용하려면 모든 데이터를 WGS84로 변환해야합니다.
측정을 많이하고 큰 다각형의 크기를 비교해야하는 경우 형상보다는 지리학을 사용하는 것이 좋습니다.
나는 다음과 같은 유용한 것을 발견했다 : http://postgis.net/workshops/postgis-intro/geography.html
이 주제는 "PostGIS in Action"(ISBN : 9781935182269)에서도 다루고 있습니다.
직관적 인 "엄지 손가락 규칙"을 사용합니다. 빠른 결정에 유용합니다.
DATABASE 정보 : 기능 및 / 또는 공간 분석이 대륙 규모 이고 정밀 (심각한 응용 프로그램)이 필요한 경우 지리를 사용하십시오 . 그렇지 않으면 지오메트리 사용 : 모든 데이터베이스가 거의 같은 ( 도시 규모 ) 영역이거나 정밀도가 필요하지 않은 경우 지오메트리 만 필요합니다. @underdark 제안 강의
에서 유사한 규칙을 참조하십시오 .
PERFORMANCE / PRECISION BALANCE 측면에서 요구 사항 : 형상이 더 빠릅니다. 실적 이 필요 하고 지역을 사용하려는 경우 먼저 벤치 마크를 수행하십시오.
이 페이지에서 우리는 키워드, 정밀도 , 성능 및 유연성 / 사용 상품 과 같은 개념에 중점을 둡니다 .
다른 사람들이 기억 하듯이, 저장 및 계산의 차이점은 지리학에서의 구면과 기하학의 평면 사용입니다.
아마도 2020 년에 모든 GIS 데이터베이스는 동일한 표준 SRID / EPSG (현재 WGS84의 경우 4326 코드와 동일)로 설정 될 것입니다. 오늘날 지역은 성능 및 기능 제한으로 인해 기본 선택이 아닙니다.
내 생각에 그것은 기술 / 이론적 인 문제가 아니라 "모범 사례"에 관한 문제이다.
데이터의 오류를 추정 한 후 테스트를 수행하고 결과를 비교하십시오. 지리의 정확도 이득이 데이터 오류보다 높습니까? 이 ST_Distance (함수와 MAX 및 AVG 그리 게이터 ) 이런 종류의 실험에서 주요 기준이다.
평면형 UTM 좌표계에서 형상으로 저장된 ~ 100km2 (직경 ~ 11km)의 도시 지역 벤치 마크 예 . 참고 : 자주 사용되는 형상 / 지리 변환으로 시작합니다. 일부 기능은 존재하지 않으며 ST_Buffer 및 ST_Intersection과 같은 일부 기능은 내부적으로 변환하기 때문에 자주 사용됩니다.
벤치 # 1 : 도시 부지를 나타내는 ~ 87000 개의 다각형이있는 테이블 (각각 (avg) ~ 13 포인트)
BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geom AS
SELECT gid, the_geom FROM urbanlots; ROLLBACK;
-- time 2080 ms ~ 2.0 s
BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geog AS
SELECT gid, Geography(ST_Transform(the_geom,4326)) AS geog
FROM urbanlots; ROLLBACK;
-- time 12374 ms ~ 12.4 s ~ 6 * geometry.따라서 geography_time = 6 * geometry_time입니다.
벤치 # 2 : 도시 블록을 나타내는 ~ 3500 개의 폴리곤이있는 테이블 (각각 (avg) ~ 50 포인트 : 0.6s vs 2.7s, geography_time = 4.5 * geometry_time).
벤치 # 3 : 도시 거리를 나타내는 ~ 10000 개의 라인, 각각 ~ 5 포인트. ~ 0.87 초 대 ~ 0.36 초, geography_time = 2.4 * geometry_time.
벤치 # 2로 돌아가서 테이블 작성 및 쿼리 수행
EXPLAIN ANALYSE SELECT ST_Area(g.the_geom)+ST_Distance(g.the_geom,t.the_geom)
FROM temp_geom g, (SELECT the_geom FROM temp_geom WHERE gid=1) as t;
-- time 182 ms ~ 0.2 s
EXPLAIN ANALYSE SELECT ST_Area(g.geog)+ST_Distance(g.geog,t.geog)
FROM temp_geog g, (SELECT geog FROM temp_geog WHERE gid=1) as t;
-- time 58657 ms ~ 59 s ~ 300*geometry
-- curioselly for only distances, geography=4*geometry결론 : 작은 작업과 좋은 하드웨어의 경우 시간이 "허용 가능한 동일한 시간"으로 수렴되지만 큰 작업의 경우 고려해야 할 성능 등급이 있습니다.
벤치 마크에서 나는 매일 작업을 수행하고 포인트 수를 확인합니다 ( ST_NPoints) ... 지리에 존재하지 않는 캐스트가 필요한 작업의 예입니다. "지리 / 형상 캐스트"는 프로그래머, 마스터 등에 게 성가신 작업입니다.
SQL 및 PL / pgSQL 함수 라이브러리를 재사용 할 경우 지역에 적응이 필요합니다. 또한 코드를 최적화하거나 많은 중간 변환으로 인한 정밀한 문제를 피하려면 지리와 함께 완전한 내장 함수 집합이없는 것이 또 다른 문제입니다. 지리 프로그램은 쉬운 일이 아닙니다.
Mapserver와 같이 집중적 인 사용자가없는 비정기적인 요구의 경우, (PostGIS) 유일한 작업이 입력 데이터를 처리하고 처리 된 데이터를 언제든지 (시간 또는 일과 같이) 반환하는 경우, 경험에 따라 "지리를 사용합니다. 편안합니다! " (위의 "유연성 / 필수품"참조). 그렇지 않은 경우 일반적인 규칙을 확인하십시오.
참고 : 물론, (비정상적인) 작업에 PostGIS에서 Mapserver 로의 데이터 만 표시되는 경우, 프로세스없이 입력 데이터와 동일한 (기하학적 또는 지리적) 데이터를 보존하는 것이 더 나은 결정입니다.
나는 데이터의 중앙 집중화는 지리가 더 나은 다른 작업이라고 생각 : 맥락에서 다양한 입력 형식과 참조 시스템의 평소 있으며, 같은 지역에 의해 수행과 같은 표준의 사용이 도움이됩니다 ... 구성을 통해 협약 이다 중앙 집중화 및 데이터 교환이 비즈니스 중심 일 때 좋은 원칙입니다 (Google지도 참조).
ST_GeomFrom*하고 ST_As*, 특히 PostGIS와는 하나의 CRS에 쿼리를 수출하는 동안 변환을 처리시키는, 사용자 정의 CRS를 정의 할 수있는 기능과 결합, 매우 편리한 것 같습니다?
가장 중요한 차이점은 지리 유형을 사용하면 지오메트리 유형 피쳐에 대한 계산에 사용되는 평평한 표면과 달리 지구를 나타내는 구에서 계산이 이루어집니다.
문서는 꽤 좋습니다 : http://postgis.net/docs/manual-1.5/ch04.html#PostGIS_Geography
지역 유형이 최근에 추가되었으므로 지원 / 구현되는 기능이 더 적습니다.
어쩌면이 기능은 쓸모없고 답은 쓸모가 없지만 형상 작업의 장점 중 하나는 공간 참조없이 (즉, SRID가 -1로 설정 됨) 작업 할 수 있다는 것입니다.
현재 공기 중 LiDAR 데이터를 필터링하는 응용 프로그램에서 데이터 소스 중 PostGIS 데이터베이스가 있으며 PostGIS 데이터베이스는 일류 공간 색인 ( RTree over GiST )을 제공하고 문제없이 많은 양의 데이터에 대처합니다. 해당 애플리케이션에는 지리 기능을 조작하거나 분석 할 필요가 없으므로 SRID가 필요하지 않으므로 오버 헤드를 피할 수 있습니다.