Personalizado de Proyección en Proj4 tiene errores, ¿qué puedo hacer para implementar un 4 parámetros de transformación?

Question

Estoy trabajando en un proyecto donde me gustaría definir una proyección en QGIS, el uso de un Proj4 cadena, por lo que un usuario puede importar y exportar sitio de coordenadas locales de la UTM o coordenadas geográficas.

He tenido una buena búsqueda por todo el lugar, y los mejores recursos que he encontrado es este sig.stackexchange post, que se me cierra, pero tengo errores todavía, que se puede ver en las imágenes de abajo. No son sistemáticos en una manera que yo pueda ver, pero podría estar relacionado con la escala.

Este es mi Proj4 cadena:

+proj=omerc +lat_0=-42.83254553 +lonc=147.31794080 +alpha=43.297962 +k_0=0.999592 +x_0=0 +y_0=0 +gamma=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

Y he usado un poco de software para generar los parámetros de transformación de coordenadas conocido de las relaciones, lo que resulta en estos:

• X cambio: 525985.101348
• Y mayús: 5257731.440819
• Z rotación: 0.755692
• Escala: 0.999592

Estos fueron lo que se utiliza para obtener los parámetros en el Proj4 cadena, incluyendo a venir para arriba con el origen Lon y Lat (a través de la transformación de la 0,0 punto de regresar a la MGA y de allí adelante a WGS84).

Si yo uso los parámetros anteriores para hacer un manual de la transformación, las coordenadas son transformados a la perfección. Si yo uso la anterior proyección en QGIS todavía estoy recibiendo errores de hasta 2 m.

Me pregunto si alguien sabe de una mejor proyección de la cadena para el uso en Proj4, o si hay otra forma en que puede manejar un sitio de referencia o sistema de coordenadas de personalizado, con una transformación en un sistema conocido.

EDIT: más info

He aquí algunos pares de coordenadas. Tenga en cuenta que la lat/lon se derivan de la MGA coordenadas. E y N mga es GDA94, MGA Zona de 55. El Zs son irrelevantes es un simple desplazamiento vertical.

Tenga en cuenta que he trabajado fuera de la Lat/Lon cambio para Proj4 cadena por la conversión de un 0,0 sitio coordinar a MGA, y se utiliza de QGIS para convertir esto en WGS Lat/Lon. De esta forma el origen Lat, Lon, como por los otros stackexchange post.

Emga,Nmga,Eplant,Nplant,Lon,Lat,Zmga,Zplant
525631.34,5258107.55,-515.61,31.13,147.3135953,-42.82917059,10.7,10.02
525634.87,5258111.13,-515.49,36.17,147.3136383,-42.82913824,10.33,9.65
525633.12,5258109.03,-515.33,33.44,147.313617,-42.82915721,12.43,11.74
525633.98,5258109.93,-515.32,34.68,147.3136275,-42.82914907,9.76,9.08
525692.84,5258084.4,-454.95,56.47,147.3143487,-42.829377,3.09,2.4
525692.41,5258083.45,-454.61,55.49,147.3143435,-42.82938557,3.14,2.46
525856.42,5258016.48,-289.24,119.25,147.3163532,-42.82998312,3.2,2.52
525876.22,5257998.88,-262.762,120.021,147.3165963,-42.83014095,9.59,8.91
525907.25,5258001.29,-241.82,143.07,147.3169758,-42.83011819,3.99,3.3
525906.52,5257997.55,-239.79,139.84,147.3169671,-42.8301519,3.23,2.54
525912.12,5257997.14,-235.43,143.38,147.3170356,-42.8301554,3.17,2.49
525925.34,5257969.74,-207,132.5,147.3171986,-42.8304017,3.41,2.73
525939,5257962.35,-191.98,136.49,147.3173661,-42.83046778,2.89,2.21
525934.89,5257911.72,-160.24,96.81,147.3173181,-42.83092385,2.91,2.23
525933.72,5257861.72,-126.8,59.6,147.3173061,-42.83137416,2.91,2.23
525981.79,5257875.04,-100.93,102.28,147.3178936,-42.83125257,41.97,41.29
526006.26,5257860.79,-73.34,108.7,147.3181937,-42.83138007,8.59,7.9
526086.76,5257842.88,-2.44,150.89,147.3191794,-42.83153861,8.79,8.1
525788.67,5257525.66,-1.84,-284.59,147.3155468,-42.83440535,10.52,9.83
525788.87,5257456.4,45.82,-334.89,147.3155524,-42.83502905,10.47,9.79
526149.54,5257795.97,75.46,159.8,147.3199497,-42.8319589,10.48,9.8
525789.24,5257402.47,83.09,-373.9,147.3155594,-42.83551469,42.49,41.81
526184.03,5257761.77,124.03,158.57,147.3203733,-42.8322657,37.11,36.43

Answer 1

Para resolver el problema de la mitad-de forma manual, me puso su planta de coordenadas en un archivo de texto denominado local.txt, y vamos a cs2cs convertir a EPSG:28355:

cs2cs +proj=omerc +lat_0=-42.8325458 +lonc=147.3179408 +alpha=43.084 +k_0=0.99994 +x_0=0 +y_0=0 +gamma=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs +to +init=epsg:28355 -f "%%.3f" local.txt >out.txt

Además, me llevó a su archivo completo en Libre Office, pegar el resultado de cs2cs en tres columnas nuevas, vamos a LibreOffice cálculo de la compensación por columna, y los cuadrados y la suma de las columnas:

El resultado (en rojo) no es muy bueno, ya que has experimentado.

Entonces empecé a jugar con las variables lat_0, lonc, alpha, k_0. Obviamente, los dos primeros pueden cambiarse para minimizar el valor de la media de deltE y deltN respectivamente (el amarillo de valor de marca el valor modificado, y el verde de la reducción al mínimo de resultado), de manera Similar, el alfa y la k_0 puede ser cambiado para reducir la suma de cuadrados. Tienes que ir a través de todas las variables varias veces para obtener el mínimo de la plaza de sumas.

El resultado proj cadena

+proj=omerc +lat_0=-42.8325458 +lonc=147.3179408 +alpha=43.084 +k_0=0.99994 +x_0=0 +y_0=0 +gamma=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

ha de desplazamientos de menos de 10 cm. Usted puede obtener mejores valores con entradas que cubren milímetros.

Comparando con sus parámetros, el origen es bastante buena, pero la rotación es diferente. Esto podría ser debido a Zona UTM 55 tiene el meridiano central (Norte verdadero) a 147° Este, mientras que en el sistema local tiene el eje del Norte verdadero en 147.3179408° Este. Así que la MGA eje Y en su origen se gira contra el Norte verdadero un poco. Supongo que esto no es cumplido por el código de python que utiliza.