В процессе работы над мобильным приложением использующим открытые данные пришлось близко познакомиться с содержанием ряда порталов, в результате возникли предложения, как усовершенствовать «внутренний мир порталов открытых данных» в интересах разработчика.
Если Вам это интересно и у Вас уже есть опыт работы в этой области, то можете сравнить свои выводы с написанным ниже.
В основе работы с любым порталом лежит паспорт набора данных. Хочешь обратиться к набору данных, найди его паспорт, извлеки наименование набора, номер, ссылку на набор и описание полей в наборе.
Вроде все логично, с точки зрения ручной картотеки, которую ведет человек, но с точки зрения приложения, этого мало, так как программно нельзя получить никакой информации о содержании набора данных.
Разработчик должен предварительно поинтересоваться сам, что это за набор, где размещен, в каком формате его данные.
Паспорт набора должен помочь приложению рассказать о своем содержимом.
Это возможно. Необходимо лишь создать в сети реестр всех порталов открытых данных России, принять единую структуру нумерации ( или ID) наборов данных и стандартизировать порядок наименования и содержания их полей.
1. Реестр порталов открытых данных России.
Место в сети где перечислены все порталы открытых данных (реестр).
Сегодня мы ищем ссылки на порталы в сети используя поисковую систему, и найдя портал, знакомимся с его содержимым. Сайта/Странички с перечнем всех порталов открытых данных России и ссылок на них, пока нет (или он мне неизвестен).
2. Единая структура номера ( или ID) набора данных.
Пришли на портал (используя реестр п.1), хотелось бы понять, что на нем размещено. Каждый набор определяется наименованием и его номером/id.
Сегодня кто как хочет, так и нумерует. На одном портале это цифры, на другом слова, на третьем предложения. На некоторых порталах в номер/наименование набора данных включен ИНН, уже хорошо, можно вытащить регион (если поймешь, что тут присутствует ИНН), но этого мало.
Наборы собраны в категории (пока не везде), что очень логично, когда собраны. Но реализация справочников категорий, у каждого своя. Уровень порталов по охвату информации тоже разный, есть федеральные, региональные, городские и поселковые.
В результате хочешь найти и использовать информацию от разных порталов в одном приложении, разрабатывай свою нумерацию порталов, наборов и категорий.
Почему мы бы не наполнить номер/id набора данных смыслом, для облегчения понимания о содержимом набора данных программными средствами.
Для этого в номер набора (его id) достаточно включить:
ID1 — уникальный номер портала (привязанный к федеральный/код региона/год города/код ….), он же id портала в единой Российской классификации,
ID2 — единый код категории информации в наборе данных (то есть должен быть разработан и утвержден единый справочник категорий),
ID3 — номер набора на портале.
Хочет любое ведомство организовать портал открытых данных, отправляет заявку в учетный госорган, получает для себя ID1 — портала и единый справочник категорий. В результате набор данных на портале получит номер в виде:
ID1-ID2-ID3, а разработчик получит готовый механизм для быстрого поиска необходимых наборов данных на любом портале.
Не надо будет для каждого города создавать отдельное замечательное приложение реализующее уникальный сервис. Меняй ссылку на портал в зависимости от геолокации пользователя, и используй приложение в любом регионе. Оно легко найдет нужный портал и нужную категорию. И при необходимости легко «вытащит» все доступные порталы в выбранной категории любого города, региона или страны.
3. Стандартизированный поход к наименованию и содержанию полей наборов данных.
Нужный набор нашли. Теперь необходимо разобраться с его внутренней структурой.
И здесь сегодня у всех все по своему.
— Поля с координатами данных (географи́ческие координаты). Кто-то в своих наборах называет их широта и долгота ( два разных поля), кто-то гео-координаты и укладывает значения в одно поле (x,y), кто-то хранит в виде массива, а кто-то в виде словаря. При этом на одном портале легко может присутствовать несколько вариантов (РосТуризм, Правительство Москвы). Разработчику было-бы приятно видеть единый вариант хранения гео-координат на всех порталах. Какой, любой, устраивающий всех. А в паспорте набора обязательно должна присутствовать отметка не только о их наличии, но и типе. Точка, линия или область.
— Содержание полей. Может быть любым, кроме размещенных внутри html-страниц, которыми сегодня наполнен портал Министерства культуры. Разработчику нужна информация, как это принято писать в определяющих документах, в машинночитаемом виде, а не в виде html-страниц для последующего парсинга и поиска информации еще и в них. Разработчик не собирается тиражировать чей-то сайт, он делает свое приложение. И не забываем о трафике, который резко возрастает, при получении информации в виде html, который подтаскивает за собой разметку и шрифты. Мобильное приложение это способ ухода от HTML, получение «голой» информации, а не еще один вариант отображения web — страниц.
— Ссылка на картинки. Сегодня это еще одна область для фантазий владельцев порталов данных. Доходит даже до хранения ссылок на pdf-файлы с картинками (Министерство культуры). Причем сделано это, без указания реального расширения файла. Разработчик, видя ссылку на картинку, предполагает найти там что угодно, но только не pdf-файл.
— Ссылка на документы. Также необходима стандартизация.
— Размер фотографий. К сожалению их почти всегда предлагают так, как снято, то есть не задумываясь о том, что они в большом разрешении не нужны для web и мобильных приложений. Выкладывают то, что есть в наличии. Очень показательный пример, справочник сотрудников на портале Московского Правительства. Посмотрите. От мелких, сканированных фото с документов, до огромных фотографий в интерьерах кабинета. Было бы приятно и здесь иметь определенный стандарт.
3. Доступность данных.
Иногда на порталах бывают профилактические работы. О которых никому никак не сообщается. Понятно, без этого нельзя. Но на это время, приложение использующие открытые данные становится не работоспособным и принимает на себя весь гнев его пользователя. Который не понимает, что приложение совсем не виновато. Для него оно «глючит». Из-за этого пользователи отказываются от приложения или пишут плохие отзывы о нем. Например на портале Правительства Москвы это периодически происходит по субботам.
Порталы необходимо обязать в свои API добавить запрос портала на предмет Открыт/Закрыт. А если портал еще вернет и предполагаемую дату своего предполагаемого открытия… Вот тогда заживем.
4. Качество данных.
Качество данных на порталах страдает от двух факторов. Ошибки в самих данных и ошибки в структуре сброшенных данных.
Грамматические, в наименованиях полей и содержании, типа «фотграфия» как нибудь переживем.
Ошибки в данных.
Плохо когда больше года, в наборе данных, входы/выходы метрополитена на портале Правительства Москвы, отсутствуют не отдельные входы, а целые станции метро. А из набора данных «остановки общественного транспорта» выясняется, что автобус на маршруте номер XX останавливается только на одной остановке. Где еще проходит его маршрут неизвестно. Или в поле отчество, прописана фамилия, а в поле фамилия отчество, портал Министерства культуры. Опять же налицо избыточность, зачем вводить отдельные поля имя, фамилия и отчество, при наличии в этом же наборе поля ФИО? Мелочи, типа перепутанные широта и долгота, мы пока не рассматриваем.
Ошибки в структуре данных.
Эта группа ошибок появляется при сбросе данных в csv формат и связана с используемыми разделителями в этом формате. Очень легко обнаруживаются данные с разделителем «,» где эта-же запятая присутствует внутри самих полей. Как Вы понимаете в этом случае корректно разделить строчку на отдельные поля невозможно. Как и в случае когда внутри поля присутствуют символы перевода строки. Подобная ситуация возникает и когда просто не выводятся все разделители в каждой строке. Их не хватает. По всей видимости, при наполнении набора данных на портале, берется красивый XLS файл и напрямую сбрасывается со всеми своими заголовками. Так делать нельзя.
CSV — файл, из-за подобных ошибок, это тихий ужас для разработчика, ночной кошмар. Попробуй объясни пользователю, что в полученных данных нельзя разобраться из-за нарушенной структуры. Но этот формат пока лидирует.
И самые неприятные ошибки, это когда, согласно приведенному описанию формированию запросов для разработчиков на портале Правительства Московской области, ты должен получить json, но тебе приходит ответ в виде csv, даже и не знаю к какому разряду отнести. Приходится сразу в код вставлять проверку, того что пришло, и выбирать обработку полученных данных в зависимости от того, что дали (csv или json), а не от того, что обещано описанием API. Бытие определяет работу приложения.
5. Актуальность данных. 2014 — 2015 год присутствуют у всех, а вот 2016 и дальше… С этим сложно.
6. Организация хранения и доступ к данным.
Одни используют для запроса и обновления данных OpenData, другие MongoDb, и так далее. Для разработчика каждый новый портал это новый парсинг, приложение растет. Вместо работы над новой функциональностью приходится отлаживать очередной вариант приема данных (запрос — ответ). Хотя схема (Паспорт — Набор) присутствует. Так нельзя.
Надо договариваться и использовать единое решение, с единым API.
Со стороны разработчика, лучший вариант, это облачный портал у одного провайдера, на основе одной СУБД, с единым API, где любое ведомство может получить себе место под свой портал открытых данных и универсальное средство для работы с ним. Надеюсь, что регулирующей организации, отвечающей за программу открытых данных в стране, это не сложно устроить. Плюс у нее появится реальный контроль над расходованием средств выделяемых на эту программу.
Это легко реализуется например на основе Windows Azure. Уверен, что все достоинства подобного варианта по затратам, скорости ввода в эксплуатацию, надежности и по цене владения понятны не только разработчикам.
И немного о том, откуда опыт, то есть о мобильном приложении, работа над которым и привела к написанному выше.
Приложение написано под iOS, работает с пятью порталами открытых данных, это 1147 наборов и информация от Центрального банка России.
— Портал Правительства Москвы — 697 наборов,
— Правительства Московской области — 266 наборов,
— Министерства культуры — 49 наборов,
— Федерального агентство России по туризму — 135 наборов.
— Портал Центрального банка не называясь прямо порталом открытых данных, по сути является таковым, поскольку на нем представлена информация о курсах котируемых им валют за любой период. Необходимая информация для перевода рублевой статистики, выложенной на порталах открытых данных, в любой валютный эквивалент.
Если Вам это интересно и у Вас уже есть опыт работы в этой области, то можете сравнить свои выводы с написанным ниже.
В основе работы с любым порталом лежит паспорт набора данных. Хочешь обратиться к набору данных, найди его паспорт, извлеки наименование набора, номер, ссылку на набор и описание полей в наборе.
Вроде все логично, с точки зрения ручной картотеки, которую ведет человек, но с точки зрения приложения, этого мало, так как программно нельзя получить никакой информации о содержании набора данных.
Разработчик должен предварительно поинтересоваться сам, что это за набор, где размещен, в каком формате его данные.
Паспорт набора должен помочь приложению рассказать о своем содержимом.
Это возможно. Необходимо лишь создать в сети реестр всех порталов открытых данных России, принять единую структуру нумерации ( или ID) наборов данных и стандартизировать порядок наименования и содержания их полей.
1. Реестр порталов открытых данных России.
Место в сети где перечислены все порталы открытых данных (реестр).
Сегодня мы ищем ссылки на порталы в сети используя поисковую систему, и найдя портал, знакомимся с его содержимым. Сайта/Странички с перечнем всех порталов открытых данных России и ссылок на них, пока нет (или он мне неизвестен).
2. Единая структура номера ( или ID) набора данных.
Пришли на портал (используя реестр п.1), хотелось бы понять, что на нем размещено. Каждый набор определяется наименованием и его номером/id.
Сегодня кто как хочет, так и нумерует. На одном портале это цифры, на другом слова, на третьем предложения. На некоторых порталах в номер/наименование набора данных включен ИНН, уже хорошо, можно вытащить регион (если поймешь, что тут присутствует ИНН), но этого мало.
Наборы собраны в категории (пока не везде), что очень логично, когда собраны. Но реализация справочников категорий, у каждого своя. Уровень порталов по охвату информации тоже разный, есть федеральные, региональные, городские и поселковые.
В результате хочешь найти и использовать информацию от разных порталов в одном приложении, разрабатывай свою нумерацию порталов, наборов и категорий.
Почему мы бы не наполнить номер/id набора данных смыслом, для облегчения понимания о содержимом набора данных программными средствами.
Для этого в номер набора (его id) достаточно включить:
ID1 — уникальный номер портала (привязанный к федеральный/код региона/год города/код ….), он же id портала в единой Российской классификации,
ID2 — единый код категории информации в наборе данных (то есть должен быть разработан и утвержден единый справочник категорий),
ID3 — номер набора на портале.
Хочет любое ведомство организовать портал открытых данных, отправляет заявку в учетный госорган, получает для себя ID1 — портала и единый справочник категорий. В результате набор данных на портале получит номер в виде:
ID1-ID2-ID3, а разработчик получит готовый механизм для быстрого поиска необходимых наборов данных на любом портале.
Не надо будет для каждого города создавать отдельное замечательное приложение реализующее уникальный сервис. Меняй ссылку на портал в зависимости от геолокации пользователя, и используй приложение в любом регионе. Оно легко найдет нужный портал и нужную категорию. И при необходимости легко «вытащит» все доступные порталы в выбранной категории любого города, региона или страны.
3. Стандартизированный поход к наименованию и содержанию полей наборов данных.
Нужный набор нашли. Теперь необходимо разобраться с его внутренней структурой.
И здесь сегодня у всех все по своему.
— Поля с координатами данных (географи́ческие координаты). Кто-то в своих наборах называет их широта и долгота ( два разных поля), кто-то гео-координаты и укладывает значения в одно поле (x,y), кто-то хранит в виде массива, а кто-то в виде словаря. При этом на одном портале легко может присутствовать несколько вариантов (РосТуризм, Правительство Москвы). Разработчику было-бы приятно видеть единый вариант хранения гео-координат на всех порталах. Какой, любой, устраивающий всех. А в паспорте набора обязательно должна присутствовать отметка не только о их наличии, но и типе. Точка, линия или область.
— Содержание полей. Может быть любым, кроме размещенных внутри html-страниц, которыми сегодня наполнен портал Министерства культуры. Разработчику нужна информация, как это принято писать в определяющих документах, в машинночитаемом виде, а не в виде html-страниц для последующего парсинга и поиска информации еще и в них. Разработчик не собирается тиражировать чей-то сайт, он делает свое приложение. И не забываем о трафике, который резко возрастает, при получении информации в виде html, который подтаскивает за собой разметку и шрифты. Мобильное приложение это способ ухода от HTML, получение «голой» информации, а не еще один вариант отображения web — страниц.
— Ссылка на картинки. Сегодня это еще одна область для фантазий владельцев порталов данных. Доходит даже до хранения ссылок на pdf-файлы с картинками (Министерство культуры). Причем сделано это, без указания реального расширения файла. Разработчик, видя ссылку на картинку, предполагает найти там что угодно, но только не pdf-файл.
— Ссылка на документы. Также необходима стандартизация.
— Размер фотографий. К сожалению их почти всегда предлагают так, как снято, то есть не задумываясь о том, что они в большом разрешении не нужны для web и мобильных приложений. Выкладывают то, что есть в наличии. Очень показательный пример, справочник сотрудников на портале Московского Правительства. Посмотрите. От мелких, сканированных фото с документов, до огромных фотографий в интерьерах кабинета. Было бы приятно и здесь иметь определенный стандарт.
3. Доступность данных.
Иногда на порталах бывают профилактические работы. О которых никому никак не сообщается. Понятно, без этого нельзя. Но на это время, приложение использующие открытые данные становится не работоспособным и принимает на себя весь гнев его пользователя. Который не понимает, что приложение совсем не виновато. Для него оно «глючит». Из-за этого пользователи отказываются от приложения или пишут плохие отзывы о нем. Например на портале Правительства Москвы это периодически происходит по субботам.
Порталы необходимо обязать в свои API добавить запрос портала на предмет Открыт/Закрыт. А если портал еще вернет и предполагаемую дату своего предполагаемого открытия… Вот тогда заживем.
4. Качество данных.
Качество данных на порталах страдает от двух факторов. Ошибки в самих данных и ошибки в структуре сброшенных данных.
Грамматические, в наименованиях полей и содержании, типа «фотграфия» как нибудь переживем.
Ошибки в данных.
Плохо когда больше года, в наборе данных, входы/выходы метрополитена на портале Правительства Москвы, отсутствуют не отдельные входы, а целые станции метро. А из набора данных «остановки общественного транспорта» выясняется, что автобус на маршруте номер XX останавливается только на одной остановке. Где еще проходит его маршрут неизвестно. Или в поле отчество, прописана фамилия, а в поле фамилия отчество, портал Министерства культуры. Опять же налицо избыточность, зачем вводить отдельные поля имя, фамилия и отчество, при наличии в этом же наборе поля ФИО? Мелочи, типа перепутанные широта и долгота, мы пока не рассматриваем.
Ошибки в структуре данных.
Эта группа ошибок появляется при сбросе данных в csv формат и связана с используемыми разделителями в этом формате. Очень легко обнаруживаются данные с разделителем «,» где эта-же запятая присутствует внутри самих полей. Как Вы понимаете в этом случае корректно разделить строчку на отдельные поля невозможно. Как и в случае когда внутри поля присутствуют символы перевода строки. Подобная ситуация возникает и когда просто не выводятся все разделители в каждой строке. Их не хватает. По всей видимости, при наполнении набора данных на портале, берется красивый XLS файл и напрямую сбрасывается со всеми своими заголовками. Так делать нельзя.
CSV — файл, из-за подобных ошибок, это тихий ужас для разработчика, ночной кошмар. Попробуй объясни пользователю, что в полученных данных нельзя разобраться из-за нарушенной структуры. Но этот формат пока лидирует.
И самые неприятные ошибки, это когда, согласно приведенному описанию формированию запросов для разработчиков на портале Правительства Московской области, ты должен получить json, но тебе приходит ответ в виде csv, даже и не знаю к какому разряду отнести. Приходится сразу в код вставлять проверку, того что пришло, и выбирать обработку полученных данных в зависимости от того, что дали (csv или json), а не от того, что обещано описанием API. Бытие определяет работу приложения.
5. Актуальность данных. 2014 — 2015 год присутствуют у всех, а вот 2016 и дальше… С этим сложно.
6. Организация хранения и доступ к данным.
Одни используют для запроса и обновления данных OpenData, другие MongoDb, и так далее. Для разработчика каждый новый портал это новый парсинг, приложение растет. Вместо работы над новой функциональностью приходится отлаживать очередной вариант приема данных (запрос — ответ). Хотя схема (Паспорт — Набор) присутствует. Так нельзя.
Надо договариваться и использовать единое решение, с единым API.
Со стороны разработчика, лучший вариант, это облачный портал у одного провайдера, на основе одной СУБД, с единым API, где любое ведомство может получить себе место под свой портал открытых данных и универсальное средство для работы с ним. Надеюсь, что регулирующей организации, отвечающей за программу открытых данных в стране, это не сложно устроить. Плюс у нее появится реальный контроль над расходованием средств выделяемых на эту программу.
Это легко реализуется например на основе Windows Azure. Уверен, что все достоинства подобного варианта по затратам, скорости ввода в эксплуатацию, надежности и по цене владения понятны не только разработчикам.
И немного о том, откуда опыт, то есть о мобильном приложении, работа над которым и привела к написанному выше.
Приложение написано под iOS, работает с пятью порталами открытых данных, это 1147 наборов и информация от Центрального банка России.
— Портал Правительства Москвы — 697 наборов,
— Правительства Московской области — 266 наборов,
— Министерства культуры — 49 наборов,
— Федерального агентство России по туризму — 135 наборов.
— Портал Центрального банка не называясь прямо порталом открытых данных, по сути является таковым, поскольку на нем представлена информация о курсах котируемых им валют за любой период. Необходимая информация для перевода рублевой статистики, выложенной на порталах открытых данных, в любой валютный эквивалент.