Thực tiễn tốt nhất cho cơ sở dữ liệu và API với dữ liệu địa lý trải dài trên phản tuyến

Cách thực hành tốt nhất để lưu trữ các tính năng địa lý (đường, đa giác và các phần tương đương của chúng) là gì khi các tính năng này trải dài trên phản hạt (kinh độ ± 180 °), và cần được gửi đến và nhận từ các ứng dụng web của khách hàng như GeoJSON?

Tôi đang bắt đầu làm việc với API web phía máy chủ với sự hỗ trợ từ cơ sở dữ liệu Postgres / PostGIS để làm việc với các cơn bão nhiệt đới lịch sử và dự báo và bán kính gió. Nhiều cơn bão ở Thái Bình Dương có xu hướng đáng tiếc là vượt qua phản hạt, đôi khi nhiều lần trong vòng đời của chúng:

Là một người New Zealand sống gần antimonidian, tôi đã gặp vấn đề này thường xuyên đủ trong dữ liệu khu vực để có một số chiến lược đối phó, nhưng tôi thực sự muốn tìm hiểu xem điều gì được coi là thực hành tốt nhất. Thật không may, không có câu hỏi hiện tại được gắn thẻ antimeridian , vì vậy thật khó để tìm kiếm các câu hỏi liên quan. Những câu hỏi mà tôi đã thấy đấu tranh với vấn đề này dường như đang tìm kiếm lời khuyên rất cụ thể cho ứng dụng. Câu hỏi này thảo luận ngắn gọn về phản hạt đối với trường hợp đa giác GeoJSON kéo dài trái đất không có ranh giới. Câu hỏi này khá gần với những gì tôi đang hỏi.

Tôi cần lưu trữ các cơn bão lịch sử và dự báo trong cơ sở dữ liệu không gian, nhưng tôi dự đoán rằng sẽ có vấn đề với phản hạt. Chẳng hạn, một đường bắt đầu từ vĩ độ / kinh độ (0,179)và kết thúc tại (0,-179)không rõ ràng đối với hướng của nó: liệu nó có đi theo con đường ngắn xuyên qua phản tuyến hay "bao bọc" trên toàn hành tinh. Làm thế nào một đường dẫn như vậy nên được lưu trữ trong cơ sở dữ liệu không gian (cụ thể là tôi đang làm việc với PostGIS nhưng tôi hy vọng giải pháp này đủ chung chung)? Một số ý tưởng mà tôi có:

1. Không thay đổi tính năng hình học và chuyển sự mơ hồ sang các ứng dụng khách.
2. Tách bất kỳ tính năng nào đi qua antimeridian thành một hình học nhiều phần với sự phá vỡ ở antimeridian . ( Đặc tả GeoJSON hỗ trợ CRS có tên .)
3. Làm việc với các dự báo phi toàn cầu cho các lưu vực lốc xoáy hoặc vùng đại dương khác nhau không có sự gián đoạn như vậy
4. Khai thác thực tế là một cơn bão chưa bao giờ được quan sát thấy để di chuyển trên toàn hành tinh, lưu trữ tọa độ của các cơn bão bắt đầu trong phạm vi vĩ độ được (90,-90) bù bởi pha 360 ° (giữ cho các -180 khác180 ° khác)
5. Khai thác thực tế là một cơn bão cực kỳ khó xảy ra ở phía nam mũi phía nam châu Phi, hãy sử dụng một điểm dừng ở kinh độ 30 ° (như trong bản đồ trên).
6. Cho phép tọa độ mở rộng ra ngoài phạm vi hợp lệ của EPSG 4326 , ví dụ> 180 ° và <-180 ° cho bất kỳ tính năng nào vượt qua phản xạ.
7. Mã hóa Delta , như trong TopoJSON (ví dụ: bắt đầu tại (0,-179)và sau đó tọa độ tiếp theo là -3vĩ độ tây). Tôi không biết có nên thực hiện việc này khi lưu trữ dữ liệu trong PostGIS hay không, nhưng đây là một giải pháp tuyệt vời để gửi dữ liệu đến các ứng dụng khách.
8. Một số dạng ký hiệu vector hoặc tọa độ cực. (Có vẻ khá khó khăn và bất thường.)

Trong số này, tôi không thích ý tưởng 2 Ném5 vì chúng không chung chung, nhưng tôi thích chúng vì chúng có ý nghĩa đối với ứng dụng cụ thể của tôi. Đối với các ứng dụng chỉ xử lý dữ liệu ở Thái Bình Dương, chúng có thể có nhiều ý nghĩa, vì vậy tôi không muốn giảm giá hoàn toàn chúng dưới dạng tùy chọn.

Ý tưởng 6 và 7 đã được gỡ bỏ từ blog của Tom MacWright , đáng để đọc nhưng không được kết luận liên quan đến phản hạt.

Ý tưởng 4 được GeographicaGSGeodesicLinesToGISPython sử dụng , lần lượt được sử dụng fiona.transform.transform_geomvới độ lệch phản xạ 360 °. Đổi lại, Fiona đang sử dụng OGR -wrapdateline. Tôi cho rằng đó là một tiền lệ rất vững chắc và thực sự khá chung chung.

Cùng với vấn đề lưu trữ, tôi cần xem xét cách gửi các tính năng như vậy đến các ứng dụng khách và cách ứng dụng của tôi nên xem xét dữ liệu được gửi lại cho nó (ví dụ như một người dự báo con người thay đổi theo dõi dự báo về lốc xoáy ở Thái Bình Dương). Định dạng trao đổi có thể sẽ là GeoJSON, nhưng không phải như vậy.

Thật không may, đặc điểm kỹ thuật của GeoJSON không rõ ràng về các vấn đề đối nghịch. Điều này từ Wikipedia :

Nhiều thư viện phần mềm địa lý hoặc định dạng dữ liệu chiếu thế giới thành một hình chữ nhật; rất thường hình chữ nhật này được phân chia chính xác tại kinh tuyến 180. Điều này thường làm cho không thể thực hiện các tác vụ đơn giản (như đại diện cho một khu vực hoặc một đường) trên kinh tuyến thứ 180. Vài ví dụ:

• Đặc tả GeoJSON không đề cập đến việc xử lý kinh tuyến thứ 180 trong thông số kỹ thuật của nó, như vậy, việc biểu diễn các đường ngang qua kinh tuyến thứ 180 cũng có thể được hiểu là đi khắp thế giới.

• Trong OpenStreetMap, các khu vực (như ranh giới của Nga) được phân chia tại kinh tuyến thứ 180.

Tôi đọc được rằng GeoJSON không có đại diện tiêu chuẩn cụ thể nào cho các tính năng kéo dài phản xạ và nó được cố tình để lại mơ hồ (hình học đa phần có thể sẽ giải quyết vấn đề). Tương tự như vậy trong OpenStreetMap, có các phân chia hình học tại phản tuyến, mặc dù tôi không biết các tính năng phân chia như vậy có phải là nhiều phần hay thực sự là các bản ghi rời rạc.

Điều này cảm thấy khá có vấn đề, đặc biệt là từ góc độ tạo hộp giới hạn hoặc các yêu cầu không gian khác trải dài trên dòng này, mà còn trong việc phân tích cú pháp và vệ sinh đầu vào và bất kỳ cập nhật nào cho hình học. Đây là lý do tại sao tôi đang cố gắng xác định một thực tiễn tốt nhất mà tôi có thể tìm cách tuân thủ.

Nói hoàn toàn từ góc độ lưu trữ và phân tích dữ liệu, geographyloại dành cho PostGIS được thiết kế với ý tưởng phản đối (trong số một số mục tiêu thiết kế). Có một số chức năng được thiết kế đặc biệt cho geographyloại .

Chẳng hạn, hãy xem xét một LineString trên toàn Taveuni, Fiji ( được ánh xạ với Great Circle Mapper ), nằm trên đường đối nghịch:

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

Chiều dài của trắc địa này là khoảng 46 km. Tương tự, ST_Area sẽ hoạt động chính xác trên Đa giác của đảo, ngay cả khi tọa độ kinh độ nhảy trong khoảng từ +179 đến -179.

Truyền một EPSG: 4326 geometrycho một geographyloại cũng bình thường hóa tọa độ, ví dụ kinh độ của tọa độ cuối cùng là> 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]]}

được chuyển đổi trở lại cùng geographyloại chính xác trong ví dụ đầu tiên, nhưng bây giờ với đầu ra GeoJSON. Bạn có thể chọn bỏ qua THÔNG BÁO (hoặc ví dụ SET client_min_messages TO WARNING;) và chuyển đổi tất cả các loại hình học trông buồn cười thành geographycác loại.

Hiển thị geographycác loại trên bản đồ bên ngoài PostGIS là một câu chuyện khác và hy vọng câu trả lời tốt hơn sẽ chạm vào khía cạnh này.

Chắc chắn, câu trả lời ưa thích là (1), tức là có khách hàng thực hiện "điều đúng". Một trường hợp tốt để xem xét là đa giác đại diện cho lục địa Nam Cực xấp xỉ bởi tệp kml này

<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>

Mã hóa hoặc dịch chuyển Delta khi xảy ra phá vỡ kinh độ sẽ không giúp ích cho dữ liệu như thế này. Làm việc với nó một phép chiếu cụ thể cho Nam Cực sẽ hoạt động, nhưng đây không phải là một giải pháp chung.

Thật ngạc nhiên, Google Earth Pro không hiển thị chính xác đa giác này (trừ khi bạn sử dụng chế độ "phác thảo"). Xem tại đây