В процессе работы над проектом для открытых данных пришлось изучить множество государственных источников данных. Это и федеральные порталы и муниципальные ресурсы. Вот наиболее известные источники открытых данных:
У всех этих ресурсов одни и те же болезни. Вот они:
- Невалидность данных.
- Разрозненность данных и отсутствие стандартов.
- Отсутствие единого механизма поиска.
- Отсутствие 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" }
]Ко всему прочему данные разбросаны по разным ресурсам:
- https://www.magnitogorsk.ru/opendata — Магнитогорск
- http://opendata.cheladmin.ru — Челябинск
- https://minvr.ru/opendata — Владивосток
- http://data.ekburg.ru — Екатеринбург
Как узнать что это официальные сайты? И почему бы не публиковать данные в одном месте?
Отсутствие единого механизма поиска
Из-за разрозненности данных, нет возможности осуществить поиск по всем государственным источникам открытых данных. Видимо не хватает национального поисковика по открытым данным…
Отсутствие API для доступа к данным
Чтобы использовать данные в своем проекте их нужно скачать. И в дальнейшем самому отслеживать их изменение и актуализировать. Это сопряжено со значительными сложностями для больших наборов данных.
Избежать этих сложностей можно если не скачивать данные, а использовать их через API. Для этого API должен предоставлять такую функциональность, которой было бы достаточно для выполнения любой задачи по работе с данными.
Того API который есть у некоторых ресурсов (например data.mos.ru) не достаточно для полноценной работы с данными. Плюс они не достаточно надежы для использования в реальных проектах.
Все это приводит к тому что открытые данные есть, но судя по количеству скачиваний на data.gov.ru ими пользуются единицы.
Чтобы раскрыть весь потенциал открытых данных они должны быть доступны в максимально удобном для использования виде. Чтобы сразу начать ими пользоваться, а не тратить время на приведение их к корректному виду.
Как можно исправить ситуацию
ИМХО, ресурс аналогичный GitHub но для данных дал бы сильный толчок в развитии открытым данным.
Да, есть например data.world, но он пока не имеет всей той функциональности которая сделала бы его GitHub'ом для данных. Какими характеристиками должен обладать ресурс:
- Визуализация — возможность визуализировать данные так как хочет автор и пользователи, а не так как это сделает система.
- Стандартизованность — возможность задать структуру данных, отклонение от которой выдаст ошибку и не позволит загрузить данные.
- API и интеграция — богатый API и возможность интеграции с различными источниками данных.
- Социальность — обсуждение, оценка и рецензирование данных сообществом.
- Международность — данные не должны размещаться на серверах в какой-то одной стране, чтобы избежать их блокирования со стороны государства.
Уверен что в скором времени такой ресурс появится и открытые данные займут значимое место в жизни каждого человека.
Crankoman
Петиция? Письмо в курирующий орган?
vilgeforce
С просьбой разъяснить наличие стандартов на эти самые данные, да.
zharikovpro
Замечтался и прочитал вторую часть как «в конкурирующий орган».
trdm
Для начала проект на github.com с замечаниями, предложениями по функционалу и стандартизации, который надеюсь выродится в технический регламентный документ, потом он преобразуется в петицию + открытое письмо президенту.
Думаю разработчики порталов и сами слабо представляют зачем они делают этот портал, по этому у них так кривовато и нерешительно идет разработка.
У представителей местной аудитории наверняка найдутся задачи, которые они могут решить с помощью данных с этих порталов.
aulitin
Я им отправлял уже три недели назад про экскейпинг (я не автор этого поста). Судя по всему, в 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 такие неоднозначности должны устранятся:
Цитата:
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"
romxx
Это довольно иронично выглядит, когда жалоба на ошибки в данных сама содержит ошибки и опечатки практически в каждой строке.
x893
Даже если в этом посте присутствуют ошибки, что говорить о данных.
Данные есть? Есть. Птичку поставили перед руководством, премию получили.
То что ими не пользуются — не дело СОЗДАТЕЛЕЙ.
pavelpromin
Эммм… Как бы так сказать, чтоб не забанили… Плохие открытые данные, это не самая острая проблема этой страны. ФГУПы, прокуратура, СК, суды,- всем пое.ать на прямое нарушение федеральных законов, а вы про неудобность формата…
r66qq3Ek
Одна из самых больших логических ошибок — думать, что от нерешения маленьких проблем вдруг сами собой начнут решаться большие. Более того, тем, кто не способен правильно выгрузить данные на сервер, я бы проблемы федеральных законов не доверил решать в принципе.
pavelpromin
Правовое регулирование и правоприменение действует по нисходящей (рыба гниёт с головы). То что в одном муниципалитете четкий программист сделал четкие скрипты и его данные валидны — ничто, когда все доходит до регионального или федерального уровня. Ибо кто в лес, кто по дрова.
pavelpromin
Я против предоставления доступа к API открытых данных. Ибо я как налогоплательщик не заинтересован в оплате доп. серверов и доп.структур которые будут этот доступ осуществлять. Главное чтобы выгрузки были регулярными и в удобном формате.
fiftin
Выгрузки все равно лежат на серверах которые требуют денег на содержание, так почему бы КПД не поднять)
rPman
разный порядок затрат, на статику и на динамически генерируемый контент
Vjatcheslav3345
Лучше так — на API принимается обязательный ГОСТ и эти данные больше никакие исполнители не готовят руками — потому что этим теперь занимаются автоматизированные рабочие места персонала и ERP-системы госорганов, которые обновляются централизованно в масштабах государства, в соответствии с текущим законодательством и независимо от хотелок местных начальничков. "Гитхаб для данных", под эгидой Росстата, нужен теперь как большой архив, связанный с ERP через API и необходимый на тот случай, если что то грохнется, нужно будет проследить исторические ряды и т. д.
pavelpromin
А как тогда припиской заниматься?! Если статистика будет отражать реальную действительность этож скока голов госслужащих полетят.
Эта инициатива не дойдет и до первого чтения.
mickvav
На статику, генерируемую девочкой в excel-e ежедневно и на динамику, отдаваемую из закешированного запроса к базе? База обгонит девочку на первой зарплате по операционным расходам и окупится за пару лет с учетом разработки.
Vjatcheslav3345
Обычно этим занимается не "одна человека" а куча народа во всех госорганах всех субъектов и на всех уровнях, а нужно, чтобы занимался простейший скрипт — который ложил бы свежие данные из локальной базы в централизованное хранилище а другой, который в хранилище* — готовит из цифр
кошекнужную расчётную статистику. При этом персонал занимается работой с людьми, а не с цифрами и не вникает в проблемы их предоставления, хранения, обновления образов своих АРМ и т. д. а закончив рабочий день — спокойно идёт домой: только вопросы правильного внесения данных в формы рабочих программ — остаются отчасти в их ведоме.P. S. *Было бы интересно, если бы бизнес и жители страны могли бы государству заказывать/голосовать за разработку нужным им скриптов и фильтров, вычислительных программ статистических методик, которые добавлялись бы в такие централизованные хранилища данных для всеобщего использования.
Например, планировать бизнес-планы стало бы гораздо проще, с их помощью.
pavelpromin
Вы подходите к вопросу как пролетарий, ну или просто прогматичный человек не наделённый властью и бюджетами. Не так давно был в населенном пункте с численностью где-то человек 100. Библиотекарь в фонде которого 5 полок с книгами получает зарплату 30 тысячи рублей. Вы что хотите чтобы ее работу отдали бездушной программе, а она умерла с голоду?! Вы что хотите развалить страну?! </сарказм>
nike32
некоторые открытые данные — большого размера. api в этом случае удобнее: можно взять лишь нужный кусок данных и сэкономить время, вместо того, чтобы раз за разом качать гигабайты, особенно если выгрузка обновляется ежемесячно или ежедневно. примеры: исполнительные производства по юрлицам (ФССП, > 2 Гб), bus.gov.ru, zakupki.gov.ru и т.д.
pavelpromin
То что удобно, никто не спорит, но когда у НИХ начнут отваливается сервера, когда они никого не предупредив начнут менять форматы и протокола API, когда они введут авторизацию для доступа к данным и когда введут плату за предоставление данных — вы будете стоять в той же очереди недовольных с требованием "дайте мне выгрузку, я сам все распарсю!"
Pakos
Вы, как налогоплательщик, оплачиваете всяких "тёток"(ТМ), вбивающих данные руками в этот ёксель и перебивающий ещё в несколько мест, вот что вы оплачиваете — симуляцию работы, результатом которой нельзя пользоваться.
pavelpromin
Ага. И я не хочу, чтобы завтра выскачило очередное ведомство с инициативой, а давайте мы api запилим за миллиардов рублей. Деньги как всегда разворуют, никого не посадят, а при свернут.
И да, я как и все разумные человека хочу чтобы был удобный доступ к государственным и муниципальным данным (правовые документы, статистика, аналитика), но сейчас это ппц как дорого выходит для обычного гражданина. Из недавних примеров поисковик Спутник
pavelpromin
Ремарка: в текущем политическом режиме, который поощряет воровство и коррупцию
sibnick
Все познается в сравнение — в целом CSV хороший формат. Любые альтернативы для таблиц в рамках открытых данных хуже.
fiftin
Да, проблема не в CSV, а в ошибках при его использовании. И по-моему проще поменять формат чем научить им пользоваться :-)
inkelyad
CSV хороший формат… Если вместо запятой использовать символ табуляции. А еще лучше, если все равно стандартизировать — воспользоваться изобретенными в незапамятные времена ASCII Group/Record/Unit separator.
staticlab
Так в конечном счёте к DBF придём.
inkelyad
А еще дальше — к HDF5/netCDF.
Но их же никто не осилит. А просто вставлять другие символы вместо запятой и перевода строки — научить можно. И большую часть проблем использования обычного CSV это решит.
aulitin
Зачем использовать табуляцую вместо запятой? Есть же отличный стандарт на csv RFC4180, который явно говорит использовать кавычки для строк со спецсимволами. если бы он появился чуть раньше, у нас бы тогда не было того ужаса, что сейчас есть на каждой формочке, которая делает "import from csv".
inkelyad
Потому что то, когда генерируют «csv», результат систематически этому стандарту не соответствует.
С табуляцией, или как я выше написал, с ASCII unit separator, вероятность наступить на грабли при самопальной генерации меньше.
Crystal_HMR
Табуляция не воспринимается "на глаз". А вот какой-то спец-символ типо < DEL > или ^D, или даже тройных пайпов (|||) — точно не будут встречаться в тексте даже случайно.
В конечном счете разделителем в csv может служить даже рандомный набор символов. Хоть [ { < RAZDELITEL > } ].
Правда тут вопрос в том, что контролировать валидность данных всё равно не получится.
inkelyad
Ну вот же уже в третий раз пальцем тычу. ASCII сепараторы именно в качестве символов-сепараторов и придуманы. Они вообще в текст не вставляются ни случайно ни специально, т.к. непечатные и смысла для текста не имеют. Если нужно с бинарными данными работать — это уже другой случай.
aulitin
Судя по всему, формат используется правильно, т.к. на сайте opendata можно посмотреть данные по
ООО ГЕЛИОС",(вкладка просмотр данных)Проблема в скрипте, который выдает эти данные на выгрузку в csv. Вот там действительно эскейпинг забыли. Я им писал об этом 27 июня. По RFC эти кавычки надо экранировать дополнительный кавычкой (что и делает питерский data.gov.spb.ru/)
kxx
Я как-то на такую заметку набрел. В целом, csv — удобный и простой формат; с другими сложнее и неудобнее.
questor
Верно, csv нужно уметь готовить, как и любой другой формат. Просто сменой формата не избежать проблемы незнания тонкостей формата. Вот, скажем, чего проще чем json, но и в нем много тонкостей: https://habrahabr.ru/company/mailru/blog/314014/
BalinTomsk
В США для геоданных предлагают сразу 3 формата: табличный, xml и json. я думаю это правильно.
MrGobus
А что, есть формат решающий проблему кавычек?
Был бы xml или json, страдали бы от избыточности и корявых тегов. По моему CSV логичный выбор.
fiftin
ODT или XLSX. Их почему-то называют «неправильными», но зато ошибки такого рода в них сключены
parfentyevmikhail
у публикаторов существует возможность размещения набора с конвертацией из *.xls/*.xlsx, что значительно решает проблему некорректных csv, если им пользуются, конечно
MrGobus
odt это xml зажатый зипом, также как и xlsx. Они тащут за собой еще больше проблем.
* 2 спецификации которым нужно следовать (xml + формат)
* избыточность данных из за тегов
* дополнительная нагрузка на память и процессор из за операций упаковки\распаковки
Научить обезьянку ставить 2 кавычки гораздо проще чем выдресировать следовать стандартам и синтаксису =)
Итого: csv — норм выбор
P.S. Проблема тут скорее в отсутствии конвертирующего api возвращающего данные в нужном формате. Хотя Вы о похожих вещах говорили в статье, по этому тут я с вами.
Envek
На прошлой работе я как раз делал возможность через админку формировать шаблон в xlsx и потом, после заполнения, загружать его обратно, валидировать по типам и количеству столбцов и формировать CSV автоматом. Ещё и RDFa выводили на страницах паспортов (у портала открытых данных есть валидатор разметки, кстати). Хорошо получилось. Однако, я вижу один из тех наборов в статье, а это значит, что что-то всё-равно пошло не так :trollface:
Собственно, с конвертацией «CSV набора > шаблон в XLSX > человек > заполненный шаблон > новая версия набора открытых данных в CSV» заморочились именно после того, как стало совершенно очевидно, что если дать человеку править машиночитаемые наборы — будет плохо. Нельзя человека туда пускать, особенно (как в случае открытых данных) если это рядовой сотрудник какого-нибудь гос. ведомства с зарплатой ниже среднего и отсутствием какой-либо мотивации к работе (вообще не понимаю, чего они там сидят).
В общем, только автоматизация и роботизация спасут открытые данные.
potan
Логичный вывод RDF.
nike32
csv хорош еще тем, что его понимают все инструменты визуализации и аналитики (и веб-сервисы, и десктоп). с xml этого ожидать не приходится. максимум, что еще работает, — json (для неплоских таблиц, где csv уже не применишь)
e_v_medvedev
Проблема форматов данных при публикации это наименьшая проблема в систему государственной и муниципальной власти. Главная — качество этих данных. Дело в том, что за качество данных в электронных хранилищах ни кто особо не несет. Может сейчас ситуация и начала немного меняться в таких учреждениях как ФНС и Роскадастр, но в остальных думаю все осталось по-прежнему. Дело в том, что правового регулирования оборота электронной информации у нас практически нет (законы об электронной подписи не в счет). Чиновники несут ответственность за информацию только на бумажных носителях. То есть если в базе данных и на бумаге, выданной каким то ведомством, есть разночтения, то главной информацией будет считаться та, что на бумаге. А сверять электронные архивы с бумажными ни кто особо не рвется. Ну так далее. то есть у нас электронная информация имеет крайне низкую юридическую значимость, а значит ее качество в база данных крайне низкое. Это по сути свалка вторичных отходов от производства главного продукта деятельности ведомств — бумажного документа. Это я по личному опыту сужу. Работал руководителем ИТ-подразделения в государственном учреждении.
Adgh
Как минимум для data.gov.ru вроде как есть API:
http://data.gov.ru/api-portala-otkrytyh-dannyh-rf-polnoe-rukovodstvo
fiftin
Есть документация, а вот есть ли API? :-)
Например там написано: «API находится в стадии разработки и поэтому методы могут быть изменены без предупреждения.» Можно ли пользоваться таким API?
nike32
API на data.gov.ru есть, но он умеет только отдавать тот же файл данных, который можно скачать руками. еще можно получить реестр всех наборов данных, которые лежат на Портале. кому интересно — ниже amgreen привел ссылку на методические рекомендации по публикации открытых данных, рекомендую взглянуть, это правда интересно. а вот сами данные, удобной выборкой в json, с data.gov.ru получить не удастся. в отличие, кстати, от сайта ГИБДД по статистике ДТП — там есть неплохой api, хотя и скрытый (спрятан под картограммой)
prijutme4ty
CSV — лучший выбор для дампов данных. Особенно tab-separated. Особенно записанный в файл не вручную, а используя какую-нибудь стандартную библиотеку. JSON раздут и страдает от некорректного форматирования куда сильнее (ибо фиг починишь).
XLSX — полупроприетарный формат, для которого зачастую нет нормальных библиотек. К тому же, люди, поддерживающие xlsx-файлы склонны туда пихать жирные шрифты и подобную лабуду. Или записывать несколько листов. Или ещё хуже: несколько разных по набору полей таблиц — на один лист. Или неправильно указывать тип полей (числа в строковых полях), что вызывает проблемы у парсеров. Ничего хуже, чем xlsx придумать вообще невозможно.
API иногда полезен, но он должен идти в дополнение к дампу, а не как замена. И зачастую дамп должен быть главным в этой паре, потому что по имеющемуся дампу API-шку можно хоть бы и самому сделать, а наоборот — не всегда. Да, поддержание данных в актуальном состоянии — неприятность, но далеко не такая большая, как попытка добыть данные из плохого API (а из API, который лёг — совсем беда). Пожелаете пример — напишите в личку.
torbasow
Да ладно. Как бы Вам понравился doc-файл, в который картинками вставлены сканы распечаток?
prijutme4ty
Месье знает толк…
amgreen
Есть методические рекомендации по разработке открытых данных http://data.gov.ru/metodicheskie-rekomendacii-po-publikacii-otkrytyh-dannyh-versiya-30
Есть разнарядка выгружать открытые данные с региональных сайтов на центральный data.gov.ru. На нем установлен валидатор как раз по методическим рекомендациям.
Pakos
Да ладно CSV — ФИАС (уже стал забывать это название, вспоминают "что-то с провалом связано..., а! фиаско". парсить это чудо, выложенное в виде changelog'а было отдельное увлекательное занятие, не говоря об объёмах, по крайней мере лет 5+ назад.
Отдельно доставляет фраза в поисковике "Возможно, этот сайт был взломан.
Федеральная информационная адресная система (ФИАС) содержит достоверную единообразную" (хотел посмотреть когда оно запустилось для уточнения когда использовал).
nike32
@Pacos, а с вызрузкой ФИАС в открытые данные не работали? с xml. структура у него, вроде, в порядке, но разобраться непросто — адрес собирается практически из атомов )
Pakos
Это было задолго до, я уже много лет как покинул то благодатное место, только подёргивание глазика при воспоминаниях осталось.
Мы скачивали непосредственно с их сервера diff и периодически полный дамп (который представляет из себя полный лог изменений), был в xml архиве, который уже обрабатывали для заливки себе в базу (делал робот по расписанию). Отдельным бонусом было представление xml в виде одной строки — открыть по f3 в том же Far и посмотреть глазами было подобно пытке.
Envek
ФИАС не так уж плох. Просто смотреть в него не надо. Открыли архив с помощью libarchive (начиная с 3-й версии умеет смотреть внутрь RAR-архивов), скормили нужные файлы из него SAX-парсеру, вытащили интересующие данные, сохранили, архив закрыли, как страшный сон забыли.
Pakos
Windows как платформа накладывает ограничение (в госструктурах в основном так), потому сначала распаковка, потом парсинг.
А смотреть внутрь очень даже надо чтобы понять что там и почему не грузится (напоминаю что это был момент запуска ФИАСа и того сервиса, который может быть сейчас, не было). Скачал страничку, распарсил, посмотрел наличие новых diff'ов и время модификации основы, решил что качать, скачал, если diff — долил в базу, если полный — перезалил в базу (не только у меня было впечатление что diff меньше, чем разница между полными).
А ФИАС (и КЛАДР) плох хотя бы отсутствием районов внутри города.
Vlad_fox
заголовок некорректный. Можно подумать что открытые данные не нужны вообще и везде.
от государственных источников в Российской федерации , кроме как самим государственным источникам, для их автоматической обработки.уточните, заголовок —