Построение модели данных для автоматизированной системы проектирования городских
транспортных сетей

С.Ю. Балынин

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

Существуют различные подходы к членению территории города на транспортные районы и построению геометрии транспортной сети на основе существующей улично-дорожной сети (УДС) [1]. Различия в подходе к разработке транспортных систем бурно развивающихся городов и городов со стабильным развитием определили существование вероятностных (синтетических) и экстраполяционных (аналоговых) методов расчёта межрайонных корреспонденций. Распределение пассажиров или транспорта на сети также возможно различными методами. Следовательно, можно говорить об этапности проектирования с применением на каждом этапе различных методов.

Данные, необходимые для проектирования транспортной системы, в большинстве либо получаются из проектных и эксплуатационных организаций, либо собираются различными подразделениями транспортных предприятий, что предопределяет большой объём работ по сбору и обработке требующейся для проектирования информации, а также разнообразие программных инструментов для выполнения расчётов на взаимодействующих друг с другом ЭВМ. Известно, что при передаче данных и возникает большинство проблем, связанных с различными форматами и формами их представления. Зачастую несогласованность систем двух различных отделов (или организаций) приводит к значительным затратам времени и сил на решение казалось бы элементарной задачи – использования уже имеющейся информации в дальнейшей работе. Так, например, желание дополнить электронную карту г.Нижнего Новгорода инструментом, позволяющим автоматически определять оптимальный вариант движения с использованием массового пассажирского транспорта [2], оказалось трудно выполнимым. В существующей системе маршруты представлялись как линии, с обязательным условием принадлежности к УДС города, в то время как для работы алгоритма необходимо представление маршрутов как совокупности участков УДС, по которым данный маршрут проходит. В существующей системе никоим образом не учитывалась связь маршрутов друг с другом (прохождение по одним и тем же остановочным пунктам), а работа алгоритма именно на этом и основывается. Таким образом, остаётся либо вовсе отказаться от данной работы, либо заново создавать транспортный раздел электронной карты.

Существует множество вариантов решения подобных проблем, начиная с полного отказа от использования данных, полученных в электронном виде и введения их вручную заново, до разработки специальных программ – конверторов, которые автоматически «выдирают» требующиеся данные и представляют их в приемлемом виде. Однако разработка конверторов – не самое оптимальное решение, разработчики неохотно раскрывают «тайны» своих программ, что ведёт к большой вероятности появления ошибок при конвертации, и однозначно к потере информации.

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

Эффективным решением данной проблемы может являться только разработка соответствующего стандарта. В конечном счёте, существуют нормативы, регламентирующие оформление графической документации, содержание пояснительной записки, перечень обязательно представляемых материалов, расчётов, документов и т.п. [6]. Очередь за правилами представления этой информации в электронном виде. И тогда если какое либо программное приложение для своей работы берёт данные из стандартных (для решения транспортных проблем) баз данных и результаты представляет в таком же стандартном виде, то любое другое программное приложение, придерживающееся подобных стандартов, без проблем сможет взаимодействовать с ним. Нечто подобное мы можем наблюдать, например, в области машинной графики, кстати, пользующейся большим вниманием крупных разработчиков программного обеспечения. Так графический формат DXF “de facto” является стандартом, его поддерживает большинство не только графических программ – AutoCAD, MicroStation, KOMPAS, но и специализированных, использующих в своей работе графику: геоинформационные системы – ArcView, MapInfo, системы автоматизированного проектирования CREDO, GIP и т. д.

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

Анализ методик проектирования транспортных систем позволяет считать, что наиболее простым, гибким и эффективным решением представления информации является совокупность массива реляционных [4,5] и сетевых баз данных (в данном контексте сетевая, графовая – содержащая сведения о взаимосвязях). Массив реляционных баз данных включает в себя таблицы, содержащие графические данные (то есть графические примитивы - элементарные графические элементы, такие как точка, линия и т.д.), и связанные с ними через идентификационные ключи, данные о свойствах реальных объектов (характеристики), отображаемых этими примитивами. Также таблицы эмпирических коэффициентов и постоянных (справочники), таблицы промежуточных расчётных данных по этапам и представленные в табличном виде результаты расчёта транспортных систем. Сетевые (графовые) базы данных, должны содержать информацию о взаимосвязях и взаимном расположении различных элементов города, например, данные об УДС или взаимной связи транспортных районов города.

Графические данные предлагается делить на расчётные и вспомогательные (нужные для оформления чертежа – рамки, штампы, указание севера, роза ветров и т.д.). Расчётные графические данные моделируют город, описывая геометрию и топологию УДС, геометрию жилых, общественно-деловых и производственных зон, зон инженерной и транспортной инфраструктур [3], а также положение точечных пунктов тяготения, прохождение существующих маршрутов ГМПТ и маршрутов пригородного транспорта. К расчётным также относятся данные, отображающие проектное решение транспортной системы целиком, или какого либо этапа проектирования. Следовательно, расчётные графические примитивы в свою очередь делятся на «исходные» (описывающие УДС, жилую, общественно-деловую, производственную зоны и т.д.), «вспомогательные» (транспортное районирование, вариант транспортной сети и т.д.) и «результирующие» (километрограммы, изохронограммы, диаграммы пассажиро- и грузо- потоков). Принадлежность к той или иной группе определяет допустимость операций над расчётными примитивами. «Исходные» примитивы возможно удалять, добавлять, редактировать. «Вспомогательные» зависят от «исходных», изменение которых влечёт за собой изменение (перерасчёт) вспомогательных примитивов. Но они тоже могут добавляться, удаляться, редактироваться, например, когда решено изменить транспортное районирование, или транспортную сеть. «Результирующие» примитивы пересчитываются в зависимости от «исходных» и «вспомогательных», но не подлежат изменению проектировщиком. Существует также разделение внутри этих групп, в зависимости от объекта реального мира в соответствии с которым определён конкретный расчётный графический примитив (т.е. примитив моделирующий объект реального мира – участок УДС, микрорайон, пром. зону и т.д.). Так участок УДС характеризуется названием улицы, пикетным положением, категорией, количеством полос движения, протяжённостью участка, допустимой скоростью и интенсивностью движения, принадлежностью участка к транспортной сети города и т.д., а промышленное предприятие - названием, количеством работающих и количеством смен на предприятии. Принадлежность к тому или иному типу определяет операции по отношению к данному примитиву. Таким образом жилые зоны, промпредприятия и т.д. определяют пассажиро- и грузо- потоки, а участки УДС и ТС определяют траекторию движения этих потоков.

Реляционные базы данных. Данные о характеристиках реальных объектов, которые моделируются графическими примитивами, распределены по таблицам, в каждой из которых представляется какая либо сущность (любой различимый объект, который мы можем отличить от другого [4]). Связь между сущностями определяется по индексам. Основой всех сущностей являются расчётные графические примитивы. Проектирование базы данных производится по правилам теории нормализации, то есть разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации [4]. Это делается не столько с целью экономии памяти при реализации на ЭВМ, сколько для исключения возможной противоречивости хранимых данных. Согласно теории нормализации баз данных, связь между сущностями представленных отдельными таблицами должна определяться единым образом. Описанная таким образом модель данных может быть реализована с использованием современных систем управления базами данных. Более того, использование реляционных баз данных позволяет практически неограниченно добавлять в существующую модель данных всё новые и новые характеристики объектов, таким образом, развивая модель данных, позволяя решать новые задачи.

Сетевые (графовые) базы данных. Операции над расчётными графическими примитивами, отображающими УДС или транспортную систему, требуют представления данных в виде единого графа (операции выбора кратчайшего расстояния, пропускной способности и т.д.). Мы моделируем УДС как граф G(X, A), рёбра Aij которого представляют участки УДС, а пересечения, ответвления и слияния – вершины Xi. Следовательно, в разрабатываемом стандарте имеет смысл определить некую стандартную форму представления матрицы смежности - как запись графа УДС. Однако граф, моделирующий сеть автодорог, УДС или транспортную сеть, характеризуется большим количеством узлов и минимальным количеством соединяющих их дуг (рёбер). Это значит, что для работы с УДС содержащей 1000 узлов необходимо выделить память под массив 1000х1000, то есть в 1000000 ячеек. Данная матрица будет заполнена в основном нулями, так как каждый участок УДС соединён в узлах не более чем с 8-10 соседними участками. Поэтому для хранения и работы с матрицей смежности предлагается следующее её представление: первая таблица содержит данные о порядковом номере узла, порядковом номере записи, содержащей данные о первой дуге, входящей в узел, и данные о количестве дуг, входящих в узел; во второй таблице содержатся пронумерованные данные о дугах. Связь между первой и второй таблицей осуществляется через идентификационные номера. Для хранения матрицы смежности в таком виде необходимы две таблицы, для графа в 1000 узлов потребуется массив 1000 * 3 + 1 000 * 4 (6) * 3, т.е. всего в 15 000 ячеек.

Однако одной сетевой базы данных с информацией о УДС недостаточно для решения всех задач проектирования городских транспортных систем. Этапность проектирования определяет последовательную трансформацию требуемых для расчёта данных и форму их представления. Существуют определённые правила трансформации сетевой базы данных УДС в сетевую базу данных транспортной сети, например, для поиска кратчайшего пути, при проектировании маршрутной системы (МС), а затем в сетевую базу данных маршрутной системы, например, для реализации алгоритма, описанного в [2], при построении изохронограмм и т.д. Возможны случаи, когда в форме графа необходимо предоставлять данные о взаимосвязи транспортных районов города, жилых районов и промышленных зон и т.д., например, при работе с картограммой межрайонных корреспонденций, корреспонденциями между зонами города, и т.д.

Выводы. Эффективное решение проблемы передачи данных между различными системами проектирования, контроля и хранения информации по городскому транспорту невозможно без создания определенного стандарта представления данных. В силу специфичности рассматриваемой отрасли – одновременно и графическая информация, и множество табличных данных, а также из-за наличия множества методов, решающих одни и те же задачи, создание модели данных представляется сложной и ответственной задачей, целесообразным решением которой, может быть:
- определение всех сущностей рассматриваемых в процессе проектирования и перечня присущих им значимых характеристик;
- разделение процесса проектирования на элементарные этапы, для выделения конкретного и законченного перечня исходных и результирующих данных по каждому этапу;
- определение оптимальной формы представления данных о взаимосвязях – графовых баз данных на каждом этапе, как это предлагается для графа УДС (транспортной сети);
- обеспечение определённой единым образом взаимосвязи между графическими, табличными и графовыми формами представления данных, так как только совместно эти формы представления информации наиболее полно и эффективно моделируют транспортную систему города.

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

Литература

1. Балынин С.Ю. Построение геометрии транспортной сети на основе существующей улично-дорожной сети города // Сборник трудов аспирантов и магистрантов / Технические науки. –Н. Новгород: Нижегород. гос. архит.-строит. ун-т, 2002, с.150-153
2. Балынин С.Ю. Методика выбора оптимального варианта траектории поездки на маршрутизированном городском транспорте // Вестник ГЭТ России, 2002, №5, с.10-14
3. Градостроительный кодекс Российской Федерации.
4. Кириллов В.В. Основы проектирования реляционных баз данных. (www.citmgu.ru)
5. Кузнецов С.Д. Основы современных баз данных. (www.citmgu.ru)
6. Овечников Е.В. Фишельсон М.С. Городской транспорт.-М.: Высшая школа, 1976. 352с.


© S.Waksman 2002