Чому я отримую правильну площу та перетинаються області, коли використовую неправильну проекцію?

Мені потрібно обчислити площі та ділянки перетину для полігонів (деякі реальні географічні об’єкти, такі як озеро, місто, країна тощо). Полігони розташовані в Каліфорнії, Новій Зеландії, Росії.Анадир, Швеція

Усі багатокутники є у WGS84.

Що я робив за допомогою API JavaToo GeoTool:

Проектуйте всі багатокутники, використовуючи EPSG: 3488 , EPSG: NAD83 (NSRS2007) / Каліфорнійський Альберс та розрахункові площі та ділянки перекриття.
Зробив те саме, використовуючи World_Mollweide та World_Eckert_IV
Вибрані " місцеві конкретні проекції " для полігонів з Каліфорнії, Нової Зеландії тощо

Я припускаю, що №3 є найбільш точним результатом, оскільки я вибираю проекцію, яка охоплює площу полігона

Результат:

"№2 показав найгірший результат порівняно з №3

"Різниця в областях №1 та №3 та місцях перетину менше 0,1%

Чому? Я вибираю абсолютно неправильну проекцію EPSG: 3488 (Каліфорнія) для полігонів зі Швеції і отримую приблизно однакові площі та ділянки перетину?

UPD: Схоже, я не пояснив правильно свою плутанину. Ось зразок виводу з поясненням

#area_from_new_zealand_1
EPSG_27200 area[11733479] CRS[World_Mollweide] area[11736023] diff[2544] [0.0%]
EPSG_27200 area[11733479] CRS[World_Eckert_IV] area[11736033] diff[2554] [0.0%] 
EPSG_27200 area[11733479] CRS[EPSG:NAD83(NSRS2007) / California Albers] area[11736034] diff[2555] [0.0%] 

#area_from_new_zealand_2
EPSG_27200 area[2952725]  CRS[World_Mollweide] area[2953281] diff[556] [0.0%] 
EPSG_27200 area[2952725]  CRS[World_Eckert_IV] area[2953342] diff[617] [0.0%] 
EPSG_27200 area[2952725]  CRS[EPSG:NAD83(NSRS2007) / California Albers] area[2953467] diff[743] [0.0%] 

#intersection_area_between_two_new_zealand_areas
EPSG_27200 intersection area[1001857] CRS[World_Mollweide]                          area[1002082] diff[225] [0.0%] 
EPSG_27200 intersection area[1001857] CRS[World_Eckert_IV]                          area[1002082] diff[225] [0.0%] 
EPSG_27200 intersection area[1001857] CRS[EPSG:NAD83(NSRS2007) / California Albers] area[1002096] diff[239] [0.0%] 


#area_from_alaska_1
EPSG_3338 area[56278347]    CRS[World_Mollweide] area[56041510] diff[236837] [0.4%] 
EPSG_3338 area[56278347]    CRS[World_Eckert_IV] area[56041585] diff[236763] [0.4%] 
EPSG_3338 area[56278347]    CRS[EPSG:NAD83(NSRS2007) / California Albers] area[56278426] diff[79] [0.0%] 

#area_from_alaska_2
EPSG_3338 area[17564799282] CRS[World_Mollweide] area[17486015889] diff[78783393] [0.4%] 
EPSG_3338 area[17564799282] CRS[World_Eckert_IV] area[17486869816] diff[77929466] [0.4%]
EPSG_3338 area[17564799282] CRS[EPSG:NAD83(NSRS2007) / California Albers] area[17566197286] diff[1398004] [0.0%] 

 #intersection_area_between_two_alaska_areas 
EPSG_3338 intersection area[43808167] CRS[World_Mollweide] area[45066901] diff[1258734] [2.8%] 
EPSG_3338 intersection area[43808167] CRS[World_Eckert_IV] area[45163183] diff[1355016] [3.0%] 
EPSG_3338 intersection area[43808167] CRS[EPSG:NAD83(NSRS2007) / California Albers] area[43885182] diff[77015] [0.2%]

Моя плутанина: EPSG: 3488 призначений для використання в Каліфорнії

Я вибираю "неправильну" проекцію EPSG: 3488 для районів Аляски, Нової Зеландії і бачу, що отримані розрахунки не суттєво відрізняються від правильних прогнозів. EPSG: 3488 навіть краще, ніж Mollweide, проекції Eckert_IV, розроблені для використання у всьому світі.

coordinate-system geotools

— Капацитрон
джерело

Я також виявив, що між цими двома прогнозами немає різниці, що спостерігається, але різниця все ще існує. В ArcGIS ви не можете створити "набір даних про особливості", якщо ваші дані не будуть в одній і тій же проекції навіть при такій невеликій різниці, що виявлена між WGS84 і NAD83. Наступна веб-сторінка була для мене дуже інформативною, і я сподіваюся, що ви також виявите її корисною. різниця

— Justin Q

з чим ви порівнюєте результати?

— Ян Тертон

@iant, будь ласка, дивіться оновлене запитання. Я додав порівняльний вихід.

— Капацитрон

Ви можете спробувати проекції AUTO (UTM зосереджено на точці, що надається користувачем) - побудувати CRS як String code = "AUTO: 42001," + x + "," + y; // System.out.println (код); CoordinateReferenceSystem auto = CRS.decode (код);

— Ян Тертон

Відповіді:

"EPSG: 3488, EPSG: NAD83 (NSRS2007) / Каліфорнійський Альберс" - це проекція на рівну площу. Він заснований на коні Альберса, який визначений для північної півкулі. Оскільки Швеція знаходиться в межах її визначення, вона є рівною площею у Швеції. Це означає, що (до помилки округлення з плаваючою комою) це дасть абсолютно правильні області.

Ні Моллвейд, ні Еккерт не є рівномірно розташованими, але (як ласкаво вказує в коментарі М. Кеннеді), вони приблизно так. Викривлення, які вони вводять, будуть порівнянні з різницями між сферою та еліпсоїдом, які обмежуються приблизно однією частиною на 300 (0,3%).

— дзижчати
джерело

Білл, Еккерт IV та Молвейд - це проекції на рівну площу, але мають лише сферичні алгоритми.

— mkennedy

@mkennedy На жаль, я повинен був перевірити. Дякую за виправлення, Меліта. Я виправлю цей коментар.

— whuber

@mkennedy, тому ESRI: 53009 та ESRI: 54009 насправді однакові? Я бачу, що Снайдер не дає формул на ellispoid, тож у чому сенс цих прогнозів World_xxx від ESRI на основі WGS84?

— AndreJ

Esri: 53009 (та інші записи 53xxx) використовують GeoCRS на основі сфери з R = 6371000,0 м. Діапазон Esri: 54xxx використовує WGS84 geoCRS, тому фактичним радіусом, що використовується, є вісь напівміжа, 6378137.0. Вони були додані як визначення тесту / вибірки.

— mkennedy

Південний полюс знаходиться за десятки тисяч кілометрів від Швеції: це в Антарктиді. Північний полюс знаходиться лише за кілька тисяч кілометрів від Швеції. Але це не має значення: якщо ви використовуєте проекцію на рівну площу і вона здатна спроектувати область, область якої ви хочете обчислити, то вона обчислить область правильно (для даної, на якій вона заснована). Деякі проекції на рівну площу здатні проеціювати весь світ за винятком однієї точки (що залежить від проекції).

— whuber

Твердження @ whuber про те, що проекція на рівну площу "дасть абсолютно правильні області", походить зірочкою, а саме, якщо припустити, що краї багатокутника є прямими у зазначеній проекції . Це часто є гарним наближенням, особливо якщо краї короткі; але це рідко є суто правдою.

Якщо, з іншого боку, краї вашого багатокутника - це геодезичні чи ремневі лінії, для визначення точної та округлої площі можна використовувати інші методи. Мій онлайн-планувальник реалізує це. Спробувати.

— cffk
джерело

Привіт! Дякуємо за весь вклад. Так хочете, може бути резюме? EPSG: 3488 використовує проекцію Альберса на рівну площу, тому він правильно обчислює площі в усьому світі, навіть на південному полюсі?

— Капацитрон

Ймовірно, рівна площа Альберса забезпечить достатній гідний результат для вашої заявки. Однак сліпо, використовуючи цю проекцію для обчислення площі Антарктиди (яка оточує полюс), дасть дурницький результат. Тому для загального використання я рекомендую обчислити геодезичну площу, щоб вам не довелося турбуватися про обмеження кожної конкретної проекції на рівну площу.

— cffk

Дякую за відповідь. На жаль, нам потрібна площа квадратних метрів.

— Капацитрон

Інструмент Planimeter дає площу в квадратних метрах.

— cffk

Той самий функціонал доступний як у пакеті Java, Geographiclib-Java . Документація включає код для обчислення площі багатокутника, зазначеного у вигляді набору точок широти / довготи з отриманим результатом у квадратних метрах.

— cffk