Влияет ли преобразование в новую проекцию, а затем обратно, на точность данных?

У меня есть класс пространственных объектов (графства Южная Каролина, поэтому довольно большой географический район) в NAD83 SC State Plane. Его необходимо преобразовать во вторую проекцию (NAD83 UTM 17), а затем преобразовать обратно в оригинал. Я буду использовать инструмент проекта Esri для достижения этой цели.

Может ли это двойное преобразование вызвать сдвиг в расположении координат многоугольников и на сколько - сантиметры, метры, километры?

Я не знаю, какой проекционный движок использует ArcGis, но очень интересный вопрос и для proj.4. Поэтому я попытаюсь протестировать проекционный механизм proj.4 в среде GNU-R. Я использую углы NAD 83 - UTM 17 и EPSG 26917, рекурсивно повторяю их 10000 и 1000000 раз и вычисляю разницу с начальными значениями.

Вот результаты:

Кажется, что ошибка «перепроецирования» в пределах сантиметрового диапазона для 10000 петель.

"LON/LAT differences after  10000  loops"
           DLON          DLAT
1 -2.441464e-07 -1.341807e-07
2  2.441129e-07 -1.341807e-07
3  1.852679e-07 -1.691737e-08
4 -1.853157e-07 -1.691819e-08

"X/Y differences after  10000  loops"
            DX           DY
1 -0.025169783 -0.014338141
2  0.025166375 -0.014338208
3  0.002419045 -0.002016762
4 -0.002419690 -0.002016889

И вырастет до ошибки в диапазоне метров, если вы выполните цикл 1000000 раз.

"LON/LAT differences after  1000000  loops"
           DLON          DLAT
1 -2.441464e-05 -1.341845e-05
2  2.441128e-05 -1.341846e-05
3  1.852621e-05 -1.691837e-06
4 -1.853105e-05 -1.691828e-06

"X/Y differences after  1000000  loops"
          DX         DY
1 -2.5172288 -1.4339977
2  2.5168869 -1.4340064
3  0.2419201 -0.2017070
4 -0.2419859 -0.2017094

Вот сценарий.

# load the package
require('proj4')

# the LON/LAT frame of NAD83 UTM 17 
lon = c(-84.00, -78.00, -84.00, -78.00 ) 
lat = c( 24.00,  24.00,  83.00,  83.00)

# build the projection conform object
ll0 = matrix(c(lon,lat),nrow=4,ncol=2)
xy0 = project(ll0,"+init=epsg:26917",ellps.default='GRS80')

# make a copy
ll1 = ll0
xy1 = xy0

# number of iterations
num = 1000000

# reproject the stuff num times
for(i in 1:num) {
 # project forward  
 xy1 = project(ll1,"+init=epsg:26917", ellps.default='GRS80')
 # project backward
 ll1 = project(xy1,"+init=epsg:26917", inverse=T, ellps.default='GRS80')
}

# build difference table ll
dll = as.data.frame(ll1-ll0)
names(dll) = c('DLON','DLAT')
# print results LON/LAT
print(paste("LON/LAT differences after ", num," loops"))
print(dll)

# build difference table xy
dxy = as.data.frame(xy1-xy0)
names(dxy) = c('DX','DY')
# print results X/Y
print(paste("X/Y differences after ", num," loops"))
print(dxy)

Дальнейшие тесты в среде статистики должны быть простыми. Сценарии и объяснение кода для среды linux доступны по адресу github.com/bigopensky .

Esri имеет собственный проекционный движок.

Большинство методов проекций и географических / базовых преобразований хорошо работают при использовании в соответствующей области интересов. Если вы выходите слишком далеко за пределы зоны UTM, поперечный Меркатор не всегда точно «инвертирует» (конвертирует в широту-долготу). Проекции, используемые для всего мира, могут иметь некоторые проблемы на полюсах или вокруг них, или на меридиане +/- 180, или на «анти-меридиане» (меридиане, который находится напротив центра проецируемой системы координат).

Я пробежал 4 очка, которые падают за пределы Южной Каролины через проекционный двигатель Esri. Для стресс-теста в 1k, 10k или 1M баллов мне придется что-то кодировать, поскольку мой существующий аналогичный тест просто выполняет «круговую передачу» - от географического до прогнозируемого. 32133 - НАД 1983 года, государственный самолет Южной Каролины (в метрах). 26917 - NAD 1983 UTM, зона 17 север.

C:\Users\melita>inverse 32133
382000 20000
      -83.40806392522212        31.98974518135408
382000 383000
      -83.50098893136905        35.26180827475587
839100 20000
      -78.57184097446545        31.98934439195045
839100 383000
      -78.47814111839074        35.26139222680582

C:\Users\melita>forward 26917
  -83.40806392522212        31.98974518135408
       272490.5730967618        3541832.738731374
  -83.50098893136905        35.26180827475587
       272485.6257057797         3904944.98998655
  -78.57184097446545        31.98934439195045
       729409.4734382738        3541830.781689366
  -78.47814111839074        35.26139222680582
       729414.4926270114        3904946.919009762

C:\Users\melita>inverse 26917
 272490.5730967618        3541832.738731374
      -83.40806392522212        31.98974518135408
  272485.6257057797         3904944.98998655
      -83.50098893136905        35.26180827475587
  729409.4734382738        3541830.781689366
      -78.57184097446545        31.98934439195045
  729414.4926270114        3904946.919009762
      -78.47814111839074        35.26139222680582
^Z

C:\Users\melita>forward 32133
  -83.40806392522212        31.98974518135408
                382000.0                  20000.0
  -83.50098893136905        35.26180827475587
                382000.0                 383000.0
  -78.57184097446545        31.98934439195045
                839100.0        19999.99999999814
  -78.47814111839074        35.26139222680582
                839100.0        382999.9999999981

Итак, вы можете видеть, что у нас было две точки, которые вернулись в 10e-09.

Обработка в ArcGIS усложняется тем, что существует пространственная привязка. Пространственная привязка включает систему координат, а также некоторые значения для хранения и анализа. По умолчанию системы координат, использующие метры, хранятся с точностью до одной десятой миллиметра, 0,0001.

Раскрытие: я работаю на Esri.

Я думаю, что это тот случай, когда вам нужно протестировать предложенный рабочий процесс с некоторыми функциями контрольных точек, к которым легко добавить поля координат XY.

Сравните значения XY ваших начальных точек с теми, которые вы проецировали / трансформировали (хотя и много раз), и вы будете количественно определять разницу.