Датасеты. Автомобили для госзакупок

Пока я работаю над общим списком массивов данных, выкладываю тут датасет с переченем легковых автомобилей ранее опубликованный МинПромТоргом в приказе N78 от 20 февраля 2009 года. Там фигурирует вордовый документ, который тут присутствует в преобразованном в CSV виде. 

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

Скачать: minprom_cars

Пример этого справочника — это, на самом деле, один из наименее удобных, но простых форматов для обработки, которая включает:

1. Извлечение данных из .DOC файла в файл Excel 

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

3. Подготовку скрипта очистки данных — для тех случаев когда названия разбились по ячейкам.

4. Прогон скрипта и последующую быструю визуальную проверку результата. 

Итого у меня это заняло примерно 30 минут времени — поскольку задача простенькая и я не спешил. При наличии алгоритма(-ов) которые бы решали задачу понимания основных способов визуализации данных — это было бы ещё быстрее. Фактически шаги с 1 по 3 могут быть ускорены и убраны. 

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

1. Сбор и систематизация структуры массивов данных.

2. Извлечение табличной и «псевдотабличной» информации «как есть» с последующим хранением в постоянном хранилище.

3. Извлечение и обогащение массивов информации — анализом текстовых полей, простановкой кросс-ссылок, распознаванием типов колонок

4.  Раскрытие данных в форме API и адаптируемого к структуре данных визуального интерфейса.

Причём пункты с 1 по 4 повторяются в цикле, главное тут чтобы рещения принимаемые на каждом из уровней обработки и визуализации могли эволюционировать. Говоря иначе, массив данных может быть обогащён не полностью, но эталонная запись должна быть зафиксирована и помечена как обработанная/необработанная. И так далее.

Всё это описание решения как если бы создавать единый реестр реестров без организационных процедур — только техническими методами. Разумеется, он утопичен из-за своих потенциальных объёмов. Безавтоматизированного выявления типовых шаблонов кодирования данных — объём работы будет огромен, но с алгоритмами выявления задача интересная, как научно, так и практически. 

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

В задачах же общего рода такие решения не проходят. Тут возникает совершенно иная потребность как в хранении, так и в обработке и мониторинге, и в визуализации данных. Итого задача сравнима  с «превращением веб сайтов в базы данных» или придание им набора API для извлечения информации вроде Скиура который был одним из примеров — преобразование новостей в RSS.

About This Author

Яндекс.Метрика