แนวทางปฏิบัติที่ดีที่สุดสำหรับฐานข้อมูลและ API ด้วยข้อมูลทางภูมิศาสตร์ที่ขยายแอนติเมริเดียน

แนวปฏิบัติที่ดีที่สุดสำหรับการจัดเก็บคุณลักษณะทางภูมิศาสตร์ (เส้นรูปหลายเหลี่ยมและเทียบเท่าหลายส่วน) เมื่อคุณสมบัติเหล่านี้ครอบคลุม antimeridian (± 180 °ลองจิจูด) และต้องถูกส่งไปและรับจากเว็บแอปพลิเคชันลูกค้าเป็น GeoJSON

ฉันเริ่มทำงานกับเว็บ API ฝั่งเซิร์ฟเวอร์ด้วยการสนับสนุนจากฐานข้อมูล Postgres / PostGIS เพื่อทำงานกับแทร็กไซโคลนเขตร้อนและประวัติศาสตร์และพยากรณ์ลม พายุไซโคลนจำนวนมากในมหาสมุทรแปซิฟิกมีแนวโน้มที่จะโชคร้ายที่จะข้ามแอนติเมริเดียนซึ่งบางครั้งก็มีอายุการใช้งานหลายครั้ง:

ในฐานะชาวนิวซีแลนด์ที่อาศัยอยู่ใกล้กับ antimeridian ฉันพบปัญหานี้บ่อยครั้งในข้อมูลระดับภูมิภาคที่จะมีกลวิธีการเผชิญปัญหา แต่ฉันอยากจะรู้ว่าสิ่งใดที่ถือว่าเป็นวิธีปฏิบัติที่ดีที่สุด น่าเสียดายที่ไม่มีคำถามที่ติดแท็กantimeridian อยู่ดังนั้นจึงยากที่จะค้นหาคำถามที่เกี่ยวข้อง คำถามเหล่านั้นที่ฉันได้เห็นการดิ้นรนปัญหานี้ทั้งหมดดูเหมือนจะหาคำแนะนำเฉพาะแอปพลิเคชันมาก คำถามนี้กล่าวถึง antimeridian สั้น ๆ สำหรับกรณีของรูปหลายเหลี่ยม GeoJSON ที่ครอบคลุมทั่วโลกโดยไม่มีขอบเขต คำถามนี้ค่อนข้างใกล้กับสิ่งที่ฉันถาม

ฉันต้องเก็บไซโคลนประวัติศาสตร์และการพยากรณ์ในฐานข้อมูลเชิงพื้นที่ แต่ฉันคาดว่าจะมีปัญหากับแอนติเมริเดียน ตัวอย่างเช่นเส้นเริ่มต้นที่ละติจูด / ลองจิจูด(0,179)และสิ้นสุดที่(0,-179)ไม่ชัดเจนเกี่ยวกับทิศทางของมัน: ไม่ว่าจะใช้เส้นทางสั้นข้าม antimeridian หรือ "ล้อมรอบ" ทั่วทั้งดาวเคราะห์ เส้นทางดังกล่าวควรจัดเก็บไว้ในฐานข้อมูลเชิงพื้นที่อย่างไร (โดยเฉพาะฉันทำงานกับ PostGIS แต่ฉันหวังว่าโซลูชันนี้จะใช้งานได้ทั่วไป) ความคิดบางอย่างที่ฉันมี:

1. ไม่ทำการเปลี่ยนแปลงรูปทรงเรขาคณิตและเลื่อนความกำกวมไปยังแอปพลิเคชันไคลเอนต์
2. แยกคุณลักษณะใด ๆ ข้ามแอนติเมอริเดียนเป็นรูปทรงเรขาคณิต multipart มีตัวแบ่งที่เป็นแอนติเมอริเดียน ( ข้อกำหนด 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ซึ่งมีค่าสำหรับการอ่าน แต่ไม่ได้ข้อสรุปเกี่ยวกับ antimeridian

ใช้ความคิดที่ 4 โดยGeographicaGS 'GeodesicLinesToGISPythonซึ่งในทางกลับกันจะใช้fiona.transform.transform_geomกับค่าชดเชย antimeridian 360 ° ในทางกลับกัน Fiona ใช้ของ -wrapdatelineOGR ฉันคิดว่ามันเป็นแบบอย่างที่มั่นคงมากและค่อนข้างธรรมดาทั่วไป

ร่วมกับปัญหาพื้นที่เก็บข้อมูลฉันต้องพิจารณาว่าคุณลักษณะดังกล่าวควรถูกส่งไปยังแอปพลิเคชันไคลเอนต์อย่างไรและวิธีการที่แอปพลิเคชันของฉันควรพิจารณาข้อมูลที่โพสต์กลับไป (เช่นผู้พยากรณ์มนุษย์ รูปแบบการแลกเปลี่ยนอาจเป็น GeoJSON แต่ไม่จำเป็นต้องเป็น

น่าเสียดายที่ข้อกำหนดของ GeoJSON ไม่ชัดเจนเกี่ยวกับประเด็นเรื่องแอนติเมริเดียน สิ่งนี้มาจากWikipedia :

ห้องสมุดซอฟแวร์ทางภูมิศาสตร์หรือรูปแบบข้อมูลจำนวนมากคาดว่าโลกจะเป็นรูปสี่เหลี่ยมผืนผ้า บ่อยครั้งที่สี่เหลี่ยมมุมฉากนี้ถูกแบ่งอย่างแน่นอนในช่วงเที่ยงวันที่ 180 สิ่งนี้มักทำให้เป็นไปไม่ได้ที่จะทำงานง่ายๆ (เช่นแทนพื้นที่หรือเส้น) เหนือเส้นแวงที่ 180 ตัวอย่างบางส่วน:

• ข้อกำหนดของ GeoJSON ไม่ได้กล่าวถึงการจัดการกับเส้นลมปราณลำดับที่ 180 ในสเปคของมันเช่นนั้นการแทนเส้นตรงข้ามเส้นแวงที่ 180 ก็สามารถตีความได้เช่นเดียวกับการเดินทางรอบโลก

• ใน OpenStreetMap พื้นที่ (เช่นขอบเขตของรัสเซีย) จะถูกแบ่งที่เส้นแวงที่ 180

การอ่านของฉันคือ GeoJSON ไม่มีมาตรฐานที่เป็นตัวแทนของคุณสมบัติ antimeridian-spanning และมันถูกปล่อยทิ้งไว้อย่างคลุมเครือโดยเจตนา (รูปทรงหลายส่วนอาจแก้ไขปัญหาได้) ในทำนองเดียวกันใน OpenStreetMap มีแผนกเรขาคณิตที่ antimeridian แม้ว่าฉันจะไม่รู้ว่าคุณสมบัติแยกดังกล่าวเป็นหลายส่วนหรือเป็นบันทึกที่ไม่ต่อเนื่องจริงหรือไม่

สิ่งนี้ให้ความรู้สึกค่อนข้างเป็นปัญหาโดยเฉพาะอย่างยิ่งจากมุมมองของการทำ bounding box หรือการร้องขอเกี่ยวกับอวกาศอื่น ๆ ที่ครอบคลุมบรรทัดนี้ นี่คือเหตุผลที่ฉันพยายามกำหนดวิธีปฏิบัติที่ดีที่สุดที่ฉันสามารถพยายามที่จะปฏิบัติตาม

การพูดอย่างหมดจดจากมุมมองการจัดเก็บข้อมูลและการวิเคราะห์geographyประเภทของ PostGISได้รับการออกแบบโดยคำนึงถึง antimeridian (ในเป้าหมายการออกแบบหลายประการ) มีฟังก์ชั่นหลายออกแบบมาเฉพาะสำหรับgeographyประเภท

ตัวอย่างเช่นพิจารณา LineString ข้ามTaveuni, ฟิจิ ( แมปกับ Great วงกลม Mapper ) ซึ่งคร่อม antimeridian:

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

ความยาวของพื้นผิวทางธรณีวิทยานี้อยู่ที่ประมาณ 46 กม. ในทำนองเดียวกัน 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 คุณสามารถเลือกที่จะเพิกเฉยต่อข้อสังเกต (หรือตัวอย่างSET client_min_messages TO WARNING;) และแปลงรูปทรงเรขาคณิตที่ดูตลกทุกประเภทเป็นgeographyประเภท

การแสดงgeographyประเภทบนแผนที่นอก PostGIS เป็นเรื่องราวที่แตกต่างกันและหวังว่าคำตอบที่ดีกว่าจะได้สัมผัสกับแง่มุมนี้

แน่นอนคำตอบที่ต้องการคือ (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 Earth Pro ไม่แสดงรูปหลายเหลี่ยมนี้อย่างถูกต้อง (เว้นแต่คุณจะใช้โหมด "เค้าร่าง") ดูที่นี่