Más

¿Calculando el área WGS84 (EPSG: 4326) en C # o SQLGeometry?

¿Calculando el área WGS84 (EPSG: 4326) en C # o SQLGeometry?


Normalmente no soy un desarrollador de SIG, solo estoy ayudando con un error y estoy perplejo con lo que está sucediendo aquí, ¿podría obtener ayuda por favor?

Tengo dos cálculos, uno en 4326 (WGS84) y otro en 3857 (Google Mercator). Las coordenadas se convirtieron de 4326 -> 3857 y he confirmado que son correctas con ArcGIS y varias herramientas de conversión de sitios en línea. Los resultados que tengo son ...

-114.50,38.0=-12746081.696,4579425.813 -114.00,40.0=-12690421.950,4865942.280

Si hago una estimación del área para 3857 calculando la diferencia en los puntos xey, luego multiplicando las diferencias y dividiendo por 1 mil para obtener km cuadrados, obtengo el resultado un poco menos de 16,000 km cuadrados. Al ejecutar SqlGeometry.STArea en un bbox de polígono usando estos puntos, esto me da un número similar.

Si convierto la latitud larga a UTM, recibo los números ...

-114.50,38.0 = 719510.335753775,4208764.46330096 -114.00,40.0 = 243900.352021924,4432069.05663229 Cálculos de Excel Orientación este al norte m2 km cuadrados 719,510.3358 4,208,764.4633 243,900.3520 4,432,069.0566 ---------------------- ---------------------------------------------- 475,609.9837 223,304.5933 106,205,894,001.5610 106,205.8940

Sitios utilizados para convertir a UTM

http://www.latlong.net/lat-long-utm.html

http://www.rcn.montana.edu/Resources/Converter.aspx

http://www.earthpoint.us/Convert.aspx

Ejecutando el mismo cálculo de la diferencia y el área me da el resultado de 106,205 kilómetros cuadrados.

El código actualmente calcula la latitud haciendo lo siguiente en un polígono de bbox ...

SqlGeography geog = SqlGeography.STGeomFromWKB (aoi.STAsBinary (), (int) aoi.STSrid); area = (doble) geog.STArea ();

Esto me da unos 9.600 kilómetros cuadrados.

Lo que necesito saber ...

Estoy tratando de averiguar qué cálculo es correcto. Me inclino a que 3857 sea correcto ya que los cálculos me dan aproximadamente los mismos números sin importar cómo los haga. Como creo que 4326 es incorrecto, necesitaría una mejor manera de calcular esto en la aplicación actual (usa C # y SQLGeometry). Si alguien ve un error en mis cálculos, hágamelo saber y cómo hacerlo mejor si es así.


Aparte del hecho de que la proyección EPSG: 3857 no conserva áreas, las unidades de la misma no son metros reales. Solo en el ecuador coinciden con los metros reales, mientras que se estiran más hacia los polos que vas.

UTM tampoco preserva áreas, pero minimiza los errores de distancia siempre que se encuentre dentro de la misma zona UTM (que no es el caso en el ejemplo). Entonces usa metros reales como unidades.

La única forma correcta de calcular áreas es utilizando una proyección de áreas iguales. Para América del Norte, puede probar ESRI: 102008

+ proj = aea + lat_1 = 20 + lat_2 = 60 + lat_0 = 40 + lon_0 = -96 + x_0 = 0 + y_0 = 0 + datum = NAD83 + unidades = m + no_defs

Usando QGIS y el integrado$ areafunción de la calculadora de campo, obtengo para su área de 0.5x2.0 grados:

EPSG: 2163 8105.49 km² (basado en una esfera) EPSG: 3857 15947.43 km² (metros cuadrados de google) EPSG: 32107 9617.65 km² (NAD83 Nevada East) EPSG: 32611 9622.15 km² (WGS 84 / UTM zona 11N) ESRI: 12008 9616.38 km² ( North_America_Albers_Equal_Area_Conic)

Como puede ver, EPSG: 3857 no vale nada. Es solo una visualización popular, nada más.


Ver el vídeo: How to convert WGS84 to PRS92 coordinate system using Civil 3D 2020