Особенности функционирования интерактивных web-ориентированных картографических систем

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Введение

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

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

В первой главе подробно рассмотрена существующая проблематика на рынке потребительских интерактивных web-ориентированных геоинформационных систем. Показана актуальность проблемы актуализации и полноты справочника организаций. Формулируется гипотеза о возможности создания META-справочника, консолидирующего данные об организациях сразу нескольких ГИС. Предлагается один из способов апробации гипотезы.

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

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

Цель данной работы - консолидация данных крупнейших источников информации о местах общественного питания города Москвы в целях обеспечения максимальной полноты и актуальности получаемой пользователем информации в процессе подбора соответствующих заведений.

Для достижения данной цели поставлены следующие задачи:

Исследовать рынок навигационных веб-приложений:

· ознакомиться с наиболее популярными навигационными веб-приложениями,

· оценить их преимущества и недостатки,

· оценить потребности людей, понять основную проблематику, понижающую эффективность пользования подобными системами,

· Тщательно изучить предметную область:

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

· оценить сложность и трудоемкость реализации поставленной задачи,

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

· Разработать веб-приложение, консолидирующее данные об организациях общественного питания г. Москва:

· спроектировать прототип будущего веб-приложения, основываясь на выявленных решениях,

· разработать функциональную составляющую,

· выгрузить данные из отобранных источников,

· разработать алгоритм сведения данных,

· разработать алгоритм визуализации полученного справочника организаций.

1. Предметная область и анализ существующих решений

1.1 Предметная область

Одним из основных способов решения навигационных задач для современных web-ориентированных картографических сервисов является совмещение (наложение) картографических данных рассматриваемой местности с информацией о субъектах экономической деятельности. Такого рода наложение позволяет создать в глазах пользователя неразрывную пространственно-информационную модель окружающего мира, формирующую новую практику ориентирования в городской среде. Подобная практика ориентирования включает изменение предпосылок, влияющих на принятие решения о выборе того или иного заведения в качестве пункта назначения. Так с ростом количества возможных альтернатив растет значимость фактора стоимости перемещения (расстояния, времени и затраченных средств) и уменьшается влияние факторов различия между самими заведениями. Неразрывно с возрастающей сложностью и стоимостью перемещения (связанную в первую очередь с ростом населения мегаполисов и заметно отстающим от него развитием транспортной инфраструктуры) растёт и цена навигационных ошибок. Таким образом, актуальность, полнота и корректность предоставляемой информации становится важнейшим критерием эффективности использования пользовательских картографических сервисов (Google Maps, Яндекс.Карты, 2GIS и т.д.).

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

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

Динамика появления/закрытия новых организаций, их филиалов и представительств, равно как и изменение существенной информации о них (область деятельности, режим работы, контактная информация и т.п.) на порядки выше скорости изменения городского ландшафта. Прямые и косвенные подтверждение этому можно найти в отчетах органов государственной регистрации и учета организаций (ФНС), из которых следует, что за один рабочий день в 2017 году в Москве в среднем появляется 379 организаций, а прекращает свою деятельность 371. Еще большие темпы изменений динамики демонстрируют данные провайдеров телефонной связи по выделению организациям телефонных номеров и данные “Координационного центра национального домена” по регистрации и использованию доменных имён в сети Интернет.

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

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

Таким подходом стал VGI (Volunteered geographic information), которую (ввиду отсутствия аналогов в русском языке) близко к смыслу можно перевести как “географические данные, собираемые волонтёрами”. По существу данный подход является подмножеством UGC (User-generated content) подхода, при котором информационное содержимое ресурса в значительной мере наполняется пользователями ресурса. Сильной стороной данных подходов является существенное снижение затрат в процессе сбора и актуализации справочника организаций, слабой -- отсутствие контроля над уровнем актуальности справочника и достоверности, предоставляемой пользователями информации.

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

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

1.2 Анализ существующих решений и проблематика

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

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

На основных рынках присутствия (США, ЕС) компания Google практикует методичное повышение квалификации волонтеров, занимающихся актуализацией данных картографического сервиса Google Maps. Достигается это за счет создания вокруг данного сервиса большого пользовательского сообщества с элементами социальной сети и обширной мотивационной программы, повышающей уровень вовлеченности волонтеров в деятельность по обновлению данных, представленных на карте. К сожалению, преимущественно деятельность именно этого VGI-сообщества сосредоточена на внесение правок непосредственно в картографическую составляющую сервиса, практически не затрагивая работу со справочником организаций.

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

1.3 Поиск возможных решений

веб картографический пользовательский

В целом компании, занимающиеся развитием картографических сервисов, прикладывают достаточно усилий для развития инструментария повышения актуальности и корректности представленной информации внутри базы данных сервиса. В целях дальнейшего повышения эффективности данного инструментария картографическим сервисам имеет смысл заимствовать практику сервиса Google Maps по созданию VGI-сообщества и повышению его вовлеченности в процесс редактирования карт, особенно в разрезе, так называемых, локальных географических правок. Такой способ дает жителям районов и домов приоритет при внесении правок в пределах своего места жительства. Это позволяет получать более достоверную и актуальную информацию. Также имеет смысл распространять данный подход на работу со справочником организаций, отображаемых на карте. Такой подход позволит косвенно повысить и уровень полноты представленной в базе информации, так как жители района, как правило, быстрее остальных узнают о появлении новых организаций рядом с их местом проживания. Однако, если не ограничивать себя экономическими интересами одного сервиса, проблему полноты, достоверности и актуальности можно решать совсем на другом уровне.

С учетом того факта, что VGI-сообщество в том или ином виде сформировалось вокруг каждого из популярных сервисов, внесение и актуализация данных представленных в каждом из них происходит параллельно и независимо друг от друга, а это означает, что все существующие сервисы охватывают разный (но безусловно пересекающийся) срез доступной информации о существующих организациях. Даже ручной анализ выдачи популярных картографических сервисов показывает, что уровень пересечения баз данных организаций популярных сервисов варьируется на уровне 70-80%, а это означает, что подавляющий объем работы сообществами проделывается повторно. Объединение сообществ и создание единого справочника естественным образом бы сократило издержки, за счет высвобождения того человеко-ресурса, который сейчас уходит на внесение и корректировку одного пересекающегося объема информации. В свою очередь высвободившийся ресурс смог бы обеспечить более широкое покрытие базы организаций в справочнике. Но такой модельный вариант развития событий негативным образом скажется на конкуренции сервисов, ведь конечной задачей любого подобного сервиса является генерация прибыли для компании-разработчика. В такой модели остается открытым вопрос о системе взаиморасчетов и взаимоотношений между картографическими сервисами, подключенными к единому справочнику организаций и сервисом обеспечивающим функционирование самого справочника.

Более того, текущий (уже накопленный) объем данных по организациям каждый из сервисов справедливо считает своей коммерческой тайной. Учитывая, что Google Maps является абсолютным лидером в глобальном масштабе и проигрывает в полноте и актуальности базы лишь некоторым локальным игрокам (таким как Яндекс.Карты и 2GIS), коммерческой заинтересованности в реализации подобного сценария в обозримом будущим в корпоративной среде ожидать не стоит.

С другой стороны, возможно создание объединенной версии справочника организаций в виде стороннего сервиса, агрегирующего информации из текущих картографических сервисов в единую базу данных с последующей репрезентаций полученного множества организаций. Такой подход похож на популярный ранее подход по улучшению текстовой поисковой выдачи систем посредством создания мета-поисковиков, которые повышали релевантность выдачи за счет агрегации результатов поиска существующих поисковых машин: Google, Яндекс, Рамблер, Bing, Yahoo. В настоящее время мета-поисковики по текстовой выдаче утратили свою актуальность, так как исходные поисковые системы смогли нарастить качество выдачи и охват поискового индекса до такой степени, что дальнейшие улучшения за счет манипуляции результатами их поиска практически не приносят заметных улучшений в плане повышения релевантности.

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

Подробное изучение доступного публичного API коммерческих сервисов Яндекс.Карты, Google Maps и 2ГИС показало, что бесплатная (некоммерческая) версия существенно лимитирована по количеству выдаваемых данных. Как правило, это постраничный доступ с размером страницы от 20 до 50 записей и общим ограничением в несколько десятков или сотен страниц.

Доступ к API для осуществления исследовательских целей на коммерческих условиях стоит слишком дорого (сотни тысяч рублей в год). Некоторые компании (2ГИС), в случае описания целей и характера проводимых исследований, могут предоставить ограниченный по времени, но не ограниченный по количеству запросов доступ к API.

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

С другой стороны, любая компания -- это в первую очередь организация, а любая организация до начала ведения деятельности обязана пройти обязательные процедуры постановки на учет в налоговых органах, фондах и органах статистики, а в случае попадания ее деятельности под лицензируемые виды экономической деятельности (как в случае с продажей алкогольных напитков) еще и получить соответствующие лицензии и разрешения. Причем, важно отметить, что за несвоевременное предоставление информации об открытии/прекращении деятельности организацией предусмотрены значительные штрафы. То есть за актуальностью данной информации следят контролирующие государственные органы, отделы по взысканию штрафов, которые обладают более чем достаточным персоналом и полномочиями. Эта цепочка размышлений приводит нас к мысли о возможности получать информацию: по правовому статусу организации, дате ее регистрации и дате прекращения деятельности от наиболее авторитетного источника -- единого государственного реестра юридических лиц и индивидуальных предпринимателей (ЕГРЮЛ и ЕГРИП). Синхронизация данных между справочником организаций картографических сервисов и базами данных указанных реестров позволила бы в значительной мере решить проблему своевременной актуализации большого пласта информации об отображаемых организациях.

Изучение возможностей сервиса egrul.nalog.ru показало, что, несмотря на техническую возможность получения информации о любой организации действующей или действовавшей на территории РФ, использовать его для решения проблемы актуализации затруднительно по двум причинам:

1. База ЕГРЮЛ не содержит указаний на название заведения, а оно редко соответствует названию юридического лица. Если в случае АО «Макдоналдс Рус» пользователь легко догадается, о каком заведении идет речь, то название ООО «Кэпиталфуд» никаких ассоциаций не вызывает.

2. База ЕГРЮЛ не содержит другой важной для пользователя информации о заведении (часы работы, телефон, количество мест, является ли заведение сетевым и пр.).

Однако наличие подобной информации в открытом доступе наводит на мысль о том, что в сети также могут быть и базы с расширенными данными по организациям, полученные от лицензирующих органов или органов статистики. Продолжительный поиск в итоге приводит нас на портал открытых данных Правительства Москвы -- http://api.data.mos.ru/, который содержит огромный перечень различных наборов данных, формируемых на основании информации, хранящейся в базах данных государственных органов. При этом важнейшим и самым критичным недостатком открытого портала является его реализация картографического сервиса -- http://atlas.mos.ru/. К сожалению, его функционал и эргономика не позволяют поддержать привычные для пользователя сценарии использования подобного рода сервисов. Он скорее напоминает решение, демонстрирующее состоятельность предложенной концепции (proof-of-concept), чем реально работающий инструмент, отвечающий потребностям пользователя. Однако с учетом того, что все данные открытого портала поставляются в популярных форматах GeoJSON и XML, становится возможным использование портала открытых данных в качестве поставщика актуальных данных о существующих заведениях.

Таким образом, становятся возможными агрегация и отображение данных об организациях города от двух открытых поставщиков: OpenStreetMap и data.mos.ru. Такая агрегация позволит не только повысить полноту результирующей базы, но и повысить скорость актуализации базы (так как база data.mos.ru актуализируется за счет информации из государственных реестров). Данную процедуру предлагается выполнить на примере мест общественного питания (кафе, рестораны, столовые, буфеты, закусочные и т.д.) как одному из наиболее динамичных и востребованных типов городских заведений.

2. Реализация поставленной задачи

2.1 Выгрузка данных

К сожалению, непосредственно API OpenStreetMap (OSM) не содержит методов, предоставляющих информацию о заведениях, содержащихся в справочнике организаций OSM, так как слой данных об объектах и слой картографии в API OSM не разделены. Одним из решений задачи выгрузки справочника организаций является полная выгрузка всей базы OSM, однако, такое решение технически сложное и ресурсозатратное, так как требует значительного количества времени как на многопоточную выгрузку XML файлов с серверов OSM, так и на их разбор (парсинг). Однако за годы развития данной платформы вокруг нее появилось множество сервисов, предоставляющих выгрузки различных срезов базы OSM в популярных форматах. Один из подобных сервисов называется Overpass API.

Overpass API (или OSM3S) это доступный только для чтения API, который позволяет извлекать выборочные данные из базы OSM по пользовательскому запросу. Он выступает в качестве базы данных через Интернет: клиент посылает запрос к API и получает обратно набор данных, который соответствует запросу.

В отличие от основного API, который оптимизирован для редактирования, Overpass API оптимизирован для разного уровня потребителей данных -- от извлечения всего нескольких элементов из базы за пару секунд или же до примерно 100 миллионов элементов за несколько минут, которые выбираются в соответствии с критериями поиска как, например, расположение, тип объектов, свойства тегов, близость или их комбинации. Он действует в качестве постоянной (и зачастую основной) базы данных для различных сервисов.

Overpass API имеет мощный язык запросов, основанный на XML -- OverpassML, но также он имеет слой совместимости, позволяющий производить плавный переход от основного языка запросов в OSM -- XAPI .

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

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

node

[amenity=cafe]

(55.625282274095,37.345962524414,55.875696039004,37.889099121094);

out;

Где cafe -- тип заведения, а четыре числа -- координаты (latitude, longitude) двух точек квадрата, описывающего Москву.

Выполнить его можно отправив GET запрос на один из серверов-интерпретаторов языка запросов Overpass ML:

http://overpass.osm.rambler.ru/cgi/interpreter?data="out:json";query

Где, query -- текст приведенного выше запроса.

К сожалению, сервис Overpass не умеет генерировать ответ в формате GeoJSON и выдаст результат в следующем JSON формате:

{

"type": "node",

"id": 431245873,

"lat": 55.6866726,

"lon": 37.5729914,

"tags": {

"addr:housenumber": "24",

"addr:street": "г. Москва, Мясницка, 24",

"amenity": "cafe",

"brand": "Shoko",

"contact:phone": "+7(916)669-07-87",

"contact:facebook": "https://www.facebook.com/shoko.ru",

"contact:website": "http://shoko.ru",

"cuisine": "coffee_shop",

"diet:vegetarian": "no",

"name": "Шоколадница",

"name:en": "Shokoladnitsa",

"name:ru": "Шоколадница",

"diet:vegetarian": "no",

"opening_hours": "Mo-Fr 07:00-00:00; Sa-Su 08:00-00:00"

}

}

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

Выгрузка данных с серверов Overpass производится последовательной отправкой GET запросов с указанием типов необходимых заведений (см. лис. 1). В то же время Портал открытых данных Правительства Москвы не поддерживает гибкого запросного механизма аналогичного сервису Overpass ML. Из доступных фильтров разработчикам предлагается возможность ограничения выдачи по региону и набору данных. В нашем случае набор данных соответствует типам заведений (кафе, рестораны, столовые, буфеты и т.п.). Сервис принимает обращения к своему API по адресу https://apidata.mos.ru. GET-запросы на получение заведений выглядят следующим образом:

https://apidata.mos.ru/v1/features/1786/features?bbox=37.4911,55.8638,37.5403,55.8901

Здесь 1786 -- номер набора данных, а параметр bbox -- координаты, ограничивающие выборку данных о заведениях.

Ответы сервис генерирует в формате GeoJSON, вида:

{

"geometry": {

"coordinates": [

37.65167937197624,

55.85621276492113

],

"type": "Point"

},

"properties": {

"DatasetId": 1786,

"VersionNumber": 2,

"ReleaseNumber": 1,

"RowId": "a6b70751-d188-43a1-a262-0350a333c108",

"Attributes": {

"global_id": 20660626,

"Name": "Кофейня Шоколадница"

"ObjectHasToilet": "да",

"ObjectHasWifi": "нет",

}

},

"type": "Feature"

}

Как видно apidata.mos.ru также предоставляет как минимально необходимый набор данных (координаты и название), так и дополнительные атрибуты. Разница в именовании атрибутов в двух источниках приведет к необходимости их точного сопоставления на этапе агрегации данных.

Выгрузка данных с серверов apidata.mos.ru происходит посредством последовательной отправки запроса на выборку данных с изменением номера набора данных. Для реализации механизма выгрузки и разбора полученных данных был выбран язык C# и платформа .NET как универсальный инструмент, обеспечивающий достаточное для решения данной задачи соотношение производительности кода и удобства (скорости) разработки решений на нем.

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

public class Feature

{

public double CoordX { get; set; }

public double CoordY { get; set; }

public long DatasetId { get; set; }

public long VersionNumber { get; set; }

public long ReleaseNumber { get; set; }

public string RowId { get; set; }

public long GlobalId { get; set; }

public string Name { get; set; }

public string OperatingCompany { get; set; }

public bool IsNetObject { get; set; }

public string AdmArea { get; set; }

public string District { get; set; }

public string Address { get; set; }

public string PublicPhone { get; set; }

public string SeatsCount { get; set; }

public bool SocialPrivileges { get; set; }

//…

}

При получении данных из обоих источников генерируются коллекции объектов класса Feature, свойства объекта заполняются данными полученными из выгрузок вида. При этом, чтобы избежать «ручного» разбора строк с JSON и GeoJSON нотациями, принято решение использовать библиотеку Newtonsoft.Json, которая позволяет превратить любую входную строку, сформированную в строгом соответствии с форматом JSON в динамический (dynamic) объект языка C#, полностью повторяющий описанную в JSON структуру данных.

После чего по динамическим объектам, полученным из JSON, генерируются и заполняются объекты класса Feature. При этом в зависимости от источника данных ожидается различная структура динамического объекта.

2.2 Хранение полученных данных

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

Рис. 1. Структура таблицы Features справочника организаций

Таким образом, для сохранения всего объема полученных данных нам необходимо разработать механизм сохранения информации из объектов класса Feature в таблицу Features с последующим обратным восстановлением данных из таблицы в набор объектов класса Feature (например, для вывода объектов на карту). Конечно, для такого сценария можно использовать базовые механизмы для работы с базами данных в .NET Framework, такие как ADO.NET. Это позволяет реализовать весь необходимый набор CRUDL запросов к подготовленной базе данных (БД). Однако, тот уровень тонкого контроля над происходящими обращениями к базе, который открывается в случае использования ADO.NET в данном проекте будет избыточен по причине небольшого объема данных, содержащихся в БД. В таком случае следует выбрать такое средство доступа к данным, которое обеспечит максимальную скорость и удобство разработки. Обоим этим требованиям отвечают системы класса ORM (Object Relational Mapping), которые осуществляют объектно-реляционное отображение данных из объектов в таблицы и обратно в автоматическом режиме. Достигается это за счет скрытия от разработчика уровня отработки CRUDL запросов с попутным повышением уровня абстракций используемых в коде. ORM системы не только ускоряют работу программных продуктов, но и в значительной мере упрощают их отладку, рефакторинг (за счет исключения из кода T-SQL запросов в текстовом виде и повышения уровня их типизации) и поддержку. За долгие годы развития подобного класса систем появились различные их разновидности, в том числе разрабатываемый и продвигаемый компанией Microsoft проект EntityFramework.

К сожалению, подобного рода библиотеки требуют от разработчика создания большого количества промежуточных сущностей (схем отображения объектов в таблицы) и вынуждают программиста наследовать свои классы от класса определенного типа. В целях настоящего проекта подобные системы будут избыточны, так как нам необходимо решить задачу отображения всего одного класса в одну таблицу. Для решения этой задачи идеально подходит подмножество ORM систем, поддерживающих работу с POCO (Plain Old CLR Objects, традиционные объекты общеязыковой среды выполнения), так как они не требуют создания промежуточных сущностей и специальных схем или классов разметки. Из всего многообразия подобных систем (более полусотни) была выбрана библиотека DAL как удовлетворительное решение по сумме факторов: простота подключения, производительность, прозрачность работы.

Для использования класса Feature в целях отображения значений его объектов в таблицe Features отнаследуем его от generic-класса TransactObject<Feature>, после чего библиотека DAL при первом запуске создаст одноименную таблицу с набором столбцов, полностью соответствующем набору полей (свойств) класса Feature. В случае обнаружения уже существующей таблицы и при эквивалентности ее структуры полям (свойствам) класса, структура таблицы останется без изменений.

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

CRUDL операции в библиотеке DAL запускаются посредством вызовов методов Update(), Insert(), Delete() и Select (через конструктор) у объектов класса, наследованных от базового класса TransactObject и их множественные аналоги: SelectMany(), UpdateMany(), InsertMany(), DeleteMany().

К примеру, для выбора объекта Feature с уникальным идентификатором 14, достаточно просто передать числовое значение идентификатора в конструктор: new Feature(14), а выборка всех объектов Feature, содержащих в названии подстроку KFC, будет выглядеть как:

List<Feature> result = Feature.Instance.SelectMany(f =>f.Name.Contains(“KFC”));

Где result - итоговый список объектов класса Feature, содержащих в названии подстроку “KFC”, а f => f.Name.Contains(“KFC”) -- условие отбора записей в Feature, заданное в форме Lambda-выражения, которое будет автоматически сконвертировано библиотекой DAL в T-SQL запрос вида:

SELECT * FROM Features WHERE Name like '%KFC%'

Для каждой строки в результатах выполнения запроса будет автоматически сгенерирован новый объект класса Feature, в свойства которого будут занесены значения соответствующих столбцов из результирующей таблицы. В случае с изменением значений свойств объектов Feature и последующим вызовом методов Update или UpdateMany, DAL автоматически проверит, какие именно свойства объекта подверглись изменению и сгенерирует запрос вида:

UPDATE Features SET Name = `КФС' WHERE ID = 14

Где 14 -- идентификатор обновляемого объекта (строки таблицы), а КФС -- новое значение поля (столбца) Name.

Таким образом, с использованием ORM DAL функция выгрузки всех заведений общественного питания города Москвы с сервера Портала открытых данных Правительства Москвы принимает весьма компактный вид:

public static List<Feature> Download(long dataSet)

{

WebClient wc = new WebClient();

wc.Encoding = Encoding.UTF8;

string json = wc.DownloadString("https://apidata.mos.ru/v1/datasets/{" + dataSet + "}/features");

dynamic list = ((dynamic)JsonConvert.DeserializeObject(json)).features;

List<Feature> res = new List<Feature>();

foreach (var obj in list)

res.Add(new Feature().FromJSON1(obj));

Feature.Instance.InsertMany(res);

return res;

}

Благодаря оптимально подобранным абстракциям, функция, которая организовывает GET запрос к серверам apidata.mos.ru, преобразовывает полученный JSON в динамические объекты языка C# и производит сохранение полученных объектов Feature в базу данных, умещается всего в 8 строк.

Суммарно из базы OpenStreetMap было выгружено 4 328 заведений общественного питания города Москвы, а из базы Портала открытых данных Правительства Москвы 11 884 заведения.

2.3 Сведение данных

Ключевой проблемой, выявленной после загрузки данных из обоих источников в БД проекта, стало пересечение общей части справочников организаций, полученных из двух различных источников. В случае попытки сведения по точному сравнению названий и координат заведений, пересечений между двумя заведениями не обнаруживается вовсе. Объясняется это тем, что заведения отличаются как по способу именования, например, встречаются подобные наименования одного и того же заведения, пришедшего из двух различных источников: “KFC”, “Ресторан KFC”, так и по координатам расположения, которыми, как известно, каждое заведение маркируется вручную.

Соответственно для составления итогового справочника заведений крайне важно разработать оптимальный алгоритм сопряжения одного и того же заведения для случая, когда оно присутствует сразу в двух базах. Как уже упоминалось ранее, на примере лис. 2 и 3 видно, что единственной информацией о заведении, позволяющей его однозначно идентифицировать является его название и расположение. Причем по отдельности ни название, ни расположение заведения не дают возможности его точной идентификации. Так ресторанов “Шоколадница” в Москве более 450 и все они в поле Name в пределах одного источника данных содержат одно и то же наименование, что не позволяет отличить одно заведение от другого без привязки к их фактическим координатам. В то же время плотность ресторанов в торговых центрах такова, что попытка их идентификации только по координатам без учета наименования так же лишена всякого смысла. Таким образом, алгоритм сведения должен основываться на рассмотрении координат и названия заведения в качестве составного ключа однозначно идентифицирующего заведение. При этом, так как точное сравнение ни координат, ни названий заведений не даёт никакого результата (т.е. пересечением множества заведений из двух источников по строгому соответствию является пустое множество), имеет смысл рассматривать алгоритмы нечеткого сравнения.

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

double LongDifGrad = 50 / 111134.861111;

double LatDifGrad = 50 / 71240.3572324;

Где LongDifGrad -- 50 метров, выраженных в градусах долготы, LatDifGrad -- 50 метров, выраженных в градусах широты.

Теперь для того, чтобы определить близость двух заведений на карте в радиусе 50 метров достаточно произвести линейные сравнения, как показано в функции Near:

private bool Near(Feature d)

{

return CoordX < d.CoordX + LongDifGrad && CoordX > d.CoordX - LongDifGrad

&& CoordY < d.CoordY + LatDifGrad && CoordY > d.CoordY - LatDifGrad;

}

Задание нестрогого сравнения позволяет снять проблему незначительно различающихся координат заведений, поступивших из различных источников. При этом для их полноценного сведения необходимо также решить проблему различных способов написания названий одного и того же заведения (“iL Patio”, “iL'Pation”, “Кафе IL PATIO”, и т.п.).

Первичный поиск возможных решений в сети показал возможность использования алгоритмов класса Soundex -- алгоритмов сравнения двух строк по их звучанию. Они устанавливают одинаковый индекс для строк, имеющих схожее звучание в английском языке. Оригинальный алгоритм Soundex, запатентованный еще в 1918 году, имел значительное количество ложноположительных срабатываний, когда несколько слов с совершенно различным фактическим звучанием определялись алгоритмом как похожие. Это привело к появлению улучшенных версий данного алгоритма, в том числе с поддержкой других языков. К сожалению, в SQL Server встроена только англоязычная версия алгоритма, что подтолкнуло к поиску алгоритмов по сравнению наименований, которые бы работали на стороне C#.

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

public static double FuzzyCompare(int gramm, string left, string right)

{

if (left != null)

left = left.ToLower();

if (right != null)

right = right.ToLower();

if (left == right || left == null || left.Length < 3)

return 1;

return Math.Max(_compare(gramm, left, right), _compare(gramm, right, left));

}

private static double _compare(int gramm, string left, string right)

{

double foundCnt = 0;

for (int i = 0; i < left.Length - (gramm - 1); i++)

foundCnt += right.Contains(left.Substring(i, gramm)) ? 1 : 0;

return foundCnt / (left.Length - (gramm - 1));

}

Где gramm -- количество подряд стоящих символов, подлежащих выделению (в нашем случае оптимальное число 3), left -- первая строка, right -- вторая строка.

Суть алгоритма отраженного в приведенном выше листинге:

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

2. Подсчет количества уникальных вхождений триграмм во вторую строку.

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

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

Применение описанного алгоритма определения близости строк действительно позволяет установить факт схожести названия таких заведений как «Кафе Песто» и «Песто». Итоговый алгоритм показан в лис. 8. После его применения к исходным базам, множество сведенных (т.е. обнаруженных в обоих источниках) заведений выросло с нуля до двух тысяч (больше половины всех кафе и ресторанов, полученных из базы OpenStreetMap).

private static List<Feature> Merge(List<Feature> src)

{

var features = Feature.Instance.SelectMany();

List<Feature> res = new List<Feature>();

foreach (Feature s in src)

{

bool found = false;

foreach (Feature d in features)

{

if (s.Near(d) && XgramCompare.FuzzyCompare(3, s.Name, d.Name) > 0.4)

{

found = true;

break;

}

}

if (!found)

res.Add(s);

}

return res;

}

Однако оба алгоритма: и алгоритм определения картографической близости, и алгоритм определения схожести строк, являются алгоритмами нечеткими, результаты их работы в большей степени зависят от пороговых значений «чувствительности» алгоритма. Для алгоритма, таким пороговым значением является константа 50 метров, для алгоритма таковой константой является 0,4 (40% пересечений в двух строках), которая используется в лис. 8. Числовые значения 50 и 0,4 определены с помощью выборочного визуального контроля полученного результата, поэтому не могут считаться оптимальными до тех пор, пока не показано, что остальные возможные значения для данных констант уменьшают процент корректно сведенных заведений. Для определения оптимальных (или субоптимальных) значений пороговой чувствительности указанных алгоритмов, необходимо изучить остальные допустимые значения указанных констант.

Так для критерия картографической близости область допустимых значений распространяется от нуля метров до бесконечности. Однако оба крайних случая лишены смысла. Слишком малое значение приведет к низкому объему сводимости (при нуле метров, количество сведенных заведений равно нулю). Слишком большое значение приведет к ложноположительным срабатываниям алгоритма, когда схожие по названию, но находящиеся на большом удалении (несколько сотен метров) заведения будут сведены. Но для разумного диапазона значений (от десяти до ста метров) разброс в количестве сведенных заведений достаточно значительный, а зависит это количество от значения второй вариативной постоянной -- коэффициента близости строк. Получаем задачу двухкритериальной оптимизации, при которой целевая функция представляет из себя максимизацию количества сведенных заведений при минимизации количества ложноположительных срабатываний. Для визуального решения данной задачи предлагается построить таблицу результатов отработки алгоритма сведения с последовательным перебором всех возможных значений обоих констант в диапазоне от 0 до 100 для константы картографической близости и от 0 до 1 для константы близости строк. Шаг изменения обеих констант возьмем равным 5.

public static void CalcMerges()

{

var all = Feature.Instance.SelectMany();

var from = all.Where(x => x.SourcesStr.Contains("data.mos.ru")).ToList();

var to = all.Where(x => x.SourcesStr.Contains("OpenStreetMap.ru")).ToList();

double distStep = 10;

double wordStep = 0.05;

Parallel.For(0, 10, di => {

for (int wi = 20; wi > 0; wi++)

{

Merge2(from, to, "", distStep * di, wordStep * wi);

}

});

}

private static long Merge2(List<Feature> from, List<Feature> to,

string source, double dDist, double dNames)

{

long cnt = 0;

List<Feature> res = new List<Feature>();

List<Feature> toUpdate = new List<Feature>();

foreach (Feature s in to)

{

foreach (Feature d in from)

{

if (s.Near2(d, dDist) &&

XgramCompare.FuzzyCompare(3, s.Name, d.Name) > dNames)

{

cnt++;

break;

}

}

res.Add(s);

}

return cnt;

}

Как видно из листинга, построение результирующей таблицы происходит посредством построения множества всех возможных комбинаций значений переменных постоянных, которое получается декартовым произведением множеств значений констант. Таким образом, имеем (100 / 5) двадцать значений каждой из констант, что в итоге приводит к 400 запускам модифицированного алгоритма сведения организаций, описанного в функции Merge2, в которой нет предопределенных констант, в отличие от оригинальной функции, описанной в лис. 8. Для ускорения отработки такого количества запусков в коде функции CalcMerges() используется конструкция Parallel.For, которая распараллеливает выполнение описанного лямбда-выражения (по сути вызова функции Merge2).

Рис. 2. Таблица распределения количества сведенных заведений в зависимости от значений варьируемых переменных

Результат отработки алгоритма из лис. 9, представлен в виде таблицы на рис. 2, где столбцы представляют из себя значения константы, задающей коэффициент близости строк, а строки -- значения константы картографической близости. В ячейках, находящихся на пересечении выбранного столбца и строки, содержится численный результат выполнения функции сведения (Merge2), который представляет из себя количество сведенных заведений. Таблица раскрашена в виде «тепловой карты», где ячейки с большим количеством сведенных заведений имеют большую интенсивность зеленого цвета в фоне. Максимальное количество сведенных заведений ожидаемо наблюдается при максимальном количестве допущений (т.е. максимально возможное расстояние между сравниваемыми объектами при минимально возможном требовании к идентичности строк -- 0%). Однако визуальный контроль списка сведенных заведений показывает, что процент ложных срабатываний при этом также крайне велик. Дальнейшее изучение таблицы результатов и визуальный контроль соответствующих им списков сведенных заведений показал, что уменьшение коэффициента близости строк до уровня меньшего 40% приводит к заметному росту количества ложноположительных сведений. При этом увеличение коэффициента близости до 100 метров практически не влияет на количество ложноположительный сведений. Связано это, прежде всего, с наличием на территории Москвы большого количества торговых центров, в которых расстояние между ресторанами зачастую превышает 50 метров. Обнаруженные новые значения констант использовались для дальнейших расчетов.

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

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

1. Для случая с нечетным количеством источников (3, 5, 7 и т.д.) пользоваться правилом простого большинства. Если значения атрибута в источниках 1, 2 эквивалентны, но отличаются от значения из источника 3, то отображается информация из источников 1, 2.

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

В нашем случае количество источников ограничено двумя, следовательно, имеет смысл использовать 2-е правило. Так как информация Портала открытых данных Правительства Москвы имеет гораздо большую частоту обновлений, чем у OSM, считаем данный источник приоритетней и выводим информацию из него.

2.4 Визуализация данных

По результатам тестирования гибкости и функциональности API различных картографических сервисов было принято решение использовать API Яндекс.Карт в качестве сервиса для отображения полученной (сведенной на предыдущем этапе) базы организаций.

Исследование способов отображения большого (>10 000) количества объектов на карте единовременно, показало, что в API Яндекс.Карт для этого предусмотрено два базовых сценария:

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