Форумы GIS-Lab.info

ginpetr писал(а): ↑

24 апр 2024, 15:11

А кто как понимает условия типа:
Обязательно для значений атрибута "STATUS" 2, 3. Обязательно для значений атрибута "REG_STATUS" 1, 2?
между ними логическое И или логическое ИЛИ?

Я понимаю это как логическое "ИЛИ". Ниже привожу пример того, как я настраиваю атрибут EVENT_TIME

но тогда придётся заполнять срок реализации для существующих объектов фед и рег значения. Тоже не логично.

ginpetr писал(а): ↑

24 апр 2024, 16:14

но тогда придётся заполнять срок реализации для существующих объектов фед и рег значения. Тоже не логично.

Кстати, да. На досуге нужно будет еще обдумать данные условия...

Если же между предложениями идет логическое "И", то получается, что срок реализации заполняется для планируемых к размещению или реконструкции объектов федерального, регионального значения. Видимо я изначально неверно сопоставил эти два условия.

да вот непонятно так или эдак правильно. Я пока для себя И настроил.

Если исходить из положений 10-го приказа, то по крайней мере для того же атрибута EVENT_TIME правильнее использовать логическую связку "И".

ginpetr писал(а): ↑

24 апр 2024, 16:14

но тогда придётся заполнять срок реализации для существующих объектов фед и рег значения. Тоже не логично.

Вопрос логичности ФГИС на совести этих товарищей.
Когда заполняю срок реализации только для планируемых объектов, ругается, когда для всех ставлю, пропускает. Такое же было со слоем ФЗ, например атрибут FZ_MFSTP, FZ_ODSTP, FZ_INGSTP и тд, т.е, которые должны заполняться для отдельных значений ФЗ, ФГИС ругается, когда заполняешь для для всех, пропускает, непонятно

Здравствуйте. Столкнулся с такой же проблемой, не читает аттрибуты wear_prcnt, event_time, fact_use при загрузке. Кто нибудь нашел решение?

Новую xsd кто-нибудь изучил уже? Там схема ссылается на другую версию GML, что-то от этого поменяется?

skryabidze2 писал(а): ↑

06 май 2024, 11:25

Здравствуйте. Столкнулся с такой же проблемой, не читает аттрибуты wear_prcnt, event_time, fact_use при загрузке. Кто нибудь нашел решение?

После обновления видимо стало считывать

skryabidze2 писал(а): ↑

08 май 2024, 11:00

skryabidze2 писал(а): ↑

06 май 2024, 11:25

Здравствуйте. Столкнулся с такой же проблемой, не читает аттрибуты wear_prcnt, event_time, fact_use при загрузке. Кто нибудь нашел решение?

После обновления видимо стало считывать

Спойлер

Да, только теперь KADASTRZU не читает)

Похоже косяк с моей стороны.

Сделал через новую схему - все получилось. Поля принял

Klaus писал(а): ↑

08 май 2024, 10:56

Новую xsd кто-нибудь изучил уже? Там схема ссылается на другую версию GML, что-то от этого поменяется?

Сейчас изучаю ее. Стоит отметить, что и здесь не обошлось без косяков. Так у классов объектов, описывающих зоны с особыми условиями использования территории, для элементов, хранящих значения учетного, реестрового номеров, а также дату внесения зоны в ЕГРН, указан тип double, то есть вещественное число.
В то время как в приказе соответствующие атрибуты приводятся как символьные. Если парсер ФГИС ТП будет сверять атрибуты в загружаемых gml-файлах с данной схемой, то высока вероятность возникновения ошибки на этапе ФЛК. Но это лишь мое предположение. Однако наличие ошибки в xsd-схеме - это факт.

И я нашел несоответствие Приказа и схемы:

Атрибут класса WaterWays:
10 приказ - WAYLENGHT
Схема - WAYLENGTH

Долго не мог понять, где отличие)))
Написал им на почту, что в итоге оставят - хз.
Вроде как правильно писать WAYLENGTH, но откорректировать схему проще, чем приказ

Если что-то еще найду, откорректирую пост

update:
NaturalRiskZone
KADASTRZU - вообще не место тут этому. И в 10-м нет

Klaus писал(а): ↑

09 май 2024, 13:58

NaturalRiskZone
KADASTRZU - вообще не место тут этому. И в 10-м нет

У меня есть подозрение, что данную схему начинали готовить еще в тот момент, когда утверждали печально известный 123-й приказ. Отсюда и повылазили описанные выше косяки: и неверный тип некоторых элементов, и лишние атрибуты. Ведь все это было впоследствии отменено и изменено соответственно 620-м и 698-м приказами. Видимо когда переделывали схему в целях приведения ее к действующей редакции 10-го приказа, что-то да пропустили.

Но что больше всего меня смущает, так это тот факт, что у некоторых справочников почему-то закомментировали некоторые актуальные значения. Вот один из примеров: у справочника RES_STYPE (вид объекта санаторно-курортного назначения) значения от 1 до 6 оформлены в виде комментария (см. изображение ниже), а это означает, что парсер будет игнорировать данный фрагмент схемы. Таким образом, если в gml-файле для соответствующего атрибута будет указано, скажем, значение 4, то система ФГИС ТП может распознать это как ошибку (якобы данное значение атрибута не предусмотрено 10-м приказом).
Печально, что подобные материалы делаются на от****сь. На всякий случай выкладываю доработанную xsd-схему (вдруг кому-то пригодится; xsd-файл запаковал в архив, поскольку с родным расширением сайт не пропускает файл). В данной схеме исправил выявленные косяки, убрал справочники, которые не используются в 10-м приказе, дабы немного облегчить схему, также добавил несколько собственных типов: KADASTRAL_NUMBER, REESTRZOIT_NUMBER и REESTRTERZONE_NUMBER. Данные типы используются для проверки соответственно кадастровых номеров объектов недвижимости, реестровых номеров ЗОУИТ и реестровых номеров территориальных зон на соответствие принятым в кадастре правилам.

Вот сделали бы разработчики на ФГИС ТП отдельную страницу для проверки GML.
А то перед заказчиками неудобно уже. Вроде все проверишь, а выходит не все.
Допустим можно было бы создать себе ЛК, если ты уже есть в системе, как разработчик и проверять на соответствие.
Услуга "загрузка в ФГИС ТП" популярна сегодня)