В 2009 г. в России официально стартовал пилотный проект создания ГИС федеральных автомобильных дорог (заказчик Рос-автодор). Зонами проведения эксперимента выбраны дороги М1 (Москва — Минск) и М53 (участки Новосибирск — Юрга — Кемерово и Юрга — Томск).
Основной целью проекта является демонстрация возможности создания полноценной ГИС автомобильных дорог на основе принципов формирования инфраструктур пространственных данных, используемых в дорожном хозяйстве за рубежом (в первую очередь в Европе). В проекте планируются создание предварительных спецификаций на модели данных, совместимых со стандартами Директивы INSPIRE и EuroRoadS, разработка прикладного программного обеспечения и наполнение его данными в пределах пилотных зон.
В нашей стране ГИС автомобильных дорог имеются только в некоторых территориальных органах управления автомобильными дорогами на уровне субъектов Федерации. Стандартов, по сути, не существует, так как отсутствует какая-либо внятная политика в отношении применения информационных технологий (ГИС, САПР, БД, ГНСС) в отрасли.
За рубежом ситуация отличается от отечественной в лучшую сторону: работы по интеграции разрозненных программных систем в сфере дорожного хозяйства ведутся с начала 2000-х годов. Среди лидеров — Швеция, Норвегия, Финляндия, Германия, Франция, Великобритания, США. В этих странах созданы единые централизованные базы дорожных данных и множество интегрированных прикладных систем. Однако и там интеграция охватывает пока не более половины используемых на практике классов систем. Россия же стоит только в начале этого пути.
Приступая к стандартизации дорожных данных, страны Евросоюза договорились делать это согласованно, что привело к старту в 2004 г. проекта EuroRoadS в рамках Директивы INSPIRE.
EuroRoadS. Основная цель проекта — создание к 2012 г. совместимых между собой и с INSPIRE национальных баз данных стран — членов EU25 (теоретически до 40 стран). Подчеркивается, что задача заключается не в создании единой европейской базы данных, а в создании правил взаимодействия национальных баз (рис. 1).
Рис. 1. Потоки данных в EuroRoadS
Основными заявленными областями применения EuroRoadS являются:
— многоуровневое управление эксплуатацией автомобильных дорог;
— проектирование дорог (стадии технико-экономического обоснования и обоснования инвестиций);
— проектирование комплексных транспортных схем городов и регионов;
— управление транспортными потоками;
— автомобильная навигация;
— логистика;
— построение общей картографической основы Европы.
Проект разбит на девять частично перекрывающихся фаз:
— WP 1: Управление проектом (стартовал в 2004 г.);
— WP 2: Оценка и контроль качества;
— WP 3: Информирование заинтересованных лиц;
— WP 4: Схемы использования;
— WP 5: Сбор требований;
— WP 6: Спецификация дорожных данных (завершен в октябре 2006 г.);
— WP 7: Демонстрация (2007 г.);
— WP 8: Реализация (2007–2012 гг.);
— WP 9: Эксплуатация (с 2012 г.).
В 2004–2006 гг. выполнены первые шесть фаз проекта, по итогам которых опубликованы финальный отчет; документы по оценке качества информации; описание предварительных изысканий и направлений работы; финальные спецификации информационной модели сети дорог, ядра европейских дорожных данных, модели обмена дорожными данными, формата обмена дорожными данными; каталоги метаданных и терминов; планы реализации и эксплуатации.
В 2007 г. работоспособность подхода продемонстрирована на тестовых полигонах в Швеции, Германии и на границе Норвегии и Швеции.
В настоящее время страны Евросоюза реализуют собственные профили EuroRoadS.
Среди основных элементов спецификации EuroRoadS можно перечислить:
— модель сети дорог (концепция, модель качества, системы координат);
— спецификация (типы объектов и атрибутов, значения атрибутов и уровни качества);
— правила генерализации;
— геодезические системы координат;
— модель и формат обмена данными;
— каталог метаданных;
— правила соответствия дуг;
— каталог терминов.
Основными объектами сети EuroRoadS являются (рис. 2):
— ER_RoadNode — узлы;
— ER_RoadLink — дуги, опирающиеся концами на узлы, вне-дорожные связи (паромы, переправы, вокзалы) или внутренность других дуг. Опирание происходит со смещением от начала дуги (пикетаж) или от некоторого маркера (аналог «рубленого» пикетажа);
— ER_FerryLink — концевые внедорожные связи (паромы, переправы, вокзалы);
— ER_Route — маршрут (последовательность дуг).
Рис. 2. Геометрическая модель данных EuroRoadS
Возможность описания пересечения дорог в виде опирания второстепенных дорог на основные позволяет использовать привычные линейные системы координат, в том числе «рубленые» пикетажные. Кроме того, такой подход отчасти решает задачу генерализации.
Каждому объекту дорожной сети должны быть сопоставлены такие обязательные атрибуты, как геометрия, универсальный идентификатор ID, тип узла, тип маршрута, тип внедорожной связи, функциональный класс дороги. Все остальные атрибуты дорог являются дополнительными и не хранятся в основной таблице. Для каждого атрибута в базе данных заводится своя таблица, содержащая идентификаторы основного объекта и значения атрибута. Таким способом достигается масштабируемость базы данных для разных задач. Дополнительными атрибутами базовой спецификации являются:
— адрес (узла или дуги);
— режим доступа (ограничение въезда);
— информация о граничных узлах;
— направление движения;
— маневр (используется для ограничения/разрешения выполнения сложных поворотов через два или более узла сети);
— многоуровневое пересечение;
— горный перевал;
— число полос;
— информация о пересечении;
— идентификация объектов;
— ограничения проезда;
— ограничения проезда для типов машин;
— длина дороги;
— имя дороги или улицы;
— номер дороги;
— ширина дороги;
— тип дорожного покрытия;
— сезонные ограничения;
— пункты сервисного обслуживания;
— ограничения скорости;
— структура;
— уклон дороги.
Каждая прикладная система должна вводить собственные атрибуты.
Рассмотренная спецификация EuroRoadS имеет сугубо ведомственное происхождение и только начинает поддерживаться производителями программного обеспечения. Помимо нее существуют несколько действующих де-факто стандартов представления информации о дорогах, в первую очередь для навигационных задач.
OpenStreetMap (OSM). Это открытый общемировой проект по созданию онлайн-карт для навигационных целей. С точки зрения моделирования пространственных объектов вообще и дорожных сетей в частности, OSM является топологическим и расширяемым. В качестве основного языка описания используется XML.
Базовым элементом описания пространственных объектов служит точка (node), которая имеет географические координаты и высоту над эллипсоидом WGS–84. В действительности все объекты карты представлены самостоятельно с подробным описанием и ссылаются на точки, образующие их контур. Таким образом, возникает возможность создавать полноценные топологически связанные объекты карты — как сети, так и покрытия. Стандарт позволяет описывать точечные объекты (ссылаются на один узел), полилинии и полигоны (ссылаются на несколько узлов).
Помимо объектов карты, состоящих из узлов, OSM предоставляет возможность создавать более сложные построения — «отношения», которые ссылаются на объекты карты и узлы. Наиболее ярким примером является отношение «запрет поворота», которое ссылается на два участка дороги и общий для них узел.
В качестве моделируемых объектов OSM предоставляет более 300 примитивов, из них около 80 относятся к транспортной и пешеходной инфраструктурам.
Keyhole Model Language (KML). Этот язык для описания пространственных объектов основан, как и OSM, на платформе XML, но в отличие от OSM не позволяет моделировать топологические отношения между объектами (рис. 3). Основной упор сделан на способы визуального представления объектов карты (точки, полилинии, полигоны и пр.). KML приобрел широкую известность благодаря чрезвычайной популярности проектов Google Maps и Google Earth, которые используют его в качестве основного языка описания пользовательских меток, объектов и т. п.
Рис. 3. Геометрическая модель данных KML
Языки, аналогичные KML, используются во многих сетевых картографических сервисах.
RusRoadS. Российский пилотный проект создания ГИС федеральных автомобильных дорог, стартовавший в 2009 г., получил рабочее название RusRoadS по аналогии с EuroRoadS, что должно подчеркивать его совместимость по моделям данных.
Помимо прямой цели создания ГИС федеральных дорог (47 тыс. км), неявно предполагается создание ГИС всех дорог страны (1145 тыс. км). Это связано с обязанностью Росавтодора вести реестр всех автомобильных дорог.
Намечен следующий график разработки RusRoadS:
— 2009 г. — предпроектное обследование, сбор требований, предварительные спецификации данных, регламенты сбора и хранения информации;
— 2010 г. — демонстрация в пилотных зонах (М1 и М53), первые финальные спецификации;
— 2011 г. — опытное внедрение в федеральных органах управления дорожным хозяйством (ОУДХ);
— с 2012 г. — промышленная эксплуатация в федеральных ОУДХ.
В качестве основы для разработки взята модель данных EuroRoadS. Среди ключевых требований к универсальной модели данных ГИС автомобильных дорог выделены:
— топологическое представление полос дороги (противоречие между моделью осей дорог и полосовым представлением в EuroRoadS не решено);
— метрические требования (двойные системы координат — геоцентрические и пикетажные; частично это решено в EuroRoadS);
— темпоральность (для одних задач требуется модель темпоральности, основанная на версиях (как в ArcGIS), для других — только диапазон жизни объекта (как в EuroRoadS));
— масштабируемость по задачам (как в EuroRoadS — атрибуты представляются отдельными сущностями) и регионам (согласованность данных на границах смежных территорий);
— генерализация в явном виде (широкий спектр решаемых задач требует разной степени детальности сети дорог: объекты большей степени детализации должны хранить ссылки на генерализованный объект);
— согласованность с иными видами транспорта и смежными отраслями (отработано в моделях данных HDM-41 ).
Рис. 4. Блоки модели RusRoadS
Основные технические спецификации моделей данных должны быть представлены в 2009–2010 гг. Они будут базироваться на следующих моделях данных:
1. EuroRoadS в качестве каркаса транспортной сети.
2. Модель данных информационной системы автомобильных дорог IndorInfo/Road («ИндорСофт», Томск) в качестве паспорта автомобильной дороги.
3. Расширенная модель данных информационной системы искусственных сооружений в качестве паспортов труб и мостов.
4. Модель данных системы проектирования мостов IndorBridge («ИндорСофт», Томск) в качестве конструктивной модели данных мостов.
5. Модель данных IndorTraffic («ИндорСофт», Томск) для макро- и VISSIM (PTVAG, Германия) для микромоделирования транспортных потоков.
6. Модель автомобильной дороги САПР IndorCAD («ИндорСофт», Томск) в качестве трехмерной проектной модели.
7. Чертежные модели IndorDraw («ИндорСофт», Томск) и Autodesk DWG (Autodesk, Inc.) для представления «замороженных» проектных решений.
8. Элементы модели HDM-4 для оценки эффективности инвестиций.
В предварительном варианте модель данных RusRoadS будет состоять из трех основных блоков (рис. 4):
— модель версий — набор базовых классов, предназначенных для темпорального представления данных, основанного на механизме версионирования;
— пространственно-топологическая модель — набор классов для представления пространственных объектов (в том числе объектов дорожной сети) с механизмами генерализации (см. пример на рис. 5);
— паспорт дороги — набор классов, расширяющих представление пространственно-топологической модели и включающих основные неизменные (либо редко меняющиеся) параметры дорожных объектов, искусственных сооружений и инженерного обустройства. Классы этого блока, в частности, реализуют интерфейсы стандарта EuroRoadS, при этом их собственные возможности гораздо шире.
Рис. 5. Уровни детализации модели данных RusRoadS
Все дополнительные модели данных, используемые в прикладных задачах дорожной отрасли (изыскания и проектирование, диагностика, управление эксплуатацией, документооборот), оформляются в виде отдельных блоков классов, наследуемых от данных базовых блоков и использующих стандартные классы RusRoadS для доступа к дорожным данным. Такая конструкция полностью соответствует концепции построения инфраструктуры дорожных данных.
RSS
Реклама
