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


11

Я збираю додаток, де мені потрібно створити векторну сітку, яка буде використовуватися для зберігання та відображення теплової карти. Він має такі вимоги:

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

Отже, моє питання: Яку проекцію я повинен використовувати для цієї сітки?

Також - чи є хороший спосіб розробити це? Хтось знає про хороше потенційне рішення цієї проблеми чи вирішив подібне раніше? Або може вказати мені в корисному напрямку.

Редагувати регістр використання - я в основному збираю обмежувальні коробки різної форми та розміру. Вони можуть бути будь-якими, розміром від кількох гектарів до тисяч квадратних км. Вони також можуть бути в різних прогнозах.

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

Дуже дякую.


Ні в якому разі не обов'язково є повною чи досконалою відповіддю, але, можливо, ви хочете, щоб Google довідковою системою військової сітки або, принаймні, Національною сіткою США fgdc.gov/usng запропонував кілька ідей щодо того, як ці організації вирішили хоча б подібні проблеми. Знову ж таки, не обов'язково ідеально, але може бути хорошим орієнтиром для вашої роботи. Сподіваюся, це допомагає.
Джон

@John - Спасибі; Я натрапив на військову сітку під час власних пошуків, але вона використовує літери та цифри, тому я не впевнений, що це підходить. Речі в USNG виглядають цікавими, але я не прагну створити свою власну.
GIS-Jonathan

1
Деякі відомості про природу даних та призначення теплової карти допоможуть зосередити відповіді, які можуть (і повинні змінюватися) залежно від того, які географічні властивості ви хочете зберегти на картах: орієнтація, несучість, площа, форма тощо. Оскільки репроектування просторових даних є відносно швидким та простим, можливо, це може призвести до того, щоб зменшити ці проблеми та зосередити увагу на більш фундаментальних зміщеннях та точності: Що планувати робити щодо MAUP? Чи плануєте ви робити будь-які умовиводи з даних, пошитих на ці комірки сітки? Чому це має бути структура векторних даних?
whuber

Чи можете ви пояснити, що таке просторова розмірність даних, що зменшуються? тобто дані є фундаментально точковими і агрегуються лише до комірки, чи це насправді ареальні?
AnserGIS

@whuber - Дані будуть використовуватися для загального представлення користувачам простого користування, а не будь-якої форми просторового аналізу. Таким чином, особливих уподобань щодо географічних властивостей не зберігається / втрачається, і MAUP не має значення, оскільки я прагну грубого узагальнення даних. Мені потрібні лише квадрати сітки, щоб акуратно накладати щось на зразок плитки OSM. Моє бажання вектора полягає в тому, що я зберігаю його в базі даних і цим набагато простіше маніпулювати.
ГІС-Джонатан

Відповіді:


3

Стандартні плитки OSM є в сферичному Меркаторі (SRID = 3857), тому, ймовірно, буде найпростіше побудувати вашу сітку, використовуючи ту саму проекцію.

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

XIndex, YIndex, кол

де індекси - це індекси в сітці плитки при бажаному рівні збільшення, count - це кількість функцій, які перетинають цю плитку, і не включають записи для точок, де кількість дорівнює нулю. Тоді ви можете просто вибрати підрахунок за індексом або на нижчих рівнях масштабування вибрати суму підрахунку за діапазоном індексу, знаючи, що якщо запит не повертає нічого, то для даного регіону немає нічого.

Це, звичайно, абстракція, я припускаю, що програмний рівень між цим та вашим рендерінгом теплової карти. Більш детальний опис того, як ви будете надавати теплову карту, допоможе мені дати кращі поради.


3

Значення, що зберігається в комірці з теплової карти, часто нормалізується за її площею. У цьому випадку я б скоріше запропонував проекцію на рівну площу, щоб ви могли легко агрегуватись до більшого масштабу


Ви плануєте обчислити щільність на проектованій площині або на сферичній поверхні і просто відобразити її таким чином? Крім того, чи потрібно коли-небудь прямокутні дані розподіляти через більше однієї комірки сітки?
AnserGIS

@AnserGIS - Розрахунок відбуватиметься на прогнозованій площині. Прямокутні дані можуть охоплювати декілька комірок сітки. Дивіться також редагування для отримання додаткової інформації.
GIS-Jonathan

2

Це відповідь на те, як можна створити теплову карту. Моя пропозиція полягає в тому, щоб ви заглянули в систему клітинної сітки квартальної ступеня . QDGC являє собою спосіб створення (майже) рівних квадратів площі, що охоплюють конкретну площу, щоб представити конкретні якості охопленої території. Самі квадрати базуються на градусних площах, що покривають землю. Навколо екватора у нас є 360 поздовжніх ліній, а з півночі на південь полюс - 180 широтних ліній. Разом це дає нам 64800 сегментів або плиток, що покривають землю. Форма квадратів стає більш прямокутною, чим довше ми на північ. На стовпах вони зовсім не квадратні або навіть прямокутні, але закінчуються витягнутими трикутниками.

Осередки сітки можна розділити на чотири, а отримані комірки сітки знову розділити на чотири. Система забезпечує користувача передбачуваною умовою іменування. Обчислюючи площі для різних комірок сітки, вони повинні бути придатними для презентації залежно від площі. Номенклатура клітинних сіток кварталу ступеня є рекурсивною.

Більш детальна інформація та посилання на деякі інші системи також доступні у статті, опублікованій кілька років тому. Стандарт використовується в кількох африканських атласах для екологічної інформації.

Форми файлів для різних континентів та країн доступні для завантаження на моєму блозі.

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


1
Дякую, що поділились; цікава ідея. Звичайно, здається, що це може бути корисним для цього. Я припускаю, що не було б занадто багато зусиль, щоб змінити це так, щоб воно було чисто числовим? тобто немає "E" чи "N"? Це, ймовірно, дозволило б простіше та ефективніше агрегувати клітини, особливо на меридіані чи екваторі.
ГІС-Джонатан

Однією з вагомих причин зберегти персонажів (текст) є збереження його у читанні. Для використання в атласах та людських посиланнях він добре відповідає цілі. Звичайно, можливо, використовуючи це, наприклад, таке подання: E = 0, W = 1, S = 0, N = 1, A = 1, B = 2, C = 3 і D = 4. Деякі добре написані фрагменти коду на пітоні чи іншій відповідній мові сценаріїв повинні мати можливість "вирішувати" виклики меридіана / екватора за невеликих витрат. Звичайно залежно від рівня роботи QDGC та розміру набору даних.
ragnvald
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.