Кадастровые данные в формате XML

[Александр Фадеев]

Это примерно так должно получиться (в mif формате) для представленного примера?

[Филиппов Владислав]

cfifti73, графика видна, но атрибуты.... во всех полях одно и то же (кроме id) и напоминает, о нет!!!, Карта200Х - ужас мой 2002 года.
И нет кадастрового номера, что очень странно.

Olga_@@@, большое спасибо! можно ваши данные мне на мыло.

А сколько заявлено ЗУ в описании к той xml которую Вы выложили??

Сергей, Notepad++ подсчитал, что тегов </Parcel> в том документе 3278, а в PDF в графе номер по порядку начинается с 18!!! и кад номер :24 и заканчивается записью с номером 3278!!!! с кадастровым номером :4175.

Текущая версия моего конвертера 0.5.1 и у меня объектов 2418, в таблице верно.
Нужно решать проблему описанную Olga_@@@.

[Александр Фадеев]

Nukevlad. Упс, извиняюсь не посмотрел. Вот доп. таблица, привязка по LINKOBJECT. По ней 3001 объект. В другом варианте преобразования получилось 2914 объектов. P.S. Панорама 11.

[SergS]

Создал черновик в Вики про проблемы которые могут быть в кадастровых XML

Не будете возражать, если я добавлю сюда пару замечаний по Вашей статье?
Я думаю (даже больше - процентов на 99 уверен), что проблемы в XML файлах Росреестра - это не проблемы ПО, которое их формирует, а именно то, что хранится в БД кадастровых палат. (пару-тройку десятков их руками пощупал, правда, еще до перехода на АИС ГКН). Там, что называется, тако-о-о-е встречается. Это что касается пунктов "1.1 Ненужные блоки описания контуров" и "1.2 Очень сильная разница в значении координат". Анализировать и исправлять это смысла не имеет. Принять как данность. Думаю, что в pdf-файлах, как отображении тех же данных, будет то же самое.

(небольшое отступление: имеется в наличии архив с кадастровой выпиской на участок. получен где-то в октябре-ноябре. так в нем данные об участке (описание границ - координаты) в xml-виде не соответствовали разделам КВ5 и КВ6 из pdf-вида, а востановленные из них образы участка не соответствовали ни друг другу, ни изображению его из раздела КВ2. ну и самое интересное - имеется и межевой план, который подавался на кадастровый учет гдето за месяц до того, кадастровый учет пройден. так вот в нем - четвертый вариант, отличающийся от первых трех)

что касается пункта "1.3 Проблемы формирования описания ЗУ".
У меня из рассмотрения как реальных файлов xml, так и xsd-схем, которым эти файлы должны соответствовать (по крайней мере, теоретически), сложилось немного другое впечатление о типах данных "Entity_Spatial", "Spatial_element" и "Contour". (Все ИМХО, конечно)
Spatial_element представляет собой именно контур в графическом смысле - просто замкнутая ломаная, совокупность которых определяет некоторую область Entity_Spatial (в общем случае - не односвязную, схема это предусматривает). То, что описывает такая совокупность (область с дырками, несколько связанных в один объект областей - многосвязную область, опять таки может быть с дырками в каждой), определяется только их взаимным положением (геометрически), но никак не порядком перечисления.
я видел, было обсуждение этого момента, были сделаны ккие-то выводы, но.... не согласен. _
а Contour - это объект учета (в смысле кадастра), то, что может иметь кадастровый (или еще какой, например, учетный) номер, что ему не мешает иметь свою собственную графическую сущность Entity_Spatial со всеми особенностями, упомянутыми выше ( в том числе и этакую извращенную вложенную "многоконтурность".)
Но, повторяю, все это только отображение того, что есть (может встречаться и встречается) в реальной БД.

[Максим Дубинин]

Принять как данность.

Мне кажется не просто принять, а описать, дать примеры, задокументировать.

[SergS]

описать, дать примеры, задокументировать.

Здесь?
кажется мне, что ошибки в базах данных Росреестра - не тема для данной темы
все равно, если они попали в xml-файл, их надо извлекать и показывать пользователю как есть. Хотя бы для того, чтобы ткнуть пальцем в них соответствующей организации. (чем и занимаемся по мере поступления)
именно поэтому написал "принять как данность" - в смысле для извлечения из xml.
Пока что вижу только одну проблему - различное понимание (и, может быть, отличное от авторов xml-схем) структуры описания данных.

[Максим Дубинин]

в вики, чтобы этим

чтобы ткнуть пальцем в них соответствующей организации. (чем и занимаемся по мере поступления)

занимались больше и активнее

[SergS]

а-а, понятно.
(надо тока разобраться как туда писать и, философский вопрос , определить адресата - от него, в принципе, зависит, что именно будет писаться и процент специфической лексики)

[Olga_@@@]

можно ваши данные мне на мыло

Можно, но пока не понимаю, какой файл содержит ошибку. Ищу.
Сдвиг появляется только при пакетном экспорте и сшивке таблиц.

Нашла один "сдвинутый" файл, импортировала его отдельно - вроде все нормально. Но, если сшивать таблицы при импорте, то все опять разъезжается


Вот нашла конфликтную пару: 438593 и 43810. Если загружать отдельно, вроде все нормально (хотя за 438593 не поручусь). Но, если импортировать одновременно, даже без сшивки таблиц, то во втором файле строки едут. Ориентироваться можно по самому большому участку их второго файла, там монастырь. При сдвиге строк монастырь превращается в многоквартирный жилой дом.

[Olga_@@@]

Нашла ошибку. Она сидит в хвосте файла 438593.mif

02.102.png (6.55 КБ) 9094 просмотра

Если убрать все, что ниже выделения, то сдвига строк при импорте не происходит.
Ай-ноне-ноне... какое-то

[Филиппов Владислав]

Olga_@@@, доброго вам утра!
Я думал проблема в XML-файлах и то, как их обрабатывает LandProcessor (моя поделка).
Или я уже не в теме?

SergS, я тоже всё жду, когда можно будет показать кому нибудь из Росреестра всё что я "нацарапал".
Я, по долгу службы, обработал уже такую гору (не менее 1200 КПТ в этих XML) и самые часто встречающие косяки это координаты в районе центра координат, около нуля.

А насчёт назначения тегов, я по ходу пытаюсь (и возможно верно) смотреть на схему кадастрового хмл как на организацию описания геометрии в geotools (вернее Java Topology Suite). Там есть Polygon - это 1 внешний контур и ноль и более дырок (holes), <Entity_Spatial>. И есть мультиполигон - массив Polygon'ов, которые не пересекаются - <Contours>.
Ну как то так.

[Olga_@@@]

Nukevlad,описанный глюк получен в двух других конвертерах, а не в вашем. Ваш еще не тестировала. Сейчас сделаю


Пожалуйста, для тупых, объясните, как им пользоваться

[SergS]

А насчёт назначения тегов, я по ходу пытаюсь (и возможно верно) смотреть на схему кадастрового хмл как на организацию описания геометрии в geotools (вернее Java Topology Suite). Там есть Polygon - это 1 внешний контур и ноль и более дырок (holes), <Entity_Spatial>. И есть мультиполигон - массив Polygon'ов, которые не пересекаются - <Contours>.

Думаю, с "философской" точки зрения это все таки не верно, но с практической, наверное, имеет право на существование.
Мне так кажется, вы притягиваете струкутуру описания графики в xml на таковую в geotools, добавляя некие требования на графику, которые изначально отсутствуют. Судя по схеме, Entity_Spatial - графическая сущность, представляющая собой полигон, а в общем случае и мультиполигон - с точки зрения представления данных в xml - массив непересекающихся контуров (замкнутая ломаная, не Contour), которые и составляют описание полигона (мультиполигона).
а <Contours> - это не массив полигонов, а массив Contour, каждый из которых представляет собой не графическую сущность, а, как писал выше, объект учета, составную часть типа данных "Многоконтурный участок", как SubParcel - составная часть типа данных "Единое землепользование" (массив <SubParcels>). И каждый из которых включает в себя как дополнительный атрибут - свою Entity_Spatial, т.е. в свою очередь теоретически может быть представлен многоконтурной многосвязной графической сущностью
О, я понимаю, что логически это все может быть не правильным, точнее - так не должно было бы быть, и для новых участков при постановке на учет реализуется схема, более близкая к Вашим представлениям (ну, может за исключением требования Polygon - это "1 внешний контур (причем, в описании первый) и ноль и более дырок (holes) = <Entity_Spatial>"),
когда <Entity_Spatial> - это всегда односвязная область, Земельный участок (простой) - имеет вот эту самую односвязную <Entity_Spatial>, а многоконтурный участок - это массив контуров, каждый из которых содержит опять так односвязную <Entity_Spatial>.
НО..., органы кадастрового учета отчитались о чуть ли не 100% "кадастризации" еще, по моему, году в 2007, и наполнение БД производилось из самых разных источников, самым разным ПО, возможности которого по формированию и редактированию граф. объектов были существенно шире требований к земельным участкам даже тогдашнего законодательства.
А если еще вспомнить продукты недоброй памяти ЕГРЗ-П и ЕГРЗ-Т с графическим клиентом на основе Mapinfo, то...
Короче имеем то, что имеем.

[Филиппов Владислав]

как работать с LandProcessor

olygon - это "1 внешний контур (причем, в описании первый) и ноль и более дырок (holes) = <Entity_Spatial>"),

О да, ключевое слово первый! пришлось писать метод для проверки и принудительного назначения "первого".

Сама структура создана не для того чтобы легко было бы это преобразовать в стандартные форматы ГИС и прочего, а для того что бы легко делать "бумажку", ту самую PDF-ку, что лежит рядом с этим XML в архивчике от Росреестра

[SergS]

пришлось писать метод для проверки и принудительного назначения "первого".

а как поступаете, если Entity_Spatial в xml - многосвязная? Расширяете Entity_Spatial в массив односвязных? Потом распределение контуров по элементам и для каждого "метод для проверки и принудительного назначения"?
блин, я б сломался....

Сама структура создана не для того чтобы легко было бы это преобразовать в стандартные форматы ГИС и прочего, а для того что бы легко делать "бумажку", ту самую PDF-ку, что лежит рядом с этим XML в архивчике от Росреестра

хм-м... интересная версия (не, я понял)
на самом деле вся эта структура сильно напоминает первичную логическую схему организации информации об объекте - еще до нормализации. Если провести над ней все необходимое (нормализацию), то получаем один в один схему БД (по крайней мере, для ЕГРЗ-Т)