Глобальная сетчатая проекция для создания тепловых карт

Я собираю приложение, в котором мне нужно создать векторную сетку, которая будет использоваться для хранения и отображения тепловой карты. Он имеет следующие требования:

Может покрыть всю планету.
Подавляющее большинство квадратов сетки не будет иметь значений.
Я не хочу хранить саму сетку; Я хотел бы рассчитать это на лету.
Масштаб данных, используемых с сеткой, может сильно различаться.
Я ожидаю, что мне понадобятся квадраты сетки от 1 км до 100 км в поперечнике. (Я знаю, сколько это будет (~ 510 миллионов за 1 км, ~ 51 000 за 100 км)).
Значения будут накапливаться / агрегироваться для каждого квадрата сетки.
В идеале я мог бы легко использовать меньшие ячейки сетки для вычисления значений для больших, а не сохранять большие значения ячейки сетки.
Я буду использовать OpenLayers для драпировки поверх OpenStreetMap.
Я буду хранить его в SpatiaLite или SQLite, поэтому желательно, чтобы они поддерживались изначально (т.е. для SpatiaLite = поддерживаемый CRS или для SQLite = система, основанная на чистых числах).

Итак, мой вопрос: какую проекцию я должен использовать для этой сетки?

Кроме того - есть ли хороший способ для разработки этого? Кто-нибудь знает о хорошем потенциальном решении этой проблемы или решал подобное раньше? Или можете указать мне полезное направление.

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

Ниже приведена сделанная на заказ версия того, чего я хочу достичь в более широком масштабе. введите описание изображения здесь

Большое спасибо.

— ГИС-Jonathan
источник

Отнюдь не обязательно полный или совершенный ответ, но вы можете зайти в Справочную систему по военным сеткам или, по крайней мере, в Национальную сетку США fgdc.gov/usng, чтобы узнать, как эти организации решают хотя бы аналогичные проблемы. Опять же, не обязательно идеально, но может быть хорошим ориентиром для вашей работы. Надеюсь, поможет.

— Джон

@ Джон - Спасибо; Я наткнулся на Военную сетку в своих собственных поисках, но она использует буквы и цифры, поэтому я не уверен, что она подходит. Материал USNG выглядит интересно, но я не пытаюсь создать свой собственный.

— ГИС-Jonathan

Некоторая информация о характере данных и назначении тепловой карты поможет сфокусировать ответы, которые могут (и должны) варьироваться в зависимости от того, какие географические свойства вы хотите сохранить на картах: ориентация, направление, площадь, форма и т. Д. Поскольку перепроецирование пространственных данных является относительно быстрым и простым, тем не менее, можно привести к тому, что эти проблемы будут игнорироваться и вместо этого сосредоточиться на более фундаментальных проблемах предвзятости и точности: что вы планируете делать с MAUP? Планируете ли вы сделать какие-либо выводы из данных, сгруппированных в эти ячейки сетки? Почему это должна быть векторная структура данных?

— whuber

Не могли бы вы уточнить, какова пространственная размерность данных подмены? то есть данные являются точечными и агрегированы только в ячейке, или это на самом деле данные?

— AnserGIS

@whuber - данные будут использоваться для общего представления непрофессионалам, а не для какой-либо формы пространственного анализа. Таким образом, нет особых предпочтений относительно того, какие географические свойства сохраняются / теряются, и MAUP не имеет значения, поскольку я ищу грубое обобщение данных. Мне нужны только квадраты сетки, чтобы аккуратно наложить что-то вроде плиток OSM. Я стремлюсь к вектору, потому что я храню его в базе данных, и им гораздо легче манипулировать.

— ГИС-Джонатан

Ответы:

Стандартные плитки OSM находятся в Spherical Mercator (SRID = 3857), поэтому, вероятно, будет проще построить вашу сетку, используя ту же проекцию.

Если вы используете SM, вы можете хранить данные на самом высоком уровне масштабирования, поддерживаемом OSM, или на самом высоком уровне масштабирования, который вы позволите пользователям увеличивать. Если охват недостаточен, используйте структуру данных в соответствии с

XIndex, YIndex, Count

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

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

— Рассел в ISC
источник

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

— radouxju
источник

Планируете ли вы рассчитать плотность на проецируемой плоскости или на сферической поверхности и просто отобразить ее таким образом? Кроме того, нужно ли когда-либо распределять прямоугольные данные по нескольким ячейкам сетки?

— AnserGIS

@AnserGIS - Расчет будет происходить на проецируемой плоскости. Прямоугольные данные могут охватывать несколько ячеек сетки. Смотрите также редактирование для получения дополнительной информации.

— ГИС-Джонатан

Это ответ на то, как вы могли бы разработать тепловую карту. Я предлагаю вам взглянуть на систему клеток четверти градуса сетки . QDGC представляет собой способ создания (почти) равных площадей площади, покрывающих определенную область, для представления определенных качеств покрытой области. Сами квадраты основаны на градусах, покрывающих землю. Вокруг экватора у нас 360 линий продольных линий, а с севера на южный полюс - 180 широтных линий. Вместе это дает нам 64800 сегментов или плиток, покрывающих землю. Форма квадратов становится более прямоугольной, чем дольше мы идем на север. На полюсах они совсем не квадратные и даже не прямоугольные, а заканчиваются вытянутыми треугольниками.

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

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

Шейп-файлы для разных континентов и стран доступны для скачивания на моем блог-сайте.

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

— Ragnvald
источник

Спасибо, что поделился; интересная идея. Конечно, кажется, что это может быть полезно для этого. Я предполагаю, что это не будет слишком много усилий, чтобы изменить его так, чтобы он был чисто числовым? т.е. нет "E" или "N"? Это, вероятно, позволило бы более легкую и более эффективную агрегацию клеток, особенно на меридиане или экваторе.

— ГИС-Джонатан

Одна хорошая причина сохранить символы (текст) - сделать их удобочитаемыми для человека. Для использования в атласах и справочных материалах это хорошо подходит для этой цели. Конечно, было бы возможно использовать это, например, это представление: E = 0, W = 1, S = 0, N = 1, A = 1, B = 2, C = 3 и D = 4. Некоторые хорошо написанные фрагменты кода на python или другом соответствующем языке сценариев должны быть в состоянии «преодолеть» проблемы меридиана / экватора при небольших затратах. Конечно, в зависимости от вашего уровня работы QDGC и размера набора данных.

— Рагнвальд