17 июля в 12:18

Почему открытые данные никому не нужны

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



У всех этих ресурсов одни и те же болезни. Вот они:


  • Невалидность данных.
  • Разрозненность данных и отсутствие стандартов.
  • Отсутствие единого механизма поиска.
  • Отсутствие API для доступа к данным.

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


Невалидность данных


Из статистики по документам data.gov.ru видно что большая часть данных размещены в CSV-формате:



И это огромная проблема. Дело в том что большая часть CSV-файлов имеют невалидный формат. В CSV легко допустить ошибку, а если пользователь не разбирается в стандарте, то вероятность ошибки близка к 100%. И так, какие ошибки встречаются чаще всего:


1 местолишние кавычки. Это бич всех CSV данных. Неправильная кавычка может сломать весь документ.


Пример: Реестр лицензий на фармацевтическую деятельность Новгородской области первая же строка:


"Фармацевтическая деятельность","ООО ГЕЛИОС"",...

2 месторазное количество колонок в строках данных.


Пример: государственный реестр лекарственных средств


regnumber,regdate,enddate,cancellationdate,nameregcertificate,country,tradename,internationalname,formrelease,stages,barcodes,normativedocumentation,pharmacotherapeuticgroup

 П N009886,28.04.2011,,,,"ООО ""Валеант""",Россия,Бронхинол,,~,,"Производство готовой лекарственной формы,Херкель Б.В., Nobelweg 6, 3899 BN Zeewolde, the Netherlands, Нидерланды
",,"П N009886-280411,2011,Бронхинол; 
",отхаркивающее средство растительного происхождения

Сопоставляем заголовок и данные, получаем:


regnumber = П N009886
regdate = 28.04.2011
enddate =
cancellationdate =
nameregcertificate =
country = ООО "Валеант"
tradename = Россия
internationalname = Бронхинол
...

80% CSV-файлов приходится править перед использованием. Это не большая проблема для небольших и редко меняющихся наборов данных. Но если набор в сотню тысяч строк и обновляется раз в неделю, то это большая проблема.


Отсюда возникает вопрос, зачем использовать CSV?


Разрозненность данных и отсутствие стандартов


Каждая служба публикует данные в произвольном виде.


Например это заголовки колонки из CSV-файла перечня карантинных зон:


"Название карантинного организма",
"Административный район",
"Площадь в пределах установленной карантинной фитосанитарной зоны (га)",
"№ и дата приказа об установлении карантинной фитосанитарной зоны Представление в орган исполнительной власти субъекта РФ (№ и дата письма)",
"Представление в орган исполнительной власти субъекта РФ (№ и дата письма)",
"Решение органа исполнительной власти субъекта РФ о наложении карантина (№ и дата)",
"Территориальное управление"

Геокоординаты могут быть представлены в виде 2 колонок, в одной колонке через запяую или в GeoJSON.


А вот несколько вариантов представления списков:


"№ 223од от 02.09.2010            № 277од от 29.09.2011       № 136од от 14.10.2009        № 556од от 02.10.2013              № 452од от 19.10.2012"

"4 номера: 3 апартамента, 9 люксов, 2 однокомнатных двухместных улучшенных, 4 одноместных, 37 двухместных номеров"

"OVDPhone": [
    { "PhoneOVD": "(495) 601-05-36" },
    { "PhoneOVD": "(495) 601-05-37" }
]

Ко всему прочему данные разбросаны по разным ресурсам:



Как узнать что это официальные сайты? И почему бы не публиковать данные в одном месте?


Отсутствие единого механизма поиска


Из-за разрозненности данных, нет возможности осуществить поиск по всем государственным источникам открытых данных. Видимо не хватает национального поисковика по открытым данным…


Отсутствие API для доступа к данным


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


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




Все это приводит к тому что открытые данные есть, но судя по количеству скачиваний на data.gov.ru ими пользуются единицы.



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


Как можно исправить ситуацию


ИМХО, ресурс аналогичный GitHub но для данных дал бы сильный толчок в развитии открытым данным.


Да, есть например data.world, но он пока не имеет всей той функциональности которая сделала бы его GitHub'ом для данных. Какими характеристиками должен обладать ресурс:


  • Визуализация — возможность визуализировать данные так как хочет автор и пользователи, а не так как это сделает система.
  • Стандартизованность — возможность задать структуру данных, отклонение от которой выдаст ошибку и не позволит загрузить данные.
  • API и интеграция — богатый API и возможность интеграции с различными источниками данных.
  • Социальность — обсуждение, оценка и рецензирование данных сообществом.
  • Международность — данные не должны размещаться на серверах в какой-то одной стране, чтобы избежать их блокирования со стороны государства.

Уверен что в скором времени такой ресурс появится и открытые данные займут значимое место в жизни каждого человека.

Денис Гуков @fiftin
карма
18,0
рейтинг 14,5
Открытые данные
Самое читаемое Разное

Комментарии (57)

  • +3

    Петиция? Письмо в курирующий орган?

    • 0
      С просьбой разъяснить наличие стандартов на эти самые данные, да.
    • 0
      Замечтался и прочитал вторую часть как «в конкурирующий орган».
    • +1

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

    • +1

      Я им отправлял уже три недели назад про экскейпинг (я не автор этого поста). Судя по всему, в opendata обратная связь идет в /dev/null, и это тоже огромный минус этого портала. (с Санкт-Петербурга ответили через неделю, что это не их компетенция)
      Форварднул в минэкономразвития.


      Заголовок спойлера

      Не могу воспользоваться открытыми данными в формате csv из за того, что не выполняется экранированией спец символов:
      Шаги для воспроизведения:
      Загрузить набор
      http://data.gov.ru/opendata/7825457753-transport
      В наборе существую строковые значения, которые содержат в себе символ кавычки (").
      Пример:
      1,"305","1","НАЛИЧНАЯ УЛ. — БЕЛООСТРОВСКАЯ УЛ.","Автобус","Прямое","22 165","2 246",0.28,"А.С. "НАЛИЧНАЯ УЛ."",59.9567858383426,30.2370663
      Эту строчку невозможно разобрать на значения, тк. символ кавычки играют двойноу роль — роль индикатор начала и конца строкового знаения, и значение символа внутри строки.
      Согласно RFC 4180 на Common Format and MIME Type for Comma-Separated Values (CSV) Files такие неоднозначности должны устранятся:
      Цитата:


      1. If double-quotes are used to enclose fields, then a double-quote
        appearing inside a field must be escaped by preceding it with
        another double quote. For example:


        "aaa","b""bb","ccc"


      • +1
        Это довольно иронично выглядит, когда жалоба на ошибки в данных сама содержит ошибки и опечатки практически в каждой строке.
  • +1
    Даже если в этом посте присутствуют ошибки, что говорить о данных.
    Данные есть? Есть. Птичку поставили перед руководством, премию получили.
    То что ими не пользуются — не дело СОЗДАТЕЛЕЙ.
  • –2

    Эммм… Как бы так сказать, чтоб не забанили… Плохие открытые данные, это не самая острая проблема этой страны. ФГУПы, прокуратура, СК, суды,- всем пое.ать на прямое нарушение федеральных законов, а вы про неудобность формата…

    • 0
      Одна из самых больших логических ошибок — думать, что от нерешения маленьких проблем вдруг сами собой начнут решаться большие. Более того, тем, кто не способен правильно выгрузить данные на сервер, я бы проблемы федеральных законов не доверил решать в принципе.
      • 0

        Правовое регулирование и правоприменение действует по нисходящей (рыба гниёт с головы). То что в одном муниципалитете четкий программист сделал четкие скрипты и его данные валидны — ничто, когда все доходит до регионального или федерального уровня. Ибо кто в лес, кто по дрова.

  • –4

    Я против предоставления доступа к API открытых данных. Ибо я как налогоплательщик не заинтересован в оплате доп. серверов и доп.структур которые будут этот доступ осуществлять. Главное чтобы выгрузки были регулярными и в удобном формате.

    • +2
      Выгрузки все равно лежат на серверах которые требуют денег на содержание, так почему бы КПД не поднять)
      • +1
        разный порядок затрат, на статику и на динамически генерируемый контент
        • +1

          Лучше так — на API принимается обязательный ГОСТ и эти данные больше никакие исполнители не готовят руками — потому что этим теперь занимаются автоматизированные рабочие места персонала и ERP-системы госорганов, которые обновляются централизованно в масштабах государства, в соответствии с текущим законодательством и независимо от хотелок местных начальничков. "Гитхаб для данных", под эгидой Росстата, нужен теперь как большой архив, связанный с ERP через API и необходимый на тот случай, если что то грохнется, нужно будет проследить исторические ряды и т. д.

          • 0

            А как тогда припиской заниматься?! Если статистика будет отражать реальную действительность этож скока голов госслужащих полетят.
            Эта инициатива не дойдет и до первого чтения.

        • –1
          На статику, генерируемую девочкой в excel-e ежедневно и на динамику, отдаваемую из закешированного запроса к базе? База обгонит девочку на первой зарплате по операционным расходам и окупится за пару лет с учетом разработки.
          • 0
            База обгонит девочку на первой зарплате

            Обычно этим занимается не "одна человека" а куча народа во всех госорганах всех субъектов и на всех уровнях, а нужно, чтобы занимался простейший скрипт — который ложил бы свежие данные из локальной базы в централизованное хранилище а другой, который в хранилище* — готовит из цифр кошек нужную расчётную статистику. При этом персонал занимается работой с людьми, а не с цифрами и не вникает в проблемы их предоставления, хранения, обновления образов своих АРМ и т. д. а закончив рабочий день — спокойно идёт домой: только вопросы правильного внесения данных в формы рабочих программ — остаются отчасти в их ведоме.




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

          • 0

            Вы подходите к вопросу как пролетарий, ну или просто прогматичный человек не наделённый властью и бюджетами. Не так давно был в населенном пункте с численностью где-то человек 100. Библиотекарь в фонде которого 5 полок с книгами получает зарплату 30 тысячи рублей. Вы что хотите чтобы ее работу отдали бездушной программе, а она умерла с голоду?! Вы что хотите развалить страну?! </сарказм>

    • +1
      некоторые открытые данные — большого размера. api в этом случае удобнее: можно взять лишь нужный кусок данных и сэкономить время, вместо того, чтобы раз за разом качать гигабайты, особенно если выгрузка обновляется ежемесячно или ежедневно. примеры: исполнительные производства по юрлицам (ФССП, > 2 Гб), bus.gov.ru, zakupki.gov.ru и т.д.
      • 0

        То что удобно, никто не спорит, но когда у НИХ начнут отваливается сервера, когда они никого не предупредив начнут менять форматы и протокола API, когда они введут авторизацию для доступа к данным и когда введут плату за предоставление данных — вы будете стоять в той же очереди недовольных с требованием "дайте мне выгрузку, я сам все распарсю!"

    • 0

      Вы, как налогоплательщик, оплачиваете всяких "тёток"(ТМ), вбивающих данные руками в этот ёксель и перебивающий ещё в несколько мест, вот что вы оплачиваете — симуляцию работы, результатом которой нельзя пользоваться.

      • +1

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

    • 0

      Ремарка: в текущем политическом режиме, который поощряет воровство и коррупцию

  • +1
    Все познается в сравнение — в целом CSV хороший формат. Любые альтернативы для таблиц в рамках открытых данных хуже.
    • +1
      Да, проблема не в CSV, а в ошибках при его использовании. И по-моему проще поменять формат чем научить им пользоваться :-)
      • +3
        CSV хороший формат… Если вместо запятой использовать символ табуляции. А еще лучше, если все равно стандартизировать — воспользоваться изобретенными в незапамятные времена ASCII Group/Record/Unit separator.
        • 0

          Так в конечном счёте к DBF придём.

          • 0
            А еще дальше — к HDF5/netCDF.
            Но их же никто не осилит. А просто вставлять другие символы вместо запятой и перевода строки — научить можно. И большую часть проблем использования обычного CSV это решит.
        • 0

          Зачем использовать табуляцую вместо запятой? Есть же отличный стандарт на csv RFC4180, который явно говорит использовать кавычки для строк со спецсимволами. если бы он появился чуть раньше, у нас бы тогда не было того ужаса, что сейчас есть на каждой формочке, которая делает "import from csv".

          • 0
            Потому что то, когда генерируют «csv», результат систематически этому стандарту не соответствует.
            С табуляцией, или как я выше написал, с ASCII unit separator, вероятность наступить на грабли при самопальной генерации меньше.
        • 0

          Табуляция не воспринимается "на глаз". А вот какой-то спец-символ типо < DEL > или ^D, или даже тройных пайпов (|||) — точно не будут встречаться в тексте даже случайно.


          В конечном счете разделителем в csv может служить даже рандомный набор символов. Хоть [ { < RAZDELITEL > } ].


          Правда тут вопрос в том, что контролировать валидность данных всё равно не получится.

          • 0
            Ну вот же уже в третий раз пальцем тычу. ASCII сепараторы именно в качестве символов-сепараторов и придуманы. Они вообще в текст не вставляются ни случайно ни специально, т.к. непечатные и смысла для текста не имеют. Если нужно с бинарными данными работать — это уже другой случай.
      • +2

        Судя по всему, формат используется правильно, т.к. на сайте opendata можно посмотреть данные по ООО ГЕЛИОС", (вкладка просмотр данных)
        Проблема в скрипте, который выдает эти данные на выгрузку в csv. Вот там действительно эскейпинг забыли. Я им писал об этом 27 июня. По RFC эти кавычки надо экранировать дополнительный кавычкой (что и делает питерский data.gov.spb.ru/)

    • 0
      Я как-то на такую заметку набрел. В целом, csv — удобный и простой формат; с другими сложнее и неудобнее.
    • 0

      Верно, csv нужно уметь готовить, как и любой другой формат. Просто сменой формата не избежать проблемы незнания тонкостей формата. Вот, скажем, чего проще чем json, но и в нем много тонкостей: https://habrahabr.ru/company/mailru/blog/314014/

    • 0
      В США для геоданных предлагают сразу 3 формата: табличный, xml и json. я думаю это правильно.
  • 0
    А что, есть формат решающий проблему кавычек?
    Был бы xml или json, страдали бы от избыточности и корявых тегов. По моему CSV логичный выбор.
    • –4
      ODT или XLSX. Их почему-то называют «неправильными», но зато ошибки такого рода в них сключены
      • +1
        у публикаторов существует возможность размещения набора с конвертацией из *.xls/*.xlsx, что значительно решает проблему некорректных csv, если им пользуются, конечно
      • 0
        odt это xml зажатый зипом, также как и xlsx. Они тащут за собой еще больше проблем.

        * 2 спецификации которым нужно следовать (xml + формат)
        * избыточность данных из за тегов
        * дополнительная нагрузка на память и процессор из за операций упаковки\распаковки

        Научить обезьянку ставить 2 кавычки гораздо проще чем выдресировать следовать стандартам и синтаксису =)

        Итого: csv — норм выбор

        P.S. Проблема тут скорее в отсутствии конвертирующего api возвращающего данные в нужном формате. Хотя Вы о похожих вещах говорили в статье, по этому тут я с вами.
      • +1

        На прошлой работе я как раз делал возможность через админку формировать шаблон в xlsx и потом, после заполнения, загружать его обратно, валидировать по типам и количеству столбцов и формировать CSV автоматом. Ещё и RDFa выводили на страницах паспортов (у портала открытых данных есть валидатор разметки, кстати). Хорошо получилось. Однако, я вижу один из тех наборов в статье, а это значит, что что-то всё-равно пошло не так :trollface:


        Собственно, с конвертацией «CSV набора → шаблон в XLSX → человек → заполненный шаблон → новая версия набора открытых данных в CSV» заморочились именно после того, как стало совершенно очевидно, что если дать человеку править машиночитаемые наборы — будет плохо. Нельзя человека туда пускать, особенно (как в случае открытых данных) если это рядовой сотрудник какого-нибудь гос. ведомства с зарплатой ниже среднего и отсутствием какой-либо мотивации к работе (вообще не понимаю, чего они там сидят).


        В общем, только автоматизация и роботизация спасут открытые данные.

    • +1
      Логичный вывод RDF.
  • +1
    csv хорош еще тем, что его понимают все инструменты визуализации и аналитики (и веб-сервисы, и десктоп). с xml этого ожидать не приходится. максимум, что еще работает, — json (для неплоских таблиц, где csv уже не применишь)
  • +3
    Проблема форматов данных при публикации это наименьшая проблема в систему государственной и муниципальной власти. Главная — качество этих данных. Дело в том, что за качество данных в электронных хранилищах ни кто особо не несет. Может сейчас ситуация и начала немного меняться в таких учреждениях как ФНС и Роскадастр, но в остальных думаю все осталось по-прежнему. Дело в том, что правового регулирования оборота электронной информации у нас практически нет (законы об электронной подписи не в счет). Чиновники несут ответственность за информацию только на бумажных носителях. То есть если в базе данных и на бумаге, выданной каким то ведомством, есть разночтения, то главной информацией будет считаться та, что на бумаге. А сверять электронные архивы с бумажными ни кто особо не рвется. Ну так далее. то есть у нас электронная информация имеет крайне низкую юридическую значимость, а значит ее качество в база данных крайне низкое. Это по сути свалка вторичных отходов от производства главного продукта деятельности ведомств — бумажного документа. Это я по личному опыту сужу. Работал руководителем ИТ-подразделения в государственном учреждении.
  • 0
    У всех этих ресурсов одни и те же болезни. Вот они:

    • Отсутствие API для доступа к данным.


    Как минимум для data.gov.ru вроде как есть API:
    http://data.gov.ru/api-portala-otkrytyh-dannyh-rf-polnoe-rukovodstvo
    • 0
      Есть документация, а вот есть ли API? :-)
      Например там написано: «API находится в стадии разработки и поэтому методы могут быть изменены без предупреждения.» Можно ли пользоваться таким API?
      • +1
        API на data.gov.ru есть, но он умеет только отдавать тот же файл данных, который можно скачать руками. еще можно получить реестр всех наборов данных, которые лежат на Портале. кому интересно — ниже amgreen привел ссылку на методические рекомендации по публикации открытых данных, рекомендую взглянуть, это правда интересно. а вот сами данные, удобной выборкой в json, с data.gov.ru получить не удастся. в отличие, кстати, от сайта ГИБДД по статистике ДТП — там есть неплохой api, хотя и скрытый (спрятан под картограммой)
  • +4
    CSV — лучший выбор для дампов данных. Особенно tab-separated. Особенно записанный в файл не вручную, а используя какую-нибудь стандартную библиотеку. JSON раздут и страдает от некорректного форматирования куда сильнее (ибо фиг починишь).
    XLSX — полупроприетарный формат, для которого зачастую нет нормальных библиотек. К тому же, люди, поддерживающие xlsx-файлы склонны туда пихать жирные шрифты и подобную лабуду. Или записывать несколько листов. Или ещё хуже: несколько разных по набору полей таблиц — на один лист. Или неправильно указывать тип полей (числа в строковых полях), что вызывает проблемы у парсеров. Ничего хуже, чем xlsx придумать вообще невозможно.

    API иногда полезен, но он должен идти в дополнение к дампу, а не как замена. И зачастую дамп должен быть главным в этой паре, потому что по имеющемуся дампу API-шку можно хоть бы и самому сделать, а наоборот — не всегда. Да, поддержание данных в актуальном состоянии — неприятность, но далеко не такая большая, как попытка добыть данные из плохого API (а из API, который лёг — совсем беда). Пожелаете пример — напишите в личку.
    • 0
      Ничего хуже, чем xlsx придумать вообще невозможно.


      Да ладно. Как бы Вам понравился doc-файл, в который картинками вставлены сканы распечаток?
      • 0
        Месье знает толк…
  • 0

    Есть методические рекомендации по разработке открытых данных http://data.gov.ru/metodicheskie-rekomendacii-po-publikacii-otkrytyh-dannyh-versiya-30


    Есть разнарядка выгружать открытые данные с региональных сайтов на центральный data.gov.ru. На нем установлен валидатор как раз по методическим рекомендациям.

  • 0

    Да ладно CSV — ФИАС (уже стал забывать это название, вспоминают "что-то с провалом связано..., а! фиаско". парсить это чудо, выложенное в виде changelog'а было отдельное увлекательное занятие, не говоря об объёмах, по крайней мере лет 5+ назад.


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

    • 0
      @Pacos, а с вызрузкой ФИАС в открытые данные не работали? с xml. структура у него, вроде, в порядке, но разобраться непросто — адрес собирается практически из атомов )
      • 0

        Это было задолго до, я уже много лет как покинул то благодатное место, только подёргивание глазика при воспоминаниях осталось.
        Мы скачивали непосредственно с их сервера diff и периодически полный дамп (который представляет из себя полный лог изменений), был в xml архиве, который уже обрабатывали для заливки себе в базу (делал робот по расписанию). Отдельным бонусом было представление xml в виде одной строки — открыть по f3 в том же Far и посмотреть глазами было подобно пытке.

        • 0

          ФИАС не так уж плох. Просто смотреть в него не надо. Открыли архив с помощью libarchive (начиная с 3-й версии умеет смотреть внутрь RAR-архивов), скормили нужные файлы из него SAX-парсеру, вытащили интересующие данные, сохранили, архив закрыли, как страшный сон забыли.

          • +1

            Windows как платформа накладывает ограничение (в госструктурах в основном так), потому сначала распаковка, потом парсинг.
            А смотреть внутрь очень даже надо чтобы понять что там и почему не грузится (напоминаю что это был момент запуска ФИАСа и того сервиса, который может быть сейчас, не было). Скачал страничку, распарсил, посмотрел наличие новых diff'ов и время модификации основы, решил что качать, скачал, если diff — долил в базу, если полный — перезалил в базу (не только у меня было впечатление что diff меньше, чем разница между полными).
            А ФИАС (и КЛАДР) плох хотя бы отсутствием районов внутри города.

  • 0
    заголовок некорректный. Можно подумать что открытые данные не нужны вообще и везде.
    уточните, заголовок —
    Почему открытые данные
    от государственных источников в Российской федерации
    никому не нужны
    , кроме как самим государственным источникам, для их автоматической обработки.

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