Владимир Русак (Все сообщения пользователя)

Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Пользователи » Владимир Русак
Выбрать дату в календареВыбрать дату в календаре

Страницы: 1
21.04.2014 Перестал работать запрос поиска по кадастровому номеру
Виталий, а позвольте уточнить - работы чисто технические или можно надеяться на появление новых сервисов?
Образование участка из состава ЕЗ
[QUOTE]Константин Финагеев пишет:
Вам медаль за лучшего Шерлока Холмса месяца[/QUOTE]
Узнать бы где так умело все остальное спрятали - который год найти не можем
:D
Образование участка из состава ЕЗ
Именно эта проверка есть в описании, только глубоко - там, где описывается Prev_CadastralNumber :
[QUOTE]
Если способ образования «Выдел», то кол-во кадастровых номеров = 1.
Если способ образования «Раздел», то кол-во = 1.
Если способ образования «Раздел с измененным земельным участком», то кол-во = 1.
Если способ образования «Перераспределение», то кол-во >= 2.
Если способ образования «Образование из земель», то кол-во = 0.
Если способ образования «Объединение», то кол-во >=2.
[/QUOTE]
Изменено: Владимир Русак - 15.11.2013 17:27:55
и снова приложенные файлы
[QUOTE]Игорь Дегтярь пишет:
Потому что криворукий (а может специально) сотрудник кадастровой этот файл подпихивает в качестве XML файла. Проблема решается требованием письменного отказа.[/QUOTE]Спасибо, Игорь!
Слов нет...
Сам бы такого и предположить не смог
и снова приложенные файлы
Коллеги, может у кого уже есть опыт или предположения.
Имеется скан документа (вероятно, протокола загрузки куда-то) гласящий:
[QUOTE]Сообщение- Ошибка проверки валидности файла D:\temp\TerraTemporaryFiles0\1CD423D3-AF24-4B2E-A1CF-73C9C787Dj64\draft_file_0.jpeg Invalid character in the given encoding. Line 1, position 1.
Объект - draft_file_0.jpeg[/QUOTE]Ниже все объясняющая надпись от руки "Недопустимый символ в заданной кодировке"
Напрашивается вывод, что не нравится сам jpeg, но почему?
Кроме этого файла в архиве еще 2 аналогичных, про них в протоколе ни слова.
Сам файл без видимых проблем открывается в редакторах и просмоторщиках
Проблемы с приложением в отдельной папке
Мы поступаем также, отказов по этой причине еще не было...
Интересно какая теперь будет интерпретация пояснений к схеме (на стр.2):
[QUOTE]
XML-файл должен располагаться в корне пакета. Графические файлы могут располагаться в подкаталогах .\<каталог>\..<каталог>\<файл> (в данном случае путь к файлам должен быть прописан в xml относительно корня пакета). Наименования каталогов и имен файлов не должны содержать служебных символов, таких как: +/ \ * < >@ « ” `] [ { } $ # ~.
[/QUOTE]
Приостановление. Приложенные файлы отсутсвует в архиве.
[QUOTE]Дмитрий Бирючков пишет:
В моём конкретном примере имена графических файлов в UTF-8.[/QUOTE]Дмитрий, мы тоже пробовали сделать в UTF-8 и он тоже не подошел. Нам дали такой рецепт проверки корректности - вложения "видны" если имена отображаются корректно при просмотре средствами win (т.е. в проводнике выбираете zip и смотрите содержимое).
Приостановление. Приложенные файлы отсутсвует в архиве.
У нас уже тоже целый комплект подобных приостановок и отказов.
Официальный ответ Краснодарской КП на данную проблему [url=http://www.kadastr-23.ru/ru/vopros-otvet/2835/]здесь[/url]
Суть в конце:
[QUOTE]При этом, в ZIP-архиве, представленном вместе с заявлением о государственном кадастровом учете изменений объекта недвижимости от 12.09.2013 № 23-0-1-182/3001/2013-469, отсутствуют графические файлы, информация о которых содержится в XML-документе.По мнению филиала учреждения, вышеуказанное несоответствие может быть обусловлено тем что, в имени графических файлов была применена кодировка, отличающаяся от кодировки Unicode (UTF-8 ).Учитывая вышеизложенное, в целях недопущения подобных ситуаций впредь, рекомендуем использовать в именах графических файлов, цифры от нуля до девяти (0 – 9) и (или) буквы латинского алфавита верхнего и нижнего регистра (a-z, A-Z).[/QUOTE]
Изменено: Владимир Русак - 16.10.2013 15:10:23
ExistEZParcels
Судя по сообщению на [url=http://geodesist.ru/forum/threads/%D0%A3%D1%82%D0%BE%D1%87%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5-%D0%97%D0%B5%D0%BC%D0%BB%D0%B5%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F-%D0%B2-%D0%95%D0%97-%D0%B8%D0%BB%D0%B8-%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE%D0%BA%D0%BE%D0%BD%D1%82%D1%83%D1%80%D0%BD%D1%8B%D0%B9.21118/]геодезист.ру[/url] до МЗУ уточнить тоже не получается
InsertEntryParcel
[QUOTE]Константин Финагеев пишет:
а про более 1 ЕЗ я лично не уверен.
[/QUOTE]
и я тоже. Нам хватило, когда разгадывали первую часть :D

[QUOTE]Вадим Яковлев пишет:
Как и сейчас все познавалось опытным путем посредством отказов :-)[/QUOTE]Вот и я о том же - к нам таких отказов не поступало, повезло видать
InsertEntryParcel
[QUOTE]такой невероятно маловероятный практический случай[/QUOTE]А по-моему это просто стечение обстоятельств, наверняка, разработчики предусматривали 2 возможности - уточнение самого ЕЗ и уточнение входящих, а данный случай получился сам собой (хотя может и такое тоже надо :|).
[QUOTE]поминается ФЛК для 3 схемы с невозможностью уточнения более 1 участка в одном межевом плане)[/QUOTE]Это было актуально только для "обычных" уточняемых, если первым ExistParcel был ЕЗ, то ExistParcel могло быть сколь угодно много (помнится долго мы над этим бились :().

[QUOTE]в ExistEntryParcel прописывались кадастровые номера всех обособленных участков, входящих в ЕЗ[/QUOTE]Такого требования встречать не приходилось ...
InsertEntryParcel
Константин, по-моему, Вы пришли к правильному выводу :
[QUOTE]только те входящие участки, которых раньше (до уточнения) не было в составе ЕЗ, и теперь они в результате уточнения здесь и сейчас включаются в состав ЕЗ[/QUOTE]Если в этом конкретном случае уточнялись все входящие, то этим же и объясняется увеличение площади в два раза - сначала взяли площади включаемых (т.е. тех же участков до уточнения), а затем - площадь уточненных входящих.
Интересно, что скажут разработчики, и еще интереснее - когда.
tDocument, особенности описания документов
Перед продолжением, хочу оговориться - я не сам это придумал, пользователи настойчиво интересуются (особенно в свете соответствия бумаги и xml). По поводу дублирования полностью с Вами солидарен, но:
[QUOTE]Марина Шайкина пишет:
есть много используемых при составлении межевого плана документов, которые (помимо указания их реквизитов) прикладываются к МП, т.е. подлинники или копии этих документов включаются в состав Приложения.[/QUOTE]Если я правильно интерпретирую написанное Вами и в п. 27 требований:
[QUOTE]Если при подготовке межевого плана использованы документы, указанные в подпунктах 4, 5, 7 и 8 пункта 23 Требований, подлинники или копии таких документов включаются в состав Приложения
[/QUOTE]то один и тот же документ должен присутствовать и в «использованных» и в «приложенных». Аналогичная ситуация и в п.56 и 63 требований (это про документы адреса и доступа).
Давайте попробуем сформулировать вопрос по-другому – как все эти документы увидит принимающая сторона в АИС ГКН? все вместе или все-таки отсортированными по разделам?
Изменено: Владимир Русак - 06.09.2013 16:37:38
tDocument, особенности описания документов
Спасибо, Марина, придется внимательно перечитать приказ :(
Как-нибудь прокомментируете вопрос про значения AppliedFile/Kind?
Ваше возвращение на форум вселяет оптимизм :D
tDocument, особенности описания документов
STD_MP v04 в отличие от v03 содержит в себе массу мест, где можно указать документы. Дабы сильно не распылятся все места рассматривать не будем, а возьмем для примера Appendix/Document, Input_Data//Document и Providing_Pass_CadastralNumbers//Document. Если не учитывать наличие дополнительных параметров у Input_Data//Document все они одинаковы, т.е. сослаться на файл можно везде (хотя и необязательно). При этом в 412 Приказе упоминаются только «приложенные» и «использованные», различие я воспринимаю буквально – «приложенные» надо «приложить» к МП в виде файла, «использованные» прикладывать не надо, а достаточно указать реквизиты (соответственно в бумажный документ надо вывести в 2 четко обозначенных места). Собственно, вопросы:
[LIST=1]
[*]можно ли использовать этот алгоритм при формировании XML и что будет, если все же приложить файл в «использованных» документах?
[*]нужно ли дублировать Providing_Pass_CadastralNumbers//Document (и т.п.) в Appendix/Document? Или же Appendix надо использовать для документов, которые больше нигде не упоминаются?
[/LIST]Возможных вариантов и соответственно вопросов можно придумать значительно больше, но хотелось бы понять чего ожидает принимающая сторона (если она здесь появится :|).
И напоследок вопрос о значениях атрибута AppliedFile/Kind – какие требования кроются за «Образ документа» и «Электронный документ (одним файлом)» особенно это «(одним файлом)». Опять же - догадки есть, но хотелось бы ясности…
Расхождение площади участка при уточнении
Коллеги, ваши мнения более чем понятны, мы действовали примерно также, но всем палатам (или КИ?) угодить так и не удалось, поэтому реализовали настройку до какого знака округлять, теперь получается уже и она не спасает - делать еще одну настройку не сильно хочется, да и непонятно, как все-таки быть "не выводить 0" или "округлять до 1". При этом Оба варианта не дают ответа как в этих случаях относится к значению погрешности площади такого многоконтурного участка с прикладной точки зрения - с таким успехом можно ничего не вычислять, а писать случайные числа, результат будет такой же.
Кроме этого, даже если разработчики дадут нам однозначный ответ, совершенно непонятно как это скажется на мнении палат...
Расхождение площади участка при уточнении
[QUOTE]Роман Камерлох пишет:
Математически я с вами согласен. Но, т.к. погрешность округляется до целого, согласно примерам, мы округляем её по правилам округления всего участка. То есть, в данном случае до 1. Про примеры из новой редакции не знал. К ним эта версия схемы однозначно не подходит.[/QUOTE]Теперь уже я чего-то не знаю - о каких примерах идет речь и что за правила округления всего участка?
Расхождение площади участка при уточнении
[QUOTE]Роман Камерлох пишет:
неоднозначная ситуация.
Может ли погрешность измерений быть нулевой и поче[/QUOTE]Роман, речь о погрешности определения площади. Для расчета используется формула типа dP=3,5*[СКП точек контура]*[корень из площади]. Поэтому в случае "большого" контура все будет нормально, а в случае контура под столб ЛЭП, у которого площадь м.б. и 0,06м2 , а СКП точек=0.2 - получаем dP=0.17, соответственно после округления имеем 0.
И еще один довод - в проекте изменений 412 приказа (п. 9 и 10) заменили примеры для погрешностей контуров, в существующей редакции п. 101 написано "(1) 560,05 кв. м ± 3 кв. м", а в новой будет (если примут :D) - "(1) 560,05 кв. м ± 0,08 кв. м"
Расхождение площади участка при уточнении
Еще одна аналогичная ситуация - значение погрешности площади контуров многоконтурных ЗУ (tArea_Contour/Innccuracy). В случае мелких контуров (например, столбы ЛЭП) после округления до целого имеем погрешность =0.
Отказ по МП по схеме 04: The 'Version' attribute has an invalid value according to its data type, Помогите разобраться в чём ошибка
Похоже в палате были какие-то проблемы - сегодня пользователь получил письмо такого содержания:
[QUOTE]Межевой план прошел форматно-логический контроль. Результат загрузки
положительный. (Ответ на письмо с отрицательной загрузкой, отправленный
27.08.2013, считать неправильным)."

[/QUOTE]
Отказ по МП по схеме 04: The 'Version' attribute has an invalid value according to its data type, Помогите разобраться в чём ошибка
[QUOTE]Артем Попов пишет:
Заказчик сформировал zip-архив заново и отослал, но пока о результатах мне ничего не говорил... :|[/QUOTE]Спасибо, Артем!
Коллеги, а вообще у кого-нибудь есть информация, что МП по 4 схеме загружен в АИС ГКН?
Разработчики который уже день здесь отсутствуют :(
Отказ по МП по схеме 04: The 'Version' attribute has an invalid value according to its data type, Помогите разобраться в чём ошибка
Артем, решили ли Вы проблему?
У нас аналогичная ситуация - пользователь утверждает, что сначала пробовали загрузить файл, потом архив, но протоколы однотипные:

[CODE]Расширенный протокол импорта к протоколу № 95525
Имя файла: Файл GKUZU_3617F93C-29E9-45AF-B005-12A07E069589.xml. Проверка на соответствие XML схеме
Число объектов: 1
Из них загруженных: 0

Незагруженные объекты:
ОБЪЕКТ: Межевой план
ПРИЧИНА: Ошибка проверки структуры файла: The 'Version' attribute has an invalid value according to its data type.

[/CODE]т.е. все останавливается на контроле номера версии, хотя файл соответствует 4 схеме.
Очень хочется получить комментарии от разработчиков 26.08 ведь уже наступило...
Изменено: Владимир Русак - 27.08.2013 09:48:34
Подписывание ЦП файлов МП
Не уверен, что это можно считать "регламентируется", но все же:
[QUOTE]
[B]3.5.Требования к формированию ЭЦП файла[/B]

Все файлы, входящие в zip-архив, подписываются ЭЦП.
[/QUOTE]Взял из [url=https://rosreestr.ru/wps/PA_FCCLPGUMWPSPtalApp/ru.fccland.pgu.infoblock?ru.fccland.ibmportal.spring.portlet.handler.BeanNameParameterHandlerMapping-PATH=%2FFileDownloaderController&ru.fccland.ibmportal.spring.portlet.dispatcher.DispatcherServiceServlet.directRequest=x¶m_infoblock_name=cc_ib_mejved_vzaim_people¶m_infoblock_file_path=doc/Opisanie_v1.0-2.docx]Описание сервиса Росреестра прямого доступа из сети Internet Версия 1.0[/url], которое лежит [url=https://rosreestr.ru/wps/portal/p/cc_ib_state_services/cc_ib_function/cc_ib_electronic_state/cc_ib_mejved_vzaim_people]здесь[/url]
О необходимости подписывания есть упоминания и в 555 приказе:
[QUOTE]2. Заявление и необходимые для кадастрового учета документы, представляемые в орган кадастрового учета с использованием сетей связи общего пользования в форме электронных документов, должны быть подписаны электронными цифровыми подписями (ЭЦП) ...[/QUOTE]Наверное, это достаточное обоснование для требования из Описания
Несколько вопросов по многоконтурным участкам
Также предлагаю расширить вопрос №3:
3.1. Нужно/можно ли использовать обозначения/учетные номера контуров в качестве "... ЗУ, посредством которых обеспечивается доступ"(3 столбец таблицы в бумажном варианте) и если да, то куда их выводить - в Definition или в Other? Вопрос возник т.к. в схеме для Definition явно написано "Обозначение ЗУ...", в п. 105 требований (412 приказ) об этом ничего не сказано, а пользователи утверждают, что нужны контуры, а не ЗУ...
Контуры уточняемой многоконтурной части
Хотелось бы продолжить тему - какой формат должны иметь учетные номера контуров (атрибут Number)? Дело в том, что в ветках уточняемых и изменяемых ЗУ атрибут Number это текст (и называется "Обозначение или учетный номер контура части"), а в смежном уточняемом - целое (и называется "Учетный номер контура части"). Т.е. в обоих случаях одинаковое значение может быть только в виде номера и то, не учетного (т.к. в ГКН они храниться не будут). Или же для ЧЗУ в смежных ЗУ необходимо использовать номер, а в остальных обозначение вида 12:12:1234567:1/1(1).
Страницы: 1