Аналитика

Баг тут не причем. Виновато все то же округление до сантиметров.
Например, до разворота у точки была координата XXXXXXX.734 которая округлялась в меньшую сторону (до XXXXXXX.73), а затем по ней считалась площадь. После разворота, координата может стать какой угодно, например YYYYYYY.576. И теперь она уже округлится в большую сторону (до YYYYYYY.58). Вот вам и произошло изменение площади.

Так что, никаких багов нет - только голая математика. Поставьте в настройках точность площади Максимум и крутите объект сколько хотите - его площадь не изменится.

PS: Поэтому я и говорил, что округление уже сидит у нас в печенках. Так как уже не один десяток раз приходилось объяснять пользователям элементарные вещи, а они все баг, баг, программа плохая. И вроде почти у всех за плечами высшее образование и курс сфероидальной геодезии, а в простую арифметику порой не въезжают

Этот способ называется также и гауссовым и давно известен в геодезии.
Соответствующий пост я размещал еще в далеком 2005 году, поэтому прошу простить за некоторую архаичность "штиля".

viewtopic.php?f=1&t=68&hilit=%D0%B3%D0%B0%D1%83%D1%81%D1%81%2A

Добавлю только сюда обещаный xls с вариантом подсчета, похоже я про него просто забыл.



Однако!



О правильных научно обоснованых методах округления можно рассуждать, когда есть кому объяснить, когда говоришь на том же языке. А в свете сложившихся обстоятельств, учитывая, что в каждом (!) ДЗК имеется доморощеная программа проверки с непонятным нутром, толковых кадров в Центрах нет по определению, также как и желания сотрудничать, говорить о каком-либо диалоге не приходится.

Вывод неутешителен - только двигать точки угодий.

Но против констант в настройках для выбора метода "упрятывания" невязки я не возражаю, эта возможность никак не мешает гипотетической команде Сервис-Утрясти площади (или Нормализировать, как было предложено выше). Я полагаю необходимый алгоритм для "утряски" создать все таки вполне реально, хотя подводные камни в виде различных ограничений упомянутых выше конечно есть.