В рубрике как это работает у них, один из источников геоданных и их каталогизации - это геопорталы. Продуктов для их создания довольно, но есть наиболее популярные и типовые и один из них - это QGIS Web Client 2 (QWC2) [1], на его основе создано немало европейских и не только геопорталов. Например, геопорталы некоторых кантонов (регионов) Швейцарии работают на QWC2 [2] и слои карты используемые в его работе доступны онлайн через специальный файл themes.json [3]
Сами слои могут быть разным образом опубликованы, не всегда самыми очевидными геопродуктами. Получается что для их индексирования как раз эти файлы и являются наиболее удобным источником метаданных.
Слоёв данных там не так уж много, десятки, в среднем, но данные хорошо локализованы и удобно доступны.
А ещё у швейцарцев есть серия каталогов геоданных с дата моделями по их стандарту INTERLIS. Но о нём как-нибудь в другой раз. А пока в реестр Dateno вношу ряд каталогов на QWC2.
Ссылки:
[1] https://qwc-services.github.io/master/
[2] https://map.geo.gl.ch
[3] https://map.geo.gl.ch/themes.json
#opendata #datacatalogs #dateno
Сами слои могут быть разным образом опубликованы, не всегда самыми очевидными геопродуктами. Получается что для их индексирования как раз эти файлы и являются наиболее удобным источником метаданных.
Слоёв данных там не так уж много, десятки, в среднем, но данные хорошо локализованы и удобно доступны.
А ещё у швейцарцев есть серия каталогов геоданных с дата моделями по их стандарту INTERLIS. Но о нём как-нибудь в другой раз. А пока в реестр Dateno вношу ряд каталогов на QWC2.
Ссылки:
[1] https://qwc-services.github.io/master/
[2] https://map.geo.gl.ch
[3] https://map.geo.gl.ch/themes.json
#opendata #datacatalogs #dateno
Уникальная фича Dateno [1] - это сужение поиска датасетов до субрегионального уровня, городов и регионов стран. Например, можно в фасете SubRegion где для многих стран можно найти данные сразу в региональном разрезе. Не просто по Франции, к примеру, а сразу по Парижу. В классическом поиске для этого обычно используют комбинации слов, вроде "COVID Paris" или "COVID Berlin", но на порталах данных часто неочевидно к какому города или регионы они относятся.
Такой фасет возможен самым банальным образом, автоматизированной и ручной разметкой каталогов в реестре каталогов Dateno [2]. В файлах YAML описания каталогов регионы прописываются явным образом в блоге coverage и построено это на основе стандарта ISO 3166-2, к примеру, код Берлина DE-BE.
Указание регионов есть только для каталогов которые отмечены как Regional government и Local government и тех по которым тип владельца ещё неизвестен (Unknown). Таких каталогов более 7989 и из них 1041 имеет привязку к subregion.
Это самый простой и очевидный способ дать геопривязку к данным. Аннотирование каталогов данных действенная штука для таких задач. Более сложный сценарий когда региональных каталогов мало, всё централизовано, а на центральном портале региональные данные есть. Что делать в этом случае? Тут есть два решения/подхода.
1-й - это машинное обучение и идентификация геопривязки наборов данных по ключевым словам в заголовке и в описании. Тут, правда, будет много ошибок потому что, к примеру, есть страна Armenia, а есть муниципалитет Armenia в Колумбии.
2-й - это ручное или автоматическое аннотирование публикаторов данных. На порталах данных, как правило, есть инфа о том кто данные опубликовал и по ней можно идентифицировать регион.
Это будет работать на некоторых крупных порталах данных вроде США с data.gov, но даже там на национальный уровень выводится относительно немного данных и нужен хороший матчер названий организаций и их территорий.
Эта фича ещё будет развиваться, пока же можно искать по тем данным которые уже размечены и их число будет пополнятся с каждым проходом краулера и обновлением реестра каталогов данных.
Ссылки:
[1] https://dateno.io
[2] https://dateno.io/registry
#opendata #datacatalogs #datasets #dateno
Такой фасет возможен самым банальным образом, автоматизированной и ручной разметкой каталогов в реестре каталогов Dateno [2]. В файлах YAML описания каталогов регионы прописываются явным образом в блоге coverage и построено это на основе стандарта ISO 3166-2, к примеру, код Берлина DE-BE.
Указание регионов есть только для каталогов которые отмечены как Regional government и Local government и тех по которым тип владельца ещё неизвестен (Unknown). Таких каталогов более 7989 и из них 1041 имеет привязку к subregion.
Это самый простой и очевидный способ дать геопривязку к данным. Аннотирование каталогов данных действенная штука для таких задач. Более сложный сценарий когда региональных каталогов мало, всё централизовано, а на центральном портале региональные данные есть. Что делать в этом случае? Тут есть два решения/подхода.
1-й - это машинное обучение и идентификация геопривязки наборов данных по ключевым словам в заголовке и в описании. Тут, правда, будет много ошибок потому что, к примеру, есть страна Armenia, а есть муниципалитет Armenia в Колумбии.
2-й - это ручное или автоматическое аннотирование публикаторов данных. На порталах данных, как правило, есть инфа о том кто данные опубликовал и по ней можно идентифицировать регион.
Это будет работать на некоторых крупных порталах данных вроде США с data.gov, но даже там на национальный уровень выводится относительно немного данных и нужен хороший матчер названий организаций и их территорий.
Эта фича ещё будет развиваться, пока же можно искать по тем данным которые уже размечены и их число будет пополнятся с каждым проходом краулера и обновлением реестра каталогов данных.
Ссылки:
[1] https://dateno.io
[2] https://dateno.io/registry
#opendata #datacatalogs #datasets #dateno
Я уже рассказывал про геоклассификацию данных в Dateno и то что существенная фича в поиске - это возможность поиска по городам/регионам, на субрегиональном уровне. Классификация датасетов по субрегионам основана почти полностью на аннотировании каталогов данных и с этой точки зрения это довольно простая задача с понятным решением.
Как оказывается куда менее простой задачей является привязка датасетов к странам и макрорегионам.
Базово привязка эта привязка делается через привязку каталога данных которые, как правило, конкретными странами ограничены. К примеру, если есть национальный портал данных какой-то страны, то и данные почти всегда касаются этой страны. Но это самые простые случаи и в основном про порталы открытых данных и про геопорталы.
Сложности начинаются с научными данными. Большая их часть чёткой геопривязки может не иметь вообще, кроме ну разве что, академического института(-ов) авторов и их местонахождения. Исключение составляют редкие датасеты из наук о земле, лингвистики и ещё ряда научных дисциплин.
Другая сложность возникает со всей статистикой и производными индикаторами. Помимо стат. показателей по странам существует неимоверное число разных групп стран, от простых, до хитровыдуманных. К примеру, группы арабских стран, страны MENA, G20, G7, Андское сообщество, наименее развитые страны, страны без выхода к морю и ещё много какие. Причём, конечно, группы стран пересекаются, но не всегда входят в друг друга.
Внутри Dateno, при этом, для группировки стран используется список макрорегионов из UN M49. Разметить страны по вхождение в эти макрорегионы несложно и внутренний справочник для этого есть. А вот справочника вхождения стран в эти многочисленные группы и их пересечений - нет и его надо составлять де-факто полувручную и нет кого-то кто бы поддерживал такую живую базу данных или программную библиотеку.
Поэтому георазметка реальных мировых статистических данных - это боль, требующая большой ручной работы по привязке к макрорегионам.
Пока что отсутствие привязки каких-то датасетов к странам и макрорегионам не так критичны поскольку другие поисковики даже такого не поддерживают и есть фасеты где разметка куда хуже. К примеру, наличие информации о лицензии есть не более чем у 10% датасетов.
Тем не менее качество фасетов в Dateno влияет на пользовательский опыт и это важная задача для построения максимально достоверного поискового индекса по данным.
#dateno #statistics #indicators #geodata #geo #thoughts
Как оказывается куда менее простой задачей является привязка датасетов к странам и макрорегионам.
Базово привязка эта привязка делается через привязку каталога данных которые, как правило, конкретными странами ограничены. К примеру, если есть национальный портал данных какой-то страны, то и данные почти всегда касаются этой страны. Но это самые простые случаи и в основном про порталы открытых данных и про геопорталы.
Сложности начинаются с научными данными. Большая их часть чёткой геопривязки может не иметь вообще, кроме ну разве что, академического института(-ов) авторов и их местонахождения. Исключение составляют редкие датасеты из наук о земле, лингвистики и ещё ряда научных дисциплин.
Другая сложность возникает со всей статистикой и производными индикаторами. Помимо стат. показателей по странам существует неимоверное число разных групп стран, от простых, до хитровыдуманных. К примеру, группы арабских стран, страны MENA, G20, G7, Андское сообщество, наименее развитые страны, страны без выхода к морю и ещё много какие. Причём, конечно, группы стран пересекаются, но не всегда входят в друг друга.
Внутри Dateno, при этом, для группировки стран используется список макрорегионов из UN M49. Разметить страны по вхождение в эти макрорегионы несложно и внутренний справочник для этого есть. А вот справочника вхождения стран в эти многочисленные группы и их пересечений - нет и его надо составлять де-факто полувручную и нет кого-то кто бы поддерживал такую живую базу данных или программную библиотеку.
Поэтому георазметка реальных мировых статистических данных - это боль, требующая большой ручной работы по привязке к макрорегионам.
Пока что отсутствие привязки каких-то датасетов к странам и макрорегионам не так критичны поскольку другие поисковики даже такого не поддерживают и есть фасеты где разметка куда хуже. К примеру, наличие информации о лицензии есть не более чем у 10% датасетов.
Тем не менее качество фасетов в Dateno влияет на пользовательский опыт и это важная задача для построения максимально достоверного поискового индекса по данным.
#dateno #statistics #indicators #geodata #geo #thoughts
unstats.un.org
UNSD — Methodology
United Nations Statistics Divisin - Methodology
Пополнение в каталоге каталогов данных Dateno, +40 репозиториев научных данных на базе Weko3 [1], все они относятся к Японии и в совокупности содержат около 50 тысяч наборов данных. Не очень много по глобальным меркам, но хорошо индексируется и имеет стандартизированное API. Прежде чем данные таких каталогов индексируются в Dateno, они описываются и размещаются в реестре, идентифицируются их точки подключения к API и тд.
Ссылки:
[1] https://dateno.io/registry/country/JP
#opendata #dateno #datacatalogs
Ссылки:
[1] https://dateno.io/registry/country/JP
#opendata #dateno #datacatalogs
Кстати, если вы ещё не видели, мы обновили главную страницу Dateno [1] и выглядит всё лучше и лучше, а заодно можно сразу увидеть того сколько датасетов есть по разным макрорегионам.
Можно увидеть насколько много данных по развитым регионам и насколько их мало, к примеру, по Африке.
Правда у этих цифр есть объективная причина.Она в том что да, в развитых странах гораздо больше данных из-за лучшей цифровизации, культуры открытости, культуры работы с данными и тд. Данных очень много и всё больше гиперлокальных, муниципальных данных
Поэтому данных по Африке так мало, даже когда мы продолжим георазметку датасетов, всё равно их будет сильно меньше чем где-то ещё и большая часть этих данных будет создана в США и Европейских странах.
А вот то что мало данных по Азии, у этого есть объективные причины необходимости индексирования данных по Китаю, где свой уникальный софт, свои каталоги данных и тд. Если даже только основные репозитории проиндексировать там будет несколько миллионов наборов данных, но все на китайском языке😂
Ссылки:
[1] https://dateno.io
#opendata #dateno #datasets #datasearch #search
Можно увидеть насколько много данных по развитым регионам и насколько их мало, к примеру, по Африке.
Правда у этих цифр есть объективная причина.Она в том что да, в развитых странах гораздо больше данных из-за лучшей цифровизации, культуры открытости, культуры работы с данными и тд. Данных очень много и всё больше гиперлокальных, муниципальных данных
Поэтому данных по Африке так мало, даже когда мы продолжим георазметку датасетов, всё равно их будет сильно меньше чем где-то ещё и большая часть этих данных будет создана в США и Европейских странах.
А вот то что мало данных по Азии, у этого есть объективные причины необходимости индексирования данных по Китаю, где свой уникальный софт, свои каталоги данных и тд. Если даже только основные репозитории проиндексировать там будет несколько миллионов наборов данных, но все на китайском языке
Ссылки:
[1] https://dateno.io
#opendata #dateno #datasets #datasearch #search
Please open Telegram to view this post
VIEW IN TELEGRAM
Почему некоторых особенно крупных порталов с данными нет в Dateno? Например, европейский портал data.europe.eu [1] кажется очень большим. Там более чем 1.8 миллиона датасетов со всех стран входящих в Европейский союз, там есть API через которое их можно выкачать и выглядит как "надо брать", проиндексировать его и сразу индекс сильно расшириться.
Всё так, за несколькими но, и очень существенными.
Проблема прослеживаемости
Data.europe.eu - это агрегатор, причём агрегатор агрегаторов. Потому что во многих европейских странах данные публикуются на городских/районных порталах, собираются на национальных и далее в индексируются в общеевропейский. В результате прослеживаемость до первоисточника и часть метаданных теряются.
Вот наглядный пример. Набор данных Miljöfarliga verksamheter (Экологически опасные виды работ) на портале данных шведского города Malmo [2] попадает на шведский национальный портал dataportal.se [2] и оттуда аггрегируется в общеевропейский [3]. В оригинальном источнике у всех ресурсов указана лицензия cc0-1.0, а в национальном и общеевропейском лицензия не указана. Также как и нет цепочки прослеживаемости до первоисточника.
Проблема полноты
На европейском портале сейчас агрегируются данные с национальных порталов открытых данных и из геокаталогов по программе INSPIRE. Для агрегации используются стандарты DCAT-AP, расширение INSPIRE для геокаталогов, в основном, на базе Geonetwork и стандарт SPARQL и расширение API для CKAN. Городские, региональные, муниципальные, научные и иные каталоги данных не поддерживающие эти стандарты туда не попадают.
В этом есть некое характерное отличие европейского портала открытых данных от, к примеру, порталу открытых данных США где более 80% всех данных - это научные данные и геоданные. В Европейском портале научных данных нет совсем, а геоданные составляют от 60% до 70% всех данных. В Евросоюзе научные данные собираются на портале OpenAIRE и в data.europe.eu не попадают. Практически все источники данных которые в data.europe.eu собираются есть и в Dateno.
Проблема качества
В европейском портале данных только около 150-180 тысяч наборов данных имеют разметку по типу используемой лицензии. Это очень, я бы даже сказал, совсем мало, максимум 10% от общего числа данных, при том что зная природу порталов открытых данных откуда агрегируются данных можно было бы идентифицировать лицензии гораздо эффективнее. Внутри Dateno сейчас идентифицируются 40 лицензий и условий использования по более чем 800 правилам
—
В целом картина складывается так что в каком-то смысле европейский портал можно рассматривать как конкурент для Dateno, а не как источник данных. Единственные значимые там характеристики - это оценка качества метаданных по их методологии и отметки что наборы данных относятся к особо ценным. Но первое можно оценивать самостоятельно, а второе содержится в метаданных первоисточников.
Важная характеристика европейского портала в попытках получить хороший поисковик выставляя высокие требования к первоисточникам которые должны соблюсти определённые стандарты.
В отличие от него в Dateno агрегируется всё что хоть как-то напоминает каталоги данных и чьи метаданные можно стандартизировать под описание схожее с DCAT, как бы оно не было в оригинале.
Ссылки:
[1] https://data.europa.eu
[2] https://ckan-malmo.dataplatform.se/dataset/miljofarliga-verksamheter
[3] https://www.dataportal.se/datasets/290_5852/miljofarliga-verksamheter
[4] https://data.europa.eu/data/datasets/https-ckan-malmo-dataplatform-se-dataset-5249aa0b-6528-43ef-880f-172adac8515b?locale=en
[5] https://github.com/commondataio/cdi-licensemapper
#opendata #data #datasets #dateno #europe
Всё так, за несколькими но, и очень существенными.
Проблема прослеживаемости
Data.europe.eu - это агрегатор, причём агрегатор агрегаторов. Потому что во многих европейских странах данные публикуются на городских/районных порталах, собираются на национальных и далее в индексируются в общеевропейский. В результате прослеживаемость до первоисточника и часть метаданных теряются.
Вот наглядный пример. Набор данных Miljöfarliga verksamheter (Экологически опасные виды работ) на портале данных шведского города Malmo [2] попадает на шведский национальный портал dataportal.se [2] и оттуда аггрегируется в общеевропейский [3]. В оригинальном источнике у всех ресурсов указана лицензия cc0-1.0, а в национальном и общеевропейском лицензия не указана. Также как и нет цепочки прослеживаемости до первоисточника.
Проблема полноты
На европейском портале сейчас агрегируются данные с национальных порталов открытых данных и из геокаталогов по программе INSPIRE. Для агрегации используются стандарты DCAT-AP, расширение INSPIRE для геокаталогов, в основном, на базе Geonetwork и стандарт SPARQL и расширение API для CKAN. Городские, региональные, муниципальные, научные и иные каталоги данных не поддерживающие эти стандарты туда не попадают.
В этом есть некое характерное отличие европейского портала открытых данных от, к примеру, порталу открытых данных США где более 80% всех данных - это научные данные и геоданные. В Европейском портале научных данных нет совсем, а геоданные составляют от 60% до 70% всех данных. В Евросоюзе научные данные собираются на портале OpenAIRE и в data.europe.eu не попадают. Практически все источники данных которые в data.europe.eu собираются есть и в Dateno.
Проблема качества
В европейском портале данных только около 150-180 тысяч наборов данных имеют разметку по типу используемой лицензии. Это очень, я бы даже сказал, совсем мало, максимум 10% от общего числа данных, при том что зная природу порталов открытых данных откуда агрегируются данных можно было бы идентифицировать лицензии гораздо эффективнее. Внутри Dateno сейчас идентифицируются 40 лицензий и условий использования по более чем 800 правилам
—
В целом картина складывается так что в каком-то смысле европейский портал можно рассматривать как конкурент для Dateno, а не как источник данных. Единственные значимые там характеристики - это оценка качества метаданных по их методологии и отметки что наборы данных относятся к особо ценным. Но первое можно оценивать самостоятельно, а второе содержится в метаданных первоисточников.
Важная характеристика европейского портала в попытках получить хороший поисковик выставляя высокие требования к первоисточникам которые должны соблюсти определённые стандарты.
В отличие от него в Dateno агрегируется всё что хоть как-то напоминает каталоги данных и чьи метаданные можно стандартизировать под описание схожее с DCAT, как бы оно не было в оригинале.
Ссылки:
[1] https://data.europa.eu
[2] https://ckan-malmo.dataplatform.se/dataset/miljofarliga-verksamheter
[3] https://www.dataportal.se/datasets/290_5852/miljofarliga-verksamheter
[4] https://data.europa.eu/data/datasets/https-ckan-malmo-dataplatform-se-dataset-5249aa0b-6528-43ef-880f-172adac8515b?locale=en
[5] https://github.com/commondataio/cdi-licensemapper
#opendata #data #datasets #dateno #europe
В качестве примера живых данных чтобы проверит Duckdb, попробовал его на одном из слепков индекса Dateno.
Вот в цифрах и фактах:
- оригинальный формат JSONL, слепок данных без файлов ресурсов/ссылок, только карточки источников и наборов данных
- всего записей в базе 16 133 670
- размер parquet файла после преобразования 1.9GB
- размер базы duckdb 15GB
- простые запросы group by отрабатываются менее чем за 1 секунду
Сложности
- Есть проблемы с запросами которые необходимы для поиска записей в которых данные отсутствуют, например, где не заполнены какие-либо поля которые являются struct'ами. К пример, если мне нужно найти все записи у которых не указаны темы или привязка к стране. В MongoDB такие запросы делают гораздо проще, даже со сложными схемами когда есть вложенные массивы внутри вложенных словарей внутри вложенных массивов.
—
Но, особенность данных в том что за исключением задач дедубликации данных, можно разрезать базу на тысячи parquet файлов или баз duckdb под каждый источник данных. Поэтому метрики качества можно замерять не по единой базе, а по источникам данных и формировать в единую базу обрабатывая каждый источник отдельно и параллельно.
Например, одна из задач в документировании источников данных, привязывании их к стране, темам и к типу владельца данных. Это перевод источников из временных в постоянные. Как определять приоритеты? По числу проиндексированных датасетов, чтобы расширить метаданные хотя бы источников данных с 1000+ наборами данных.
#data #datatools #duckdb #dateno
Вот в цифрах и фактах:
- оригинальный формат JSONL, слепок данных без файлов ресурсов/ссылок, только карточки источников и наборов данных
- всего записей в базе 16 133 670
- размер parquet файла после преобразования 1.9GB
- размер базы duckdb 15GB
- простые запросы group by отрабатываются менее чем за 1 секунду
Сложности
- Есть проблемы с запросами которые необходимы для поиска записей в которых данные отсутствуют, например, где не заполнены какие-либо поля которые являются struct'ами. К пример, если мне нужно найти все записи у которых не указаны темы или привязка к стране. В MongoDB такие запросы делают гораздо проще, даже со сложными схемами когда есть вложенные массивы внутри вложенных словарей внутри вложенных массивов.
—
Но, особенность данных в том что за исключением задач дедубликации данных, можно разрезать базу на тысячи parquet файлов или баз duckdb под каждый источник данных. Поэтому метрики качества можно замерять не по единой базе, а по источникам данных и формировать в единую базу обрабатывая каждый источник отдельно и параллельно.
Например, одна из задач в документировании источников данных, привязывании их к стране, темам и к типу владельца данных. Это перевод источников из временных в постоянные. Как определять приоритеты? По числу проиндексированных датасетов, чтобы расширить метаданные хотя бы источников данных с 1000+ наборами данных.
#data #datatools #duckdb #dateno
Про разного рода технически сложные задачи и их решения.
Я тут регулярно пишу про разные форматы файлов данных и могу сказать что, конечно, файловых форматов как и стандартов какое-то бесконечное количество. Когда-то я и сам делал и периодически обновляю инструменты вроде undatum [1] по работе с некоторыми из них. Так в undatum я недавно добавил работу с множеством алгоритмов сжатия обработкой файлов с минимизацией объёма их хранения и нагрузкой на оперативную память, с быстрым преобразованием из JSON lines / BSON в аналогичные форматы со сжатием xzip, zstd и др. В общем-то из-за банальных задач уменьшения объёма хранения JSON lines файлов, но с возможностью работы с ними.
Однако вот сейчас я смотрю на задачу преобразования данных в условно "диком состоянии", а то есть в большинстве популярных форматов, среди которых, конечно, лидируют CSV и Excel файлы и могу сказать что самые типовые задачи решает DuckDB, а чуть более сложные DuckDB + Polars + Pandas + предобработка некоторых форматов файлов на входе.
Причём именно в такой комбинации. Почему так?
DuckDb - даёт большую скорость в работе с табличными и большей частью иерархичных данных. Но DuckDb не умеет читать файлы Excel, ORC, ORC и тд. Их умеют читать Pandas и Polars. И частично их писать.
Из фундаментальных проблем DuckDB - непонимание кодировок кроме utf-8 для CSV файлов что решается их предобработкой. Вторая проблема в том что DuckDB не умеет определять структуру CSV файлов если заголовки не в начале файла. Это вообще не все инструменты умеют и это, в принципе, умеют немногие инструменты, особенно с открытым кодом.
CSV самый распространённый формат, плохо стандартизированный в "диком виде", слишком часто CSV файлы лежат в открытом доступе после экспорта из Excel.
Еще один недостаток DuckDB при работе с CSV файлами - это отсутствие поддержки алгоритмов сжатия за исключением GZip. Если исходить из эффективности хранения и стоимости хранения - это важный фактор. Например, несколько сотен тысяч CSV файлов в Dateno - это около 4TB данных. Хранить их в оригинальном виде неэффективно, сжатыми GZip лучше, а ещё лучше в чём то вроде zstd или даже сразу в Parquet со сжатием. Что логично поскольку эти данные статичны.
Но в итоге именно DuckDB + Polars + Pandas + предобработка + постобоработка данных + хранение первичных данных в Parquet оказывается наиболее универсальным решением в таких задачах.
Ссылки:
[1] https://github.com/datacoon/undatum
#thoughts #data #datatools #fileformats #dateno
Я тут регулярно пишу про разные форматы файлов данных и могу сказать что, конечно, файловых форматов как и стандартов какое-то бесконечное количество. Когда-то я и сам делал и периодически обновляю инструменты вроде undatum [1] по работе с некоторыми из них. Так в undatum я недавно добавил работу с множеством алгоритмов сжатия обработкой файлов с минимизацией объёма их хранения и нагрузкой на оперативную память, с быстрым преобразованием из JSON lines / BSON в аналогичные форматы со сжатием xzip, zstd и др. В общем-то из-за банальных задач уменьшения объёма хранения JSON lines файлов, но с возможностью работы с ними.
Однако вот сейчас я смотрю на задачу преобразования данных в условно "диком состоянии", а то есть в большинстве популярных форматов, среди которых, конечно, лидируют CSV и Excel файлы и могу сказать что самые типовые задачи решает DuckDB, а чуть более сложные DuckDB + Polars + Pandas + предобработка некоторых форматов файлов на входе.
Причём именно в такой комбинации. Почему так?
DuckDb - даёт большую скорость в работе с табличными и большей частью иерархичных данных. Но DuckDb не умеет читать файлы Excel, ORC, ORC и тд. Их умеют читать Pandas и Polars. И частично их писать.
Из фундаментальных проблем DuckDB - непонимание кодировок кроме utf-8 для CSV файлов что решается их предобработкой. Вторая проблема в том что DuckDB не умеет определять структуру CSV файлов если заголовки не в начале файла. Это вообще не все инструменты умеют и это, в принципе, умеют немногие инструменты, особенно с открытым кодом.
CSV самый распространённый формат, плохо стандартизированный в "диком виде", слишком часто CSV файлы лежат в открытом доступе после экспорта из Excel.
Еще один недостаток DuckDB при работе с CSV файлами - это отсутствие поддержки алгоритмов сжатия за исключением GZip. Если исходить из эффективности хранения и стоимости хранения - это важный фактор. Например, несколько сотен тысяч CSV файлов в Dateno - это около 4TB данных. Хранить их в оригинальном виде неэффективно, сжатыми GZip лучше, а ещё лучше в чём то вроде zstd или даже сразу в Parquet со сжатием. Что логично поскольку эти данные статичны.
Но в итоге именно DuckDB + Polars + Pandas + предобработка + постобоработка данных + хранение первичных данных в Parquet оказывается наиболее универсальным решением в таких задачах.
Ссылки:
[1] https://github.com/datacoon/undatum
#thoughts #data #datatools #fileformats #dateno
К вопросу о состоянии открытости данных в РФ, я не очень верю что в ближайшие месяцы (годы?) случится чудо и оживёт государственный портал data.gov.ru. Пока не проглядывается сценарий при котором внутри гос-ва тренд на систематическую открытость вернулся. Больше шансов что мы в Dateno соберём больше данных чем когда-то было в data.gov.ru. Там уже сейчас проиндексировано много разного и можно больше.
Но есть посмотреть профиль РФ в Dateno, то там проиндексировано только около 15 каталогов данных из 154. Почему так? Можно ли лучше?
Конечно можно, и ограничения тут очень понятные:
1. Большая часть российских госресурсов сейчас не индексируются с зарубежных датацентров. Это преодолевается развертыванием прокси в РФ и индексация через прокси. И РФ не единственная страна где есть такие ограничения.
2. Значительная часть открытых данных в России публикуется по метод рекомендациям Минэка. Они очень плохо написаны, индексировать сайты публикующие данные по ним сложно, но возможно. Только этот парсер будет только под российские госпорталы, и то не все. И, по большей части, с устаревшими данными.
3. Очень много в РФ своих геопродуктов, самописных порталов данных и тд. Это также требует написания множества парсеров. Штук 40-50. Более менее стандартизированы только порталы NextGIS, Bitrix и Орбис, но их не так много.
4. Часть порталов с данными используют известное ПО типа Ipt, Pure, Figshare и до них пока ещё не дошли руки, но как только дойдут они добавятся в общий индекс.
В итоге, если специально не заморачиваться российской спецификой получится проиндексировать ещё 20-40 каталогов данных через прокси и за счёт парсеров для универсального софта, а в остальном надо приложить существенные усилия чтобы проиндексировать оставшиеся.
В этом смысле, собрать данные, например, по Финляндии гораздо проще. Там уже большая часть каталогов данных проиндексирована, да и не проиндексированные работают на типовом ПО которое тоже скоро будет индексироваться.
Вся эта национальная специфика очень сильно снижает видимость и находимость данных. И в Dateno ещё можно более-менее, но измерить эту доступность, а, к примеру, в Google Dataset Search невозможно даже посмотреть сколько датасетов и источников есть по странам.
#opendata #dateno #datasets #datacatalogs
Но есть посмотреть профиль РФ в Dateno, то там проиндексировано только около 15 каталогов данных из 154. Почему так? Можно ли лучше?
Конечно можно, и ограничения тут очень понятные:
1. Большая часть российских госресурсов сейчас не индексируются с зарубежных датацентров. Это преодолевается развертыванием прокси в РФ и индексация через прокси. И РФ не единственная страна где есть такие ограничения.
2. Значительная часть открытых данных в России публикуется по метод рекомендациям Минэка. Они очень плохо написаны, индексировать сайты публикующие данные по ним сложно, но возможно. Только этот парсер будет только под российские госпорталы, и то не все. И, по большей части, с устаревшими данными.
3. Очень много в РФ своих геопродуктов, самописных порталов данных и тд. Это также требует написания множества парсеров. Штук 40-50. Более менее стандартизированы только порталы NextGIS, Bitrix и Орбис, но их не так много.
4. Часть порталов с данными используют известное ПО типа Ipt, Pure, Figshare и до них пока ещё не дошли руки, но как только дойдут они добавятся в общий индекс.
В итоге, если специально не заморачиваться российской спецификой получится проиндексировать ещё 20-40 каталогов данных через прокси и за счёт парсеров для универсального софта, а в остальном надо приложить существенные усилия чтобы проиндексировать оставшиеся.
В этом смысле, собрать данные, например, по Финляндии гораздо проще. Там уже большая часть каталогов данных проиндексирована, да и не проиндексированные работают на типовом ПО которое тоже скоро будет индексироваться.
Вся эта национальная специфика очень сильно снижает видимость и находимость данных. И в Dateno ещё можно более-менее, но измерить эту доступность, а, к примеру, в Google Dataset Search невозможно даже посмотреть сколько датасетов и источников есть по странам.
#opendata #dateno #datasets #datacatalogs
В продолжение размышлений о поиске геоданных и связанных с этим сложностей. Я ранее писал про GeoSeer, единственный известный мне поисковик геоданных в мире, но и он сравнительно небольшой. А вот в качестве альтернатив ему выступают уже не поисковики, а каталоги георесурсов. В первую очередь поисковики в экосистеме ArcGIS по их каталогам открытых данных и георесурсов и некоторое, небольшое число альтернатив.
Например, Spatineo Directory [1] от финских геоконсалтеров Spatineo. Там более 87 тысяч георесурсов, в виде точек API по стандартам WFS, WMS, WMTS, но без сбора информации о слоях, поэтому это не поисковик, а именно каталог. Его существенный минус в то что более менее там систематизированы только точки API из развитых стран.
Другой, неожиданно, государственный проект это FGDS Status Checker [2] гигантский каталог геовебсервисов созданный как сервис проверки их доступности. Список вебсервисов там огромный, но почти полностью ориентированный на США и почти не охватывающий морские территории. Есть подозрение что Spatineo делали свой каталог с оглядкой именно на этот продукт, поскольку функции схожи.
Но ещё больше каталогов которые прекратили своё существование. К примеру WFS Geodata Catalog от германского GeoClub. Сейчас можно найти только скриншот.
Ещё был Pyxis crawler с каталогом из 29+ тысяч датасетов, вот он ближе к GeoSeer, но индексировал всего 1572 источника и его тоже больше нет. Тоже остался тоже скриншот.
И был ещё такой поисковик Geometa, но теперь даже его скриншот найти оказалось непросто.
Фактических попыток систематизировать и сделать доступными геоданные и геосервисы было много. Можно сказать что у Dateno тоже есть подзадача в части геоданных.
В каталоге Dateno сейчас 4.4 миллиона наборов геоданных извлеченных из 3127 геопорталов. При этом в реестре Dateno всего 5955 геопорталов и после индексации оставшихся объём геоданных существенно вырастет, кроме того много геоданных в других типах дата каталогов: порталах открытых данных, научных репозиториях и тд., это тоже добавит число геоданных.
Но пока приходится держать в голове что в части геоданных относительно сравнимой референсной базой является GeoSeer.
Ссылки:
[1] https://directory.spatineo.com
[2] https://statuschecker.fgdc.gov
#opendata #geodata #datasets #datacatalogs #dateno
Например, Spatineo Directory [1] от финских геоконсалтеров Spatineo. Там более 87 тысяч георесурсов, в виде точек API по стандартам WFS, WMS, WMTS, но без сбора информации о слоях, поэтому это не поисковик, а именно каталог. Его существенный минус в то что более менее там систематизированы только точки API из развитых стран.
Другой, неожиданно, государственный проект это FGDS Status Checker [2] гигантский каталог геовебсервисов созданный как сервис проверки их доступности. Список вебсервисов там огромный, но почти полностью ориентированный на США и почти не охватывающий морские территории. Есть подозрение что Spatineo делали свой каталог с оглядкой именно на этот продукт, поскольку функции схожи.
Но ещё больше каталогов которые прекратили своё существование. К примеру WFS Geodata Catalog от германского GeoClub. Сейчас можно найти только скриншот.
Ещё был Pyxis crawler с каталогом из 29+ тысяч датасетов, вот он ближе к GeoSeer, но индексировал всего 1572 источника и его тоже больше нет. Тоже остался тоже скриншот.
И был ещё такой поисковик Geometa, но теперь даже его скриншот найти оказалось непросто.
Фактических попыток систематизировать и сделать доступными геоданные и геосервисы было много. Можно сказать что у Dateno тоже есть подзадача в части геоданных.
В каталоге Dateno сейчас 4.4 миллиона наборов геоданных извлеченных из 3127 геопорталов. При этом в реестре Dateno всего 5955 геопорталов и после индексации оставшихся объём геоданных существенно вырастет, кроме того много геоданных в других типах дата каталогов: порталах открытых данных, научных репозиториях и тд., это тоже добавит число геоданных.
Но пока приходится держать в голове что в части геоданных относительно сравнимой референсной базой является GeoSeer.
Ссылки:
[1] https://directory.spatineo.com
[2] https://statuschecker.fgdc.gov
#opendata #geodata #datasets #datacatalogs #dateno
Почему я в последнее время много думаю и пишу про геоданные?
Есть 4 основных типов общедоступных данных данных которые собираются в Dateno:
- открытые данные (opendata). С ними всё довольно понятно, их много, не не бесконечно много. Большая часть порталов известны, далее просто длительная методическая работа по их систематизации и сбору датасетов
- научные данные. Тут не всё так понятно, и этих данных по объёму более всего в мире, но в каждой науке свои виды каталогов данных, стандарты и тд. За пределами отдельных научных дисциплин у этих данных не так много пользы
- статистика и индикаторы. Нужны всем, чаще стандартизированы, поддаются систематизированному сбору и "расщепляются" на множество поддатасетов в привязке к конкретным странам и территориям. Много усилий требуется по агрегации национальных каталогов статистики.
- геоданные. Их много, чаще стандартизированы, но поиск и каталогизация явно недостаточны. Предыдущие попытки чаше безуспешны.
Остальные типы данных - это данные для машинного обучения, данные из коммерческих маркетплейсов или датасеты из порталов микроданных (социология), все они сильно меньше количественно.
Существенный количественный рост данных в Dateno будет от трёх категорий: научные данные, данные индикаторов и геоданные.
При этом научные данные можно _очень быстро_ загрузить из 3-4 крупных источников и это добавит +20 млн датасетов и создаст огромные пузыри данных по нескольким языкам, категориям и темам.
Данные индикаторов стремительно превратят Dateno в портал по макроэкономике/макростатистике. Их также можно загрузить +5 млн датасетов в короткое время.
А в агрегированных геоданных сейчас есть объективный "пузырь", огромное число датасетов по Германии отчего в любом поисковике по данным доля геоданных их Германии достигает 40-60% от общего числа. Если не больше.
Конечно, в какой-то момент, можно перестать думать про этот баланс и залить в Dateno несколько десятков миллионов датасетов и уже потом заниматься вопросами качества индекса. Так, например, сделали в агрегаторах научных данных типа SciDb и OpenAIRE. Там очень много мусора который создаёт количество датасетов, но который и почти не найдёшь потому что эти мусорные данные даже не подпадают под фасеты. В общем-то там ставка однозначно сделана на количество датасетов, а в этом смысле нет проблемы достигнуть того же.
#opendata #data #dateno #thoughts #geodata
Есть 4 основных типов общедоступных данных данных которые собираются в Dateno:
- открытые данные (opendata). С ними всё довольно понятно, их много, не не бесконечно много. Большая часть порталов известны, далее просто длительная методическая работа по их систематизации и сбору датасетов
- научные данные. Тут не всё так понятно, и этих данных по объёму более всего в мире, но в каждой науке свои виды каталогов данных, стандарты и тд. За пределами отдельных научных дисциплин у этих данных не так много пользы
- статистика и индикаторы. Нужны всем, чаще стандартизированы, поддаются систематизированному сбору и "расщепляются" на множество поддатасетов в привязке к конкретным странам и территориям. Много усилий требуется по агрегации национальных каталогов статистики.
- геоданные. Их много, чаще стандартизированы, но поиск и каталогизация явно недостаточны. Предыдущие попытки чаше безуспешны.
Остальные типы данных - это данные для машинного обучения, данные из коммерческих маркетплейсов или датасеты из порталов микроданных (социология), все они сильно меньше количественно.
Существенный количественный рост данных в Dateno будет от трёх категорий: научные данные, данные индикаторов и геоданные.
При этом научные данные можно _очень быстро_ загрузить из 3-4 крупных источников и это добавит +20 млн датасетов и создаст огромные пузыри данных по нескольким языкам, категориям и темам.
Данные индикаторов стремительно превратят Dateno в портал по макроэкономике/макростатистике. Их также можно загрузить +5 млн датасетов в короткое время.
А в агрегированных геоданных сейчас есть объективный "пузырь", огромное число датасетов по Германии отчего в любом поисковике по данным доля геоданных их Германии достигает 40-60% от общего числа. Если не больше.
Конечно, в какой-то момент, можно перестать думать про этот баланс и залить в Dateno несколько десятков миллионов датасетов и уже потом заниматься вопросами качества индекса. Так, например, сделали в агрегаторах научных данных типа SciDb и OpenAIRE. Там очень много мусора который создаёт количество датасетов, но который и почти не найдёшь потому что эти мусорные данные даже не подпадают под фасеты. В общем-то там ставка однозначно сделана на количество датасетов, а в этом смысле нет проблемы достигнуть того же.
#opendata #data #dateno #thoughts #geodata
Читаю научную статью Relationships are Complicated! An Analysis of Relationships Between Datasets on the Web [1] от команды Google Datasets из которой немного больше понятно о том как устроен их Google Dataset Search и не могу не отметить насколько неглубоко они погружаются в тематику того чем занимаются и с насколько небольшими датасетами метаданных работают. В этом случае они работали с датасетом с метаданными о 2.7 миллионов наборах данных.
Но сама проблема которую они поднимают актуальна. К данным не работают индексы цитирования, а взаимосвязи между ними не всегда можно установить простым образом если авторы сами не указали.
Но, почему я лично считаю их статью неглубокой:
1. Кроме базовых стандартов вроде DCAT, Schema.org и других есть куда больше более сложных стандартов публикации данных, особенно научных, где эти взаимоотношения прописаны куда чётче.
2. Взаимоотношения датасетов, по хорошему, это предмет онтологического моделирования и дополнения/расширения/адаптации DCAT
3. Более сложная эвристика не только и не столько в анализе названий, как это делают авторы, а в общих схеме/структуре данных между датасетами, пересечение по содержанию и тд.
Правда работ в этой области не так много, но от ребят из Гугла я ждал большего.
Когда у меня только начинались мысли про Dateno изначально желание было с запустить процесс постоянного обогащения метаданных чтобы сделать поиск насыщеннее: больше фильтров, лучше связи между данными, больше понимания их содержимого и тд. Но, случайно, получилось собрать быстро много датасетов и по прежнему не покидает ощущение что их слишком мало. Данных всегда мало!😜
Но о том что можно выдавать пользователю инфу про схожие датасеты мысли были и есть. Можно использовать тут сложную эвристику или функции а ля ИИ заложенные в поисковый движок, а можно большее знание о самих данных и простые выборки на основе этого.
Ссылки:
[1] https://www.semanticscholar.org/paper/Relationships-are-Complicated%21-An-Analysis-of-on-Lin-Alrashed/97e3cfd5a6cf88f2b1887c5fefc76b528e92f23b
#opendata #datasets #google #dateno #readings
Но сама проблема которую они поднимают актуальна. К данным не работают индексы цитирования, а взаимосвязи между ними не всегда можно установить простым образом если авторы сами не указали.
Но, почему я лично считаю их статью неглубокой:
1. Кроме базовых стандартов вроде DCAT, Schema.org и других есть куда больше более сложных стандартов публикации данных, особенно научных, где эти взаимоотношения прописаны куда чётче.
2. Взаимоотношения датасетов, по хорошему, это предмет онтологического моделирования и дополнения/расширения/адаптации DCAT
3. Более сложная эвристика не только и не столько в анализе названий, как это делают авторы, а в общих схеме/структуре данных между датасетами, пересечение по содержанию и тд.
Правда работ в этой области не так много, но от ребят из Гугла я ждал большего.
Когда у меня только начинались мысли про Dateno изначально желание было с запустить процесс постоянного обогащения метаданных чтобы сделать поиск насыщеннее: больше фильтров, лучше связи между данными, больше понимания их содержимого и тд. Но, случайно, получилось собрать быстро много датасетов и по прежнему не покидает ощущение что их слишком мало. Данных всегда мало!
Но о том что можно выдавать пользователю инфу про схожие датасеты мысли были и есть. Можно использовать тут сложную эвристику или функции а ля ИИ заложенные в поисковый движок, а можно большее знание о самих данных и простые выборки на основе этого.
Ссылки:
[1] https://www.semanticscholar.org/paper/Relationships-are-Complicated%21-An-Analysis-of-on-Lin-Alrashed/97e3cfd5a6cf88f2b1887c5fefc76b528e92f23b
#opendata #datasets #google #dateno #readings
Please open Telegram to view this post
VIEW IN TELEGRAM
www.semanticscholar.org
[PDF] Relationships are Complicated! An Analysis of Relationships Between Datasets on the Web | Semantic Scholar
This paper presents a comprehensive taxonomy of relationships between datasets on the Web and map these relationships to user tasks performed during dataset discovery and demonstrates that machine-learning based methods that use dataset metadata achieve multi…