ПКЗО. Программный комплекс для кадастрового инженераПКЗО. Автоматизация подготовки межевых и технических планов
  
 
E-MAIL:
ПАРОЛЬ:
 
  
главная / форум

Обсуждение

перейти к последнему сообщению в данном обсуждении

 Пожелания по доработке ПКЗОПожелания по доработке ПКЗО [ Андрей ]
Воскресенье, 17 сентября 2017, 16:15

Внимание! Длиннопост!

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

Объекты, на которые необходимо было сформировать межевой план, являются линейными, проходящими через весь район (автомобильная дорога) и пересекали от 15 до 30 кварталов, на которые были заказаны выписки КПТ.

С самого начала попробовал импортировать все через импорт XML в базу, но помимо долгой процедуры импорта впоследствии при работе с этой базой программа неоднократно делает «Загрузку данных проекта…», которая занимает времени до 10 минут, и это не одноразово, а при обновлениях графики и прочими действиями!

Решил воспользоваться вашими советами, чтобы разгрузить базу, обратился к параллельной базе в Mapinfo, где сделал SQL запрос на пересечение 10 метровой буферной зоны моего объекта с земельными участками, получил их список. Далее импортировал XML не целиком, а выбирал каждый участок, список которых был ранее получен. Ох уж и муторно это все было…

Далее подгружаю полностью XML в виде графики. Исключать из загрузки в графику уже загруженные в базу участки не стал, так как времени на это все не было. Загрузил как есть и очень «удивился». Поскольку в КПТ на квартал имеются участки из нулевого квартала, то ПКЗО загрузила их ВСЕ в графику не анализируя на дубли. Получилось, что дублирующих слоев доходило до 10! Это опять же загружало базу ненужной информацией.

Таким же образом я поступил с ЗОУИТ, поскольку их номера в проекте все равно вручную вписывать и нужны они по идее только для графики.

Далее началась работа по загрузке проектного слоя, формированию образуемых участков, что делается в ПКЗО довольно быстро и логично, к чему нареканий никаких нет!

Ну и самое муторное это подготовка графики, которая заняла 90 процентов всего времени и включала в себя размещение номеров поворотных точек, номеров участков и наведение прочей красоты, поскольку ту графику, которую автоматически формирует программа предоставлять заказчику совершенно нельзя!

Для формирования СРЗУ и МП решил сначала подготавливать межевые, а потом копировал их в эту же базу, изменять вид работ на подготовку СРЗУ и приводить в соответствие с требованиями к СРЗУ.

Что же мне не понравилось конкретно:
1) При загрузке из XML участков и других объектов средствами ПКЗО не предусмотрен выбор участков по буферу от какой-то линии (объекта), а приходится вручную выбирать каждый участок и искать его в «бесконечном» списке из ЕЗП, многоконтурных и обособленных, что на самом деле оказалось не простой (быстрой) задачей. Это же касается и выбора ЗОУИТ, ОКСов.
2) В ПКЗО при выборе участков (ЗОУИТ, ОКСов) из XML не предусмотрено возможности сохранить выборку, обратить выборку, чтобы в графику не загружать те участки, которые ранее были загружены в базу.
3) При генерации графики расположение надписей участков, кварталов, зон и проч. оказываются в таких местах, что найти и перенести надпись в зону листа рядом с образуемым участком оказывается не простой задачей, даже с применением кнопки показать надпись на карте. Как я понял надпись не всегда располагается в центроиде. У линейных объектов она расположена в начале объекта. Неужели нельзя сделать кнопку, чтобы при нажатии на объект подпись, относящаяся к нему, размещалась в этом месте? Другими словами, не искать ее по всей карте и перемещать из одного края карты в другой, а просто в области листа нажать кнопку, ткнуть в объект и вуаля! Подпись этого объекта оказалась в этой точке!
4) При разбивке на листы в случае с длинными образующимися участками, которые из-за своей длины помещались на нескольких листах, приходится копировать номер участка и растаскивать на другие листы, чтобы было понятно какой участок образуется. То же приходится делать с надписями кварталов, больших смежных участков, зон! Это занимает очень много времени!
5) Когда из скопированного межевого плана делал вид работ – «схема на КПТ», то ПКЗО удаляет слой с Чертежом, а оставляет схему, что приводит к дополнительным проблемам. Дело в том, что масштаб Чертежа в МП выбирается исходя из читаемого расположения номеров поворотных точек, что не скажешь о схеме, где должны читаться только номера участков. И по логике Чертеж из МП схож со Схемой из СРЗУ. На нем также отображаются номер поворотных точек, необходим тот же масштаб для читаемости, та же разбивка на листы. По моему мнению при изменении вида работ на СРЗУ из МП необходимо полностью копировать масштаб, разбивку на листы, расположение нумерации поворотных точек образуемых участков из Чертежа! Это ускорит процесс разработки пары МП-СРЗУ!
6) Применение ГИС ObjectLand в ПКЗО, по моему мнению, не самый оптимальный вариант, так как обновление графики происходит очень долго, на порядок дольше чем делает то же MapInfo. Может это связано с точностью карты? Если это так, то считаю самым оптимальным изначально делать точность карты в OL кратной 1 сантиметру, как это реализовано в MI c числами с плавающей запятой! Убрать кнопку округление координат, а при импорте границ в ПКЗО делать округление в процессе импорта.
7) Генерализация надписей — это тоже проблема, так как на карте после генерации графики показываются абсолютно все надписи, что создает кашу! Может рассмотреть связку ПКЗО QGIS? Насколько я знаю почти во всех нормальных ГИС предусмотрена возможность генерализации подписей, если подпись не помещается в границы участка, она не показывается. То же реализовано и на ПКК Росреестра, которая реализована на ArcGIS. Я еще раз заострю внимание на подготовке графики, которая является лицом межевого плана и занимает уйму времени в ПКЗО!
8) После загрузки в графику из XML дублирующих слоев и обновления надписей, каким-то образом эти надписи немного сместились одна относительно другой и стали выглядеть жирными и размытыми. Пришлось удалять дубли вручную, их много и это тоже очень долго. Учитывая, что надпись располагается над участком, потом опять участок, а над ним надпись, то пришлось удалять еще и дублирующиеся участки, загруженные в графику из XML!
9) При добавлении из панели проекта ЗОУИТ, они не сортируются по номеру! Опять трата времени на поиск нужной зоны!
10) Зоны автоматически не добавляются в свойства участка, который полностью или частично расположен в ЗОУИТ. Это приходится делать вручную самостоятельно, или опять же в сторонней программе MapInfo помощью SQL запроса получать список ЗОУИТ, которые пересекают участок. Думаю, это несложно реализовать, если учесть, что нечто похожее вы уже сделали с поиском ОКС, которые пересекают или расположены на участке.
11) Было бы неплохо, чтобы у слоев можно было бы сделать показ узлов в полигонах. Это удобно, когда границу проектируемого участка с помощью стяжки необходимо подтянуть к смежному ЗУ.
12) При удалении границы сформированного участка (если необходимо изменить границу на новую) вылетает ошибка «Операция не допустима в текущем режиме блокировки транзакции (Код ошибки ГИС:210). Может это связано с моей WIN10 и правами к базе данных? Но при отказе от отправки ошибки разработчикам операция все же выполняется.
13) При проверке МП в ошибках указываются наложения менее 1 см, что не верно.
14) Кнопка включения панели проекта включается, если нажать точно в центр. А если с краю, то кнопка проваливается, но действия не происходит.

Хотелось бы подытожить! С каждым годом количество участков, ЗОУИТ, ОКС растет. При нынешнем быстродействии ПКЗО с каждым годом будет все сложнее и сложнее в ней работать с протяженными или большими объектами. По моему мнению очень важным является пересмотр подхода к ядру программы, ГИС, оптимизации кода. Аналитика и логика реализована на «ура», но быстродействие оставляет желать лучшего! Не судите строго, но когда 90 процентов времени затрачивается на графику и ожидание «загрузки данных проекта» хочется задать вопрос, а может стоить больше внимания уделить графике и быстродействию? Ведь нет ничего ценнее времени! И компьютеры, и программы должны работать на благо человека! То есть не я после нажатия кнопки должен ждать программу, а она должна ждать нажатия мной кнопки и скорость выполнения работ должна зависеть от скорости работы оператора, а не бесконечного ожидания обработки программой алгоритмов.
Как я вижу идеальную ПКЗО? Это надстройка над нормальной ГИС, в которой и так уже реализовано много функций по генерализации и правилам прописывания объектов, применения EPSG проекций, подключения WMS и прочих слоев. В идеале это выбор контуров образуемых участков, ответов на пару вопросов и вот тебе межевой план сформирован, разбит на листы при необходимости с приемлемой графикой! Время – бесценно! Поэтому я считаю в центре должна стоять не надстройка ПКЗО, а ГИС(к слову OL в целом не изменялась со времен ее разработки)! Не компьютер, а оператор (к чему долгое время и стремится Apple)!
Я имею не самый слабый компьютер (Intel Core i-5 2430M 2.4 GHz, 8ГБ ОЗУ, 64х, твердотельный накопитель 250 Гб под систему, NVIDIA GEFORCE GT-540M) и я не представляю, как работают люди на железе попроще! И еще! Было бы неплохо иметь многоплатформенную версию программы. Спасибо за понимание! Много слов, надеюсь в тему...

 Пожелания по доработке ПКЗО [ Андрей Егоров ]
Понедельник, 18 сентября 2017, 07:51

Работают люди с трудом, проблемы в основном всё те же.
Недавно делали образование части в участке лесного фонда, границы которого состоят из нескольких контуров и более чем 18 тысяч точек, так генерация графики составляла более 4-5 часов (приходилось оставлять на ночь), а формирование печатного документа вообще получилось только после отключения в Ворде проверки орфографии и пунктуации, иначе 872 страницы печатного документа просто не формировались из-за большого количества ошибок. Соответственно и PDF в межевой план пришлось добавлять вручную, иначе выгрузка МП завершалась ошибкой даже с отключенной проверкой орфографии.
Про замену ОЛ на другую ГИС, тоже мысли возникают, но не имея опыта работы в других ГИС, данные мысли пока не могу облечь в слова. MapInfo стоит дорого, поэтому лучше переходить на что-то бесплатное и наверное всё-же кроссплатформенное, может быть и на предложенную вами QGIS.
Надо уходить от MS Office на что-то другое, может быть даже не на полноценный офисный пакет, а на какой-либо генератор отчётов типа FastReport, с возможностью прямого сохранения в PDF, RTF и т.п.
Может быть есть смысл предусмотреть в ПКЗО, чтобы каждый проект автоматически формировался в виде отдельной базы (благо большинство ГИС позволяют работать со сторонними базами данных), а в самой ПКЗО будет просто список данных проектов. Возможно это увеличит быстродействие за счёт уменьшения размера базы данных, но тут я не специалист.

 Пожелания по доработке ПКЗО [ Денис Николаев (разработчик) ]
Понедельник, 18 сентября 2017, 17:00

Мы тоже видим, что объем данных растет и, очевидно, продолжит расти в будущем. Проблема работы с большими объемами данных в программе имеет место быть. Определенные решения уже намечены и в ближайшее время будут реализованы.

В плане производительности в ближайшее время мы планируем сделать:

1. При загрузке из XML добавить опцию, чтобы можно было загружать только те объекты, которые пересекаются или находится на  заданном расстоянии от объектов работ. Это позволит исключить загрузку объектов, которые не нужны для проведения работ. Как правило, это значительное количество объектов. В результате объем данных в проекте будет меньше и, соответственно, скорость работы выше.

2. Исключить справочные объекты из топологической модели (где точки связаны с ребрами) и вынести их в отдельные слои. Это должно существенно ускорить загрузку из XML, загрузку проекта и обработку справочных объектов.

3. Изменить способ загрузки XML-файлов на последовательный (или смешанный), что позволит, в принципе, загружать файлы любого размера и существенно быстрее. Ограничение на размер загружаемых XML-файлов, которое есть в программе сейчас, это ограничение используемой нами библиотеки MSXML, которую мы планируем заменить.

По поводу генерации графики рекомендации такие:

1. Программа помечает объекты, для которых графика требует обновления. Есть специальная команда "Графика\Актуализировать графику", которая выполняет обновление только той графики, которая реально требует обновления.

2. Выполнять финальную подготовку надписей (выставлять высоту, выполнять ручную расстановку) имеет смысл только после того, как все объекты внесены в проект, определен конечный масштаб и выполнена разбивка на листы (если она необходима).

3. Для обновления высоты надписей предусмотрено два варианта:
1) использовать команду "Графика\Установить высоту надписей"; здесь можно задать, чтобы обновление выполнялось только для точек, например;
2) использовать команду "Графика\Генерация графики"; здесь нужно указать генерацию только надписей; если опция "Сохранять местоположение надписей" выключена, то все надписи будут созданы с нуля, иначе их положение и линии-выноски сохранятся.

4. Графику можно обновлять только для выбранных объектов. Для этого используйте подменю "Графика" в контекстном меню в списке объектов. Предварительно в списке выберите объекты, для которых нужно обновить графику. Это значительно быстрее, чем пользоваться командами в меню "Графика" в панели проектов, т.к. там затрагиваются все объекты проекта.

Конкретно по всем пунктам отвечу чуть позже.

 Пожелания по доработке ПКЗО [ Андрей ]
Понедельник, 18 сентября 2017, 18:14

При работе я следовал вашим рекомендациям, но это не намного упрощает подготовку качественной графики.

Буду ждать ответа по пунктам.

 Пожелания по доработке ПКЗО [ Денис Николаев (разработчик) ]
Вторник, 19 сентября 2017, 18:06

> чтобы разгрузить базу, обратился к параллельной базе в Mapinfo, где сделал SQL запрос
> на пересечение 10 метровой буферной зоны моего объекта с земельными участками,
> получил их список. Далее импортировал XML не целиком, а выбирал каждый участок,
> список которых был ранее получен. Ох уж и муторно это все было… 

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

> Далее подгружаю полностью XML в виде графики. Исключать из загрузки в графику уже
> загруженные в базу участки не стал, так как времени на это все не было. Загрузил как
> есть и очень «удивился». Поскольку в КПТ на квартал имеются участки из нулевого квартала,
> то ПКЗО загрузила их ВСЕ в графику не анализируя на дубли. Получилось, что дублирующих
> слоев доходило до 10! Это опять же загружало базу ненужной информацией.

Количество возможных дублей в разных КПТ, как правило, незначительно и вряд ли окажет существенное влияние на производительность.

При загрузке только графики проверку на дубли можно сделать только путем сравнения полигонов (связанной информации нет). Смысла в такой проверке мы не видим.

В случае загрузки нескольких КПТ, мы рекомендуем грузить каждый КПТ в отдельный слой (с номером квартала). Тогда по принадлежности к слою можно будет определить источник.

> Ну и самое муторное это подготовка графики, которая заняла 90 процентов всего времени и
> включала в себя размещение номеров поворотных точек, номеров участков и наведение
> прочей красоты, поскольку ту графику, которую автоматически формирует программа
> предоставлять заказчику совершенно нельзя!

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

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

> 1) При загрузке из XML участков и других объектов средствами ПКЗО не предусмотрен выбор участков по буферу
> от какой-то линии (объекта), а приходится вручную выбирать каждый участок и искать его в «бесконечном» списке
> из ЕЗП, многоконтурных и обособленных, что на самом деле оказалось не простой (быстрой) задачей.
> Это же касается и выбора ЗОУИТ, ОКСов. 

Возможность задать фильтр по расстоянию до объектов работ находится в разработке и будет доступна в ближайшее время.

> 2) В ПКЗО при выборе участков (ЗОУИТ, ОКСов) из XML не предусмотрено возможности сохранить выборку,
> обратить выборку, чтобы в графику не загружать те участки, которые ранее были загружены в базу. 

В одной из следующих версий при загрузке из XML в списке выбора объектов добавим поле, показывающее наличие объекта в проекте. Также добавим возможность исключения из загрузки тех объектов, которые уже есть в проекте.

> 3) При генерации графики расположение надписей участков, кварталов, зон и проч. оказываются в таких местах,
> что найти и перенести надпись в зону листа рядом с образуемым участком оказывается не простой задачей,
> даже с применением кнопки показать надпись на карте. Как я понял надпись не всегда располагается в центроиде.
> У линейных объектов она расположена в начале объекта. Неужели нельзя сделать кнопку, чтобы при нажатии
> на объект подпись, относящаяся к нему, размещалась в этом месте? Другими словами, не искать ее по всей карте
> и перемещать из одного края карты в другой, а просто в области листа нажать кнопку, ткнуть в объект и вуаля!
> Подпись этого объекта оказалась в этой точке! 

Добавим такую возможность в одной из следующих версий. В контекстном меню объекта будет пункт "Графика\Позиционировать надпись".

> 4) При разбивке на листы в случае с длинными образующимися участками, которые из-за своей длины
> помещались на нескольких листах, приходится копировать номер участка и растаскивать на другие листы,
> чтобы было понятно какой участок образуется. То же приходится делать с надписями кварталов, больших
> смежных участков, зон! Это занимает очень много времени! 

Проблема понятна. Рассмотрим возможность создания нескольких надписей на каждом листе.

> 5) Когда из скопированного межевого плана делал вид работ – «схема на КПТ», то ПКЗО удаляет слой с Чертежом,
> а оставляет схему, что приводит к дополнительным проблемам. Дело в том, что масштаб Чертежа в МП выбирается
> исходя из читаемого расположения номеров поворотных точек, что не скажешь о схеме, где должны читаться только
> номера участков. И по логике Чертеж из МП схож со Схемой из СРЗУ. На нем также отображаются номер поворотных
> точек, необходим тот же масштаб для читаемости, та же разбивка на листы. По моему мнению при изменении
> вида работ на СРЗУ из МП необходимо полностью копировать масштаб, разбивку на листы, расположение
> нумерации поворотных точек образуемых участков из Чертежа! Это ускорит процесс разработки пары МП-СРЗУ! 

Сделаем в одной из следующих версий.

> 6) Применение ГИС ObjectLand в ПКЗО, по моему мнению, не самый оптимальный вариант, так как обновление
> графики происходит очень долго, на порядок дольше чем делает то же MapInfo. Может это связано с точностью карты?
> Если это так, то считаю самым оптимальным изначально делать точность карты в OL кратной 1 сантиметру,
> как это реализовано в MI c числами с плавающей запятой! Убрать кнопку округление координат, а при импорте
> границ в ПКЗО делать округление в процессе импорта. 

Нет, это не связано с точностью карты. При выставлении точности карты в MapInfo нужно учитывать, что она влияет не только на хранение, но и на вычисления. В зависимости от формулы это может давать существенную погрешность.

Аналоги ПКЗО для MapInfo, насколько я знаю, хранят координаты прямо в виде графических объектов. В ПКЗО все координаты хранятся отдельно, а графика создается только для построения изображения. Это занимает время, но дает определенные возможности: хранить дополнительные атрибуты для точек, ребер, границ, плюс можно показывать один объект по разному в разных разделах.

> 7) Генерализация надписей — это тоже проблема, так как на карте после генерации графики показываются
> абсолютно все надписи, что создает кашу! Может рассмотреть связку ПКЗО QGIS? Насколько я знаю почти
> во всех нормальных ГИС предусмотрена возможность генерализации подписей, если подпись не помещается
> в границы участка, она не показывается. То же реализовано и на ПКК Росреестра, которая реализована на ArcGIS.
> Я еще раз заострю внимание на подготовке графики, которая является лицом межевого плана и занимает уйму
> времени в ПКЗО! 

Генерализация надписей подходит для динамических карт (где пользователь по мере просмотра меняет видимую область и масштаб). В кадастровых работах это уместно лишь при анализе ситуации. При формирования графических разделов кадастровых документов видимая область и масштаб фиксированы и нужно обеспечить видимость ВСЕХ надписей. Если скрыть часть надписей, это может послужить основанием для приостановки. Поэтому возможность генерализации может быть и была бы полезной в каких-то ситуациях, но не при подготовке графических разделов.

> 8) После загрузки в графику из XML дублирующих слоев и обновления надписей, каким-то образом эти
> надписи немного сместились одна относительно другой и стали выглядеть жирными и размытыми.
> Пришлось удалять дубли вручную, их много и это тоже очень долго. Учитывая, что надпись располагается
> над участком, потом опять участок, а над ним надпись, то пришлось удалять еще и дублирующиеся участки,
> загруженные в графику из XML! 

Для таких задач удобно пользоваться управлением видимости и селектируемости слоев, доступным в окне легенды. Если нужно удалить объекты только из заданного слоя, то можно выключить селектируемость для всех других слоев. Это обеспечит выбор объектов только из нужного слоя или типа.

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

> 9) При добавлении из панели проекта ЗОУИТ, они не сортируются по номеру! Опять трата времени на поиск нужной зоны! 

Сортировку исправим. Как-то проглядели.

> 10) Зоны автоматически не добавляются в свойства участка, который полностью или частично расположен в ЗОУИТ.
> Это приходится делать вручную самостоятельно, или опять же в сторонней программе MapInfo помощью SQL
> запроса получать список ЗОУИТ, которые пересекают участок. Думаю, это несложно реализовать, если учесть,
> что нечто похожее вы уже сделали с поиском ОКС, которые пересекают или расположены на участке. 

Эта возможность запланирована и будет добавлена в одной из следующих версий.

> 11) Было бы неплохо, чтобы у слоев можно было бы сделать показ узлов в полигонах. Это удобно, когда границу
> проектируемого участка с помощью стяжки необходимо подтянуть к смежному ЗУ. 

Не очень понял как это должно работать. Если это должно работать на лету, то, скорее всего, не получится. Такое могут позволить CAD-программы, где все объекты уже загружены в память. В ГИС, где объекты загружаются только по необходимости, такая операция будет работать с большими тормозами (или нужно применять кэширование, а это уже делает слишком большую сложность задачи).

> 12) При удалении границы сформированного участка (если необходимо изменить границу на новую)
> вылетает ошибка «Операция не допустима в текущем режиме блокировки транзакции (Код ошибки ГИС:210).
> Может это связано с моей WIN10 и правами к базе данных? Но при отказе от отправки ошибки разработчикам
> операция все же выполняется. 

Это точно не связано с версией Windows и с правами к базе. Нужно разбираться. Если эта ошибка воспроизводится, то нужно это отдельно рассмотреть, чтобы мы смогли у себя воспроизвести и исправить.

> 13) При проверке МП в ошибках указываются наложения менее 1 см, что не верно. 

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

> 14) Кнопка включения панели проекта включается, если нажать точно в центр. А если с краю, то кнопка
> проваливается, но действия не происходит.

Исправлено.


 Пожелания по доработке ПКЗО [ Андрей ]
Вторник, 19 сентября 2017, 23:00

Спасибо за внимание к проблемам! Буду ждать обновления с моими замечаниями! А там посмотрим, может еще что всплывет! )))

Но Вы все-же протестируйте добавление дублирующих участков, чтобы обнаружить причину изменения положение текстовых надписей участков, которые смещаются и становятся визуально жирными с эффектом размытости. Это выглядит совсем не красиво. Хотя бы добиться того, чтобы надписи не разъезжались, раз анализ на дубли при загрузке в графику Вы делать не планируете. Да, это не существенно влияет на скорость работы программы, но влияет на скорость работы оператора по приведению в читаемый вид графических разделов.

 Пожелания по доработке ПКЗО [ ВладимиR [42] ]
Среда, 20 сентября 2017, 07:27

6) Применение ГИС ObjectLand в ПКЗО, по моему мнению, не самый оптимальный вариант, так как обновление графики происходит очень долго, на порядок дольше чем делает то же MapInfo. Может это связано с точностью карты? Если это так, то считаю самым оптимальным изначально делать точность карты в OL кратной 1 сантиметру, как это реализовано в MI c числами с плавающей запятой! Убрать кнопку округление координат, а при импорте границ в ПКЗО делать округление в процессе импорта.

У МИ - свое представление хранения координат (на сколько я помню, она хранит в целых числах), точность зависит от размера границ карты

Надо полностью уходить от операций с плавающей точкой. Конечно это надо тестировать на проектах. Так как для четырехугольного ЗУ это будет незаметно.

 Пожелания по доработке ПКЗО [ ВладимиR [42] ]
Среда, 20 сентября 2017, 07:34

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

 Пожелания по доработке ПКЗО [ Андрей Егоров ]
Среда, 20 сентября 2017, 08:19

А кто будет администрировать?

 Пожелания по доработке ПКЗО [ ВладимиR [42] ]
Среда, 20 сентября 2017, 09:57

Как кто – кому больше всех надо.

 Пожелания по доработке ПКЗО [ ВладимиR [42] ]
Среда, 20 сентября 2017, 09:59

Естественно зависит от штата, объемов, подхода к работе.

 Пожелания по доработке ПКЗО [ Андрей Егоров ]
Среда, 20 сентября 2017, 10:35

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

 Пожелания по доработке ПКЗО [ Игорь Тыщенко ]
Среда, 20 сентября 2017, 11:09

Хочу сказать про еще один недостаток. В настройках выключено обновление графики сразу после операции. Участок в новых границах содержит элементы контура. При актуализации графики, не происходит обновление обозначений этих элементов на чертеже. Пишет что нет объектов требующих обновления. Приходится заходить в свойства каждого элемента, снимать галку «формировать автоматически» и только потом актуализация проходит нормально.

 Пожелания по доработке ПКЗО [ Андрей ]
Среда, 20 сентября 2017, 12:07

У МИ - свое представление хранения координат (на сколько я помню, она хранит в целых числах), точность зависит от размера границ карты

Я и имел ввиду, что задаешь размер карты, а точность сразу идет кратная 1 см. У мапинфо например это можно сделать, задав границы от -2 000 000 до 2 000 000 (насколько помню). Плавающая в нашем случае не нужна. Просто я имел ввиду, что изменив точность сразу до 1 см, которая выше и не нужна, можно повысить скорость прорисовки по-моему мнению. Еще бы сделали возможность включать сетку в виде точек с 1 см шагом для наглядности и привязки. Тоже было бы удобно.

 Пожелания по доработке ПКЗО [ Андрей ]
Среда, 20 сентября 2017, 12:12

А еще бывает надо скопировать одну подпись и вставив ее исправить значение надписи. В режиме когда она селектируется красным цветом. Было бы удобно попадать в меню редактирование двойным нажатием на надпись в этом режиме. А не запускать через контекстное меню нажатием строки "Редактировать".

 Пожелания по доработке ПКЗО [ ВладимиR [42] ]
Среда, 20 сентября 2017, 12:54

Андрей, компьютер (программа) не знает ничего о см или м. Как скажешь называть единицу измерения - так и будет. Это абстракция, также как вас зовут Андрей, а меня Владимир. :D

 Пожелания по доработке ПКЗО [ Денис Николаев (разработчик) ]
Среда, 20 сентября 2017, 13:20

> Недавно делали образование части в участке лесного фонда, границы которого состоят
> из нескольких контуров и более чем 18 тысяч точек, так генерация графики составляла
> более 4-5 часов (приходилось оставлять на ночь),

Количество точек не очень большое. Скорее всего, дело в других объектах. В главном окне, если позиционироваться на проект, в правой панели отображается общее число записей в проекте. Это более информативный индикатор, чем количество точек (участка-объекта работ или даже всех участков).

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

> а формирование печатного документа вообще получилось только после отключения в Ворде
> проверки орфографии и пунктуации, иначе 872 страницы печатного документа просто
> не формировались из-за большого количества ошибок.

На больших документах проверка орфографии и пунктуации может приводить к проблемам. Зависит, конечно, от версии Word и конфигурации компьютера, но в любом случае рекомендуется это отключать.

> Но Вы все-же протестируйте добавление дублирующих участков, чтобы обнаружить причину
> изменения положение текстовых надписей участков, которые смещаются и становятся визуально
> жирными с эффектом размытости. Это выглядит совсем не красиво.

Фактическая высота надписей зависит от текущего масштаба. Если масштаб будет отличаться, то надписи будут разного размера. Если масштаб будет отличаться незначительно, то надписи будут выглядеть как с эффектом размытости.

Чтобы добиться полного совпадения надписей, убедитесь, что на момент загрузки каждого файла масштаб будет идентичный.

Если все-таки проблема возникла, можно попробовать ее исправить с помощью команды "Сервис\Параметры текстовых объектов..." в меню окна просмотра карты. Эта команда позволяет установить высоту сразу для всех надписей в заданных слоях\типах. Нужно выставить одинаковую высоту для всех перекрывающихся надписей.

> Еще бы сделали возможность включать сетку в виде точек с 1 см шагом для наглядности и привязки.
> Тоже было бы удобно.

Такая возможность есть. В панели управления редактором (открывается при выборе режимов редактирования, когда объекты выделяются синим цветом) на вкладке "Сетка" установите шаг 0,01. Там же можно управлять видимостью сетки и привязкой к сетке при выполнении операций с объектами карты.

> А еще бывает надо скопировать одну подпись и вставив ее исправить значение надписи.
> В режиме когда она селектируется красным цветом. Было бы удобно попадать в меню
> редактирование двойным нажатием на надпись в этом режиме. А не запускать через
> контекстное меню нажатием строки "Редактировать".

На команду "Объект\Редактировать..." можно настроить горячую клавишу. Для этого в меню окна просмотра карты выберите пункт "Вид\Панели инструментов\Настройка". Там на вкладке "Клавиатура" найдите команду "Объект\Редактировать" и назначьте ей комбинацию клавиш.


 Пожелания по доработке ПКЗО [ Денис Николаев (разработчик) ]
Среда, 20 сентября 2017, 17:25

Игорю Тыщенко

> Хочу сказать про еще один недостаток. В настройках выключено обновление графики
> сразу после операции. Участок в новых границах содержит элементы контура.
> При актуализации графики, не происходит обновление обозначений этих элементов на чертеже.
> Пишет что нет объектов требующих обновления. Приходится заходить в свойства каждого элемента,
> снимать галку «формировать автоматически» и только потом актуализация проходит нормально.

Уточните после какой операции актуализация графики не отрабатывает. Если это происходит после изменения свойств, то сообщите в каком объекте (участке, контуре, элементе контура) были изменения и какие именно характеристики менялись.


 Пожелания по доработке ПКЗО [ Игорь Тыщенко ]
Среда, 20 сентября 2017, 20:32

1.Тип документа "Межевой план". На чертеже образуемый (допустим, на измененных также) участок соответственно обозначен :ЗУ1. Меняем тип документа на "Проект межевания". На чертеже теперь должно отображаться :ЗУ1/Какая-то площадь, но при актуализации графики объектов требующих обновления нет.
2.Тип документа "Проект межевания".На чертеже образуемый участок соответственно обозначен :ЗУ1/Какая-то площадь. Меняем тип документа на "Межевой план". На чертеже теперь должно отображаться :ЗУ1, но при актуализации графики объектов требующих обновления нет.
3.Тип документа "Проект межевания". Если снимаем галку "Вычислять по координатам" в свойствах участка и прописываем там любую другую площадь, то опять нет объектов для актуализации.
Это из того, что попадалось...

 Пожелания по доработке ПКЗО [ Игорь Тыщенко ]
Среда, 20 сентября 2017, 20:39

Добавлю...
При генерировании графики все отображается как надо и если включено обновление сразу после операции, также все прорисовывается...
Это именно в элементе контура

 Пожелания по доработке ПКЗО [ Андрей ]
Четверг, 21 сентября 2017, 11:46

Андрей, компьютер (программа) не знает ничего о см или м. Как скажешь называть единицу измерения - так и будет. Это абстракция, также как вас зовут Андрей, а меня Владимир. :D

Да кто же спорит? Однако в есть требования к точности описания координат в законодательстве относительно кадастровых работ кратной 1 см. ПКЗО в свою очередь подготавливает документацию для него и условно принята система СИ за единицу измерения метр и округление до сантиметра (эти единицы указываются при формировании межевого плана между прочим, а не абстракционно), а в карте можно привязать объект до сотых (или еще точнее, не помню). Потому и думаю зачем делать нижнюю границу точнее, если необходимо и достаточно сделать кратной 1 см.

Если бы я написал ранее не 1 см, а сотую единицы карты, думаете многие бы это поняли? Зачем все усложнять? Или хотите поделиться своими знаниями в ГИС, СУБД, языках программирования?

 Пожелания по доработке ПКЗО [ Денис Николаев (разработчик) ]
Четверг, 21 сентября 2017, 17:11

Игорю Тыщенко

Актуализация после изменения типа документа исправлена.

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


 Пожелания по доработке ПКЗО [ Игорь Тыщенко ]
Четверг, 21 сентября 2017, 19:54

Давайте я вам проект скину, а вы посмотрите...

 Пожелания по доработке ПКЗО [ ВладимиR [42] ]
Пятница, 22 сентября 2017, 05:28

2Андрей, по поводу точности, она должна быть такой, какой нужна стандартами на предприятии, стандарты на предприятии могут быть выше требований, также как и требования могут поменяться, и пользователь не должен заботиться об этом.

По поводу хвастаться: вы можете считать что угодно, где угодно, свобода мысли.

 Пожелания по доработке ПКЗО [ Денис Николаев (разработчик) ]
Пятница, 22 сентября 2017, 13:15

Игорь Тыщенко, нашли, исправили.

 Пожелания по доработке ПКЗО [ Игорь Тыщенко ]
Понедельник, 2 октября 2017, 14:31

Здравствуйте!
Опишу еще незначительный огрех в работе программы, связанный с панелью управления редактором. Если в режиме с нажатой кнопкой «Редактирование» и «Панель управления редактором», выключаем отображение панели управления редактором, то при нажатии на мыше колеса прокрутки панель редактирования опять появляется. В это время кнопка «Панель управления редактором» не нажата. Такое происходит только в режиме редактирования. В режиме селекции все нормуль.

 Пожелания по доработке ПКЗО [ Денис Николаев (разработчик) ]
Понедельник, 2 октября 2017, 17:00

Исправили.


 Пожелания по доработке ПКЗО [ Андрей Ларионов ]
Среда, 11 октября 2017, 18:58

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

 Пожелания по доработке ПКЗО [ Иван Климентьев (разработчик) ]
Четверг, 12 октября 2017, 09:03

О каком типе документа и о каком графическом разделе идет речь?

 Пожелания по доработке ПКЗО [ Андрей Ларионов ]
Четверг, 12 октября 2017, 10:26

Технический план

 Пожелания по доработке ПКЗО [ Иван Климентьев (разработчик) ]
Четверг, 12 октября 2017, 10:36

О каких конкретных слоях (точные названия), какого графического раздела техплана идет речь?

 Пожелания по доработке ПКЗО [ Андрей Ларионов ]
Четверг, 12 октября 2017, 15:07

Технический план сооружения. Раздел "схема расположения". Слой "границы кварталов" расположен на один уровень выше слоя "исходные участки", поэтому в карте схемы расположения границы участков лежат сверху границ кварталов. Визуально лучше смотрится, когда в окне схемы расположения границы кварталов лежат поверх земельных участков

 Пожелания по доработке ПКЗО [ Денис Николаев (разработчик) ]
Четверг, 12 октября 2017, 15:49

Согласно п.54 Требований границы кварталов отображаются на схеме расположения в техническом плане только при условии, что в ЕГРН отсутствуют сведения о границах участка (или участков), на котором расположен объект работ. В связи с чем проблема наложения границ участков и квартала на практике возникать не должна.


 Пожелания по доработке ПКЗО [ Андрей Ларионов ]
Четверг, 12 октября 2017, 15:55

А если окс попадает в один участок одного квартала и второй участок другого квартала. Или лежит в пределах земельного участка с кварталом 0000001 и частично располагается в квартале 0000002. Или, например, проходит по земельным участкам в десяти кварталах, то вы считаете что границы кадастровых кварталов отображать не нужно?

 Пожелания по доработке ПКЗО [ Денис Николаев (разработчик) ]
Четверг, 12 октября 2017, 16:23

Если в наличии сведения о границах всех участков, на которых расположено, например, линейное сооружение, то границы кварталов отображать не нужно, даже если сооружение расположено в нескольких кварталах. Это вытекает из формулировки п.54, где сказано "при отсутствии в ЕГРН описания местоположения границ земельного участка в виде списка координат характерных точек".

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

Конечно, на практике всякое может быть: например, сооружение очень протяженное и границы участков получаются нечитаемыми в масштабе схемы и тогда удобнее будет ориентироваться по границам кварталов. Это достаточно редкий случай и в данном случае порядок слоев можно скорректировать вручную.

Нам не сложно поменять порядок слоев по умолчанию, просто в вашем случае (если вы не абстрактно рассуждаете) удобнее, если кварталы поверх участков, а в каких-то случаях (когда наложение небольшое) кому-то удобнее наоборот. Поэтому, наверное, лучше оставить как есть.


 Пожелания по доработке ПКЗО [ Ксения ]
Понедельник, 23 октября 2017, 16:00

Добрый вечер!! Прошу помочь, вопрос крайне срочный.. Выполняю раздел зу с сохранением в измененных границах. У исходного участка есть чзу.. так вот когда я создаю аналогичные части в разделенных контурах и переношу наименование с исходных, при выгрузке в хмл мне выдает критичное замечание о том, что количество символов не предусматривает.. 400 вроде было написано, а у меня явно текст больше. Текст копирую точно как выписке из егрн. Как-то можно увеличить количество символов в строке "характеристики объекта"??

 Пожелания по доработке ПКЗО [ Иван Климентьев (разработчик) ]
Понедельник, 23 октября 2017, 16:23

Увеличить нельзя. 4000 символов – ограничение утвержденной Росреестром xml-схемы МП. Большее количество приведет к несоответствии xml-схеме – гарантированный отказ.


 Пожелания по доработке ПКЗО [ Асламбек Амхадов ]
Понедельник, 23 октября 2017, 16:28

Здравствуйте! Когда добавите опцию согласие на обработку персональных данных, обещали вроде

 Пожелания по доработке ПКЗО [ Денис Николаев (разработчик) ]
Понедельник, 23 октября 2017, 17:11

Работаем над этим. Будет через несколько дней.

 Пожелания по доработке ПКЗО [ Екатерина ]
Пятница, 27 октября 2017, 15:39

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

 Пожелания по доработке ПКЗО [ Асламбек Амхадов ]
Пятница, 27 октября 2017, 15:44

Присоединяюсь :))

 Пожелания по доработке ПКЗО [ Константин Финагеев (разработчик) ]
Пятница, 27 октября 2017, 16:56

Спасибо за позитивные слова от всего нашего коллектива!

Автоматическое формирование программой описания измененной части границы смежного участка - одна из множества вещей в ПКЗО, которой я горжусь :)

Рассказывайте также своим коллегам-пользователям других программ за что Вам нравится ПКЗО, может они и смогут понять, чего лишены :).


 Пожелания по доработке ПКЗО [ Екатерина ]
Пятница, 27 октября 2017, 17:14

Ну это было при большом скоплении кадастровых инженеров сказано, кто захотел, наверное, задумался)
А, вообще, да, я вас объективно рекомендую коллегам. И нынешний дикий сэйл на приобретение, по моему мнению, лишил конкурентов последнего преимущества)

 Пожелания по доработке ПКЗО [ Алексей Показиев ]
Вторник, 31 октября 2017, 14:59

Использую версию ПКЗО 5.1.6. При формировании декларации, если выбрать тип окса, в остальных графах отсутствуют прочерки. То же самое в п. 1.2, 1.3,1.4, 5.1, 6.3. Ранее обещали исправить. В актуальной версии это исправлено?

 Пожелания по доработке ПКЗО [ Иван Климентьев (разработчик) ]
Вторник, 31 октября 2017, 15:02

Мы не поняли Вашего вопроса. 

Почему бы не установить актуальную версию и получить экспресс -ответ на вопрос....


 Пожелания по доработке ПКЗО [ Алексей Показиев ]
Вторник, 31 октября 2017, 15:11

Потому что период обновления закончен, версия 5.1.6 рабочая, без багов. Одной из причин продления обновления послужит внесение изменений в заполнение декларации

 Пожелания по доработке ПКЗО [ Иван Климентьев (разработчик) ]
Вторник, 31 октября 2017, 15:17

Мы не поняли Вашего вопроса. Опишите понятными словами.

PS. Всегда можно вернуться на предыдущую версию, сделала предварительно резервную копию ГБД перед обновлением. Ничего хитрого в этом нет.


 Пожелания по доработке ПКЗО [ Алексей Показиев ]
Вторник, 31 октября 2017, 15:23

При выборе типа ОКСа "здание", в ячейках "помещение", "сооружение", "машино-место" остаются пустые места, а нужны прочерки. Также пустыми остаются не выбранные значения "материал наружных стен здания", "публичное образование"

 Пожелания по доработке ПКЗО [ Иван Климентьев (разработчик) ]
Вторник, 31 октября 2017, 15:48

Насколько мы помним, ничего подобного не обещалось. Здесь объясняли, почему не проставляются прочерки.


 Пожелания по доработке ПКЗО [ Алексей Показиев ]
Вторник, 31 октября 2017, 16:07

Всегда заполнял вручную прочерками пустые ячейки, ни разу не было замечаний от регистраторов. Видимо продолжу руками забивать незаполненные поля декларации. Спасибо за оперативные ответы

 Пожелания по доработке ПКЗО [ Владимир Полянский (разработчик) ]
Вторник, 31 октября 2017, 17:17

Способ выбора нужного варианта "галочкой", по нашему мнению, не предполагает вычеркивания всех не правильных вариантов...

Скажите, кто-то от вас требует проставлять прочерки в пустых ячейках? Вы пробовали сдавать без прочерков?

Другие пользователи сдают декларации без прочерков и у них они проходят проверку.


 Пожелания по доработке ПКЗО [ Алексей Показиев ]
Вторник, 31 октября 2017, 17:36

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

 Пожелания по доработке ПКЗО [ Денис Николаев (разработчик) ]
Вторник, 31 октября 2017, 17:53

Алексей, я вас уверяю, что никто не ставит прочерки для галочек. Но раз вы сомневаетесь, давайте попробуем проверить. Напишите в каком регионе вы работаете, а ваши коллеги, работающие в вашем регионе, подтвердят, что все проходит без проблем, риска приостановок нет.


 Пожелания по доработке ПКЗО [ Алексей Показиев ]
Вторник, 31 октября 2017, 19:31

Москва и область

 Пожелания по доработке ПКЗО [ Михаил ]
Среда, 1 ноября 2017, 03:42

Здравствуйте. не знаю, писали ли в этой теме предложение по доработке такой функции как увеличение/уменьшение масштаба к центру курсора мыши. Считаю что данная функция необходима, так как обычное увеличение/уменьшение занимает огромное количество времени при работе с большими объектами.
Прошу рассмотреть данное предложение.
С уважением Михаил!!!

 Пожелания по доработке ПКЗО [ Денис Николаев (разработчик) ]
Среда, 1 ноября 2017, 16:22

> увеличение/уменьшение масштаба к центру курсора мыши.

Эта возможность уже есть: при вращении колесика мыши удерживайте клавишу Shift.


 Пожелания по доработке ПКЗО [ Денис Николаев (разработчик) ]
Среда, 1 ноября 2017, 16:41

Уважаемые инженеры, просим помочь и развеять наши сомнения: кто-нибудь сдавал успешно в Москве или Московской области декларации об объекте недвижимости, в которых незаполненные места для галочек оставлены без прочерков. Хотелось бы подтверждения, что на практике в этих регионах все проходит успешно.


 Пожелания по доработке ПКЗО [ Марсель ]
Четверг, 2 ноября 2017, 08:51

План этажа рисуем в сторонних САПР. Нельзя ли добавить в панель ПКЗО несколько CAD инструментов: добавление линейных объектов заданной длины по заданному углу,добавление параллельных на заданном расстоянии, отслеживание, привязка?

 Пожелания по доработке ПКЗО [ Денис Николаев (разработчик) ]
Четверг, 2 ноября 2017, 11:31

Мы рассматривали возможность добавления инструментов для создания поэтажных планов. Для нас задача не профильная (все-таки это специфика САПР, а не ГИС) и соответственно потребует по сути создания нового редактора. При этом на рынке уже есть достаточное количество инструментов для этой задачи. В результате пока решили не делать.

Если есть проблемы с переносом планов из сторонней программы в ПКЗО, обращайтесь, постараемся найти решения.


 Пожелания по доработке ПКЗО [ Марсель ]
Вторник, 7 ноября 2017, 07:35

Проблемы думаю не существенные, ObjectLand принимает в .dxf из nanocad и autuocad, только надписи куда-то исчезают, размеры и площади, приходится доделывать.

 Пожелания по доработке ПКЗО [ Денис Николаев (разработчик) ]
Вторник, 7 ноября 2017, 13:26

Почему вы переносите планы через вектор (dxf), а не целиком готовое изображение?

Мы рекомендуем загружать планы в ПКЗО в виде растровых объектов с готовым изображением. В этом случае отрисовка плана будет выполнена в той программе, в которой план готовился. Это важно, т.к. специализированная программа имеет более подходящие средства отрисовки для поэтажных планов.

Если загружать векторное представление, то дополнительно, как минимум, потребуется настроить стилевое оформление. И не факт, что ПКЗО сможет отрисовать изображение, идентичное тому, которые было в исходной программе.

Ответить

Знаком «*» отмечены обязательные для заполнения поля.
Ваше имя:  *
Адрес электронной почты:  
Тема:  *
Сообщение:
 *
Подтверждение:
(не требуется для зарегистрированных пользователей)
 *
 
Copyright © 2016–2017 ООО «Радом-АйТи»
Лицензионое соглашение
главная | новости | о продукте | скачать | купить | форум | библиотека | наш адрес