TP_v03

Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
XML-схемы » XML по ОКСам
Страницы: 1
TP_v03
Что за очередной бред?

Код
                     <xs:element name="SchemeGeodesicPlotting" type="tAppliedFilePDF" minOccurs="0">
                        <xs:annotation>
                           <xs:documentation>Схема геодезических построений</xs:documentation>
                        </xs:annotation>
                     </xs:element>
                     <xs:element name="SchemeDisposition" type="tAppliedFilePDF" minOccurs="0">
                        <xs:annotation>
                           <xs:documentation>Схема расположения сооружения</xs:documentation>
                        </xs:annotation>
                     </xs:element>
                     <xs:element name="DiagramContour" type="tAppliedFilesJPEG">
                        <xs:annotation>
                           <xs:documentation>Чертеж контура сооружения</xs:documentation>
                        </xs:annotation>
                     </xs:element>
Ну и чем таким не угодил Чертеж контура сооружения, что для него отдельный тип введен tAppliedFilesJPEG вместо tAppliedFilePDF как у всех остальных разделов?
Это мы для всех разделов делаем один способ формирования, а для чертежа еще один. Просто верх универсальности...
Это требования, которым уже более года, трудолюбиво воплощаемые в xml: Приказ 88, пункт 15.
Изменено: Константин Финагеев - 01.07.2015 12:43:40
Идиотизм вечен. Кто-то скопипастил не читая со старого документа в новый. А теперь все, и КИ и сотрудники КП должны возиться с кучей приложенных jpeg-ов одного чертежа. В остальных то приказах все нормально, там везде пдф. Поправьте меня, если я не прав.
Не могу поправить. Согласен. Чаще всего именно сооружения расположены на множестве листов, jpg всем только усложнит работу.
Но ещё интереснее количество точек в этом jpg.
"Размер рисунка JPEG (файла с расширением jpg) должен быть равен 600(ширина)x700(высота) пикселей или 980(ширина)x1080(высота) пикселей)."
Т.е. или 300dpi уже не надо выдерживать, или от крупных форматов нужно отказываться, хотя приказ их предусматривает.
С чем связаны такие размеры тоже не понятно, на пропорции А4, А3 не похоже.
Нет больше никаких крупных форматов в JPEG: 250-450 dpi из приказа + 600х700 (980х1080) пикселей из описания схемы ~ от 6х7 (10х11) см до 3,3х4 (5,5х6) см размер чертежа. Особенно подходят такие размеры для линейных сооружений, расположенных на территории более одного кадастрового округа :))) Раздолье для филуменистов!
Меня порадовал Appendix. Вот это настоящий квест, что за фигня и как это заполнять ни слова. Что такое "Номер приложения" и "Наименование приложения"? При этом в исходных данных предусмотрена выгрузка образа. Приказы говорят, что образ исходного документа это Приложение, но спрашивается на кой чёрт его выгружать в приложения, когда проще и удобней, причём всем удобней, выгрузить непосредственно в исходных данных? Или этот раздел предусмотрели для неких документов, которые не являются исходными данными, как сейчас прикладываются образы печатных ТП и МП? Ну неужели было трудно написать объяснение? А ведь я поднимал этот вопрос ещё по предварительной схеме и просил уточнить этот момент в Приказе (в описании схемы). Такое ощущение, что специально делается дырка для трактовки проверяющими этих моментов как им интересно!
Цитата
Константин Финагеев пишет:
Нет больше никаких крупных форматов в JPEG: 250-450 dpi из приказа + 600х700 (980х1080) пикселей из описания схемы ~ от 6х7 (10х11) см до 3,3х4 (5,5х6) см размер чертежа. Особенно подходят такие размеры для линейных сооружений, расположенных на территории более одного кадастрового округа )) Раздолье для филуменистов!
Вспомнился один пользователь, буквально сейчас он оформляет трубопровод, если не ошибаюсь, этот трубопровод идёт через пол Башкортостана. Это ему придётся делать обзорный лист обзорных листов обзорных листов обзорных листов...

UPD:
Ошибочка вышла, в линейном контур в PDF, причём файлов может быть несколько! Это для обычного жэпэг.
Изменено: Игорь Дегтярь - 02.07.2015 22:10:00
Цитата
Игорь Дегтярь пишет:
UPD:
Ошибочка вышла, в линейном контур в PDF, причём файлов может быть несколько! Это для обычного жэпэг.
В линейном тоже jpeg, если имеется в виду TPLinear_v03. Я его в первую очередь проверил, думал опечатка в типах. Ан нет, там оказалось также, что на опечатку не тянет.
Цитата
Алексей Ябров пишет:
В линейном тоже jpeg, если имеется в виду TPLinear_v03. Я его в первую очередь проверил, думал опечатка в типах. Ан нет, там оказалось также, что на опечатку не тянет.
Точно, чего то меня плющит. Ну тогда вообще веселуха :o
Наткнулись на интересный момент: для части здания по схеме обязательны координаты...какая-то печальная история.

В текущей (QIP Shot - Screen 069.png) стоит переключатель: или координаты, или план. А по новой (QIP Shot - Screen 070.png) переключателя нет: координаты обязательно и план (необязательно)

Как думаете, коллеги? Косяк или глубокая задумка, которую нам не понять?
Изменено: Владимир Немов - 12.08.2015 15:06:15
Тоже долго думал, но пришёл к выводу, что в обновленном приказе это и предусмотрено, разработчики схем только соблюли требование.
На мой взгляд, глупость координировать часть, которая находится в глубине здания и не спутники над ней не летают, ни тахеометрический ход никто не погонит по коридорам и лифтам. Хотел бы посмотреть, как тот, кто это требование придумал, рулеткой выдержит нормативную точность в каком-нибудь небоскребе.
Цитата
Николай Малютин пишет:
Тоже долго думал, но пришёл к выводу, что в обновленном приказе это и предусмотрено, разработчики схем только соблюли требование.
На мой взгляд, глупость координировать часть, которая находится в глубине здания и не спутники над ней не летают, ни тахеометрический ход никто не погонит по коридорам и лифтам. Хотел бы посмотреть, как тот, кто это требование придумал, рулеткой выдержит нормативную точность в каком-нибудь небоскребе.
А разве внутри знания это не помещение? Я всегда думал, что часть здания это отдельный элемент знания, состоящего из нескольких частей. И это внешний элемент, а не внутренний. Соответственно и координаты на него внешние. Или я ошибаюсь?
Но то, что логика непонятна, согласен. Смысл имея координаты части прикладывать расположение... :?:
Изменено: Алексей Ябров - 14.08.2015 06:22:01
Да, помещение, но иногда здание не содержит помещений и делить его на помещения собственник не планирует (или не может), но хочет выделить часть с целью сдачи в аренду. Например, взять здание завода, где-то в дебрях которого нужно сдать в аренду пару станков и выделить для этого часть. Или в торговом центре выделить часть под "модный бутик", у которого и стен толком нет, следовательно, обособленным и изолированным быть не может.
Ну я тоже не истина в последней инстанции, может в этих случаях по каким-либо требованиям необходимо ставить на учет помещения, и тогда всё сходится. Но есть подозрения, что скоро у многих кадастровых инженеров и их заказчиков возникнут массовые проблемы.
Цитата
Николай Малютин пишет:
Но есть подозрения, что скоро у многих кадастровых инженеров и их заказчиков возникнут массовые проблемы.
По любому, куда же без них. А разгребать нам, простым смертным программистам, т.к. все претензии в первую очередь посыпятся на ПО.
Изменено: Алексей Ябров - 14.08.2015 11:09:33
Коллеги, добрый вечер!

Столкнулись с еще одним косяком схемы. При учете изменений здания, например, все тэги необязательны, в т.ч. координаты здания. Но вот тэг Survey (сведения о выполненных измерениях и расчетах) является обязательным, т.е. координат может не быть, а метод определения быть обязан. Что Вы думаете по этому поводу?
Изменено: Владимир Немов - 15.09.2015 17:52:50
Цитата
Николай Малютин пишет:
Но ещё интереснее количество точек в этом jpg.
"Размер рисунка JPEG (файла с расширением jpg ) должен быть равен 600(ширина)x700(высота) пикселей или 980(ширина)x1080(высота) пикселей)."
Т.е. или 300dpi уже не надо выдерживать, или от крупных форматов нужно отказываться, хотя приказ их предусматривает.
С чем связаны такие размеры тоже не понятно, на пропорции А4, А3 не похоже.
в приказе (№ 86 на здание) сказано: "п.17 ...Для сканирования документов необходимо использовать полноцветный режим с разрешением 300 dpi. Документы в формате JPEG должны быть выполнены в 24-битном цветовом пространстве. Разрешение изображения не должно быть меньше 250 dpi и больше 450 dpi."
т.е. для рисунков как минимум 250 dpi. А в описании ХМL схемы ".. Размер рисунка JPEG (файла с расширением jpg) должен быть равен 600(ширина)x700(высота) пикселей или 980(ширина)x1080(высота) пикселей. dpi - это количество пикселей на дюйм. А4 размером 8,3дюйма на 11,7 дюйма. умножаем на качество 250 dpi получаем 2075 на 2925 пикселей будет наш рисунок при минимальном dpi. какого же качества будет рисунок 600 на 700 если растянуть на А4. Однозначно требование по размеру надо убирать из документов. Достаточно качества не должно быть меньше 250 dpi и больше 450 dpi. Если есть на форуме специалисты с росреестра обратите на эти противоречия внимание.
Цитата
Николай Малютин пишет:
Тоже долго думал, но пришёл к выводу, что в обновленном приказе это и предусмотрено, разработчики схем только соблюли требование.
Обещают внести изменения в схему. Будем ждать и смотреть каким образом: публично или втихаря...
Цитата
Владимир Немов пишет:
Цитата
Николай Малютин пишет:
Тоже долго думал, но пришёл к выводу, что в обновленном приказе это и предусмотрено, разработчики схем только соблюли требование.
Обещают внести изменения в схему. Будем ждать и смотреть каким образом: публично или втихаря...
так отменили же уже данное ограничение. Мне кажется такая проверка выполняется в программе и хмл тут ни причем. Просто патч поставили, а в хмл этого нет.
Цитата
Алексей Ябров пишет:
так отменили же уже данное ограничение. Мне кажется такая проверка выполняется в программе и хмл тут ни причем. Просто патч поставили, а в хмл этого нет.
Вы несколько подменяете понятия. В тексте приложения 1, к приказу П/338 четко написано

Цитата

Размер рисунка JPEG (файла с расширением jpg) должен быть равен 600(ширина)x700(высота) пикселей или 980(ширина)x1080(высота) пикселей.
А то, что программа сначала проверяла, а потом нет - это трудности разработчиков АИС ГКН и тех, кто ставит им задачи. Т.е. патч - это не та вещь, которая может отменить положения приказа
Цитата
Владимир Немов пишет:
Цитата
Алексей Ябров пишет:
так отменили же уже данное ограничение. Мне кажется такая проверка выполняется в программе и хмл тут ни причем. Просто патч поставили, а в хмл этого нет.
Вы несколько подменяете понятия. В тексте приложения 1, к приказу П/338 четко написано
Цитата

Размер рисунка JPEG (файла с расширением jpg ) должен быть равен 600(ширина)x700(высота) пикселей или 980(ширина)x1080(высота) пикселей.
А то, что программа сначала проверяла, а потом нет - это трудности разработчиков АИС ГКН и тех, кто ставит им задачи. Т.е. патч - это не та вещь, которая может отменить положения приказа
Конечно программа не отменяет. Отменяет разъяснительное письмо. Или у нас все приказы издают идеальными и без ошибок?
Изменено: Алексей Ябров - 16.10.2015 05:46:46
Цитата
Алексей Ябров пишет:
Отменяет разъяснительное письмо.
Да ну, письмо является нормативным документом? Фактически это позиция того человека, который подписал это письмо или даже того, кто есть исполнитель. У нас даже орган нормативно-правового регулирования в сфере кадастровых отношений не уполномочен разъяснять положения законодательства, о чем они упоминают в каждом письме. Тем более наверняка Вы сталкивались в своей практике работы с ОКУ, что какие-то письма они используют в своей работе, а какие-то нет, потому что, читайте выше, они не являются нормативным документом...
Цитата
Алексей Ябров пишет:
Или у нас все приказы издают идеальными и без ошибок?
Я думаю, что Вы, как и я, знаете ответ на этот вопрос. И от него становится печально, что к разработке документов не привлекают практиков. Яркий пример - этот форум. Задумка отличная, поначалу даже работала, а теперь - это чистое общение между разработчиками ПО для КИ, что тоже, кстати, не плохо, но если бы изначальная задумка работала, было бы намного лучше.
Изменено: Владимир Немов - 16.10.2015 09:33:53
Цитата
Владимир Немов пишет:
Я думаю, что Вы, как и я, знаете ответ на этот вопрос. И от него становится печально, что к разработке документов не привлекают практиков. Яркий пример - этот форум. Задумка отличная, поначалу даже работала, а теперь - это чистое общение между разработчиками ПО для КИ, что тоже, кстати, не плохо, но если бы изначальная задумка работала, было бы намного лучше.
Вот тут я с вами полностью согласен. Приказы пишут теоретики, хотя они предназначены для описания рабочих процессов. Поэтому мы и имеем то, что имеем. И поэтому я и говорю, что в данном случае, письмо отменяет приказ, т.к. требования приказа не обеспечивают полноценное выполнение работ. Ну не читабельно изображение 600 на 700. Так зачем доводить до абсурда и всеми силами пытаться сделать то, что мешает всем, и КИ, и разработчикам, и самому Росреестру. И в этом плане это письмо самый правильный вариант, т. к. изменение в приказ, это бог знает сколько времени, а работать надо сейчас.
Страницы: 1
Читают тему (гостей: 1, пользователей: 0, из них скрытых: 0)