Pull to refresh

Comments 57

С просьбой разъяснить наличие стандартов на эти самые данные, да.
UFO just landed and posted this here

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

Я им отправлял уже три недели назад про экскейпинг (я не автор этого поста). Судя по всему, в 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"


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

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

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

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

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

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

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

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

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

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




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

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

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

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

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

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

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

Все познается в сравнение — в целом CSV хороший формат. Любые альтернативы для таблиц в рамках открытых данных хуже.
Да, проблема не в CSV, а в ошибках при его использовании. И по-моему проще поменять формат чем научить им пользоваться :-)
CSV хороший формат… Если вместо запятой использовать символ табуляции. А еще лучше, если все равно стандартизировать — воспользоваться изобретенными в незапамятные времена ASCII Group/Record/Unit separator.
UFO just landed and posted this here
А еще дальше — к HDF5/netCDF.
Но их же никто не осилит. А просто вставлять другие символы вместо запятой и перевода строки — научить можно. И большую часть проблем использования обычного CSV это решит.

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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


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


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

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

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


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

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


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

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


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

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


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

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

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

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

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

Articles