В такой туманной ситуации немудрено, что существуют проблемы как с формулированием требований, предъявляемых теми или иными кадастрами к программному обеспечению, так и с нахождением правильного их решения. Постараемся, без подробного рассмотрения специфики конкретных кадастров, обозначить их некоторые общие черты, существенные с точки зрения требований к программному обеспечению. Далее постараемся дать краткий обзор соответствия существующего сегодня программного обеспечения этим требованиям. При этом мы не будем, по возможности, останавливаться на конкретных пакетах и производителях программного обеспечения. И уж, тем более, не будем подробно описывать какой-либо пакет В последнем вообще нет необходимости в свете данной задачи выбора ПО, ибо достаточно убедиться в отсутствии какой-то даже одной базовой, жизненно необходимой функции, чтобы не рассматривать далее этот пакет в качестве возможного кандидата на использование в кадастре (во всяком случае в качестве базового программного обеспечения). Таким образом, мы можем заметно оптимизировать процедуру выбора из огромного спектра ПО. Достаточно выбрать в качестве ключевого то требование к пакету которое, являясь абсолютно необходимым, сразу же позволит отсечь наибольшее число кандидатов.
Какие это могут быть требования? Базовыми для кадастров любого типа являются функции учетные, инвентаризационные. Соответственно, критически важным является качество представления в компьютере графических данных, прежде всего, границ объектов. Качество в данном случае не исчерпывается только полнотой (отсутствием пропусков объектов) и малыми допусками на точность представления положения каждой линии по сравнению с натурой. Качество цифровой графической базы в данном случае - это еще и ее корректность, внутренняя непротиворечивость. Это внутренняя непротиворечивость внутри одного тематического слоя - соответствие формального геометрического типа каждого объекта его смысловому содержанию (я говорю о такой, например, вещи, как замкнутость всех площадных объектов. Все, что по смыслу своему является площадным объектом, должно быть представлено замкнутым полигоном, замкнутым не только визуально, но и в формальном геометрическом смысле). Все границы прилегающих полигонов должны быть в точности одной и той же линией, а не просто визуально неотличимыми двумя близкими линиями. В земельном кадастре абсолютно вся территория, без пропусков, должна принадлежать какому-либо площадному объекту - полигону, пусть даже полигону с атрибутом "нет сведений". Не должно быть никаких, даже микроскопических паразитных полигонов, происходящих из неточных соответствий контуров. Да и между различными слоями информация должны быть согласована.
Все эти требования делают необходимым использование топологического контроля в процессе создания кадастровых карт. Я берусь со всей ответственностью заявить, что никакие квалификация и усердие операторов ввода, будь то дигитайзерные технологии, сканерные технологии с ручной прорисовкой или с использованием программ-векторизаторов, не дают необходимого качества карт без использования топологического контроля. Правда, сегодня даже некоторые наиболее продвинутые отечественные пакеты по векторизации, типа Easy Trace и MapEdit, включают в себя некоторые средства такого контроля. Это очень хорошо, но окончательное редактирование карт должно производиться все-таки в самой ГИС. То есть, делаем вывод - ГИС пакет или система пакетов, используемых в кадастре, должны поддерживать векторно-топологическую модель данных по крайней мере на каких-то этапах работы и на определенном уровне рабочих мест,
Пожалуй, еще более существенно наличие топологического контроля на этапе функционирования кадастровой системы. Многочисленные редактирования, особенно проводимые как отдельные разрозненные акты редактирования, в разное время и разными исполнителями, неизбежно быстро нарушат целостность базы данных без наличия того же топологического контроля. Это касается и целостности системы связей "графические объекты-атрибуты", и корректности взаимоотношений между графическими объектами. Часто, говоря о требованиях кадастровой системы к программному обеспечению, забывают, что кадастр не создается один раз навсегда как система, фиксирующая существующие отношения собственности на, например, земельные угодья. Кадастр должен жить активной жизнью, и быть способным отслеживать оперативно и без нарушения работоспособности все происходящие изменения.
В частности, должна обеспечиваться упомянутая целостность базы данных при ее редактировании, и должна поддерживаться возможность отслеживания истории изменений базы данных. Юристы легко подтвердят важность возможности отслеживания такой истории владения объектами собственности - земельными участками, объектами недвижимости - для урегулирования спорных ситуаций. Надо понимать, что для этого необходимы специальные средства, отслеживающие каждое изменение базы данных и ведущие журнал таких изменений, а не просто хранение копий состояний базы данных в отдельные дискретные моменты времени (это, например, обеспечивает модуль ArcStorm системы ARC/INFO). А отслеживать изменения пространственной БД гораздо сложнее, чем непространственной - земельные участки не только меняют владельца и характер использования, они еще по ходу их истории делятся, объединяются, меняют форму и соседей, В такой ситуации отслеживание истории землепользования (например)также требует использования векторно-топологической модели данных.
Аналитические функции кадастра, без которых он по сути представляет собой бюрократическую систему регистрации и только, также требуют для реализации всего спектра необходимых операций работы с векторно-топологическим форматом.
Кадастр на значительные территории, естественно, приходится создавать порциями - по отдельным листам карт, отдельным стереопарам снимков, отдельным административным единицам. Естественно, при этом потребуется увязка и согласование по границам карт. Если мы хотим получить, хотя бы некоторую автоматизацию и контроль качества в этом процессе - единственный выход - использование тех же топологических структур данных.
Опять та же пресловутая топология! Не слишком ли много о ней разговоров. Многие говорят, что это хорошо, но вот все системы, поддерживающие векторно-топологический формат, дороги, сами структуры данных чрезвычайно сложны и, за счет этого, не обеспечивают того быстродействия, как более простые! Ответ на это должен быть простой - ни один пакет ГИС, взятый в единственном числе, не обеспечит сегодня эффективного решения задачи построения и, тем более, эксплуатации кадастра. Требуется находить некоторую комбинацию из нескольких тесно взаимоувязанных пакетов разного уровня сложности и разной стоимости, разделяющих одну и ту же идеологию, модели, форматы данных. Это, помимо прочего, позволит также радикально разрешить и проблему выбора аппаратной платформы. Ясно, что на некотором уровне кадастра совершенно необходимо сегодня - или будет необходимо завтра (не надо обольщаться!) - использование компьютеров более мощных, чем привычные офисные персоналки (будут ли это мощные сервера и рабочие станции на базе lntelовского процессора с Windows NT или RISC/UNIX рабочие станции и сервера, это не так принципиально). И так же ясно, что уровень массового пользователя не может и не должен быть обеспечен ими, а только гораздо более дешевыми ПК не самого верхнего уровня. Я не случайно употребил во множественном числе "модели данных", а не "модель данных", потому что сегодня есть примеры комплексирования в одной системе связных пакетов нескольких моделей данных, в частности, векторно-топологической и векторной нетопологической (наглядный пример - покрытия ARC/INFO и шейп-файлы), а также и растровой моделей данных.
Следует также отдавать себе отчет, что никакая комбинация из сегодняшних ГИС (имея в виду именно ГИС-пакеты) не в состоянии обеспечить работу кадастра на федеральном и даже большом региональном уровне при высокой интенсивности пространственных запросов большого числа удаленных, то есть работающих по каналам связи, пользователей. А такая перспектива для нас является если и не ближайшей, то очень близкой. Sдecь необходимо использование принципиально нового и в мире, а в России почти совсем неизвестного, класса программных продуктов - серверов пространственных баз данных. Эти системы обычно опираются как на подстилающий уровень на мощные реляционные СУБД класса Oracle или Informix, но представляют собой совершенно отдельный, новый тип систем. (О сервере пространственных данных SDE мы уже кратко рассказывали в предыдущих номерах ARCREVIEW, а в этом номере ему посвящен целый разворот).
Наконец, о самом, на мой взгляд, важном -о квинтэссенции всего этого, о комплексном территориальном кадастре. Совершенно ясно, что создавая любые, пусть самые совершенные, системы частных кадастров, мы сможем решить только узковедомственные проблемы. В реальности, все они должны взаимодействовать друг с другом. Как на федеральном уровне, помогая решать большие аналитические и прогнозные задачи, так и, в особенности, на местном уровне, решая конкретные повседневные задачи управления. Как может земельный кадастр не взаимодействовать с кадастром минерально-сырьевых ресурсов, когда требуется на их стыке решать проблему выделения горных отводов? Как может градостроительный кадастр или кадастр объектов недвижимости не взаимодействовать с земельным? Или с кадастром водных ресурсов? Число таких