CADmaster

Программа PlanTracer пользуется у специалистов заслуженной популярностью: это приложение создавалось специально для БТИ, в нем реализованы именно те приемы работы, которые каждый день используются техниками-инвентаризаторами. В этой статье мы рассмотрим менее известные (но не менее важные!) возможности PlanTracer — взаимодействие с другими приложениями.

Другая сторона

Журнал уже не раз рассказывал о построении планов средствами PlanTracer — мы же поговорим о совместной работе PlanTracer ¹ с другими решениями, в первую очередь с базами данных, содержащих описательную (семантическую) ² информацию по объектам недвижимости.

Мы предлагаем взглянуть на новейшую, третью версию PlanTracer как на поставщика не только графических планов, но и другой информации, используемой в работе бюро технической инвентаризации (БТИ). Ниже рассматриваются различные способы взаимодействия PlanTracer с другими системами, приводится пример совместной работы PlanTracer и АС «Архив».

«Невидимая» информация

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

Зачем это нужно? План создается не для красоты: по результатам инвентаризации необходимо получить экспликацию объекта недвижимости (квартира, дом, нежилые строения и пр.) — список всех помещений и их частей с основными характеристиками, к которым, в частности, относятся площадь, а также формула ее получения. Экспликация является основой главного документа на объект недвижимости — технического паспорта (ТП).

Эти данные, хранящиеся в атрибутах объектов плана, вы можете видеть в диалогах свойств этажа, помещения, части помещения (рис. 1−3).

Рис. 1. Диалог свойств этажа

Рис. 2. Диалог свойств помещения

Рис. 3. Диалог свойств части помещения

«Раздельная» и «единая» технология

Читатель может спросить — зачем же заполнять невидимые атрибуты на графическом плане, ведь это не обязательно? Конечно, не обязательно. Можно просто сделать картинку и распечатать ее, вот только никакой пользы от такого плана не будет. А как же экспликации? Большая часть БТИ формирует их, используя собственные базы данных (БД). Конечно, купив PlanTracer, можно всё оставить как есть. В этом случае чертить станет гораздо приятнее и быстрее, но и только. Назовем это «раздельной» технологией, не предполагающей никакого обмена между PlanTracer и БД.

Нужен ли такой обмен? И чем, собственно, обмениваться?

Для примера представим на плане кухню из квартиры № 12.

Можно вычертить план в PlanTracer, а потом, уже в БД, создать эту же кухню и ввести всю описательную информацию (площадь, формулу, назначение и тип площади и пр.).

Такой вариант возможен, но содержит ряд проблем.

Самая большая из них — сложность расчетов площади без плана. Все равно придется держать перед глазами абрис — схематичный чертеж, который техник приносит с обмера. Я не раз видел, как люди мучаются с разложенным бумажным планом и БД, открытой на компьютере. Когда дело доходит до заполнения базы, нужно постоянно смотреть на план, а площадь вообще зачастую отдельно рассчитывается на калькуляторе. В итоге много нудной работы и постоянный риск ошибки. А ошибка в расчете площади при нынешних ценах на недвижимость и аренду может закончиться судом и стоить больших денег!

Гораздо более логичным представляется другой путь: коль скоро многие данные зависят от графического плана, то и работать с ними нужно прямо на плане! Действительно, когда перед глазами имеется план кухни из квартиры № 12, сразу становятся ясны многие вещи: площадь, использованная формула…

Вот мы и получили ответ: PlanTracer и базе данных есть чем обмениваться. Это данные для экспликации. Причем обмен возможен в обе стороны. Передача данных с плана в БД необходима в случае первичной инвентаризации, когда в базе еще нет никакой информации. В этой ситуации логично создать сначала план, а потом перенести экспликацию с плана в БД. Эти данные останется дополнить тем, чего нет и не может быть на плане: сведениями о принадлежности (владельцах), благоустройстве, расчете стоимости и т.д.

При текущей инвентаризации план в PlanTracer может создаваться уже после того, как в БД занесена информация по объекту недвижимости и рассчитаны площади. В этом случае лучше перенести экспликацию из БД на план. Работа с планом станет проще — на нем можно будет легко ориентироваться по номерам и названиям помещений.

Два пути. Путь первый: COM

Ответив на вопрос, чем именно обмениваться, посмотрим на то, как это делается. Здесь возможны два пути. Первый из них — работа с PlanTracer через его COM API.

Такой вариант прост в использовании и наиболее распространен, при этом обе программы (PlanTracer и программа, получающая/передающая данные с плана или на план) должны быть запущены на компьютере одновременно. Этот способ используется, например, в отчетах на базе MS Excel. Примеры отчетов расположены в папке [папка с установленным PlanTracer]/Samples. На базе этих примеров многие БТИ разработали собственные формы.

Для разработки используется простой язык программирования Visual Basic for Application (VBA). Освоить его недолго, тем более что при создании новой формы понадобятся лишь элементарные навыки.

Возможно использование и других современных языков программирования: С, Delphi. Все они поддерживают COM, что и позволило многим БТИ подключить PlanTracer к собственным базам данных.

Подробное описание COM API PlanTracer находится в Руководстве разработчика (рис. 4), которое устанавливается вместе с программой [папка с установленным PlanTracer]/Help.

Рис. 4. Руководство разработчика

Два пути. Путь второй: XML

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

Объясняется это простотой, универсальностью и независимостью такого решения. XML — это способ создания своих форматов («языков») передачи данных в текстовых файлах. Скажем, одна программа, написанная на Visual Basic, выдает результаты в виде XML-файлов, а другая, написанная на C и работающая под Linux, использует результаты для дальнейшей обработки и т.д. Это открывает огромные возможности совместной работы приложений.

Например, в Роснедвижимости разработан формат XML для передачи данных по объектам недвижимости, земельным участкам, собственникам и т.д. Данные в этом формате передаются из БТИ в Роснедвижимость при создании Единого государственного реестра объектов капитального строительства (ЕГРОКС). В рамках пилотного проекта такая работа уже проведена — в Тверском областном БТИ. Подробнее с форматом можно ознакомиться на сайте ФКЦ «Земля" ³ - основного разработчика информационных решений для Роснедвижимости.

В третьей версии PlanTracer тоже получил возможность выдавать семантические данные с плана в формате XML, а также принимать их. Передается вся неграфическая информация, такая как номера и названия помещений, площади, формулы площадей и многое другое. Точное описание формата (в виде XML-схемы документа) можно найти в файле Plan.xsd ([папка с установленным PlanTracer]/Config), а фрагмент XML-файла — увидеть на рис. 5.

Рис. 5. Пример XML-выгрузки из PlanTracer

Практически использовать XML из PlanTracer можно, например, в MS Office 2003, где обеспечена полноценная поддержка XML и существуют специальные инструменты работы с ним.

Работа с PlanTracer через XML уже реализована в АС «Архив-БТИ» (НПО «Криста»).

А что на входе?

Выдача информации с плана в формате XML — это только полдела. В различных БТИ могут использоваться разные названия помещений и классификация типов площади. Предложенного набора характеристик (атрибутов) объектов также может не хватить. Если бы в PlanTracer была жестко «зашита» какая-то схема, он был бы непригоден для большинства организаций. Чтобы обеспечить совместимость с принятой схемой работы и существующим программным обеспечением, требуется дополнительная настройка.

Разработчики предусмотрели гибкую настройку типов площади, а также механизм пользовательских атрибутов. И, что самое главное, эти настройки тоже хранятся в формате XML!

Редактировать названия и типы площадей можно через окно Классификатор помещений или напрямую — в файле RoomTypes.xml ([папка с установленным PlanTracer]/Config).

Рис. 6. Редактирование XML через Классификатор помещений

Дополнительные (пользовательские) атрибуты (рис. 7) настраиваются в файле AttributeDefs.xml. С их помощью можно решать различные задачи (вносить дополнительную информацию о владельцах или, например, ключи для связи с БД). Одновременно можно задействовать появившийся в третьей версии механизм пользовательских профилей (рис. 8), позволяющих создавать индивидуальные настройки и, самое главное, ограничивать права доступа. Например, есть атрибуты проверки, которые, если программа работает с профилями, может устанавливать только пользователь с правами бригадира, но не техника-инвентаризатора. Стандартная настройка (файл Profiles.xml) уже содержит три настроенных профиля: Администратор, Бригадир, Исполнитель. Подробности о настройке профилей можно узнать в Руководстве администратора, которое поставляется вместе с программой.

Рис. 7. Дополнительные (пользовательские) атрибуты

Рис. 8. Профили пользователей

То, что настройки программы также хранятся в XML, позволяет автоматически настраивать PlanTracer средствами других программ. Например, база данных организации может в автоматическом режиме создавать для PlanTracer файлы настроек на основе хранящихся в ней данных — и PlanTracer сразу начнет работать с учетом местной специфики. Если такой процесс будет налажен, то перенастройка тоже произойдет быстро: например, внести изменения, касающиеся нового вида площади, будет достаточно только в БД, а в PlanTracer эта информация попадет автоматически.

Составные приложения: «технология скотча»

Выше мы говорили о возможностях взаимодействия PlanTracer и баз данных, но этот принцип может применяться и шире. Представьте, что будет, если вдруг поменяется применявшаяся много лет программа (допустим, регистрирующая заказы, поступающие в БТИ от граждан), с которой была налажена связь других программ? Ясно, что цепочка передачи информации от одной программы к другой будет нарушена. Пропадет зря много труда программистов, придется заново переписывать приложения, которым необходимо работать вместе.

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

Зачем нужны составные приложения? Не слишком ли это сложно?

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

У составного приложения есть общий язык обмена информацией, что позволяет собирать такие приложения из кусочков, как в конструкторе. Имеющиеся в организации программы, если они справляются со своими задачами, можно не менять (зачем выбрасывать то, что хорошо работает?). Недостающие «детали» — добавить. Если требования изменились, цепочка приложений собирается по-другому. Изменение одной части не затрагивает других.

Таким образом, мы получаем:

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

Применительно к БТИ речь идет о нескольких программах (система приема заказов, общая база данных, программа для создания графических планов, подсистема печати документов и т.д.), которые могут, оставаясь независимыми друг от друга, совместно использовать данные через обмен в XML. Выше мы рассказали, как отдельные звенья общего составного приложения, написанные в разное время и на разных языках, способны работать в разных операционных системах. Например, в составном приложении могут участвовать система приема заказов на 1С, база данных на Delphi+Interbase и PlanTracer.

Ведь нас интересует результат, а как, с применением каких программ он был достигнут — дело десятое. Главное, чтобы информация была собрана, обработана и сохранена для будущего использования.

Практический пример: АС «Архив-БТИ» (НПО «Криста»)

АС «Архив-БТИ» традиционно использует XML (сама эта система написана на базе XML). В 2006 году в ней была реализована комплексная поддержка PlanTracer как редактора графических планов: многие рутинные операции (создание, загрузка и сохранение файлов в БД) теперь происходят автоматически и незаметно для пользователя. Передача информации с плана PlanTracer в экспликацию объекта недвижимости осуществляется через XML. При загрузке данных с плана в БД запускается специальный мастер, который позволяет выборочно синхронизировать информацию плана и базы данных.

Рис. 9. Мастер импорта данных в АС «Архив-БТИ»

Итоги

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

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

Успехов в работе!

Скачать статью в формате PDF — 309.2 Кбайт