В рубрике как это устроено у них один из крупнейших научных репозиториев данных в мире ScienceBase.gov [1] поддерживается Геологической службой США (USGS) и содержит более чем 18.7 миллионов записей включающих наборы данных, точки подключения к API, файлы данных тайлов и многие другие относящиеся к геологии, геодезии, географии и другим гео наукам в США.
Большая часть записей там это разрезанные по регионам очень крупные базы данных такие как: National Elevation Dataset (NED) - 7.4 миллиона записей и
3D Elevation Program (3DEP) - 6.1 миллион записей и так далее.
Многие датасеты в этом репозитории - это описания физических объектов и содержан они, как машиночитаемое представление, так и многочисленные фотографии. Почти у всех датасетов есть геопривязка в форме точки на карте или полигон где находится множество точек/объектов.
Этот каталог по масштабам можно сравнить с Data.one и Pangaea, но по объёму и числу датасетов он гораздо больше.
При этом у него, как и у многих предметно тематических научных репозиториев, собственные API для доступа и форматы публикации метаданных. Это и собственная схема описания данных, и стандарт FGDC используемый в США, и стандарт ISO TC 211.
Важно и то что USGS требует от исследователей публиковать данные в этом репозитории и он непрерывно наполняется результатами профинансированных ими проектами, данных геофондов на уровне штатов и результатами работ научных институтов.
А с точки зрения поиска, это довольно хорошо структурированный репозиторий, с возможностью фасетного поиска. Из видимых недостатков у него нет bulk выгрузки метаданных, так чтобы была возможность выгрузить все записи целиком, да и некоторые датасеты тоже. Это кажется очень логичным, изучая практики публикации геномных данных, с одной стороны, с другой стороны в геологии нет такой всеобъемлющей широты использования онтологий и бесконечного числа идентификаторов. Датасеты менее гомогенны, но и в этом направлении явно идёт постепенная работа.
Ссылки:
[1] https://www.sciencebase.gov
#opendata #datasets #datacatalogs #geology #geography #geodata
Большая часть записей там это разрезанные по регионам очень крупные базы данных такие как: National Elevation Dataset (NED) - 7.4 миллиона записей и
3D Elevation Program (3DEP) - 6.1 миллион записей и так далее.
Многие датасеты в этом репозитории - это описания физических объектов и содержан они, как машиночитаемое представление, так и многочисленные фотографии. Почти у всех датасетов есть геопривязка в форме точки на карте или полигон где находится множество точек/объектов.
Этот каталог по масштабам можно сравнить с Data.one и Pangaea, но по объёму и числу датасетов он гораздо больше.
При этом у него, как и у многих предметно тематических научных репозиториев, собственные API для доступа и форматы публикации метаданных. Это и собственная схема описания данных, и стандарт FGDC используемый в США, и стандарт ISO TC 211.
Важно и то что USGS требует от исследователей публиковать данные в этом репозитории и он непрерывно наполняется результатами профинансированных ими проектами, данных геофондов на уровне штатов и результатами работ научных институтов.
А с точки зрения поиска, это довольно хорошо структурированный репозиторий, с возможностью фасетного поиска. Из видимых недостатков у него нет bulk выгрузки метаданных, так чтобы была возможность выгрузить все записи целиком, да и некоторые датасеты тоже. Это кажется очень логичным, изучая практики публикации геномных данных, с одной стороны, с другой стороны в геологии нет такой всеобъемлющей широты использования онтологий и бесконечного числа идентификаторов. Датасеты менее гомогенны, но и в этом направлении явно идёт постепенная работа.
Ссылки:
[1] https://www.sciencebase.gov
#opendata #datasets #datacatalogs #geology #geography #geodata
Большая область работы в дата инженерии - это геокодирование данных. Причём относится это не только к датасетам, но ко всем цифровым объектам для которых привязка к конкретной геолокации необходима.
Например, в Dateno есть геопривязка датасетов к странам, макрорегионам и субрегионам (территориям). Она, в большей части, реализована относительно просто. Изначально полувручную-полуавтоматически геокодированы источники данных, а их всего около 10 тысяч и далее с них геопривязка транслируется на датасеты. Это довольно простая логика работающая со всеми муниципальными и региональными порталами данных и куда хуже работающая в отношении национальных порталов данных, реестров индикаторов, каталогов научных данных и так далее.
Главная причина в том что национальные порталы часто агрегируют данные из локальных, научные данные могут происходить из любой точки мира, а индикаторы могут быть как глобальными, так и локализованными до стран, групп стран и отдельных городов и территорий.
Для самых крупных каталогов данных у нас есть дополнительная геопривязка датасетов через простое геокодирование стран по внутреннему справочнику и использованию pycountry.
Но это всё даёт геокодирование, максимум, 40-60% всех датасетов и многие значимые наборы данных привязки к конкретной стране/региону могут не иметь.
Что с этим делать?
Один путь - это использовать существующие открытые и коммерческие API геокодирования такие как Nominatim, Geonames, Googe, Yandex, Bing и другие. У автора библиотеки geocoder они хорошо систематизированы и можно использовать её как универсальный интерфейс, но одно дело когда надо геокодировать тысячи объектов и совсем другое когда десятки миллионов. Кроме того остаётся то ограничение что может не быть отдельных полей с данными геопривязки у первичных датасетов. На национальном портале могут быть опубликованы данные у которых геопривязка может быть только в названии или в описании, но не где-то отдельным полем.
Вот, например, набор данных исторических бюджетов города Мальмо в Швеции на общеевропейском портале открытых данных. Там геопривязка есть только до страны поскольку сам датасет в общеевропейский портал попадает со шведского национального портала открытых данных. При этом в публикации на шведском портале открытых данных можно через API узнать что там есть геокод города Malmo через Geonames и есть он в оригинальных данных на портале данных города.
При этом геоидентифицирующие признаки могут быть разнообразны, начиная со ссылок на geonames, продолжая ссылками на справочники Евросоюза, тэгами и просто текстовым описанием на любом условно языке.
Другой путь в попытке применить LLM для геокодирования в идеале так чтобы отправить туда JSON объект с кучей атрибутов и запросом на то чтобы по нему получить код территории/страны по ISO 3166-1 или ISO 3166-2.
Что выглядит интересно ещё и потому что у всех API геокодирования есть серьёзные ограничения на число запросов и на их кеширование.
И, наконец, данные о геопривязке могут быть в самих данных датасета, но это самая дорогая операция поскольку требует уже принципиально других вычислительных усилий.
#opendata #dateno #geodata #thoughts
Например, в Dateno есть геопривязка датасетов к странам, макрорегионам и субрегионам (территориям). Она, в большей части, реализована относительно просто. Изначально полувручную-полуавтоматически геокодированы источники данных, а их всего около 10 тысяч и далее с них геопривязка транслируется на датасеты. Это довольно простая логика работающая со всеми муниципальными и региональными порталами данных и куда хуже работающая в отношении национальных порталов данных, реестров индикаторов, каталогов научных данных и так далее.
Главная причина в том что национальные порталы часто агрегируют данные из локальных, научные данные могут происходить из любой точки мира, а индикаторы могут быть как глобальными, так и локализованными до стран, групп стран и отдельных городов и территорий.
Для самых крупных каталогов данных у нас есть дополнительная геопривязка датасетов через простое геокодирование стран по внутреннему справочнику и использованию pycountry.
Но это всё даёт геокодирование, максимум, 40-60% всех датасетов и многие значимые наборы данных привязки к конкретной стране/региону могут не иметь.
Что с этим делать?
Один путь - это использовать существующие открытые и коммерческие API геокодирования такие как Nominatim, Geonames, Googe, Yandex, Bing и другие. У автора библиотеки geocoder они хорошо систематизированы и можно использовать её как универсальный интерфейс, но одно дело когда надо геокодировать тысячи объектов и совсем другое когда десятки миллионов. Кроме того остаётся то ограничение что может не быть отдельных полей с данными геопривязки у первичных датасетов. На национальном портале могут быть опубликованы данные у которых геопривязка может быть только в названии или в описании, но не где-то отдельным полем.
Вот, например, набор данных исторических бюджетов города Мальмо в Швеции на общеевропейском портале открытых данных. Там геопривязка есть только до страны поскольку сам датасет в общеевропейский портал попадает со шведского национального портала открытых данных. При этом в публикации на шведском портале открытых данных можно через API узнать что там есть геокод города Malmo через Geonames и есть он в оригинальных данных на портале данных города.
При этом геоидентифицирующие признаки могут быть разнообразны, начиная со ссылок на geonames, продолжая ссылками на справочники Евросоюза, тэгами и просто текстовым описанием на любом условно языке.
Другой путь в попытке применить LLM для геокодирования в идеале так чтобы отправить туда JSON объект с кучей атрибутов и запросом на то чтобы по нему получить код территории/страны по ISO 3166-1 или ISO 3166-2.
Что выглядит интересно ещё и потому что у всех API геокодирования есть серьёзные ограничения на число запросов и на их кеширование.
И, наконец, данные о геопривязке могут быть в самих данных датасета, но это самая дорогая операция поскольку требует уже принципиально других вычислительных усилий.
#opendata #dateno #geodata #thoughts