Не делила с частями... Но если это (деление частей) - учет изменений, то через портал, думаю, не пройдет... Вы сами, лапа, пишете, что при образовании частей в бумажном виде еще подавали заявление от собственника. Тогда нузна ЭЦП собственника. У меня, кстати, поставили на учет участок, а часть (сервитут) проигнорировали (было все в одном МП). Видимо, нужно отдельное заявление от того, кто будет этим сервитутом пользоваться (т.е. проходить на свой участок). А вот здесь не смотрели? turochak_dda делал образование с частью...
Понимаю, что точки новые и как бы не выглядело это невероятным, но сделайте их без префикса "н". Говорю из своего опыта, мне лично так разъясняла инженер из кадастровой, ФЛК не прошло по этой причине, но учёт они всё равно провели, просто просили учесть на будущее, и ещё сказала, что возможно АИС будет доработана и эта проблема будет устранена.
Я так понимаю, что данный раздел(SpecifyRelatedParcel ) должен заполняться, когда уточняем существующую в гкн границу смежного участка.
Логику понимаю так, что точки дублируются? Я тоже против этого дурдома, но у нас давно такая практика сложилась, боролся как мог... А уж в свете новых требований плюнул и смирился, но проклинаю долбаных законотворцев каждый раз как делаю такой раздел.
Странно. Структурой предусмотрено описание смежников через Neighbours -Смежные земельные участки в бордере.
Наверное в этом скорее всего и ошибка ФЛК. А я уже больше десятка МП с SpecifyRelatedParcel сделал и всегда включал в этот раздел уточняемые не существующие в ГКН границы смежников. Походу будет десяток отказов по ФЛК
Фиг её знает. Я по началу удивлялся и возмущался. Теперь придерживаюсь мнения, что она универсальна и через нее можно описать любое действие с участком. Беда в том, что это не возможно регламентировать и следствие этого - различное толкование данных в структуре. Есть и ошибки в структуре, но это уже мелочи. Если убрать людей и оставить обмен по описанной структуре, проблемы исчезнут. Например, большинство программ формирует хмл с данными по горизонтальному проложению. Зачем? Идет изобретение по заполнению необязательных атрибутов. Зачем? Так и здесь. Если на хмл схему вешаете проверку, то опишите ее, опишите выдаваемые ошибки.
Могут быть "н" но как я понял порядок описания должен быть соблюден. В SpecifyRelatedParcel перед и после новой точки или точек должны обязательно стоять существующие точки, иначе система не сможет определить куда вставлять новые точки, только вот порядок расположения точек, то ли по часовой стрелке или против я не совсем понял, так в разных источниках описывают по разному.
Я имел ввиду между какими существующими точками вставлять новые точки, т.е. по сути показать порядок обхода части границы.
Всем доброго времени суток. Народ, подскажите, если я уточнение участка всвязи с кадастровой ошибкой делаю, сведения о характерных точках через раздел SpecifyParcels/ExistParcel/ Entity_Spatial записывать в хмл? Там же нет возможности записать старые координаты точки и новые. Эта возможность есть в ветке про уточнение смежных участков SpecifyRelatedParcel, но я же не смежный уточняю... Может есть у кого пример МП по исправлению кадастровой ошибки, прошедший учет. Скиньте плз на мыло zloy_fet@mail.ru
Да с уточнением косяк. Получается что не предусмотрено существование точки со старыми координатами. Т.е. при уточнение точка может иметь либо новые, либо старые.
Межевой план "Исправление кадастровой ошибки" ps/ - Версия XML-2 - Исправлялась кадастровая ошибка (координаты) в 3 (трёх) существующих точках из 8 (восьми).
