В рубрике интересных наборов данных, сайт День сурка (Groundhog-Day.com) [1] где собрана база из 74 животных предсказателей длинной зимы или ранней весны, включая 43 сурка.

Сделано явно с большой любовью к животным и к данным, потому что у сайта есть открытое API [2] с информацией о всех животных, их местонахождении и предсказаниях.

Ссылки:
[1] https://groundhog-day.com
[2] https://groundhog-day.com/api

#opendata #api

Подборка регулярного чтения про данные, технологии и не только:
- A Eulogy for Dark Sky, a Data Visualization Masterpiece [1] о визуализации данных в погодном приложении The Dark Sky для iOS и там же про наглядные решения контекстуализации данных. Я бы добавил этот термин в словарь "констектуализация данных" - это когда данные у Вас есть, но Вы подаёте их в том виде в каком они наиболее информативны и наглядны именно в том контексте/приложении/среде в которой их смотрят. А это приложение погоды отличный пример

- The Beginner's Guide to Databases [2] для новичков желающих разобраться в базах данных отличное руководство, оно не покрывает очень много чего, но одновременно даёт все нужные вводные для старта работы

- Meet Alpaca: Stanford University’s Instruction-Following Language Model that Matches GPT-3.5 Performance [3] новый интересный продукт как альтернатива GPT-3.5 под названием Альпака, главные отличия в открытости и меньших требованиях к железу. Открытый код главное преимущество [4]

- Finding Undocumented APIs [5] автор пишет про мою любимую тему, обнаружение недокументированных API. Я несколько выступлений и лекций проводил за эти годы про поиск и нахождение недокументированных API и ещё немало трюков могу рассказать о том как API находить, помимо перехвата запросов браузера к серверу. Так вот два самых очевидных способа часто срабатывающих:
* 1) Поискать API поиском Гугла на сайте явным образом вроде "REST API site:roskachestvo.gov.ru" и результат может удивить
* 2) Выяснить на каком программном продукте работает сайт и проверить не сохранилось ли в нём API идущее по умолчанию, у многих продуктов такое есть. Пример: Архив оцифрованных материалов Национальной электронной детской библиотеки РФ arch.rgdb.ru работает на движке DSpace, а у DSpace по умолчанию API доступно по ссылке /rest, проверяем, ага, вот и оно https://arch.rgdb.ru/rest/
Я могу не то что презентацию, а целый курс прочитать только по этой теме. Тем не менее ту статью рекомендую, часто информацию о API приходится выковыривать из сессий браузера.

- Data wrangling essentials: comparisons in JavaScript, Python, SQL, R, and Excel [6] сравнение функций преобразований данных в Excel, Python, R, SQL и Javascript. Полезно для тех кто вынужден пользоваться 2-3 языками/синтаксисами. Python там, правда, это не совсем Python, а конкретно Pandas, но текст от этого ценности не теряет.

Ссылки:
[1] https://nightingaledvs.com/dark-sky-weather-data-viz/
[2] https://technically.substack.com/p/the-beginners-guide-to-databases
[3] https://pub.towardsai.net/meet-alpaca-stanford-universitys-instruction-following-language-model-that-matches-gpt-3-5-490a38114a7e
[4] https://github.com/tatsu-lab/stanford_alpaca
[5] https://inspectelement.org/apis.html
[6] https://observablehq.com/@observablehq/data-wrangling-translations

#opensource #readings #api #data #guides

Про публикацию открытых государственных данных в России иногда, всё же, можно рассказать и что-то хорошее, хотя и нечасто. ФНС России обновило портал ФИАС [1] (Федеральной информационной адресной системы) в которой собраны сведения о более чем 32 миллионах зданий и сооружений и других связанных с ними объектов [2]. Система эта существует достаточно давно и доступ к ней есть через скачивание полных дампов, скачивание дельт изменений, API и СМЭВ. В общем это очень хороший пример того как правильно публиковать данные в открытом доступе если делать это на системной основе.

Я бы сказал что высокие оценки ФНС в части открытости [3] вполне оправданы, это редкое по нынешним временам системное раскрытие нужных бизнесу данных, причём данных референсных, составляющих базовую цифровую инфраструктуру. По сравнению с каким-нибудь Минэкономразвития России ФНС большие молодцы.

Особенно важно что в ведомстве понимают продолжают публиковать данные для массовой выгрузки в виде полных дампов, до 36GB в сжатом виде один дамп. К сравнению власти Санкт-Петербурга "похоронили" свой портал открытых данных ради портала API [4], что власти города конечно не красит.

Возвращаясь к ФИАС, конечно, даже подобная публикация данных неидеальна и её есть куда улучшить, особенно если смотреть не на форму, а на суть данных. А суть в том что это геоданные, без геоидентификаторов. Для того чтобы данные можно было применять в большой аналитической работе необходимо чтобы записи о муниципалитетах, улицах, зданиях и иных объектах содержали их геокоординаты, геоформу, включали Shape файлы, KML, GeoJSON, GML и все остальные геоформаты доступа к таким данным. Иначе говоря были бы интегрированы с данными Росреестра и доступны для выгрузки.

Другая важная сторона публикации данных в раскрытии их под свободными лицензиями. До сих пор на сайте ФИАС нет явно указанных, четких, не имеющих оговорок, условий использования этих данных. А чтобы использовать их в таких проектах как Wikidata или OSM лицензии имеют значение. Публикация данных под Creative Commons Zero выглядит наиболее логично.

Ссылки:
[1] https://fias.nalog.ru
[2] https://fias.nalog.ru/Statistics/
[3] https://t.me/ahminfin/568
[4] https://api.petersburg.ru

#opendata #geodata #russia #api #datasets

Я уже несколько раз писал о том что государства по всему миру продолжают создавать каталоги API, по аналогии с сайтами для разработчиков предлагаемыми в коммерческом секторе. Новые каталоги API в тот же список:
- Каталог административных API Японии http://api-catalog.e-gov.go.jp/ открыт 31 марта 2023 г., 39 API
- Государственные API в Малайзии https://www.mygdx.gov.my/en/landing-page/architecture?theme=first-theme 130 API
- Портал API налоговой службы Австралии https://apiportal.ato.gov.au, 6 API
- Портал госAPI ОАЭ https://api.government.ae 29 API
- Портал API налоговой службы Новой Зеландии https://portal.api.business.govt.nz 30 API
- Каталог API Литвы https://api.gov.lt около 40 API

А также предыдущий список из 6 каталогов API.

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

#openapi #opendata #api #government

В рубрике интересных продуктов по работе с API Metatype [1], платформа для декларативной разработки API, как сами создатели его позиционируют, продукт позволяющий проектировать API не будучи программистом. Внутри всё построено вокруг Typegraph [2], одновременно идеи и одноимённого пакета для Python с помощью которого описывается спецификация API. У продукта своя система типов, своя система управления доступа к ресурсам, интеграция с Prism, Deno и другими инструментами и ещё много чего.

Похоже что он годится как элемент строительного блока для построения собственной API платформы, хотя и удивляет что авторы игнорируют стандарт OpenAPI кроме как использования его спецификации для импорта описаний [3]

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

Ссылки:
[1] https://metatype.dev
[2] https://metatype.dev/docs/concepts/typegraph
[3] https://metatype.dev/docs/guides/importing-openapi-definitions

#opensource #api #datatools

Открытые данные в России о которых многие не знают,

- Открытые данные ГУАП [1] ГУАП - это Санкт-Петербургский государственный университет аэрокосмического приборостроения, а на сайте у них есть раздел с API с информацией о ВУЗе. Есть внятное API, для полной открытости нехватает условий использования.
- Открытые API для сервисов Санкт-Петербурга [2] категорически малоизвестный портал Санкт-Петербурга с их официальными API к городским информационным системам. Развивают они его, почему-то, параллельно порталу открытых данных, а не совместно. Как и во многих других случаях, "забывают" написать про условия использования, но сами данные есть.
- Геопортал СВКНИИ ДВО РАН [3] и другие их ГИС сервисы [4] с картами и слоями карт по Дальнему востоку. Включает доступ к данным через открытое API сервера ArcGIS

Ссылки:
[1] https://api.guap.ru/data/
[2] https://api.petersburg.ru
[3] http://hags.north-east.ru:8080/geoportal/catalog/main/home.page
[4] http://www2.neisri.ru/index.php/ru/%D0%B3%D0%B8%D1%81-%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D1%8B.html

#opendata #datasets #api #russia #geodata

Подборка полезных ссылок про данные, технологии и не только:
- drawdb [1] визуальное проектирование баз данных и SQL генератор на базе draw.io. Открытый код на JS, лицензия MIT. Выглядит очень даже неплохо
- quickwit [2] альтернатива Datadog и подобным сервисам, но с открытым кодом. Реализует поисковую систему для наблюдаемости процессов. Лицензия AGPL или коммерческая, для бизнеса. Выглядит как минимум интересно, очередной пример YAML программирования, огромного числа файлов для настройки.
- paradedb [3] альтернатива Elasticsearch на базе Postgres, обещают что внутри файлы parquet и многократно выше скорость аналитических запросов. Обещают облачный сервис, пока доступен open source продукт. Лицензия AGPL для всех и коммерческая для бизнеса.
- traefik [4] реверсный прокси для HTTP для развертывания микросервисов и API, похож на альтернативу Kong и Tyk. Открытый код под MIT лицензией

Ссылки:
[1] https://github.com/drawdb-io/drawdb
[2] https://github.com/quickwit-oss/quickwit
[3] https://github.com/paradedb/paradedb
[4] https://github.com/traefik/traefik

#opensource #data #datatools #api #dataviz

В рубрике *как это устроено в России* о том что должно было бы быть открытыми данными, но ими не является. У почти всех российских регионов есть инвестиционные карты. Это, либо отдельные геопорталы, либо разделы на инвестиционных порталах которые точно есть у всех. Например, инвестиционная карта Курганской области [1] или инвестиционная карта Волгоградской области [2]. Можно убедиться что на них есть слои карт и их от десятков до полутора сотен. Другие подобные инвестиционные карты легко находятся по ссылкам с портала инвестпроектов Минэка РФ [3].

Что можно о них сказать? Они все содержат то или иное недокументированное API. Там всего несколько вендоров геоинформационных систем и у них всё довольно стандартизировано. При очень небольших усилиях то же Минэкономразвития могло бы добавить на нацпортал открытых данных более 1000 датасетов и/или стандартизированных API по стандарту WFS. Очень небольшие расходы на всё это нужно, я бы даже сказал мизерные, а вероятность что эти данные были бы небесполезны, конечно, есть.

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

Кстати, к примеру в Казахстане национальный геопортал [4] сделан довольно прилично и там публикуют открытые данные. Не со всех региональных геопорталов они их агрегируют, но и 571 слой карт - это неплохо.

Возвращаясь к ситуации в РФ. Мне бы вот, например, хотелось агрегировать данные с российских геопорталов в Dateno и даже недокументированность их API решается. У типовых систем, типовые API. Но тут уже другое ограничение, российские госсайты в большинстве своём недоступны с зарубежных IP адресов. Краулер работающий не изнутри страны не сможет достучасться до большого числа сайтов. Это, конечно, тоже решается, но требует больше времени и усилий.

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

Ссылки:
[1] https://invest45.ru/investmap
[2] https://investmap.volgograd.ru
[3] https://invest.economy.gov.ru
[4] https://map.gov.kz

#opendata #data #geodata #russia #api

Нашёл презентацию Paul Bradshaw о недокументированных API веб-сайтов и как их искать [1]. Рецепты у него довольно простые:
- используйте Chrome Developers Tools и аналог в Firefox
- изучайте структуру ссылок и XHR типы запросов
- учитесь декодировать параметры

Ну и примеры недокументированных API тоже. Презентация должна быть доходчивой для журналистов, для которых собственно он и пишет как автор The Online Journalism Handbook.

У меня на эту же тему было несколько презентаций в контексте проблем с архивацией сайтов и в контексте поиска недокументированных API.

Так вот ключевой инструмент в работе с ними - это поисковые системы, возможность найти точки подключения проиндексированные ими.

Второй значимый инструмент - это "типовые", но недокументированные API многих программных продуктов. В первую очередь типовые API CMS.

И третий - это мобильные приложения, декодирование байткода которых или перехват их обращений к сайту также может дать много чего интересного.

Но, опять же, это всё полезно, в первую очередь журналистам, OSINT'щикам и хакерам. Для других задач нужно куда реже.

Ссылки:
[1] https://github.com/paulbradshaw/undocumentedapis/blob/main/Undocumented%20APIs.pdf

#api #readings #datajournalism

Подборка ссылок на продукты публикации датасетов для API и аналитики:

С открытым кодом:
- SQLite Studio [1] быстро первращает базы SQLite в веб интерфейс. Можно смотреть структуру таблиц и делать запросы. А также есть демо [2]. По ощущениям очень простой и удобный для этой небольшой задачи.
- Datasette [3] хорошо известный в узких кругах продукт, очень быстро превращающий датасеты в веб интерфейс. Умеет в разные данные, разные API, разные интерфейсы и куча расширений. Когда хочется конструктор и разного
- CSVBase [4] простой до безобразия для превращения CSV файлов в API. Внутри всё Python, одновременно и сервис для публикации данных онлайн для тех кто очень хочет делать это за деньги
- APIReady [5] написанный мной 11 лет назад очень простой движок по превращению CSV файлов в API. Честно говоря с той поры я его даже не развивал, просто как демонстрация самой идеи.
- APICrafter [6] тоже написанная мной утилита по публикации API к базам MongoDB. Развитие APIReady и необходимость поскольку MongoDB по умолчанию не давало и не даёт приемлимое API в их Community Server. Только в облачном сервисе есть уже что-то удобное. Всё на Python, управляется развесистыми YAML конфигами которые строятся автоматически на основе просканированных баз данных [7]

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

А я через какое-то время напишу про то какие есть бесплатные и коммерческие, не open source, онлайн инструменты делиться датасетами.

Ссылки:
[1] https://github.com/frectonz/sqlite-studio
[2] https://sqlite-studio.frectonz.io/
[3] https://datasette.io/
[4] https://github.com/calpaterson/csvbase
[5] https://github.com/ivbeg/apiready
[6] https://github.com/apicrafter/apicrafter
[7] https://github.com/apicrafter/apicrafter/blob/main/examples/rusregions/apicrafter.yml


#opensource #datatools #data #api

Поработав в избытке с данными и со смыслом публикации разной статистики, в какой-то момент напишу лонгрид на тему того как хорошо и как плохо публикуют статистику в разных странах и территориях, а пока в виде выжимки накопленные мысли. Поскольку я на эту тему несколько раз уже писал в таком формате, то где-то могу и повторяться:
1. Унификация. Хорошо опубликованные статистические данные практически всегда хорошо унифицированы. У них есть так называется code lists, стандартизированные справочники территорий, видов деятельности и тд. Они унифицированы в единые форматы и с ними можно работать унифицированным образом с любым индикатором. Можно сказать что почти во всех развитых странах базы индикаторов доступны таким вот унифицированным образом. В современных национальных системах управления статпоказателями такая унификация почти всегда увязана на внедрение стандарта SMDX от 2 до 3 версии.
2. Массовая выгрузка. На английском языке она звучит как bulk download, возможность выкачать базу индикаторов целиком с минимальным объёмом усилий. Может выглядеть как 1-2 zip файла со всем содержимым, так делают в FAO, или тысячи csv/csv.gz файлов по одному по каждому индикатору, со всем содержимым индикатора и каталогом ссылок на все файлы. Так делают в Евростате и ILO.
3. Универсальный поиск. Статистические продукты бывают разные, иногда в разных информационных системах, в разных форматах, включая архивные статсборники. Универсальный поиск позволяет искать по ним всем. Начиная с интерактивных таблиц и заканчивая архивными материалами и даёт возможность найти нужные данные в нужном формате за заданный период.
4. Открытые данные по умолчанию. Практика альтернативная возможности массовой выгрузки когда статистические показатели с самого начала публикуются на стандартизированном портале открытых данных с уже имеющимся API этого портала и доступны для выгрузки через это стандартное API. Например, так делают в ЦБ Бразилии с дата порталом на базе CKAN и в Катаре с их госпорталом открытых данных на базе OpenDataSoft
5. Экспорт данных и доступ через API. Не просто экспорт в Excel, а как минимум выбор из 5-6 форматов начиная от самых простых вроде csv, продолжая форматами для Stata и других продуктов, автогенерацией кода для Python или R и наличию SDK к хотя бы паре популярных языков разработки для доступа к данным. У многих европейских порталов статданных есть неофициальные SDK, в других вроде статданных Гонконга автоматически генерируется код на Python на страницах интерактивных таблиц.
6. Технологичность. Тут можно было бы добавить и соответствие лучшим дата-инженерным практикам. Это включает: доступность данных в форматах parquet, документация к API по стандарту OpenAPI, общедоступные примеры работы через Postman или аналоги, общая документация в стиле технологических проектов с интерактивными примерами, а не в форме отчетности подрядчика по контракту в PDF. Технологичность - это про доступ и про документацию, как ни странно, но это самое актуальное для статданных.

#opendata #api #statistics #thoughts

Полезная статья о которой хочется написать отдельно Deliver Your Data as a Product, But Not as an Application [1], она требует авторизации на Medium. но почитать её стоит.

Основная идея в том что данные - это продукт, но этот продукт не приложение. Иначе говоря если Ваша бизнес модель построена на предоставлении данных, то надо помнить что именно данные, являются продуктом и не надо смешивать их с кодом.

Собственно в статье отсылка к хорошо известной книге Principles of Data-Oriented Programming [2] и следующим принципам:
- Отделяйте код (поведение) от данных;
- Рассматривайте данные как неизменные (immutable)
- Отделяйте схемы/структуры данных от их представления
- Представляйте данные с помощью простых структур данных

Статья написана с прицелом на OOP разработчиков которые хотели бы понять отличия программирования с данными и без.

Идея отделения данных от кода, в принципе, не нова. Лично я при проектировании разных ИТ продуктов за последние годы придерживался принципа API-first, то есть вначале у тебя появляется API, а потом уже разные интерфейсы поверх него.

В случае с данными оно разделяется на 2+ сервиса API. Первый сервис API для бизнес логики/кода, второй для данных, как правило Data API отдающее JSON или Protocol Buffers. Реальные системы могут иметь больше вариаций по разделению и компонентам, но бизнес логика и доступ к данным разделять стоит всегда.

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

И это, конечно, относится не только к данным статистики.

Ссылки:
[1] https://towardsdatascience.com/deliver-your-data-as-a-product-but-not-as-an-application-99c4af23c0fb
[2] https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.html

#itarchitecture #datasaproduct #data #api

В рубрике интересных открытых данных данные по трафику судов [1] от Finnish Transport Infrastructure Agency. Данные по портам, кораблям, движению, портозаходам и ещё много чему. Всё без ограничений и аутентификации, покрывает практически всё Балтийское море.

Тот случай когда API оправдано на 100%. Для полного счастья нехватает только исторических данных для bulk download.

Ссылки:
[1] https://www.digitraffic.fi/en/marine-traffic/#vessel-locations

#opendata #finland #API

Обновлённая подборка государственных каталогов открытых API. Последний раз я писал о них полтора года назад за это время список пополнился:
- API.GOUV.FR - каталог API, стандарты и рекомендации Франции
- API.GOVERNMENT.AE - каталог API Объединённых Арабских эмиратов
- API.GOV.UK - каталог государственных API Великобритании
- API.GOV.AU - австралийский государственный стандарт предоставления API и каталог общедоступных API
- DEVELOPER.VIC.GOV.AU - портал для программистов (каталог API) правительства штата Виктория, Австралия
- API.NSW.GOV.AU - портал открытых API Нового Южного Уэльса, Австралия
- PORTAL.API.IPAUSTRALIA.GOV.AU - портал API патентного ведомства Австралии
- DEVELOPER.HEALTH.GOV.AU - B2G (Business To Government) портал API Департамента здравоохранения Австралии
- DEVELOPER.TECH.GOV.SG - портал для разработчиков от Правительства Сингапура, API, документация и тд.
- ESERVICES.MAS.GOV.SG - портал открытых API главного монетарного управления Сингапура (аналог центробанка)
- MYGDX.GOV.MY - каталог API на малазийском государственном портале MyGDX

В реальности каталогов API сильно больше, не везде они сразу бросаются в глаза.

#api #openapi

Dateno Expands Data Capabilities for Professionals with API and Dashboard Tools!

We are thrilled to announce the launch of two powerful tools designed specifically for data professionals: the My Dateno personal dashboard and the Dateno API! These updates will greatly enhance your ability to manage and integrate data search into your workflows.

With My Dateno, users can now track their search history and access API keys, making it easier than ever to tap into Dateno's extensive data search capabilities. In the future, My Dateno will also provide access to premium features and additional data services. Plus, those who join our early access program will get free access to these new features during the testing period!

The Dateno API enables developers and businesses to integrate our platform’s search functionality directly into their products and infrastructure. This API offers fast, efficient search across 19 million datasets—including data files, geoAPI connections, and statistical indicators—with powerful filtering options. Retrieve comprehensive metadata and related resources, and streamline your data processing with ease.

We’re excited to empower data professionals with these new tools! 🚀

Learn more and sign up for early access at dateno.io

#Dateno #DataSearch #API #Innovation #DataIntegration #DataProfessionals