Порядок обхода точек

Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
XML-схемы » XML по земле
Страницы: 1 2 След.
Порядок обхода точек
Приветствую всех!
Есть несколько вопросов по 4-й версии xml-схемы. Пока что первый вопрос.
В Общих требованиях к заполнению межевого плана в формате XML, в пп.5 и 6 сказано:
Цитата
5. При описании границ земельного участка, который имеет внутрен-ние границы (контур с «дырками») нужно описать несколько элементов <Spatial_Element>. Сначала приводится описание границ внешнего контура, за ним должны быть описаны внутренние контура. При этом порядок обхода точек внешнего контура должен соответствовать направлению против часовой стрел-ки, а внутренних – по часовой стрелке.
6. Если участок имеет более одного внешнего контура, вместо ветки <Entity_Spatial> должна быть сформирована ветка <Contours>. Каждый внешний контур должен быть описан в элементе <Contour>, при этом правила описания его границ <Entity_Spatial> соответствуют правилам описания границ <Entity_Spatial> обычного земельного участка (см. п.5).
А в Приказе №412 читаем:
Цитата
49. В графы "Обозначение характерных точек границы" разделов текстовой части межевого плана вносятся обозначения на Чертеже характерных точек границы земельного участка или части земельного участка по часовой стрелке. Список характерных точек границы должен завершаться обозначением начальной точки.
На лицо явное противоречие. Возможно, я не правильно понимаю п.5 Требований, если можно, поясните.
Остальные вопросы задам позже. :)
Этот вопрос поднимали на фейсбуке
https://www.facebook.com/groups/140861242777574/permalink/143537075843324/
Артем, пожалуйста, скопируйте ответ из фейсбука сюда для людей с ограниченными способностями (как минимум для меня :) ), которым фейсбук при переходе по Вашей ссылке говорит, что они должны выполнить вход в систему чтобы просмотреть эту страницу.
Цитата
Константин Финагеев пишет:
Артем, пожалуйста, скопируйте ответ из фейсбука сюда
Присоединяюсь, группа то закрытая :D
Вопрос к составителям Схемы STD_MP v04:
В документе "Описание_структуры_STD_MP.doc", который входит в архив новой схемы, встретилась такая фраза (пункт 2.5) - "порядок обхода точек внешнего контура должен соответствовать направлению против часовой стрелки, а внутренних – по часовой стрелке", но по приказу №412, пункт 49, точки должны обходится по часовой стрелке всегда, и приказ-поправка №32 эту ситуацию не изменяет.
Собственно вопрос: зачем появилось такое сложное требование к обходу контуров? И дополнительный вопрос: зачем вообще регулировать порядок обхода контуров?
Нравится · · Подписаться на обновления публикации · 22 июня в 18:34





  • Видели: 46


    Игорю Дегтярю это понравилось.











  • Роман Трущенков Особенность хранения данных в ПО, используемом кадастровыми палатами. Oracle spatital.
    22 июня в 18:53 · Нравится












  • Виталий Глезер Я этого решения не принимал, но оно правильное. В сложных случаях необходимо знать, где находится внутренность участка и не всегда это можно определить прямо не задав. Например, направлением обхода.
    22 июня в 18:59 · Нравится












  • Артём Попов Спасибо за ответы.
    Немного неудобно будет с этими обходами (многие ГИС не регулируют подобные правила), *но это решаемо*
    Меня смущает то, что это требование противоречит приказу.

    22 июня в 19:04 · Отредактировано · Нравится












  • Артём Попов И еще вопрос: на этапе загрузки вы будете проверять правила обхода?
    22 июня в 19:05 · Нравится












  • Виталий Глезер Составители приказа, видимо, не учитывали, что участок может иметь форму бублика
    Я реализацией не занимался. Надо уточнить у программистов - Фокиной или Пахомова. Однако боюсь, что на уровне ФЛК проверить это затруднительно.

    22 июня в 19:12 · Нравится












  • Артём Попов " на уровне ФЛК проверить это затруднительно" - вот и я к тому же.
    Тогда напрашиваются следующие вопросы:
    1) зачем это требование включать в описание, если его проверить сложно?
    2) а если не проверять, то что будет, если в Oracle Spatial попадут контура нарушающие эти правила?

    22 июня в 19:21 · Нравится












  • Виталий Глезер Как минимум,будут считаться несуразные площади и будут пересекаться участки. С участками со сложной топологией, вообще много мороки.
    Альтернативу может предложить? Для "бублика" например? Но еще раз повторяю, поговорите с теми, кто знает реализацию.

    22 июня в 19:26 · Нравится












  • Артём Попов А "те кто знает реализацию" в вашей команде есть?
    22 июня в 19:28 · Нравится












  • Виталий Глезер Я вполне ясно написал к кому обратиться. Фокина, правда, в отпуске, но Пахомов доступен, по крайней мере в рабочее время.
    22 июня в 19:35 · Нравится












  • Виталий Глезер Он в групппе
    22 июня в 19:36 · Нравится












  • Артём Попов Тогда это уже для Пахомова:
    судя по наспех нарытому -https://forums.oracle.com/thread/2348345 - у Oracle есть функция исправляющая порядок обхода ( SDO_UTIL.RECTIFY_GEOMETRY ). Почему бы все импортируемые контура не прогонять через нее и избавить сторонних разработчиков мучится с особенностями своих ГИС?




    polygons - array clockwise | Oracle Forums
    forums.oracle.com




    22 июня в 19:42 · Нравится · Убрать предварительный просмотр












  • Виталий Глезер Не знаю, как работает эта функция. Однако представьте себе участок, ограниченный тремя концентрическими окружностями. Какой именно порядок обхода исправлять?
    22 июня в 19:45 · Нравится












  • Артём Попов Насколько я знаю дуги xml в схеме не предусмотрены, но если мы предположим что у нас 3 замкнутых полигона один в другом, то есть методология позволяющая установить, количество контуров покрывающих некоторую точку, и отсюда можно понять какой контур является дыркой (количество покрывающих контуров чётно) а какой нет.
    в любом случае, доверимся Oracle и предположим, что он всё исправит как ему надо

    22 июня в 19:51 · Отредактировано · Нравится












  • Виталий Глезер Вы не поняли. Три концентрические окружности могут задавать границы разных множеств. Как, кроме направлением обхода указать, что мы имеем в виду?
    22 июня в 19:55 · Нравится












  • Albert Demidenko Собственно к методике описания топологии внешних и внутренних контуров вопросов нет. Смущает различие их описания для бумажного варианта ("все по часовой") и для XML. Одновременно с этим Приказ 412 четко указывает "при различии между электронным и бумажным вариантом, приоритет отдается бумажному". Нужно или привести в соответствие нормативную базу, или в XML записывать в соответствии с Приказом.
    24 июня в 11:52 · Нравится












  • Юрий Городничев Совершенно очевидно, что электронное представление просто по определению не может по форме соответствовать бумажному варианту межевого плана. Да это и не требуется в 412 приказе. В этом приказе определяется тот состав сведений о земельных участках (о...Еще
    24 июня в 13:57 · Нравится












  • Юрий Городничев У Вас вероятно текст 412 приказа не точный. Приведенной Вами цитаты нет в этом приказе.
    Если межевой план оформляется в форме электронного документа, заверенного электронной подписью, то он ничем «не хуже» бумажного документа.

    24 июня в 14:11 · Нравится












  • Albert Demidenko Извините, за неточность. Это требование не Приказа, а территориальных органов кадастрового учета. Собственно предложение мое заключалось в том, чтобы п.49 "Требований к оформлению МП..." привести в соответствие с XML.
    24 июня в 14:55 · Нравится












  • Юрий Городничев Не забывайте, что в бумажном документе имеются схемы, на которых видно какой контур внешний, какой внутренний и т.п.
    В любом случае это уже полномочия Минэкономразвития.

    24 июня в 15:48 · Нравится












  • Игорь Дегтярь Требование бредовое. Есть очень простой способ определить внешний контур: у кого площадь больше, тот и внешний. Можно было просто потребовать первым выгружать внешний контур, а потом вырезы. Теперь понесутся отказы, в печать одно пошло, в XML другое, тем более, что это требование противоречит 412 приказу, если конечно в него не внесут изменения. К тому же что бы понять в какую сторону обход нужно знать площадь )))
    24 июня в 20:44 · Отредактировано · Нравится












  • Виталий Глезер Игорь! Во-первых, попросил бы Вас соблюдать приличия. Вы имеете дело с людьми взрослыми и, честное слово, неглупыми (не о себе). Во-вторых, я Вам сходу приведу пример, когда на участке со сложной топологией ваш способ не будет работать. В третьих, то, что Вы предлагаете, нисколько не лучше того, что реализовано, скорее хуже и запутанней и также не проверяется. И так же не предусмотрено 412 приказом.
    24 июня в 20:48 · Нравится












  • Игорь Дегтярь Прошу прощение, если кого обидел. Интересен ваш пример для общего развития, когда площадь внешнего контура будет меньше выреза. А чем плох мой второй вариант? Разве не логично первым в Spatial_Element запихнуть внешний контур? Да на худой конец постави...Еще
    24 июня в 21:18 · Нравится












  • Albert Demidenko Игорь! Обсуждать форму представления координат считаю далее нецелесообразным. В ГКН уже накоплена база данных по земельным участкам в соответствии с принятыми "правилами игры". Лишняя дискуссия на эту тему только отнимает время у разработчиков. Именно из-за возможности неконструктивных диалогов они долгое время не решались открыть обсуждение сервиса электронных услуг.
    24 июня в 21:31 · Отредактировано · Нравится












  • Виталий Глезер Разумеется, часть по площади меньше целого. Но тогда, в случае в общем случае, придется явно показывать где чья часть, а это ни сколько не проще и никак не легче контролируется, чем простое правило обхода. Вообще, рассуждать о том, что можно было сделать по-другому, можно сколько угодно. Укажите на ошибку или на то, как сделать удобнее. Пока не вижу чем то, что Вы предлагаете лучше или удобнее.
    24 июня в 21:32 · Нравится












  • Артём Попов Albert Demidenko, проблема в том, что это новое требование, по крайней мере раньше порядок координат регламентировался текстом приказа 412 и для xml пока таких требований не было. Поэтому "накоплена база данных" была с использованием других правил, хотя я могу ошибаться...
    24 июня в 21:44 · Отредактировано · Нравится












  • Albert Demidenko Artem Popov, полностью с Вами согласен. Поэтому и прошу согласовать порядок обхода. Пусть будет однообразно - как для отчета, так и для XML.
    24 июня в 21:50 · Нравится












  • Игорь Дегтярь "49. В графы "Обозначение характерных точек границы" разделов текстовой части межевого плана вносятся обозначения на Чертеже характерных точек границы земельного участка или части земельного участка по часовой стрелке." Вот Вам и ошибка. Как быть с эти...Еще
    24 июня в 22:16 · Нравится












  • Игорь Дегтярь Albert Demidenko я считаю даже очень целесообразным. Я так понимаю для этих целей и была создана эта группа. Подобные косяки разработчиков вытекают потом у нас в виде немалых убытков. Когда наша техподдержка объясняет пользователям, что это не мы приду...Еще
    24 июня в 22:29 · Нравится












  • Андрей Чернов Виталий Глезер:
    "Однако представьте себе участок, ограниченный тремя концентрическими окружностями. Какой именно порядок обхода исправлять?"
    Если не брать случай, когда внешнего контура нет (рассматривать только замкнутые множества - не рассматривать земельный участок "Россия-матушка"), то 3 окружности задают одно множество. По следующему принципу. Если точка лежит внутри нечетного числа контуров, то она внутри земельного участка, если в четном, то вне.

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

    24 июня в 22:50 · Нравится


  • Дмитрий Бирючков Ольга, а в бумажном варианте согласно 412 приказа? Согласно пункта "49. В графы "Обозначение характерных точек границы" разделов текстовой части межевого плана вносятся обозначения на Чертеже характерных точек границы земельного участка или части земельного участка по часовой стрелке." Или в бумажном варианте внешний контур по часовой а в XML против часовой?
    26 июня в 18:26 · Нравится

  • Ольга Фокина Да, именно так: в XML против, в бумаге по часовой. С МЭР данное расхождение согласовано.
    26 июня в 18:32 · Нравится

  • Игорь Дегтярь А против как: 1, 5, 4, 3, 2, или 5, 4, 3, 2, 1? Точнее 1, 5, 4, 3, 2, 1 или 5, 4, 3, 2, 1, 5? Т.е. начальная точка в печатной форме должна соответствовать XML?
    26 июня в 19:04 · Отредактировано · Нравится · 2

  • Дмитрий Бирючков Игорь, а 1-5 это что Вы имеете ввиду? Номер межевой точки? Я так понимаю, если ЗУ имеет 4 точки, номер 1 это первая точка полигона и нумерация (1...4) соответствует движению ПО часовой стрелке, тогда на бумаге будет 1,2,3,4,1 а в XML будет 1,4,3,2,1
    26 июня в 19:14 · Отредактировано · Нравится

  • Игорь Дегтярь Дмитрий, по сути Вы правы и в теории так оно и должно быть. Вопрос как АИС всосет этот контур, как бы не получилось, что он их будет втягивать банально в обратном порядке, тогда полетят отказы.
    26 июня в 19:14 · Нравится

  • Николай Малютин Может "полететь" описание смежеств, по примеру того, как они сейчас зачастую "летят" в кадастровых выписках.
    26 июня в 19:21 · Нравится

  • Роман Камерлох Ольга, а что значит "С МЭР данное расхождение согласовано". Есть какой то документ об этом? Или это негласное согласование?
    27 июня в 9:21 · Нравится

  • Ольга Фокина согласовано в рабочем порядке. Обещали в след. версии поправить это в тексте приказа, если таковая будет.
Изменено: Дмитрий Бирючков - 12.08.2013 08:42:34
Уважаемая Ольга!
Не могли бы Вы более конкретно ответить на данный вопрос. Как все таки должны нумероваться точки на бумаге и в xml? Желательно на примере.
Цитата
Как все таки должны нумероваться точки на бумаге и в xml?
Сергей, а что именно непонятно после прочтения процитированной переписки с facebook?
http://forum-rosreestr.ru/messages/forum25/topic325/message5209/#message5209
Цитата
Дмитрий Бирючков пишет:
а что именно непонятно
Не понятно то, как все таки должны нумероваться точки. Если брать за основу 412 приказ, то получается по часовой стрелке 1, 2 , 3 ... 1. Как это будет выглядеть в xml файле? И так ли это критично, если и там и там будет нумерация против часовой?
Цитата
Сергей Авакимян пишет:
Цитата
Дмитрий Бирючков пишет:
а что именно непонятно
Не понятно то, как все таки должны нумероваться точки. Если брать за основу 412 приказ, то получается по часовой стрелке 1, 2 , 3 ... 1. Как это будет выглядеть в xml файле? И так ли это критично, если и там и там будет нумерация против часовой?
"... в XML против, в бумаге по часовой. С МЭР данное расхождение согласовано... " Что непонятно в данном предложении?
Изменено: Дмитрий Бирючков - 12.08.2013 13:56:02
Цитата
Дмитрий Бирючков пишет:
Что непонятно в данном предложении?
Можно конкретный пример?


И еще. А кадастровые палаты на местах знают об этой "договоренности с МЭР"? Или при получении отказов кадастровый инженер должен будет им об этом сообщать?
Изменено: Сергей Авакимян - 12.08.2013 14:21:43
Сергей, если под конкретным примером понимаете файл XML и печатную форму МП 4 версии - нет, нельзя, у меня из нет готовых, просто физически нет.
Но Вы не ответили на мой вопрос.
Изменено: Дмитрий Бирючков - 12.08.2013 14:24:20
Цитата
Дмитрий Бирючков пишет:
у меня из нет готовых
Достаточно просто указать порядок точек на бумаге и в xml.
Цитата
Сергей Авакимян пишет:
Цитата
Дмитрий Бирючков пишет:
у меня из нет готовых
Достаточно просто указать порядок точек на бумаге и в xml.
PS
Цитата
Я так понимаю, если ЗУ имеет 4 точки, номер 1 это первая точка полигона и нумерация (1...4) соответствует движению ПО часовой стрелке, тогда на бумаге будет 1,2,3,4,1 а в XML будет 1,4,3,2,1
Не годится?
Цитата
Дмитрий Бирючков пишет:
Не годится?
Ну, если Вы гарантируете, что это так и есть, то годится. Только не понятно, почему нельзя было это указать в Описании схемы? У меня готова программа под 4-ю версию, в которой нумерация, согласно Описанию, идет против часовой. Теперь придется в срочном порядке вносить изменения.
Цитата
Сергей Авакимян пишет:
Ну, если Вы гарантируете, что это так и есть, то годится.
Я не имею оснований это гарантировать.
Данный вопрос уже обсуждали и я просто цитировал фразы из прошедшего объяснения.
Я не представитель Росреестра! Посмотрите мой профиль.
Кстати, как модератор форума, рекомендую Вам дополнить информация в Вашем профиле с соответствии с пунктом 2 http://forum-rosreestr.ru/rules/
Изменено: Дмитрий Бирючков - 12.08.2013 14:43:04
Спасибо большое за процитированную информацию. Я восхищен и впечатлен.

Для описания внешней границы участка, который не имеет внутренних границ, в xml-файле точно так же должен использоваться порядок описания точек вешней границы против часовой стрелки или при отсутствии внутренних границ этого уже не требуется и порядок должен быть по часовой стрелке?
Цитата
Константин Финагеев пишет:
Для описания внешней границы участка, который не имеет внутренних границ, в xml-файле точно так же должен использоваться порядок описания точек вешней границы против часовой стрелки или при отсутствии внутренних границ этого уже не требуется и порядок должен быть по часовой стрелке?
вот этот вариант
Цитата
Константин Финагеев пишет:
должен использоваться порядок описания точек вешней границы против часовой стрелки
Спасибо. Артем, я Вам, конечно же верю, но в непонятных/спорных ситуациях хотелось бы получать ответы/цитаты непосредственно разработчиков схемы, иначе остается только надеяться на то, что их молчание подтверждает озвученную другими истину, а не является нежеланием обсуждать ту или иную тему.

И еще почти по данной теме: несмотря на эти требования о порядке описания точек по/против часовой стрелки, при использовании SpecifyRelatedParcel/ChangeBorder последовательность точек должна во всех случаях исключительно соответствовать описанной в п.7 "Описания формата представления файлов обмена информацией" или есть какие-то оговорки/исключения?
Судя по ответам/цитатам разработчиков, порядок вершин должен быть такой как нужно Oracle Spatial, оттуда это правило и пришло (а в оракл из геометрии) - внешние контура против ч.с., внутренние (при наличии) по ч.с.
//это мои выводы из общения с разработчиками, общение, как вы видели, тоже нервное вышло :)
Просто порядок описания вершин изменяемой границы в SpecifyRelatedParcel более важен для успешной загрузки содержимого этого элемента и на него вроде как существуют (предположительно) и распространяются определенные правила. Неупорядоченная информация, уже хранящаяся в ГКН (контуры с самыми разнообразными порядками вершин, которые никто не собирается автоматически приводить к одному виду), большое количество контуров с обходом по часовой стрелке, которые были поставлены на учет и исправлены в течение всего времени действия первых трех схем, и декларируемый новый порядок обхода вершин в 4 версии схемы, который тоже вроде как никто не будет контролировать и проверять при загрузке - все это хорошо и замечательно, хаос и всякие новые правила создают отличную иллюзию прогресса и объема проводимых работ и исследований. Но, тот кто знает/сталкивался со спецификой оформления SpecifyRelatedParcel/ChangeBorder (особенно когда нужно учитывать порядок вершин в исходном контуре), вроде как должен уже на воду дуть, поэтому меня очень интересует достоверная и точная информация именно об этом моменте. Эмоции меня не интересуют при обсуждении технических вопросов :))), главное - правда.
Еще вопрос про порядок точек в Entity_Spatial, во второй его части, в описании границ (Entity_Spatial/Borders): в Spatial_Element выгружаем точки 1, 4, 3, 2, 1:

Код
<NewOrdinate Num_Geopoint="1" Point_Pref="н" />
<NewOrdinate Num_Geopoint="4" Point_Pref="н" />
<NewOrdinate Num_Geopoint="3" Point_Pref="н" />
<NewOrdinate Num_Geopoint="2" Point_Pref="н" />
<NewOrdinate Num_Geopoint="1" Point_Pref="н" />

Как должно выглядеть при этом описание границы? Ребра тоже должны идти в обратном порядке против часовой стрелки (я помню, что в Point1/Point2 указывается порядковый номер точки в элементе, который с Num_Geopoint не имеет ничего общего)?

Код
<Borders>
 <Border Spatial="1" Point1="1" Point2="2">
  <Border Spatial="1" Point1="2" Point2="3">
  <Border Spatial="1" Point1="3" Point2="4">
  <Border Spatial="1" Point1="4" Point2="1">
</Borders>

или

Код
<Borders>
 <Border Spatial="1" Point1="1" Point2="4">
  <Border Spatial="1" Point1="4" Point2="3">
  <Border Spatial="1" Point1="3" Point2="2">
  <Border Spatial="1" Point1="2" Point2="1">
</Borders>

?
Цитата
Константин Финагеев пишет:
Как должно выглядеть при этом описание границы? Ребра тоже должны идти в обратном порядке против часовой стрелки (я помню, что в Point1/Point2 указывается порядковый номер точки в элементе, который с Num_Geopoint не имеет ничего общего)?
Да вчера тоже задумались над этим.
Присоединяюсь к вопросу.
Удивительно, все одновременно об одном и том же думают.
Я уже даже текст вопроса подготовил.
Также жду ответа.
Добавлю и я один вопрос:
В разделе RelatedParcels, в элементе Definition порядок точек тоже нужно менять против часовой стрелки или он должен соответствовать 6 реквзиту раздела "Сведения об уточняемых земельных участках и их частях"?
Страницы: 1 2 След.
Читают тему (гостей: 1, пользователей: 0, из них скрытых: 0)