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

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

Краткий ответ: считать нужно не карточки, а пригодные связи

Количество наборов ничего не говорит об их пригодности, поскольку одна запись в каталоге может скрывать несколько очень разных ресурсов. В транспортном наборе, например, одновременно могут быть рабочий архив GTFS, отдельный CSV с маршрутами и ссылка на файл, возвращающий ошибку. Формально это один набор. Для пользователя это три разные ситуации: данными можно пользоваться, данные нужно соединить, один из дублирующих путей сломан.

Есть и обратная ошибка: неудобный интерфейс не означает отсутствия данных. Два финансовых ресурса не отдали архив простому клиенту, но загрузились с корректными браузерными HTTP-заголовками. Внутри оказались тысячи XML-файлов по кварталам. Поэтому технический сбой одного способа доступа нельзя называть сокрытием, а успешное открытие страницы — доказательством полноты.

В нашей выборке 10 наборов можно анализировать для заявленных практических вопросов, 8 требуют очистки или обходного пути, а 2 не дают оснований для городского вывода. Это не рейтинг распорядителей и не оценка всего каталога. Это журнал конкретных проверок конкретных ресурсов.

Как сформирована выборка и что означают семь критериев

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

Для каждого набора открывали страницу Портала данных Киева, загружали паспорт и машиночитаемую структуру, а затем обращались к каждому ключевому файлу или API. На национальном портале проверяли наличие киевских копий, но не складывали их с городскими ресурсами как два независимых источника. Официальные рекомендации Минцифры использовали как эталон словаря: название поля, человекочитаемый заголовок, описание, тип данных и признак обязательности.

Оценка по каждому критерию имеет три уровня: 0 — критический пробел, 1 — частично пригодно или нужна ручная проверка, 2 — условие выполнено. Максимум — 14 баллов. Сумма помогает сравнивать наборы, но не отменяет здравого смысла: полностью пустая ключевая колонка может отправить набор на очистку даже при высоком итоге.

1. Машиночитаемость. Два балла — файл или endpoint открывается и парсится; один — работает только запасной ресурс или нужны нетипичные заголовки; ноль — табличные данные получить не удалось.
2. Полнота. Проверяли не абстрактное количество колонок, а поля, необходимые для вопроса: название, ключ, период, статус, сумму, адрес или другой существенный признак.
3. Фактическое обновление. Сравнивали заявленную частоту с датами ресурсов, периодами в файлах и временными метками записей. Обновлённая карточка не приравнивалась к обновлённым значениям.
4. Геокодирование. Для пространственных наборов искали координаты или геометрию и считали пропуски. Для финансовых и реестровых таблиц, где карта не нужна для основного вопроса, отсутствие координат не штрафовали.
5. Устойчивые идентификаторы. Проверяли наличие ключа, его заполнение и уникальность в пределах логической сущности. Повтор ключа мог быть нормальным для истории измерений, но требовал составного ключа со временем.
6. Словарь полей. Два балла получал набор с описанными колонками, типами и обязательностью; один — частичный словарь или расхождение с файлом; ноль — вместо схемы стояло тире или описание было только прозаическим текстом.
7. Лицензия и описание доступа. Все двадцать паспортов содержали лицензионное условие. Второй балл зависел от того, достаточно ли объяснены ресурс, параметры API или статический способ загрузки для повторения.

Такой scorecard удобно вести в обычной контрольной книге: одна строка на набор, отдельные колонки для баллов, пропусков и последствия. Для читателя, который хочет увереннее сортировать, соединять и проверять большие таблицы, уместным следующим шагом может быть курс Microsoft Excel для анализа данных. Он помогает освоить работу с таблицами, формулами, фильтрами и диаграммами, но не заменяет документацию городского API.

Контрольная таблица хранит не только баллы. В ней есть идентификатор страницы, названия проверенных ресурсов, ожидаемые поля, фактическое количество строк и колонок, доля пустых значений, техническая ошибка и её последствие. Именно эта детализация делает подсчёт воспроизводимым.

Лабораторный журнал: двадцать карточек без приукрашивания результата

1. Остановки городского транспорта

Ожидали: идентификатор, название, адрес, широту, долготу и признак доступности. Получили: JSON на 2991 запись с 22 полями; координаты заполнены, uid уникален. Пропуск: GeoJSON endpoint вернул серверную ошибку, а словаря основного JSON нет; заявленную частоту «более одного раза в день» файл не подтверждает. Последствие: точки можно анализировать из загруженного JSON, но автоматизацию на GeoJSON следует заменить, а оперативность не предполагать.

2. Расписание движения

Ожидали: основные таблицы GTFS — перевозчиков, маршруты, остановки, рейсы, время прибытия, календарь и геометрию. Получили: рабочий архив с девятью таблицами: 161 маршрут, 1492 остановки, 24 275 рейсов и 104 134 записи времени остановок; отдельный CSV содержит 102 маршрута, а его три версии имеют одинаковые заголовки. Пропуск: отдельный agency.csv вернул 404, хотя agency.txt есть в GTFS. Последствие: базовое расписание можно воспроизвести; битый дублирующий файл не блокирует анализ.

3. Парковочные площадки

Ожидали: площадку, оператора, вместимость, тариф, геометрию и стабильный ключ. Получили: 1181 GeoJSON-объект, у каждого есть геометрия, globalid и objectid уникальны; отдельный CSV описывает оператора. Пропуск: для основного GeoJSON нет словаря, а часть ценовых и контактных атрибутов пустая. Последствие: расположение и вместимость анализируются, второстепенные поля требуют сверки с описанием страницы.

4. Финансовая отчётность коммунального сектора

Ожидали: код предприятия, отчётный период, форму баланса и показатели. Получили: ZIP из 21 335 XML-файлов с 2020 года до последнего доступного квартала; код предприятия и период зашиты в названии файла. Пропуск: простой клиент получал 403, браузерный запрос загрузил архив; словаря XML-элементов нет. Последствие: динамику можно считать после распаковки и нормализации, но единицы и теги нужно проверить вручную.

5. Отчёты о выполнении финансовых планов

Ожидали: код предприятия, квартал, плановые и фактические показатели. Получили: 4643 XML-файла с 2023 года до последнего доступного квартала. Пропуск: повторяется барьер с 403 для простого клиента и отсутствует словарь элементов. Последствие: периоды сравнить можно, но без документированной семантики автоматическое толкование каждого тега рискованно.

6. Целевые местные программы

Ожидали: программу, распорядителя, правовой акт, изменения, отчёты, период и ссылку на документ. Получили: 41 программу, 112 изменений и 30 отчётов; заголовки соответствуют словарям, обязательные поля заполнены. Пропуск: один URL отчёта пустой, а полная история версий есть только для таблицы отчётов. Последствие: три ресурса надёжно соединяются идентификаторами; можно проверить, к каким программам прикреплены отчёты.

7. Общественные туалеты

Ожидали: тип, адрес, координаты, график, платность и доступность. Получили: CSV на 38 объектов с полными координатами и уникальным uid. Пропуск: GeoJSON endpoint вернул 500; тип пустой примерно в каждой двадцатой строке, а поля доступности заполнены неравномерно. Последствие: карту из CSV построить можно, сравнение условий для маломобильных людей будет неполным.

8. Коммунальные контейнеры

Ожидали: тип, вид отходов, количество, балансодержателя, график, адрес и координаты. Получили: 6776 строк, 33 колонки, уникальный uid и восемь сохранённых версий. Пропуск: type, balanceHolderId и balanceHolderName пусты полностью, координат нет в 0,72% строк. Последствие: количество и размещение поддаются обработке, но ответить, к какому типу относится объект и кто за него отвечает, из этого файла нельзя.

9. Зелёные насаждения, подлежащие удалению

Ожидали: акт, дату, адрес, координаты, вид, состояние, количество и причину. Получили: 34 538 строк, 33 колонки и семь версий с устойчивой структурой. Пропуск: lat и lon пусты полностью, в 12,11% строк нет названия улицы, uid повторяется в части записей. Последствие: итог по видам или актам возможен, пространственный вывод требует отдельного геокодирования и составного ключа.

10. ОСМД и ЖСК

Ожидали: код ЕГРПОУ, название, адрес, руководителя, контакты, координаты и дату создания. Получили: 2925 строк и 22 фактические колонки; координаты есть в 92,03% строк. Пропуск: словарь описывает 23 поля, но contactPointTelephone в файле нет; entityId не уникален в 11,04% записей. Последствие: перечень пригоден для поиска, но подсчёт организаций и домов требует дедупликации.

11. Обслуживание жилищного фонда

Ожидали: адрес дома, координаты, providerId, название и контакты обслуживающей организации. Получили: 8299 адресов и 10 поставщиков, между таблицами есть ключ providerId. Пропуск: 12,6% адресов не имеют координат; один заголовок содержит неразрывный пробел и формально не совпадает со словарём; истории версий нет. Последствие: зону обслуживания можно воспроизвести после нормализации заголовка и геокодирования пропусков.

12. Оценка качества воздуха

Ожидали: станцию, координаты, время, концентрации загрязнителей, радиацию и статус. Получили: исторический JSON на 72 202 измерения с полными координатами и показателями; отдельный API вернул семь станций и имел ссылку на Swagger. Пропуск: временные метки live-ответа отстают от публикации набора, хотя заявлено многократное ежедневное обновление; словаря нет. Последствие: исторические ряды исследовать можно, называть API текущим состоянием воздуха без проверки свежести — нет.

13. Разрешения на выбросы

Ожидали: разрешение, субъекта, адрес источника, координаты, срок действия и документы. Получили: 273 записи, 44 колонки по словарю и уникальный uid. Пропуск: lat, lon и addressThoroughfare пусты полностью; многие колонки документов также не заполнены. Последствие: реестровый подсчёт возможен, пространственная картина источников выбросов — нет.

14. Муниципальные пляжи

Ожидали: идентификатор, название, статус, инфраструктуру и геометрию. Получили: 15 GeoJSON-объектов с геометрией, уникальными globalid и objectid. Пропуск: словаря нет, для 20% объектов пусты отдельные контактные или временные атрибуты, версии не сохраняются. Последствие: расположение и базовую инфраструктуру сравнивать можно, редкие атрибуты — только с осторожным толкованием.

15. Учреждения культуры

Ожидали: uid, тип, название, адрес, контакты, часы работы, координаты и услуги. Получили: 286 строк, 30 колонок по словарю, уникальный uid и полные координаты. Пропуск: institutionId пуст в 53,85% записей, хотя отдельный uid заполнен; необязательные сервисные URL есть не везде. Последствие: учреждения можно считать и распределять по районам, но универсальным ключом должен быть uid, не institutionId.

16. Учреждения дошкольного образования

Ожидали: полный перечень учреждений с ключом, названием, типом, адресом, координатами, контактами и группами. Получили: endpoint вернул только четыре учреждения; координаты есть во вложенном contacts. Пропуск: структурированный address пуст, данные дублируются в другом блоке, документации параметров и словаря нет. Последствие: четыре записи не являются основанием для вывода о городской сети.

17. Очередь детей в детсады

Ожидали: очереди по всем учреждениям и периодам, номер, дату, возраст, льготу, учреждение и статус. Получили: 29 полных записей для одного жёстко заданного kindergartenid. Пропуск: нет справочника идентификаторов учреждений и документации API; один пример не формирует городскую совокупность, а сочетания года рождения с возрастной группой требуют объяснения. Последствие: общую длину и динамику очереди определить невозможно.

18. Учреждения профессионального образования

Ожидали: uid, id, название, тип, адрес, контакты, профиль, дуальное образование и общежитие. Получили: 18 учреждений, 25 колонок по словарю, уникальные uid и id, заполненные обязательные поля. Пропуск: отдельных lat и lon нет, хотя структурированный адрес есть; истории версий тоже нет. Последствие: профили и характеристики сравниваются без дополнительной работы, для карты адреса нужно геокодировать.

19. Обращения в контактный центр

Ожидали: идентификатор, время, тип, категорию, содержание, адрес, исполнителя, статус и результат. Получили: параметризованный JSON API отдаёт данные по году и месяцу; контрольный месяц содержал 71 227 записей и 21 поле, Id уникален. Пропуск: словарь и ответ расходятся на одном адресном поле, в ответе добавлен Id, 18,11% названий улиц пусты, координат нет. Последствие: темы, исполнители и сроки анализируются, пространственный разрез требует очистки адресов.

20. Электронные петиции

Ожидали: петицию, uid, тему, статус, дату, количество голосов, ответ и голосование. Получили: 2706 петиций с 15 полями и уникальным uid; ZIP голосований доступен, имеет две версии и весит около 255 МБ. Пропуск: словаря нет, большой архив является практическим барьером, а answerText пуст в 92,46% всех записей. Последствие: темы и статусы анализируются; наличие ответа следует оценивать только среди завершённых петиций, архив загружать потоково.

Пять провалов: что действительно нашлось, а что нет

PDF вместо таблицы: ноль случаев в выборке

Официальные советы прямо предостерегают от сканированных PDF и JPEG как замены структурированных данных. В двадцати отобранных наборах этот дефект не выявлен: ключевые ресурсы были CSV, JSON, GeoJSON, XML или ZIP с такими файлами. Ноль — важный результат, но не разрешение обобщать его на весь каталог. Мы проверяли общественно важную выборку, а не каждую карточку портала.

Неустойчивые колонки: не путать риск с доказанным фактом

В сохранённых версиях маршрутов, отчётов, контейнеров и актов заголовки были стабильными. Зато в трёх текущих ресурсах фактическая структура не совпала со словарём: в перечне ОСМД исчез телефон, в таблице поставщиков жилищных услуг в название колонки попал невидимый пробел, а в обращениях одно поле отсутствует и одно добавлено. Это проблема контракта импорта, но ещё не доказательство того, что колонки постоянно менялись во времени.

Пустые координаты: семь наборов с разным масштабом проблемы

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

Отсутствующий словарь: восемь ключевых ресурсов

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

Обновление без истории: четырнадцать наборов

Новая версия файла часто заменяет старую. В таком режиме нельзя воспроизвести прошлый расчёт, найти исправленную запись или отличить реальное изменение от перезагрузки. Историю увидели только в отдельных ресурсах расписания, целевых программ, контейнеров, зелёных насаждений, ОСМД и голосований за петиции. Даже там версионирование не всегда охватывает все части набора.

Три городских вопроса, на которые данные уже позволяют ответить

Можно ли воспроизвести базовое расписание общественного транспорта?

Да, в пределах опубликованного GTFS. Есть маршруты, остановки, рейсы, последовательность и время остановок, календарь и геометрия. Ключи route_id, stop_id, trip_id и service_id позволяют соединить таблицы. Вывод не означает, что каждый фактический приезд соответствует плану; он означает, что публикации достаточно для анализа планового расписания.

К скольким целевым программам прикреплены отчёты?

Таблица содержит 41 уникальную программу, а 30 строк отчётов ссылаются на 25 уникальных programId. Все эти ключи найдены в перечне программ, «сиротских» отчётов нет. Следовательно, в выбранной публикации отчёт представлен для 25 программ, а для 16 программ строки в таблице отчётов нет. Это не утверждение, что документ не существует нигде; это точный вывод об опубликованном ресурсе.

Как распределены учреждения культуры по типам и районам?

В 286 строках координаты заполнены, районы указаны для всех записей, uid уникален. Среди типов больше всего библиотек — 147, далее идут 42 школы искусств, 18 музеев и 17 театрально-зрелищных учреждений. По районам больше всего записей в Шевченковском — 47, меньше всего в Святошинском — 16. Здесь структура позволяет не только посчитать, но и проверить пространственное распределение.

Как исправить набор и как честно описать его границы

Распорядителю не обязательно начинать с нового портала. Большинство проблем исправляется дисциплиной публикации:

• экспортировать исходную таблицу или JSON, а документ для чтения оставлять дополнительным ресурсом;
• публиковать машиночитаемый словарь с названием, заголовком, описанием, типом и обязательностью каждого поля;
• закрепить неизменный идентификатор за сущностью и отдельно документировать составной ключ для исторических измерений;
• проверять не только наличие колонок, но и долю пустых значений в ключевых полях;
• для пространственных наборов валидировать диапазоны координат и публиковать долю негеокодированных записей;
• сохранять предыдущие версии, контрольную сумму, краткий журнал изменений и дату фактического среза внутри метаданных ресурса;
• для API давать описание параметров, пример ответа, схему, коды ошибок и правило пагинации;
• запускать автоматический тест загрузки после каждой публикации, чтобы 404, 500 или пустой архив не ждали пользователя.

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

Формулировка вывода должна точно повторять границу данных. Не «у города нет информации об очередях», а «опубликованный endpoint возвращает только одно учреждение и не позволяет воспроизвести городскую совокупность». Не «город скрывает географию выбросов», а «в проверенном CSV координаты и название улицы пусты». Такой язык менее громкий, зато его можно проверить.

Итоговый реестр: три разных уровня доверия

Можно анализировать

• расписание движения городского электрического и автомобильного транспорта;
• данные о парковке;
• финансовая отчётность субъектов коммунального сектора;
• отчёты о выполнении финансовых планов;
• перечень целевых местных программ, изменений и отчётов;
• перечень муниципальных пляжей;
• перечень учреждений культуры;
• учреждения профессионального образования;
• обращения в контактный центр;
• электронные петиции.

Этот статус не означает «безупречно». Он означает, что для сформулированного вопроса есть достаточная таблица, ключи и контролируемый способ получения, а выявленные дефекты не искажают основной ответ.

Нужна очистка или обходной путь

• места размещения остановок — статический JSON работает, GeoJSON endpoint нет;
• общественные туалеты — координаты есть, поля доступности неполные;
• коммунальные контейнеры — пустые тип и балансодержатель;
• зелёные насаждения к удалению — нет координат и части адресов;
• ОСМД и ЖСК — расхождение словаря, дубликаты ключа и неполная география;
• обслуживание жилищного фонда — координатные пропуски и невидимый символ в заголовке;
• качество воздуха — история есть, но live-ответ нельзя считать свежим без проверки времени;
• разрешения на выбросы — реестр читается, пространственные поля пусты.

Городской вывод невозможен

• учреждения дошкольного образования — endpoint вернул только четыре записи без объяснения полноты;
• очередь детей в дошкольные учреждения — доступен пример для одного учреждения без справочника параметров.

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

Следующий шаг: превратить разовую проверку в рабочий регламент

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

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