반 자오선에 걸친 지리 데이터가있는 데이터베이스 및 API에 대한 모범 사례

자오선 (± 180 ° 경도)에 이르고 GeoJSON으로 클라이언트 웹 응용 프로그램에서 보내고받을 필요가있을 때 지리적 지형 (선, 다각형 및 여러 부분으로 된 등가)을 저장하는 가장 좋은 방법은 무엇입니까?

과거 및 예측 열대 저기압 트랙 및 바람 반경을 다루기 위해 Postgres / PostGIS 데이터베이스를 지원하여 서버 측 웹 API 작업을 시작하고 있습니다. 태평양의 많은 사이클론은 불행히도 반 자오선을 가로 지르는 경향이 있습니다.

반 자오선 근처에 살고있는 뉴질랜드 인으로서, 지역 데이터에서 대처 전략을 가질만큼이 문제를 자주 겪었지만 실제로 모범 사례로 생각되는 부분을 찾고 싶습니다. 불행히도 antimeridian 태그가 지정된 기존 질문이 없으므로 관련 질문을 찾기가 어렵습니다. 이 문제를 해결하는 데 보인 질문은 모두 응용 프로그램 별 조언을 찾는 것으로 보입니다. 이 질문 은 경계가없는 지구 스패닝 GeoJSON 다각형의 경우에 대한 자오선을 간단히 설명합니다. 이 질문 은 내가 요구하는 것에 매우 가깝습니다.

기록 및 예측 사이클론을 공간 데이터베이스에 저장해야하지만 반 자오선에 문제가있을 것으로 예상합니다. 예를 들어 위도 / 경도로 시작하여 (0,179)끝나는 선 (0,-179)은 방향에 대해 모호합니다. 이러한 경로는 공간 데이터베이스에 어떻게 저장해야합니까 (특히 PostGIS로 작업하고 있지만 솔루션이 충분히 일반적이기를 바랍니다)? 내가 가진 몇 가지 아이디어 :

1. 기능 형상을 변경하지 말고 모호성을 클라이언트 응용 프로그램으로 이동하십시오.
2. 자오선 을 가로 지르는 자오선 을 가로 지르는 자오선 을 가로 지르는 형상을 여러 부분 으로 나눕니다 . ( GeoJSON 사양 지원은 CRS를 이름 .)
3. 이러한 불연속성이없는 다른 사이클론 유역 또는 해양 지역에 대한 비전 역 투영 작업
4. 사이클론이 지구 전체를 돌아 다니는 것이 결코 관찰되지 않았다는 사실을 악용하여 (90,-90) 360 ° 위상으로 오프셋 된 위도 범위에서 시작하는 사이클론 좌표를 저장합니다 (다른 것들은 -180–180 ° 유지).
5. 사이클론이 아프리카의 남쪽 끝에서 매우 남쪽에있을 가능성이 거의 없다는 사실을 악용하려면 위의지도와 같이 경도 30 °에서 휴식을 취 하십시오.
6. 허용 좌표 EPSG 4326의 유효 범위를 넘어 확장하는 자오선을 전달되는 기능에 대한 예> 180 및 <-180 °.
7. TopoJSON에서와 같이 델타 인코딩 (예 : 시작하여 (0,-179)다음 좌표는 -3위도 서쪽)입니다. PostGIS에 데이터를 저장할 때 이것을 구현할지 여부 또는 방법을 모릅니다. 그러나 이것은 클라이언트 응용 프로그램으로 데이터를 보내기위한 훌륭한 솔루션입니다.
8. 어떤 형태의 벡터 표기법 또는 극좌표. (어려우며 특이한 것 같습니다.)

이 중 일반적인 아이디어가 아니기 때문에 아이디어 2-5는 마음에 들지 않지만, 특정 애플리케이션에 적합하기 때문에 아이디어가 마음에 듭니다. 태평양 지역의 데이터만을 다루는 응용 프로그램의 경우 많은 의미가있을 수 있으므로 옵션으로 완전히 할인하고 싶지는 않습니다.

아이디어 6과 7은 Tom MacWright의 블로그 에서 가져 왔습니다.이 기사 는 읽을 가치가 있지만 반 자오선 과 관련하여 결정적인 것은 아닙니다.

Idea 4는 GeographicaGS 'GeodesicLinesToGISPython 에서 사용 fiona.transform.transform_geom되며 360도 자오선 오프셋과 함께 사용 됩니다. Fiona는 OGR을 사용하고 -wrapdateline있습니다. 나는 그것이 매우 견고한 선례이며 실제로는 일반적인 것이라고 가정합니다.

스토리지 문제와 관련하여 이러한 기능을 클라이언트 애플리케이션으로 전송하는 방법과 애플리케이션에서 다시 게시 된 데이터를 고려해야하는 방법을 고려해야합니다 (예 : 태평양의 사이클론 예측 트랙을 변경하는 사람 예측기). 교환 형식은 아마도 GeoJSON 일 것이지만 반드시 그럴 필요는 없습니다.

불행히도 GeoJSON 사양은 반 자오선 문제에 대해 명시 적이 지 않습니다. 에서이 위키 백과 :

많은 지리 소프트웨어 라이브러리 또는 데이터 형식은 세계를 직사각형으로 투영합니다. 이 사각형은 매우 자주 180 번째 자오선으로 나뉩니다. 이것은 종종 180 번째 자오선을 통해 간단한 작업 (영역 또는 선을 나타내는 것과 같은)을 수행하는 것을 불가능하게합니다. 몇 가지 예 :

• GeoJSON 사양은 사양에서 180 번째 자오선 처리에 대해 언급하지 않았으며, 180 번째 자오선을 가로 지르는 선의 표현은 세계를 돌아 다니는 것으로 해석 될 수 있습니다.

• OpenStreetMap에서 (러시아 경계와 같은) 영역은 180 번째 자오선에서 분할됩니다.

필자는 GeoJSON에 자오선 확장 기능의 특정 표준 표현이 없으며 의도적으로 모호하게 남아 있습니다 (여러 부분의 기하학적 구조로 인해 문제가 해결 될 수 있음). 마찬가지로 OpenStreetMap에는 반 자오선에 지오메트리 분할이 있지만, 그러한 분할 피처가 다중 부분인지 실제로 불연속적인 레코드인지는 알 수 없습니다.

이것은 특히 경계선 또는이 라인에 걸쳐있는 다른 공간 요청을 만드는 관점에서나 입력과 피처 지오메트리에 대한 업데이트를 구문 분석하고 살균하는 관점에서 다소 문제가 있습니다. 이것이 내가 따라야 할 모범 사례를 결정하려는 이유입니다.

데이터 스토리지 및 분석 관점에서 순수하게 말하면 geographyPostGIS 의 유형은 여러 설계 목표 중에서 반 자오선을 염두에두고 설계되었습니다. 유형에 맞게 특별히 설계된 몇 가지 기능geography 이 있습니다 .

예를 들어, 피지의 타베 우니 ( Taveuni) 피지 ( 그레이트 서클 매퍼로 매핑)를 가로 지르는 라인 스트링을 생각해보십시오 .

SELECT ST_Length('LINESTRING(179.9 -17, -179.8 -16.7)'::geography);

이 측지선 의 길이 는 약 46km입니다. 마찬가지로 ST_Area는 경도 좌표가 +179와 -179 사이에서 점프하더라도 섬의 다각형에서 올바르게 작동합니다.

EPSG : 4326 geometry을 geography유형으로 캐스팅 하면 좌표가 정규화됩니다. 예를 들어 마지막 좌표의 경도는> 180입니다.

SELECT ST_AsGeoJSON('LINESTRING (179.9 -17, 180.2 -16.7)'::geography);

NOTICE:  Coordinate values were coerced into range [-180 -90, 180 90] for GEOGRAPHY
                           st_asgeojson
------------------------------------------------------------------
 {"type":"LineString","coordinates":[[179.9,-17],[-179.8,-16.7]]}

geography첫 번째 예에서 정확히 동일한 유형 으로 다시 변환 되지만 GeoJSON 출력 으로 다시 변환됩니다 . NOTICE (또는 예 SET client_min_messages TO WARNING;) 를 무시하고 모든 종류의 재미있는 모양을 geography유형 으로 변환 할 수 있습니다.

geographyPostGIS 외부의지도에 유형을 표시 하는 것은 다른 이야기이며 더 나은 답변 이이 측면에 영향을 미치기를 바랍니다.

분명한 대답은 (1) 즉, 고객이 "올바른 일"을하도록하는 것입니다. 고려해야 할 좋은 사례는이 kml 파일로 근사한 남극 대륙을 나타내는 다각형입니다.

<kml> <Folder> <name>Antarctica</name> <Placemark> <name>Antarctica</name> <Polygon> <tessellate>1</tessellate> <outerBoundaryIs> <LinearRing> <coordinates> -58,-63.1,0 -74,-72.9,0 -102,-71.9,0 -102,-74.9,0 -131,-74.3,0 -163,-77.5,0 163,-77.4,0 172,-71.7,0 140,-65.9,0 113,-65.7,0 88,-66.6,0 59,-66.9,0 25,-69.8,0 -4,-70,0 -14,-71,0 -33,-77.3,0 -46,-77.9,0 -61,-74.7,0 -58,-63.1,0 </coordinates> </LinearRing> </outerBoundaryIs> </Polygon> </Placemark> </Folder> </kml>

경도 나누기가 발생하는 델타 인코딩 또는 이동은 이와 같은 데이터에는 도움이되지 않습니다. 그것을 남극 대륙에 특정한 투영으로 사용하면 효과가 있지만 이것은 일반적인 해결책이 아닙니다.

놀랍게도, Google 어스 프로는 "개요"모드를 사용하지 않는 한이 다각형을 올바르게 표시하지 않습니다. 여기를 봐