Pourquoi ai-je une zone correcte et une zone d'intersection lorsque j'utilise une projection incorrecte?

J'ai besoin de calculer des zones et des zones d'intersection pour les polygones (certains objets géographiques réels comme le lac, la ville, le pays, etc.). Polygones situés en Californie, Nouvelle-Zélande, Russie.Anadyr, Suède

Tous les polygones sont en WGS84.

Ce que j'ai fait en utilisant l'API Java GeoTool:

Projetez tous les polygones en utilisant EPSG: 3488 , EPSG: NAD83 (NSRS2007) / California Albers et les zones calculées et les zones de chevauchement.
A fait de même en utilisant World_Mollweide et World_Eckert_IV
Sélection de " projections locales spécifiques " pour des polygones de Californie, de Nouvelle-Zélande, etc.

Je suppose que # 3 est le résultat le plus précis, car je choisis une projection qui couvre la zone du polygone

Résultat:

'# 2 a montré le pire résultat par rapport à # 3

La différence entre les zones # 1 et # 3 et les zones d'intersection est inférieure à 0,1%

Pourquoi? Je choisis une projection EPSG: 3488 (Californie) absolument incorrecte pour les polygones de Suède et j'obtiens à peu près les mêmes zones et zones d'intersection?

UPD: On dirait que je n'ai pas expliqué ma confusion correctement. Voici un exemple de sortie avec explication

#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%]

Ma confusion est la suivante: EPSG: 3488 conçu pour être utilisé en Californie

Je choisis la projection «incorrecte» EPSG: 3488 pour les régions de l'Alaska et de la Nouvelle-Zélande et je constate que les calculs résultants ne diffèrent pas «de manière significative» des projections correctes. EPSG: 3488 fonctionne même mieux que Mollweide, les projections Eckert_IV conçues pour être utilisées dans le monde entier.

coordinate-system geotools

— Capacytron
source

J'ai également constaté qu'il n'y a pratiquement aucune différence observable entre ces deux projections, mais la différence existe toujours. Dans ArcGIS, vous ne pouvez pas créer un "jeu de données d'entités" à moins que vos données ne soient dans la même projection, même avec une si petite différence que celle trouvée entre WGS84 et NAD83. La page Web suivante m'a été très informative et j'espère que vous la trouverez également utile. differencebetween.net/technology/… J'aurais mis cela comme un commentaire mais je n'ai pas 50 représentants :(

— Justin Q

à quoi comparez-vous les résultats?

— Ian Turton

@iant veuillez voir la question mise à jour. J'ai ajouté une sortie de comparaison.

— Capacytron

Vous pouvez essayer les projections AUTO (UTM centré sur un point fourni par l'utilisateur) - construire CRS comme String code = "AUTO: 42001," + x + "," + y; // System.out.println (code); CoordinateReferenceSystem auto = CRS.decode (code);

— Ian Turton

Réponses:

"EPSG: 3488, EPSG: NAD83 (NSRS2007) / California Albers" est une projection à surface égale. Il est basé sur la conique d'Albers, qui est définie pour l'hémisphère nord. Parce que la Suède est dans sa gamme de définition, elle est à superficie égale en Suède. Cela signifie que (jusqu'à une erreur d'arrondi en virgule flottante) cela donnera des zones absolument correctes.

Ni le Mollweide ni l' Eckert ne sont exactement à égalité de superficie, mais (comme M. Kennedy le souligne gentiment dans un commentaire), ils le sont approximativement. Les distorsions qu'ils introduisent seront comparables aux différences entre la sphère et l'ellipsoïde, qui sont limitées à environ une partie sur 300 (0,3%).

— whuber
source

Bill, Eckert IV et Mollweide sont des projections à surface égale, mais ne disposent que d'algorithmes sphériques.

— mkennedy

@mkennedy Oups - j'aurais dû vérifier. Merci pour la correction, Melita. Je vais corriger ce commentaire.

— whuber

@mkennedy donc ESRI: 53009 et ESRI: 54009 sont en fait identiques? Je vois que Snyder ne donne pas de formules sur l'ellispoïde, alors quel est le sens de ces projections World_xxx d'ESRI basées sur WGS84?

— AndreJ

Esri: 53009 (et les autres entrées 53xxx) utilisent un GeoCRS basé sur une sphère avec R = 6371000,0 m. La gamme Esri: 54xxx utilise un géoCRS WGS84 donc le rayon réel utilisé est l'axe semi-principal, 6378137.0. Ils ont tous deux été ajoutés juste en tant que définitions de test / échantillon.

— mkennedy

Le pôle Sud est à des dizaines de milliers de kilomètres de la Suède: c'est en Antarctique. Le pôle Nord n'est qu'à quelques milliers de kilomètres de la Suède. Mais cela n'a pas d'importance: si vous utilisez une projection à aire égale et qu'elle est capable de projeter une région dont vous voulez calculer l'aire, alors elle calculera l'aire correctement (pour la donnée sur laquelle elle est basée). Certaines projections à surface égale sont capables de projeter le monde entier à l'exception d'un seul point (qui dépend de la projection).

— whuber

L'affirmation de @ whuber selon laquelle une projection à aire égale "donnera des aires absolument correctes" s'accompagne d'un astérisque, à savoir, en supposant que les bords du polygone sont des lignes droites dans ladite projection . C'est souvent une bonne approximation, surtout si les bords sont courts; mais c'est rarement strictement vrai.

Si, en revanche, les bords de votre polygone sont des géodésiques ou des lignes de rhumb, d'autres techniques peuvent être utilisées pour déterminer la zone précise à arrondir. Mon planimètre en ligne les met en œuvre. Essaie.

— cffk
source

Salut! Merci pour toutes les contributions. Vous voulez donc le résumé? EPSG: 3488 utilise la projection à surface égale d'Albers, c'est pourquoi il calcule correctement les zones du monde entier, même sur le pôle Sud?

— Capacytron

Il est probable qu'Albers à surface égale fournira un résultat suffisamment décent pour votre application. Cependant, utiliser aveuglément cette projection pour calculer la superficie de l'Antarctique (qui entoure le pôle) donnera un résultat non-sens. Donc, pour une utilisation générale, je recommanderais de calculer la zone géodésique afin que vous n'ayez pas à vous soucier des limites de chaque projection à surface égale particulière.

— cffk

Merci pour la réponse. Malheureusement, nous avons besoin d'une surface carrée en mètres.

— Capacytron

L'outil Planimètre vous donne la surface en mètres carrés.

— cffk

La même fonctionnalité est disponible en tant que package Java, Geographiclib-Java . La documentation comprend un code pour calculer l'aire d'un polygone spécifié comme un ensemble de points de latitude / longitude avec le résultat donné en mètres carrés.

— cffk