SASGIS - SAS.Планета
View Issue Details
0002275SAS.Планета[All Projects] Багpublic26-11-2013 15:5526-11-2013 20:32
zed 
vdemidov 
normalminoralways
resolvedfixed 
131111 
140303140303 
0002275: Ошибка в рассчёте расстояний и площадей
Причём, ошибка не в алгоритмах, а где-то выше (может где появилось лишнее округление координат точек?). Ошибка воспроизводится на полигонах из *.sml, т.е. туда всё пишется верно.
Берём ночнушку или релиз 13111, импортируем полигон из аттача и смотрим в информацию:

Количество частей: 1
Количество точек: 2962
Периметр: 2978,29 км
Площадь: 204826,71 км2

Билдим SAS по состоянию на пол-года назад (к примеру, rev.7350), запускаем с тем же файлом меток (sml), который создал релиз и смотрим на информацию ещё раз:

Количество частей: 1
Количество точек: 2962
Периметр: 2991,25 км
Площадь: 206207,16 км2
Значения периметра/площади старой версии можно считать референсными, поскольку они сравнивались с GlobalMapper и QGIS.

Собственно, начав копаться в сорцах QGIS на предмет расчёта расстояний/площадей и обнаружилось что хоть в qgis алгоритм расчёта расстояний и идентичен нашему, SAS вдруг стал нагло врать и ничего не сходится, даже с его же прошлыми показаниями...

НО если раньше SAS выдавал ошибку на полигоне 1-4.kml из этого сообщения на форуме, сегодняшняя версия отрабатывает без ошибок алгоритма (о точности результата пока не возьмусь говорить).
No tags attached.
? EuropeMinsk.kml (66,213) 26-11-2013 15:55
http://www.sasgis.org/mantis/file_download.php?file_id=1604&type=bug
png Image 2.png (2,485) 26-11-2013 17:09
http://www.sasgis.org/mantis/file_download.php?file_id=1605&type=bug
png
Issue History
26-11-2013 15:55zedNew Issue
26-11-2013 15:55zedFile Added: EuropeMinsk.kml
26-11-2013 15:56zedAdditional Information Updatedbug_revision_view_page.php?rev_id=5856#r5856
26-11-2013 16:18vdemidovNote Added: 0013323
26-11-2013 16:21zedNote Added: 0013324
26-11-2013 16:39vdemidovNote Added: 0013325
26-11-2013 17:09zedFile Added: Image 2.png
26-11-2013 17:10zedNote Added: 0013326
26-11-2013 17:16zedNote Added: 0013327
26-11-2013 17:17vdemidovNote Added: 0013328
26-11-2013 17:21zedNote Added: 0013329
26-11-2013 17:46zedNote Added: 0013330
26-11-2013 19:33vdemidovAssigned To => vdemidov
26-11-2013 19:33vdemidovStatusnew => assigned
26-11-2013 20:31vdemidovStatusassigned => resolved
26-11-2013 20:31vdemidovFixed in Version => 140303
26-11-2013 20:31vdemidovResolutionopen => fixed
26-11-2013 20:32vdemidovTarget Version => 140303

Notes
(0013323)
vdemidov   
26-11-2013 16:18   
Попробуй переключиться с гугловской карты на яндексовскую или наоборот перед вычислением площади и периметра.
(0013324)
zed   
26-11-2013 16:21   
Не помогает.

Нашёл проблемный коммит: 7440 (0489aad5146b) Хэш в датум и конвертре координат - вот после него и стало всё плохо.
(0013325)
vdemidov   
26-11-2013 16:39   
Странно. Там добавляется только вычисление хэша. никакая логика не меняется. Разве что где-то очепятался. Глянь свежим взглядом.
(0013326)
zed   
26-11-2013 17:10   
Пока не нашёл где, но явная ошибка в передаче параметров в конструктор TDatum (скриншот).
(0013327)
zed   
26-11-2013 17:16   
Нашёл. В нескольких местах есть такие строчки:

> u_GlobalState.FGPSDatum := TDatum.Create(3395, 6378137, 6356752);
> u_MarkDbGUIHelper.TDatum.Create(3395, 6378137, 6356752)

Это как минимум. И как оно вообще работает с такими-то багами???
(0013328)
vdemidov   
26-11-2013 17:17   
Ух ты. А как оно вообще скомпилилось?????
(0013329)
zed   
26-11-2013 17:21   
Скомпилилось-то без проблем: THashValue = UInt64; и есть перегруженный конструктор, который принимает 3 параметра.
(0013330)
zed   
26-11-2013 17:46   
А заодно, кстати, и выявился баг не баг, а недоработка - информация для меток выводится не в датуме карты, а в жёстко зашитом в коде датуме. И на текущий момент это эллипсоид. Нужно добавить переключатель какой-нить что-ли: какой именно использовать датум, для расчётов - тот что у карты или эллипсоид. И по-умолчанию таки стоит оставить эллипсоид.

P.S. И кстати, почему для создания _датума_ используется код _проекции_? Тоже баг?