Не решит, поскольку “нормализировать” каждое угодие отдельно - это головная боль, а потом последнее угодие может не выйти на “идеал”. Если и нормализировать, то весь участок одновременно (в смысле угодия в участке), но при этом точки должны быть совмещенными.
А если на длинном расстоянии (100 и больше) подвинуть точку на 1 см томожет измениться на целый кв.м.
Плюс к этому нужно учесть что двигать можно только точки внутри участка, а участок нет (соседи и т.п.).
Для того и предложил работь с каждым отдельно 
Вы сами пока разберитесь чего хотите. Ато получается хочу чтоб всё - но это нельзя , то нельзя. Надо с чегото начать. Предлагаю начать с абсолютно ручного варианта описаного выше. Со временем (в процессе работы) родится полуавтомат а за ним и автомат
Наверное все-таки лучше мой предыдущий вариант с корректировкой одного угодия.
Только вот с уведомлением о невязке (пометка красным цветом) может быть накладной, так-как Дигиталс постоянно будет проверять файл на невязку. Наверное лучше будет кнопочка типа “найти одинаковые” (“найти невязку” 
). 
Мы планируем отказаться от добавления невязки в самое большое по площади угодье
Взамен хотим использовать накопительное округление. Суть его в том, что при каждом округлении запоминается отброшенная/добавленная разница, которая постоянно суммируется и участвует в каждом следующем округлении.
Что это такое можно посмотреть на тестовой программе - vinmap.net/temp/Round.exe
Значения в левой колонке можно менять или копировать туда свой список площадей.
Средняя колонка показывает результат и баланс площадей при обычном округлении (там видно, что на тестовых данных набежало целых 7 метров). В третьей колонке результат при накопительном округлении.
Балас площадей при таком подходе всегда гарантирован. Но при этом площадь каждого угодья отличается от расчетной уже не на ±0.5 м, как при обычном округлении, а на ±1.0 м.
Что скажете?
И снова округление !!! А с физическими координатами будут отличия.
AnDi
Это-же опять виртуально.
Пункт 4.4.3 Вимоги до структури, змісту та формату файлу обміну даними результатів землевпорядних робіт в електронному вигляді на магнітних носіях:
…
Прямокутні координати X, Y вузла полігону повинні уноситись до обмінного файлу з точністю до сантиметрів (два знаки після коми). Обчислення площ полігонів кадастрових одиниць виконується по координатах з вказаною точністю для виключення можливих розбіжностей у значеннях площ, що уносяться до обмінного файлу та контрольним обчисленням площ за координатами метричної інформації кадастрових одиниць.
…
Надо совать координаты.
Вот как раз перемещение точек и вызывает реальное изменение физических координат объекта. Корень проблемы лежит в непонимании авторов ИН4 формата простых математических принципов.
Есть измеренные величины, измерения которых производятся приборами с ограниченной точностью. При этом разряды числа, выходящие за границу точности в самом деле не значащие и могут быть отброшены. Следовательно, ограничение точности до см в координатах я считаю оправданным.
Есть величины расчетные. Здесь ограничение точности настолько незначительно, что им можно пренебречь. Речь о компьютерных программах, типа Digitals . Это уже ограничение разрядности используемого вещественного типа. 19 значащих разрядов, этого должно хватить . И я не согласен с необходимостью принудительного округления расчетных величин. Особенно, когда требуется свести некий баланс. Округлять площади угодий по-отдельности, суммировать их, сравнивать с площадью участка и удивляться почему не бьет. И я уверен, что остались еще люди, которые не устают удивляться Мол, программа неправильно считает.
Недавно нам даже привозили системный блок, который неверно сохраняет в ИН4. Продемонстрировали, что после сохранения в ИН4 с точностью координат 2 знака после точки, координаты смещаются на миллиметры относительно исходного DMF файла. В DMF координаты хранились с макс. точностью. А вы тут о невязках рассуждаете…
Надеюсь, в новом стандарте обмена кадастровой информацией эти “магические” вещи предусмотрят. А пока с ошибками округления надо бороться более хитрым округлением. Мне кажется это самый верный подход. Двигая точки мы подбираем голову, для которой шапка будет в самый раз, а не шапку по размеру головы.
Однако накопительное округление не будет работать когда объект один. Получается, что для угодия, скопированного и вставленного в пустую карту, будет отображаться уже другая площадь. Это не есть хорошо. Мне кажется лучше положиться на статистику, как уже предлагалось выше. Но решать о способе округления значения площади без привлечения значений площадей других объектов.
Например, по такой методике. Если округляем до 4-х знаков, а 5-й знак =5, то смотрим на значение 3-го знака, если оно четное округляем в большую сторону, иначе в меньшую. Кажется этот способ округления называется банковским или бухгалтерским. Он конечно не даст такого точного баланса как накопительное округление, но все таки снизит накопление ошибки. Особенно для случаев с большим набором значений и случайным распределением четных/нечетных цифр в разрядах.
А еще лучше дать возможность пользователю выбирать какой способ округления использовать. Не зря в Excel’e так много разных формул для такой простой задачи. Задавать способ округления можно в маске параметра. Например, для площади в маске будет написано /10000 0.0000 RoundMethod=Simple/Even/Exact, или что-то вроде.
Давайте еще припомнем изменение площади при развороте, к примеру участок 5*200=0.1000 га. Развернем на 13 градусов получаются странные вещи 0.1002га. Тут как двигать ручками границы и тем более угодия другим спосбом не обойдешся.
Это не баг - это наша сантиметровая реальность, и её никак не исправить (в смысле до оригинала). Все равно в большинстве случаев меняются длинны линий и/или площадя.
Не намного и сложнее. Просто вычислить необходимую площадь угодия с помеченной точкой (необходимая площадь=площадь участка-площадь угодия1-площадь угодия2-площадь угодия3…). Да, и соседнего тоже.
Потом циклически двигать в радиусе на 1 см, при этом вичисляя его площадь. Если в этом радиусе не будет подходящей площади редактируемого угодия то перейти на радиус в 2 см.
Далее как я предлагал выше и все в ажуре.
По образованию - да, но 8 лет в земле.
Баг тут не причем. Виновато все то же округление до сантиметров.
Например, до разворота у точки была координата XXXXXXX.734 которая округлялась в меньшую сторону (до XXXXXXX.73), а затем по ней считалась площадь. После разворота, координата может стать какой угодно, например YYYYYYY.576. И теперь она уже округлится в большую сторону (до YYYYYYY.58). Вот вам и произошло изменение площади.
Так что, никаких багов нет - только голая математика. Поставьте в настройках точность площади Максимум и крутите объект сколько хотите - его площадь не изменится.
PS: Поэтому я и говорил, что округление уже сидит у нас в печенках. Так как уже не один десяток раз приходилось объяснять пользователям элементарные вещи, а они все баг, баг, программа плохая. И вроде почти у всех за плечами высшее образование и курс сфероидальной геодезии, а в простую арифметику порой не въезжают 
Этот способ называется также и гауссовым и давно известен в геодезии.
Соответствующий пост я размещал еще в далеком 2005 году, поэтому прошу простить за некоторую архаичность “штиля”. 
Добавлю только сюда обещаный xls с вариантом подсчета, похоже я про него просто забыл.
округления.xls (101 KB)
Однако!
О правильных научно обоснованых методах округления можно рассуждать, когда есть кому объяснить, когда говоришь на том же языке. А в свете сложившихся обстоятельств, учитывая, что в каждом (!) ДЗК имеется доморощеная программа проверки с непонятным нутром, толковых кадров в Центрах нет по определению, также как и желания сотрудничать, говорить о каком-либо диалоге не приходится.
Вывод неутешителен - только двигать точки угодий.
Но против констант в настройках для выбора метода “упрятывания” невязки я не возражаю, эта возможность никак не мешает гипотетической команде Сервис-Утрясти площади (или Нормализировать, как было предложено выше). Я полагаю необходимый алгоритм для “утряски” создать все таки вполне реально, хотя подводные камни в виде различных ограничений упомянутых выше конечно есть.