та получается то что Вы описали впинципе что НКС что Дигитал не отображают вкрапленых контуров, НО в Дигитале можно прописать все это в ручном режиме а в НКС этого нельзя сделать и получается дилема одни требуют а другие просто не могут.
Я звонил розроботчикам НКСа те в упор нехотят ничего делать у них программа роботает на все 100 коректно то у Розроботчиков обменники НЕ правильные … и все.
и Эта проблема висит мертвым грузом еще с прошлой весны
Я не очень понял что значит
. НКС отлично отображает внутренних смежников если обменник сформирован из ГИС6 (столбы по крайней мере). просто на сегодняшний день дигиталс описывает геометрию внутренних смежников, так что НКС сходит немного с ума. я разработчикам конкретно описал проблему, в чем отличия геометрии обменника из ГИС6 и дигиталса. Будем надеяться что поправят в ближайшее время.
может и так я просто с ГИСом не имел дела, но с Дигитала это не получается сделать коректно
впринципе рекламный диск с ГИС-6 есть попробую поморочится
Диджиталс сохраняет смежников в следующем порядке:
Они всегда такое говорят что виноваты: а) исполнители б)разработчики. А если у них все давно работает, то что они там делают еще?
+100
То что Digitals не всегда корректно рисует смежников на планах (Сервис-Документы), не значит что так же сохраняются смежники в xml.
ну НКСу вообще все равно в каком порядке у нас создаются смежники. он их создает сам четко по порядку из каталога координат. Еще раз повторюсь почему для меня очень важна проблема, у нас обменники со столбами не единичный случай - в прошлом году их было порядка 300 шт. и получать столько протоколов как-то не очень хочется. Я не спорю что НКС кривой, но надо как-то решить эту проблему. Наши регистраторы не хотят пропускать обменные файлы.
Добрий день, форумчани!
Є в Digitals так проблемка, що при формуванні звіту по шаблонах DMT не відбувається описування суміжників вкраплених контурів. Тому хочу написати скрипт, який би перебирав всі суміжники, визначав, чи суміжник замкнутий і, якщо так, то описував його як вкраплений.
Доведеться, правда, повністю відмовитися від програмної функції формування суміжників в шаблонах DMT. Натомість буду формувати табличку тільки скриптами. Також, за одно, буду чистити кожний суміжник від дефісів (коли нема імені чи по-батькові).
Але от не знаю, як правильно мають бути описані ці вкраплені контури.
Я раніше описував їх так:
А(А’) - землі…
А(Б’) - землі…
А(В’) - землі…
Та знайшов тут на форумі іншу форму:
Тобто, за цією формою виходить, що вкраплені суміжники мають бути описані в кінці після звичайних наступними по порядку дубльованими буквами?
Як має бути правильно?
Виникла така, я б сказав дуже цікава проблема, є земельна ділянка, всі внутрішні угіддя вирізаються за допомогою складного полігону, проблем немає, але угіддя (воно-ж обмеження), яке проходить по зовнішньому контуру ділянки, НКС не рахує його і тому видає помилку, що загальна обчислена площа угідь, не співпадає з площею земельної ділянки, вказаної в електронному документі. Обмінний файл прикладаю.
Полігон, що знаходиться в шарі XML:угіддя під обмеженням, потрібно видалити.
З сумою площ угідь у вас все в порядку. Окреме угіддя під обмеженням не обов’язково видаляти і не обов’язково створювати. Тобто, обмеження не мусить бути окремим угіддям, але якщо створили окремим - то це не заважає.
paul, який сенс видаляти це угіддя?
Помилку НКС, скоріш за все, дає тому, що у вас відсутні кадастрові номери угідь. НКС просто не може прочитати угіддя як угіддя.
Наші реєстратори відправляють такі обмінні файли з помилкою. Після видалення цього угіддя під обмеженням (воно з’являється після конвертації з In4) - НКС пропускає.
На рахунок МОФ я з вами згідний. Але МОФ конвертує трохи по-іншому. Він, коли є обмеження, дублює угіддя. А в даному випадку, якщо видалити це угіддя, то частина ділянки під обмеженням буде взагалі не покритою жодним угіддям.
Так, не додивився. Найбільше угіддя (складний полігон) повинне охоплювати і обмеження також. Так буде вірно.
Доброго дня. Підкажіть будь ласка яка правильно повинна бути в DMT шаблоні таблиця координат з вирізками на ділянці? Бо перед вирізкою пустий рядок, тоді виходить що N це не кількість точок а кількість рядків в таблиці? Якщо на ділянці 63 точки то і в каталозі повинно бути 63 а їх 72. Як зробити щоб в таблиці відображало фактична кількість точок не враховуючи пустий рядок? І в загалі як правильно воно повинно бути з пустим рядком чи ні?
У колег користувачів ГІС-6 в звітних формах пустих рядків немає і за запитом у розробників Гіс-6, розробники такого ні де не бачили. Прошу будь ласка відповіді від розробників Дігіталс.