KVZU_v06: проблемы с номерами точек и Border

Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
XML-схемы » XML по земле
KVZU_v06: проблемы с номерами точек и Border
1) В описании xsd у элемента tSpelementUnitZUOut есть атрибут SuNmb, который описывается так: "Номер части элемента (порядок обхода)".
2) У tOrdinateOut есть NumGeopoint - Номер точки (межевой точки)
3) У tBorder есть три атрибута :
Spatial - Порядковый номер элемента контура
Point1 - Порядковый номер точки1 в элементе
Point2 - Порядковый номер точки2 в элементе
Т.е. чтобы мне выяснить что за ребро описано и с какими номерами точек, то по идее нужно сделать как-то так:
Код
protected static void GetBorderPointNames(tEntitySpatialBordersZUOut es, tBorder border, out string point1, out string point2)
{
    var SpatialElement = es.SpatialElement[border.Spatial - 1];
    var su1 = SpatialElement.SpelementUnit[border.Point1 - 1];
    point1 = su1.Ordinate==null ? su1.SuNmb : su1.Ordinate.NumGeopoint;
    var su2 = SpatialElement.SpelementUnit[border.Point2 - 1];
    point2 = su2.Ordinate==null ? su2.SuNmb : su2.Ordinate.NumGeopoint;
}
///Код упростил и убрал доп проверки.
И это работало с выписками 5-ой версии.
Теперь получили выписку где значения SuNmb, Point1, Point2 противоречат описаниям:

Код
<ns3:SpatialElement>
   <ns3:SpelementUnit TypeUnit="Точка" SuNmb="12693">
      <ns3:Ordinate X="5932889.15" Y="305709.07" OrdNmb="1" DeltaGeopoint="7.50" />
   </ns3:SpelementUnit>
   <ns3:SpelementUnit TypeUnit="Точка" SuNmb="3014">
      <ns3:Ordinate X="5932880.19" Y="305695.47" OrdNmb="1" DeltaGeopoint="7.50" />
   </ns3:SpelementUnit>
   <ns3:SpelementUnit TypeUnit="Точка" SuNmb="3013">
      <ns3:Ordinate X="5932930.25" Y="305693.14" OrdNmb="1" DeltaGeopoint="7.50" />
   </ns3:SpelementUnit>
   <ns3:SpelementUnit TypeUnit="Точка" SuNmb="12799">
      <ns3:Ordinate X="5932942.61" Y="305691.85" OrdNmb="1" DeltaGeopoint="7.50" />
   </ns3:SpelementUnit>
.....
<ns3:Borders>
   <ns3:Border Spatial="1" Point1="12693" Point2="3014">
      <ns3:Edge>
         <ns3:Length>16.29</ns3:Length>
         <ns3:DirectionAngle>
            <ns3:Degree>236</ns3:Degree>
            <ns3:Minute>37</ns3:Minute>
         </ns3:DirectionAngle>
      </ns3:Edge>
   </ns3:Border>
   <ns3:Border Spatial="1" Point1="3014" Point2="3013">
      <ns3:Edge>
         <ns3:Length>50.11</ns3:Length>
         <ns3:DirectionAngle>
            <ns3:Degree>357</ns3:Degree>
            <ns3:Minute>20</ns3:Minute>
         </ns3:DirectionAngle>
      </ns3:Edge>
   </ns3:Border>
   <ns3:Border Spatial="1" Point1="3013" Point2="12799">
      <ns3:Edge>
         <ns3:Length>12.43</ns3:Length>
         <ns3:DirectionAngle>
            <ns3:Degree>354</ns3:Degree>
            <ns3:Minute>3</ns3:Minute>
         </ns3:DirectionAngle>
      </ns3:Edge>
   </ns3:Border>
   <ns3:Border Spatial="1" Point1="12799" Point2="3114">
      <ns3:Edge>
         <ns3:Length>12.36</ns3:Length>
         <ns3:DirectionAngle>
            <ns3:Degree>0</ns3:Degree>
            <ns3:Minute>8</ns3:Minute>
         </ns3:DirectionAngle>
      </ns3:Edge>
   </ns3:Border>
....
 
Т.е. из этого файла я делаю вывод, что
SuNmb - это на самом деле номер межевой точки (а не порядок обхода, т.к. они нумеруются не по порядку)
Point1, Point2 - это на самом деле тоже номера межевых точек, а не порядковые номера в элементе.
при этом Spatial - таки Порядковый номер элемента контура

Так конечно для меня проще - зная бордер, я сразу знаю номера точек, НО это же не соответствует документации, и вдруг такое поведение изменится?
Коллеги сталкивались с таким? или элемент Бордер не анализируете? Может знаете, разработчикам куда писать по этому вопросу?
//выписку прикрепляю. кстати в выписке баг, о котором я упоминал тут: http://forum-rosreestr.ru/messages/forum25/topic465/message7908/#message7908
Response №50-6704144.zip (497.44 КБ)
Страницы: Пред. 1 2
Ответы
Цитата
Сергей Авакимян пишет:
Алексей, но Вы же прекрасно знаете, сколько в стране КП, столько и мнений.
Цитата
Алексей Ябров пишет:
Мне кажется и отстаивать надо свои права ссылаясь на него же, точнее на отсутствие в нем таких требований.
В том то и дело, что в Приказе отсутствует понятие "Уточнение части границы". Я не понимаю, зачем вообще нужен 412 Приказ в таком виде, да еще не поленились внести изменения 89-м Приказом. Ведь там сказано в п.18 Общих положений:
Цитата


Если договором подряда предусмотрена подготовка межевого плана на бумажном носителе, то межевой план подготавливается дополнительно в форме документа на бумажном носителе, заверенного подписью и печатью кадастрового инженера, подготовившего такой план
А большая часть приказа как раз посвящена оформлению именно бумажного варианта. Лучше бы выпустили аналогичный документ по "оформлению" xml-версии МП.
Тут я с вами согласен на все 100%.
Цитата
Алексей Ябров пишет:
И в акте согласования вы не пишите, что с точки 1 до точки 10 у вас идет два смежника. Все равно вы выясняете на местности, что с 1 до 5 это один смежник, а с 5 до 10 другой. Даете смежникам на подпись, что они с этим согласны.
Вот с этого я и начинал. Иногда бывает невозможно найти точку "5". Не знают хозяева где граница между ними, а чтобы узнать нужно уже им в свою очередь межевание делать. Или хозяев нет в принципе и согласование проводится через публикацию. Многие кадастровые пропускают такой вариант, что вполне логично, по указанным мной причинам.
Страницы: Пред. 1 2
Читают тему (гостей: 6, пользователей: 0, из них скрытых: 0)