В рубрике как это устроено у них раскрытие данных в штате Нью Джерси, США. Раскрытие данных в штате осуществляется в рамках
NJ Geographic Information Network [1] проекте основанном NJOGIS (New Jersey Office of GIS).
В рамках этого проекта публикуются геоданные штата, начиная с информации о дорогах, кадастровых участках и иных данных большая часть которых доступна через портал в облаке ArcGIS [3], а также на сайте проекта публикуются изображения аэрофотосъёмки c 1920 по 2020 годы [4] доступные, как в виде сервисов по стандарту WMS, так и данных для массовой выгрузки.
Что может показаться необычным, но, на самом деле, уже становится стандартным способом раскрытия многих данных, так это то что все крупные датасеты предоставляются не только для выгрузки по прямым ссылкам, но и изнутри инфраструктуры Amazon AWS с помощью их утилиты для командной строки.
Общий объём данных измеряется десятка терабайт, начиная от простых CSV таблиц, до большого числа GeoTIFF файлов оптимизированных для облаков.
Ссылки:
[1] https://njgin.nj.gov
[2] https://njgin.nj.gov/njgin/about/ogis/
[3] https://njogis-newjersey.opendata.arcgis.com/
[4] https://njgin.nj.gov/njgin/edata/imagery/index.html
#opendata #usa #datasets #geodata #datacatalogs
NJ Geographic Information Network [1] проекте основанном NJOGIS (New Jersey Office of GIS).
В рамках этого проекта публикуются геоданные штата, начиная с информации о дорогах, кадастровых участках и иных данных большая часть которых доступна через портал в облаке ArcGIS [3], а также на сайте проекта публикуются изображения аэрофотосъёмки c 1920 по 2020 годы [4] доступные, как в виде сервисов по стандарту WMS, так и данных для массовой выгрузки.
Что может показаться необычным, но, на самом деле, уже становится стандартным способом раскрытия многих данных, так это то что все крупные датасеты предоставляются не только для выгрузки по прямым ссылкам, но и изнутри инфраструктуры Amazon AWS с помощью их утилиты для командной строки.
Общий объём данных измеряется десятка терабайт, начиная от простых CSV таблиц, до большого числа GeoTIFF файлов оптимизированных для облаков.
Ссылки:
[1] https://njgin.nj.gov
[2] https://njgin.nj.gov/njgin/about/ogis/
[3] https://njogis-newjersey.opendata.arcgis.com/
[4] https://njgin.nj.gov/njgin/edata/imagery/index.html
#opendata #usa #datasets #geodata #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
В рубрике закрытых данных в РФ у геопортала Архангельской области на базе ArcGIS закончилась лицензия [1] и слои данных и сервисы с этого сервера более недоступны. Хотя они всё ещё перечислены в их каталоге геоданных [2]. Похоже что геопортал уже, или перевели, или переводят на российскую ГИС Orbis, у которой открытых слоёв с данными нет и в каталоге они не перечислены, но есть недокументированные API. Не совместимые с ArcGIS или с протоколами OGC.
А каталог геоданных в Архангельской области не обновляли уже 3 года.
Ссылки:
[1] http://maps1.dvinaland.ru/arcgis/rest/services/AdressnPlan/Kadastr/FeatureServer/0
[2] https://maps29.ru/catalog/#
[2] https://maps29.ru
#opendata #closeddata #datasets #russia #geodata
А каталог геоданных в Архангельской области не обновляли уже 3 года.
Ссылки:
[1] http://maps1.dvinaland.ru/arcgis/rest/services/AdressnPlan/Kadastr/FeatureServer/0
[2] https://maps29.ru/catalog/#
[2] https://maps29.ru
#opendata #closeddata #datasets #russia #geodata
Один из крупнейших проектов с большими научными данными - это Китайский национальный центр биоинформации через сайт которого доступно более 53 Петабайт геномных данных [1]. Причём в августе 2021 года их было всего 5 Петабайт и сейчас можно наблюдать 10-кратный рост за 3 года. Такими темпами к концу 2025 года будут все 100 Пб.
Внутри центра много разных баз данных и архивов, от нескольких терабайт, до десятка петабайт. Все данные доступны в форматах специфичных в для биоинформатики и геномных исследований.
Часть этих данных полностью открытые и их можно сразу скачать через FTP или HTTP интерфейсы, часть требуют процедуры получения доступа через профильный комитет доступа к данным Data Access Committee(DAC) [2].
Ссылки:
[1] https://www.cncb.ac.cn/services
[2] https://ngdc.cncb.ac.cn/gsa-human/browse/HRA002875
#opendata #china #data #genomics #bigdata
Внутри центра много разных баз данных и архивов, от нескольких терабайт, до десятка петабайт. Все данные доступны в форматах специфичных в для биоинформатики и геномных исследований.
Часть этих данных полностью открытые и их можно сразу скачать через FTP или HTTP интерфейсы, часть требуют процедуры получения доступа через профильный комитет доступа к данным Data Access Committee(DAC) [2].
Ссылки:
[1] https://www.cncb.ac.cn/services
[2] https://ngdc.cncb.ac.cn/gsa-human/browse/HRA002875
#opendata #china #data #genomics #bigdata
Для тех кто любит заниматься дата сторителлингом (журналисты, аналитики) новый полезный инструмент Closeread [1] позволяющий рассказывать истории внутри HTML документов open source системы документирования Quarto [2].
Quarto сама по себе удобная система и я лично давно смотрю на неё с разных сторон и хочу применить в деле. А Closeread ещё и приближает её к задачам рассказывания историй.
И всё это в Markdown, расширяемо, и тд.
А ещё интересно для публикации научных статей, уже есть примеры их подготовки в Quarto и множество шаблонов [3].
Куда ни посмотри, отличный инструмент.
Ссылки:
[1] https://closeread.netlify.app
[2] https://quarto.org
[3] https://github.com/quarto-journals
#opensource #datajournalism #analytics #datadocs #tools
Quarto сама по себе удобная система и я лично давно смотрю на неё с разных сторон и хочу применить в деле. А Closeread ещё и приближает её к задачам рассказывания историй.
И всё это в Markdown, расширяемо, и тд.
А ещё интересно для публикации научных статей, уже есть примеры их подготовки в Quarto и множество шаблонов [3].
Куда ни посмотри, отличный инструмент.
Ссылки:
[1] https://closeread.netlify.app
[2] https://quarto.org
[3] https://github.com/quarto-journals
#opensource #datajournalism #analytics #datadocs #tools
Кстати, помните я расхваливал китайский портал/агрегатор научных данных SciDb [1].
Так вот его можно не только хвалить. После некоторого исследования его содержания он на 100% соответствует подходу "главное не быть, а казаться". Из заявленных 10 миллионов наборов данных лишь 18 тысяч имеют присоединённые файлы и загружены через сам портал, ещё 754 тысячи собраны из нескольких больших открытых порталов научных данных таких как Zenodo и PANGAEA, а всё остальное - это просто слепок поискового индекса по данным DataCite, сильно замусоренного и, объективно, без значимых метаданных, да и не факт что ссылки на сами данные.
С одной стороны, как обидно, так мало данных. С другой стороны, очередное подтверждение приоритетов индексирования и то что из SciDB можно собирать только те данные что туда были загружены. Другой вопрос что отфильтровать их непросто.
В любом случае удивительно то что вместо индексации тех же геномных данных китайцы пошли по этому пути.
Ссылки:
[1] https://www.scidb.cn
#opendata #china #datasets #datacatalogs
Так вот его можно не только хвалить. После некоторого исследования его содержания он на 100% соответствует подходу "главное не быть, а казаться". Из заявленных 10 миллионов наборов данных лишь 18 тысяч имеют присоединённые файлы и загружены через сам портал, ещё 754 тысячи собраны из нескольких больших открытых порталов научных данных таких как Zenodo и PANGAEA, а всё остальное - это просто слепок поискового индекса по данным DataCite, сильно замусоренного и, объективно, без значимых метаданных, да и не факт что ссылки на сами данные.
С одной стороны, как обидно, так мало данных. С другой стороны, очередное подтверждение приоритетов индексирования и то что из SciDB можно собирать только те данные что туда были загружены. Другой вопрос что отфильтровать их непросто.
В любом случае удивительно то что вместо индексации тех же геномных данных китайцы пошли по этому пути.
Ссылки:
[1] https://www.scidb.cn
#opendata #china #datasets #datacatalogs
В рубрике больших каталогов открытых данных проект DR Power (egriddata.org) [1] с наборами данных моделей для моделирования системы электроэнергетики США. Содержит 272 тысячи наборов данных, фактически модель по каждому объекту, и почти 800 тысяч файлов, в основном, в специализированных для проектирования электроэнергетики форматах.
Все данные опубликованы на портале на базе ПО DKAN, у которого есть открытое API, но которое явно не справляется с такой нагрузкой.
Ссылки:
[1] https://egriddata.org
#opendata #datasets #energy #usa
Все данные опубликованы на портале на базе ПО DKAN, у которого есть открытое API, но которое явно не справляется с такой нагрузкой.
Ссылки:
[1] https://egriddata.org
#opendata #datasets #energy #usa
К вопросу об обработке данных с минимальным футпринтом (потреблением памяти оперативной и при хранении). Я добавил к библиотеке iterable пример по обработке дампов Википедии [1].
Для тех кто не сталкивался ранее, Фонд Викимедия обеспечивает открытость всех вариантов Википедии на сайте дампов [2] где они доступны в виде файлов SQL для загрузки в MySQL совместимые СУБД сжатых GZip и в виде дампов XML сжатых Bzip2. Если хочется поработать с этими данными локально, то надо или воссоздавать SQL базу данных из SQL файлов или работать с большими XML документами внутри которых страницы и другие объекты. Размер этих XML документов может быть весьма велик, до десятков гигабайт и обрабатывать их DOM парсерами весьма накладно.
Для некоторых задач Dateno мне нужны дампы Википедии, так чтобы к ним можно было строить запросы, но без желания воспроизводства инфраструктуры с MySQL и, в целом, хочется обрабатывать их оптимизировано.
Поэтому в примере выше использование библиотеки iterable для преобразования одной из маленьких Wiki (simplewiki) с дампом в 308MB в формате xml.bz2.
Идея в том чтобы:
1. Превратить его в формат для работы с помощью DuckDB
2. Сохранить минимально возможный объем для локального хранения, обработки и анализа.
3. Иметь возможность проделывать вме это на десктопе и с минимальным потреблением оперативной памяти.
В итоге пример можно посмотреть в репозитории. Два скрипта.
- convert.py преобразует xml.bz2 файл в jsonl.zst.
- enrich.py добавляет в полученный файл дополнительные метаданные по категориям вики страниц.
Почему jsonl и zst ? Потому что DuckDB умеет этот формат. После преобразования можно работать с ним напрямую без доп. преобразований.
Итог:
1. Сжатый XML дамп в 308MB преобразуется в сжатый JSONl файл в 325 MB
2. Время преобразования на простом десктопе порядка 2 минут.
3. С итоговым результатом можно работать как с базой данных DuckDB и делать запросы.
Еще лучше было бы будь возможность преобразовать в parquet, но и такой вариант пригоден к дальнейшей работе. К тому же parquet наиболее эффективен на хорошо сжимаемых колонках, а тут много викитекста для которого колоночное сжатие того же эффекта не несёт.
Пример на то и пример чтобы продемонстрировать саму идею. Simplewiki небольшая вики и на русскоязычной или испаноязычной википедиях процесс займёт дольше времени, но всё это демонстрация того что с этими данными можно работать локально и с удобными инструментами.
P.S. Если кто-то знает хорошие движки и примеры быстрого преобразования викидампов в компактные локальные базы данных, поделитесь плз.
Ссылки:
[1] https://github.com/apicrafter/pyiterable/tree/main/examples/simplewiki
[2] https://dumps.wikimedia.org
#dataengineering #datatools #opendata #wikipedia
Для тех кто не сталкивался ранее, Фонд Викимедия обеспечивает открытость всех вариантов Википедии на сайте дампов [2] где они доступны в виде файлов SQL для загрузки в MySQL совместимые СУБД сжатых GZip и в виде дампов XML сжатых Bzip2. Если хочется поработать с этими данными локально, то надо или воссоздавать SQL базу данных из SQL файлов или работать с большими XML документами внутри которых страницы и другие объекты. Размер этих XML документов может быть весьма велик, до десятков гигабайт и обрабатывать их DOM парсерами весьма накладно.
Для некоторых задач Dateno мне нужны дампы Википедии, так чтобы к ним можно было строить запросы, но без желания воспроизводства инфраструктуры с MySQL и, в целом, хочется обрабатывать их оптимизировано.
Поэтому в примере выше использование библиотеки iterable для преобразования одной из маленьких Wiki (simplewiki) с дампом в 308MB в формате xml.bz2.
Идея в том чтобы:
1. Превратить его в формат для работы с помощью DuckDB
2. Сохранить минимально возможный объем для локального хранения, обработки и анализа.
3. Иметь возможность проделывать вме это на десктопе и с минимальным потреблением оперативной памяти.
В итоге пример можно посмотреть в репозитории. Два скрипта.
- convert.py преобразует xml.bz2 файл в jsonl.zst.
- enrich.py добавляет в полученный файл дополнительные метаданные по категориям вики страниц.
Почему jsonl и zst ? Потому что DuckDB умеет этот формат. После преобразования можно работать с ним напрямую без доп. преобразований.
Итог:
1. Сжатый XML дамп в 308MB преобразуется в сжатый JSONl файл в 325 MB
2. Время преобразования на простом десктопе порядка 2 минут.
3. С итоговым результатом можно работать как с базой данных DuckDB и делать запросы.
Еще лучше было бы будь возможность преобразовать в parquet, но и такой вариант пригоден к дальнейшей работе. К тому же parquet наиболее эффективен на хорошо сжимаемых колонках, а тут много викитекста для которого колоночное сжатие того же эффекта не несёт.
Пример на то и пример чтобы продемонстрировать саму идею. Simplewiki небольшая вики и на русскоязычной или испаноязычной википедиях процесс займёт дольше времени, но всё это демонстрация того что с этими данными можно работать локально и с удобными инструментами.
P.S. Если кто-то знает хорошие движки и примеры быстрого преобразования викидампов в компактные локальные базы данных, поделитесь плз.
Ссылки:
[1] https://github.com/apicrafter/pyiterable/tree/main/examples/simplewiki
[2] https://dumps.wikimedia.org
#dataengineering #datatools #opendata #wikipedia