Новые схемы выписок и КПТ

Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти  
XML-схемы » XML по земле
Новые схемы выписок и КПТ
Сейчас прислали 2 свежих xml от росреестра - судя по ним, вышли новые схемы КВЗУ v06 и КПТ v09 похожие на те, что обсуждались тут: https://forum-rosreestr.ru/forum25/topic456/
Собственно вопросы:
  • Давно ли они в действии?
  • нет ли ссылки на скачивание официальных новых схем?
  • Росреестр объявлял о вводе этих новых схем и предварительно их публиковал? (на старом сайте я видел новые схемы только для Зон - ZoneToGKN)
2015_1_12_01_2015.zip (100.51 КБ)
Изменено: Артем Попов - 12.01.2015 16:17:14
Страницы: Пред. 1 2 3
Ответы
Цитата
Борис Деточкин пишет:
Вот к слову сказать, сейчас, в последних версиях схем, я не вижу отличий в версиях подсхем для разных схем. В каких схемах отличаются подсхемы?
Акт обследования 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_nedvijj_blanki_xm­l_files¶m_infoblock_file_path=doc/InspectionAct_v01.rar
Справочник dAllDocuments_v01.xsd дата изменения 14.05.2014
и
Карта (план) https://rosreestr.ru/upload/Doc/MapPlan_v01.rar
Справочник dAllDocuments_v01.xsd дата изменения 28.08.2014
Были различия и по составу.

Но вопрос снят, т.к. сейчас в карта (плане) этот справочник заменён на dAllDocuments_v02.xsd. Но опять таки, выложили новую схему, хот пометку бы поставили, что схема обновлена. Не первый раз такое наблюдаю. Конечно это не к Вам претензия, а к Росреестру.
Цитата
Юрий Федоринов пишет:
Правила это не приказ,
Названия переменных могут не совпадать с названиями узлов
Да, могут, но когда совпадают намного проще. Нужно найти пропертю, контрол+ф и ввёл имя элемент или атрибута, намного проще, чем вспоминать, а как я у себя называл переменную. Можно конечно и проперть обзывать типа Entity_Spatial, работать будет, но код не красивый.
В общем всё это флуд. Ребята идут правильным путём и это радует. Есть правила регулирующие требования разработки схем для гос. услуг, если есть вопросы почему сделано так - можно почитать.
Потенциальная проблема в новом справочнике dUnit_v01.xsd для единицы измерения "Минута"
dUnits.png (10.09 КБ)
Цитата
Юрий Федоринов пишет:
Потенциальная проблема в новом справочнике dUnit_v01.xsd для единицы измерения "Минута"
А какие проблемы? Если бы пробел в вэлью был, тогда да, а в описании ничего страшного.
не обошлось и без моей любимой проблемы - одинаковые имена которые не любит xjc...
Снимок.png (38.98 КБ)
Изменено: Владислав Филиппов - 15.01.2015 14:44:41
Цитата
Игорь Дегтярь пишет:
Цитата
Юрий Федоринов пишет:
Потенциальная проблема в новом справочнике dUnit_v01.xsd для единицы измерения "Минута"
А какие проблемы? Если бы пробел в вэлью был, тогда да, а в описании ничего страшного.
Точно. попутал
Цитата
Владислав Филиппов пишет:
не обошлось и без моей любимой проблемы - одинаковые имена которые не любит xjc...
Странно, у них и ТНС отличаются. Генератор разве не должен их в разные классы сложить?
Борис, вот тут я ничего сказать не могу. Надо спросить у Java-гуру :D
Эта проблема у меня была при использовании демаршалинга в JDK 6 и сейчас в JDK 8
вот что я делал:
Код
xjc -extension -p org.tomskgislab.landprocessor.shema.kpt9 -d out -b binding.xml KPT_v09.xsd

весь код
То ли я туплю... А что в новых схемах КПТ убрали сведения о частях участков (SubParcels)?
Изменено: Алексей Ябров - 16.01.2015 06:59:50
Похоже на то.
Цитата
Алексей Ябров пишет:
То ли я туплю... А что в новых схемах КПТ убрали сведения о частях участков (SubParcels)?
Ну они там и были раньше в жутко кастрированном виде, без границ.
коллеги, буду признателен за примеры новых документов. шлите на filippov70[at]gmail[dot]com
Цитата
Владислав Филиппов пишет:
шлите на filippov70[at]gmail[dot]comИ на
И на xax_nv[at]inbox[dot]ru. В первую очередь интересуют KVZP всех возможных видов (ЕЗ, многоконтурные, с "дырками", с частями). Но и от KPT не откажусь.
Цитата
Владислав Филиппов пишет:
Борис, вот тут я ничего сказать не могу. Надо спросить у Java-гуру
Эта проблема у меня была при использовании демаршалинга в JDK 6 и сейчас в JDK 8
вот что я делал:
Код
 xjc -extension -p org.tomskgislab.landprocessor.shema.kpt9 -d out -b binding.xml KPT_v09.xsd 

весь код
Поковырялся на досуге и выяснил, что если не использовать демаршализацию в один пакет свой указанный в параметре, то тогда все нормально, все раскладывается по классам. Иначе приходится в файле биндингов указывать переопределения классов. Типа такого вот:

<jaxb:bindings schemaLocation="KPT_v09/KPT/KPT_v09.xsd">
<jaxb:bindings node="//xs:complexType[@name='tName']">
<jaxb:class name="KptTName"/>
</jaxb:bindings>
</jaxb:bindings>
<jaxb:bindings schemaLocation="KPT_v09/SchemaCommon/_AddressOut_v03.xsd">
<jaxb:bindings node="//xs:complexType[@name='tName']">
<jaxb:class name="AdressTName"/>
</jaxb:bindings>
</jaxb:bindings>
Вроде проделана большая работа по вынесению общих типов в отдельные схемы, однако есть еще типы, которые, по моему мнению, можно было сделать общими, а не объявлять заново в КПТ, КВЗУ, КПЗУ:
<xs:complexType name="tUtilization">
<xs:complexType name="tAreaOut">
<xs:complexType name="tAreaCadastralBlock">
<xs:complexType name="tDuration">

и т.п.
Просто получаются одни и теже сущности объявляются как разные классы, соответсенно и алгоритмы обработки нужно будет дублировать или "ручками" выделять общего потомка, а из этих делать наследников, у которых новое только неймспэйс.
Цитата
Артем Попов пишет:
Вроде проделана большая работа по вынесению общих типов в отдельные схемы, однако есть еще типы, которые, по моему мнению, можно было сделать общими, а не объявлять заново в КПТ, КВЗУ, КПЗУ:
<xs:complexType name="tUtilization">
<xs:complexType name="tAreaOut">
<xs:complexType name="tAreaCadastralBlock">
<xs:complexType name="tDuration">

и т.п.
Просто получаются одни и теже сущности объявляются как разные классы, соответсенно и алгоритмы обработки нужно будет дублировать или "ручками" выделять общего потомка, а из этих делать наследников, у которых новое только неймспэйс.
также не понятно, почему если у этих типов есть собственная версия, зачем их продолжают привязывать к версии документа (создают пути вида https://portal.rosreestr.ru/xsl/GKN/KPT/09/schema/KPT_v09/KPT/SchemaCommon/P_CommonSimpleType_v01.xsd)
это же SchemaCommon!
Цитата
Дмитрий Баландин пишет:
Цитата
Артем Попов пишет:
Вроде проделана большая работа по вынесению общих типов в отдельные схемы, однако есть еще типы, которые, по моему мнению, можно было сделать общими, а не объявлять заново в КПТ, КВЗУ, КПЗУ:
<xs:complexType name="tUtilization">
<xs:complexType name="tAreaOut">
<xs:complexType name="tAreaCadastralBlock">
<xs:complexType name="tDuration">

и т.п.
Просто получаются одни и теже сущности объявляются как разные классы, соответсенно и алгоритмы обработки нужно будет дублировать или "ручками" выделять общего потомка, а из этих делать наследников, у которых новое только неймспэйс.
также не понятно, почему если у этих типов есть собственная версия, зачем их продолжают привязывать к версии документа (создают пути вида https://portal.rosreestr.ru/xsl/ GKN/KPT/09/schema/KPT_v09/KPT/SchemaCommon/ P_CommonSimpleType_v01.xsd)
это же SchemaCommon!
Не совсем понятно про версию документа и собственную версию для указанных типов и про пути к справочнику простых типов. Подробнее, если можно.
Например, справочник регионовРФ для КПТ
https://portal.rosreestr.ru/xsl/GKN/KPT/09/schema/KPT_v09/SchemaCommon/dAllDocumentsOut_v02.xsd
Это понимается, как
d = Словарь
AllDocumentsOut = Все документы
_v02 = версии 2.
т.е. словарь Документов версии 2

теперь смотрим xsl схемы для других документов:
КВЗУ:
<xsl:variable name="var" select="document(concat($urlPrefixDict, 'schema/KVZU_v06/SchemaCommon/dAllDocumentsOut_v02.xsd'))"/>
КПЗУ:
<xsl:variable name="var" select="document(concat($urlPrefixDict, 'schema/KPZU_v05/SchemaCommon/dAllDocumentsOut_v02.xsd'))"/>

Все 3 вида документов (КПТ, КВЗУ, КПЗУ) используют один и тот же словарь.

Зачем, в этом случае, существует разделение по разным каталогам?
КПТ: <xsl:variable name="ddoc" select="document(concat($urlPrefixDict,'schema/KPT_v09/SchemaCommon/dAllDocumentsOut_v02.xsd'))"/>
КВЗУ: <xsl:variable name="var" select="document(concat($urlPrefixDict, 'schema/KVZU_v06/SchemaCommon/dAllDocumentsOut_v02.xsd'))"/>
КПЗУ: <xsl:variable name="var" select="document(concat($urlPrefixDict, 'schema/KPZU_v05/SchemaCommon/dAllDocumentsOut_v02.xsd'))"/>

Но даже если смотреть внутри одного типа документов, например КПТ
КПТ: <xsl:variable name="ddoc" select="document(concat($urlPrefixDict,'schema/KPT_v09/SchemaCommon/dAllDocumentsOut_v02.xsd'))"/>
что будет когда выйдет КПТ 10?
При сегодняшней логике, схема будет лежать тут
КПТ: <xsl:variable name="ddoc" select="document(concat($urlPrefixDict,'schema/KPT_v10/SchemaCommon/dAllDocumentsOut_v02.xsd'))"/>

Такое разделение приводит к ситуациям, которая сложилась в первую неделю 2015, когда РР не выложили каталог SchemaCommon для КВЗУ и работа с этим типом документов стала невозможна по всей России. Никто в России не мог работать вплоть до среды.

Судя по названию SchemaCommon, логика разработчиков была в том, чтобы сделать общее хранилище для вспомогательных схем для упрощения поддержания актуальности. Если это так, то почему вы не настояли, чтобы каталог был один?

как то так, в общем :)
Изменено: Дмитрий Баландин - 19.01.2015 15:28:20
Расписано все верно про именование и версионность имени справочника.

Структура каталогов у всех схем одинаковая. Каждая схема описывается в своей структуре отдельно. Не припомню, чтобы ставилось целью сделать общую свалку всех схем с одним каталогом всех подсхем и справочников. Каждая из схема утверждается отдельно и было бы странно, если бы передали на утверждение этакую большую свалку из всех схем. Но это не значит, что для своих нужд нельзя свалить все в одну кучу и пользоваться. С большой долей вероятности эта общая куча будет даже работоспособная. Если какие-то справочники расходятся по-содержимому, то это скорее недоработка, которая должная быть устранена и будет устранена со временем.

Следующая версия КПТ, я думаю, будет именно там и лежать :)

К ситуации с КВЗУ привело не такое разделение схем на каталоги, а банальная техническая ошибка. Лично я передаю пакет с xsl-шаблонами для тестирования и выкладывания их на Портал. И вот почему именно для КВЗУ и именно в версии для Портала пропали папки со схемой, я затрудняюсь ответить. И именно здесь я узнал об этой ошибке с самого начала, а после этого уже пошла ошибка по линии саппорта, но к тому моменту уже была передана исправленная версия.

SchemaCommon - это каталог для справочников и подсхем, которые разработчики могут изменять.
SchemaCommonSMEV - это каталог для внешних справочников и подсхем, которые приходят извне и которые разработчики не могут изменять.

Как то так :)

П.С. Забыл сказать, что в любом случае схемы лучше брать там, куда их выкладывает Росреестр, а не там, где они лежат в составе xsl-шаблонов.
Изменено: Борис Деточкин - 19.01.2015 16:18:29
Спасибо, за развернутый ответ. Очень полезно
Страницы: Пред. 1 2 3
Читают тему (гостей: 1, пользователей: 0, из них скрытых: 0)