Створення векторних полігонів із ефективністю візуалізації на зразок GISCloud?


59

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

Наскільки мені відомо, є 3 конкретні варіанти досягнення цього через канву, SVG, Flash.

Flash здається, що це було б найкращим рішенням, якби він працював на яблучних iphone / ipads, оскільки, схоже, забезпечує найшвидший показ і найчистіший дисплей. Полотно, здається, є другим найкращим вибором, але займає ДУЖЕ довго, якщо у вас сотні полігонів відображаються на карті, тоді як SVG займає ще більше часу для візуалізації.

Я майже втратив надію на пошук вирішення цієї проблеми, але сьогодні я натрапив на компанію GISCloud http://www.giscloud.com (наразі знаходиться в бета-версії з безкоштовною реєстрацією).

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

Погляньте на себе, переглянувши цю дивовижну демонстрацію: http://www.giscloud.com/map/284/africa

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

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


Тут я також повинен зазначити, що після того, як giscloud завантажує дані на сторінку, що нависає над вектором, негайно змінює колір, не створюючи нового запиту.

ПРИКЛАДИ:

Я припускаю, що структура URL дотримується стандартної логіки обслуговування плитки (наприклад, третя остання папка має рівень масштабування ...).

У будь-якому випадку я проаналізував фактичні дані цих файлів json, і, схоже, логіка, яку вони використовують, дотримується певного типу логіки, за допомогою якої вони створюють свої вектори просто на основі цих значень даних:

  • ширина / висота: вони визначають ширину та висоту даних, що подаються у кожному запиті json
  • пікселів: тут вони визначають значення пікселів, які, я вважаю, якимось чином стосується деяких загальних координат пікселів x / y для узагальнених рівнів точок? Я здогадуюсь, що вони якось мають спосіб автоматичного спрощення регіону залежно від рівня збільшення. Я припускаю, що вони використовують піксельні координати. Я здогадуюсь, вони різко зменшують розмір даних, які потрібно завантажити, порівняно з даними lat / long.
  • стилі: тут вони визначають два значення css RGB. "F", що представляє колір файлу багатокутника, і "S", що представляє колір межі полігона.
  • geom: ось де я здогадуюсь, вони якимось чином конкретно визначають кожен полігон у плитці, що завантажується, де такі дані визначаються на основі вікна контейнера карт. Що також цікаво, це те, що кожен запис має значення "S", яке, я вважаю, використовується як необов'язковий атрибут або значення посилання на функцію, і в кінці кожного запису тут є область, яка, здається, визначає конкретний векторний ідентифікатор разом із ідентифікатор шару, який я здогадуюсь, використовується для того, щоб якось приєднатись до даних кожного виклику плитки json, що викликається.

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

Ось вилучена розбивка одного з цих запитів:

{"width":256,"height":256,"tile":
{"pixels":
[0,6461,-1,0,5,148,0,509,-1,10715,-1,1,-1,251,-1,1,-1,1,-1,251,-2,3,-1,255,-1,249,-2,5,-2,247,-1,509,-3,251,-1,2,-2,253,-2,252,-2,254,-1,255,-1,254,-1,255,-1,1276,-2,13,-1,233,-1,2,-1,253,-1,1,-1,255,-1,247,-1,1306,-1,1533,-1,1269,-1,1276,-1,2303,-1]},

"styles":
[{"f":"rgb(99,230,101)","s":"rgb(5,148,0)","lw":"0"}],

"geom":
[
{"s":0,"p":[4,143,5,144,3,146,1,146,2,143,4,143],"c":"layer1156_5098"},
{"s":0,"p":[-2,143,0,140,2,141,2,144,1,146,-2,144,-2,143],"c":"layer1156_5067"},
{"s":0,"p":[7,143,5,144,4,143,2,143,2,141,5,138,6,139,5,141,7,143],"c":"layer1156_5051"},
{"s":0,"p":[10,141,11,137,12,137,14,137,12,142,9,143,9,142,10,141],"c":"layer1156_5041"},
{"s":0,"p":[1,136,0,140,-2,143,-2,136,1,136],"c":"layer1156_5038"},
{"s":0,"p":[8,143,5,141,5,137,8,136,10,137,10,141,8,143],"c":"layer1156_5033"},
{"s":0,"p":[5,137,2,141,0,140,1,136,1,136,2,135,3,136,5,137],"c":"layer1156_5028"},
{"s":0,"p":[10,134,12,136,11,138,8,135,10,134],"c":"layer1156_5020"},
{"s":0,"p":[-2,133,0,136,-2,136,-2,133],"c":"layer1156_5005"},
{...}
...
]
}

Як ми можемо повторити той самий (або подібний) тип швидкості за допомогою постгігів (які я, начебто, також використовую)?


Ах! Не дивіться на файл JSON, подивіться на інші, здавалося б, неважливі образи, які проходять навколо :) Дивіться мою відповідь нижче.
Рагі Ясер Бурхум

"Є 3 конкретні варіанти" ... То що таке Silverlight, подрібнена печінка ?
Кірк Куйкендалл

Silverlight вимагає, щоб його плагін працював, і я не думаю, що це насправді швидше, ніж використовує рішення giscloud, але я не робив жодних прямих порівнянь.
NetConstructor.com

2
Це питання пропонує багато цікавого, для розмови про яке не вписується звичайний формат запитань. Давайте поговоримо про них у розділі Використання векторів у світі веб-карт
matt wilkie

@RagiYaserBurhum Є приємне пояснення того, як це використовувалося для подорожнього ізохронового картографування за допомогою подібної методики: mysociety.org/2012/11/08/…
djq

Відповіді:


56

Я бачив цю техніку, яку застосовували раніше. Мені це пояснив Заїн Мемон (від Trulia), який допоміг дати деякий внесок, коли Міхал Мігурський створював TileStache. Заїн переглянув це, пояснивши свій демонстратор Trulia, який використовує цю техніку на одному з наших старих зустрічей SF GeoMeetup . Насправді, якщо ви наступного тижня перебуваєте в SF (це моя кульгава спроба на штепсельну вилку, він торкнеться цього , тому не соромтесь показуватись :)

Гаразд, тепер до пояснення.

По-перше, ви дивитесь трохи в неправильне місце, дивлячись на файли json вище.

Дозвольте мені пояснити (якомога коротше), чому.

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

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

Чому він порожній? Це не так. Пікселі містять дані - просто не традиційні видимі дані зображення. Вони використовують дуже розумну техніку для передачі даних, закодованих у самі пікселі.

Протягом останнього десятиліття люди торгували читабельністю та портативністю даних форматів за рахунок ефективності зберігання.

Візьмемо цей приклад даних проб xml:

<data>

  <feature>
    <point>
      <x> -32.1231 </x>
      <y> 10.31243 </y>
    </point>
    <type> 
      sold
    </type>
   </feature>

  <feature>
    <point>
      <x> -33.1231 </x>
      <y> 11.31243 </y>
    </point>
    <type> 
      available
    </type>
   </feature>

</data>

Добре, скільки укусів, щоб перенести це? За умови, що ми маємо utf8 (1 байт на символ при роботі з цим вмістом). Ну, у нас є близько 176 символів (без рахунку вкладок чи пробілів), що робить це 176 байтів (це оптимістично з різних причин, які я опускаю заради простоти). Зауважте, це за 2 бали!

І все-таки якась розумна дупа, яка не розуміє, про що він говорить, десь буде стверджувати, що "json дає вам більш високу компресію".

Добре, давайте поставимо ту саму xml дурницю, що й json:

{ "data": [
            "feature" : { "x" : -32.1231, "y" : 10.31243 , "type": "sold" },
            "feature" : { "x" : -33.1231, "y" :11.31243, "type": "avail" },
          ]
}

Скільки байтів тут? Скажіть ~ 115 символів. Я навіть трохи обдурив і зробив її меншою.

Скажіть, що моя область охоплює 256x256 пікселів, і що я на рівні масштабу настільки високий, що кожна функція відображається як один піксель, і у мене так багато функцій, що вона повна. Скільки даних мені потрібно, щоб показати, що 65 536 функцій?

54 символи (або utf bytes - і я навіть ігнорую деякі інші речі) за записом "функції", помноженим x 65,536 = 3,538,944 або приблизно 3,3 МБ

Я думаю, ти зрозумів картину.

Але саме так ми передаємо дані в архітектуру, орієнтовану на сервіс. Зрозуміле роздуте лайно.

Що робити, якщо я хотів перевезти все за бінарною схемою, яку я сам винайшов? Скажіть, що замість цього я кодував цю інформацію в односмуговому зображенні (тобто чорно-білому). І я вирішив, що 0 кошти продаються, а 1 - доступний, а 2 - не знаю. Хек, у 1 байті я маю 256 варіантів, які я можу використовувати - і я використовую лише 2 або три з них для цього прикладу.

Яка вартість зберігання? 256x256x 1 (лише одна смуга). 65 536 байт або 0,06 МБ. І це навіть не враховує інших методів стиснення, які я отримую безкоштовно за кілька десятиліть досліджень стиснення зображень.

У цей момент ви повинні запитати себе, чому люди не просто надсилають дані, закодовані у двійковому форматі, а не серіалізують до json? Ну, по-перше, виявляється, javascript забирає великий час для транспортування бінарних даних , тому люди цього не робили історично.

Деякі люди використовували дивовижну роботу, коли з'явилися нові функції HTML5, зокрема полотна . То що це за дивовижна робота? Виявляється, ви можете надсилати дані по дроту, закодованому на зображення, яке видається зображенням, а потім ви можете перенести це зображення на полотно HTML5, що дозволяє безпосередньо маніпулювати пікселями ! Тепер у вас є спосіб захопити ці дані, розшифрувати їх на стороні клієнта та генерувати об’єкти json у клієнта.

Зупиніться на мить і подумайте над цим.

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

Полотно HTML навіть не потрібно використовувати для малювання, воно використовується лише як двійковий механізм декодування!

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

Тож як ви кодувати їх на стороні сервера? Добре, вам потрібно узагальнити дані на стороні сервера та створити значущу плитку для кожного рівня збільшення, на якому дані кодуються. В даний час для цього вам доведеться запустити своє власне - рішення з відкритим кодом з відкритого коду не існує, але у вас є всі інструменти, необхідні для цього. PostGIS зробить узагальнення через GEOS, TileCache можна використовувати для кешування та допоможе вам запустити генерацію плиток. На стороні клієнта вам потрібно буде використовувати HTML5 Canvas для передачі спеціальних "фальшивих плиток", а потім ви можете використовувати OpenLayers для створення реальних об'єктів javascript на стороні клієнта, які представляють вектори з ефектами миші.

Якщо вам потрібно кодувати більше даних, пам’ятайте, що ви завжди можете генерувати RGBA-зображення на піксель (що дає 4 байти на піксель або 4 294 967 296 цифр, які ви можете представляти на піксель ). Я можу придумати кілька способів скористатися цим :)

Оновлення : відповідь на питання QGIS нижче.

QGIS, як і більшість інших настільних GIS , не мають фіксованого набору масштабів. Вони мають гнучкість масштабування в будь-якому масштабі та просто візуалізації. Чи можуть вони показувати дані з джерел WMS або на основі плиток? Звичайно, вони можуть, але більшу частину часу вони насправді німі: це масштабувати в різній мірі, обчислювати обмежувальне поле, обчислювати необхідну плитку, захоплювати їх, показувати. Більшість випадків вони ігнорують інші речі, як-от кеш-файли заголовків, які дозволять зробити це таким чином, щоб їм не довелося перечитувати. Іноді вони реалізують простий механізм кешування (зберігайте плитку, якщо ви попросите її, перевірте, чи є плитка, не вимагайте). Але цього недостатньо.

За допомогою цієї техніки плитки та вектори потрібно переробляти на кожному масштабі . Чому? Тому що вектори були узагальнені для розміщення масштабів.

Що стосується всього хитрості, пов’язаного з розміщенням плитки на полотні HTML5, щоб ви могли отримати доступ до буферів, ця вся справа не потрібна. QGIS дозволяє писати код на Python та C ++, обидві мови мають чудову підтримку для обробки бінарних буферів, тому ця робота навколо справді не має значення для цієї платформи.

* ОНОВЛЕННЯ 2 **:

Виникло питання про те, як створити узагальнені векторні плитки в першу чергу (дитячий крок 1, перш ніж мати можливість серіалізувати результати на зображення). Можливо, я недостатньо уточнив. Tilestache дозволить вам створювати ефективні "векторні плитки" ваших даних на кожному рівні збільшення (у нього навіть є опція, яка дозволяє вам відсікати або не обрізати дані, коли вона проходить межу плитки). Це гарантує розділення векторів на плитки на різних рівнях збільшення. Я вибрав би варіант "не кліп" (але він вибере довільну плитку там, де вона охоплює більше площі). Тоді ви можете подавати кожен вектор за допомогою опції узагальнення GEOS з великою кількістю, насправді, ви хочете, щоб він був достатньо великим, щоб полілінії та багатокутники руйнувалися на себе, тому що якщо вони є, ви можете вилучити їх із рівня збільшення, оскільки для цього етапу вони є не має значення. Tilestache навіть дозволяє писати прості пітонічні постачальники даних, де ви можете застосувати цю логіку. На цьому етапі ви можете вибирати їх як файли json (як це зроблено з деякими зразками африканських карт) або як серіалізовані геометрії в pngs, як це робиться в інших зразках (або в одному з Trulia), який я подав вище.


2
Поки що кожна людина, яку я бачив, використовуючи цю техніку, не розміщувала код. IMHO, оскільки важлива частина насправді відбувається на сервері, і для цього немає "стандарту" і тому, що вибір того, що означає кожен піксель (1 = продано, 2 = доступ і т. Д.) Настільки специфічний для вашої поточної карти, що цей код швидше за все, не "родовий".
Рагі Ясер Бурхум

1
Що стосується QGIS, то відповідь трохи більше задіяний, я оновлю свою відповідь по дорозі на роботу. Не біда, я
сідаю

12
+1 Дякую за те, що ви не
стислили

1
Ви можете це зробити з Silverlight або Flash напевно. Проте, пам'ятайте , що важлива частина відбувається на сервері , флеш або Silverlight не матиме , що більшу частину допомоги.
Рагі Ясер Бурхум

2
Через чотири роки еволюціонувало багато речей, і це текстове поле має лише 500 символів, щоб пояснити це. Підсумок полягає в тому, що WebGL є зрілим і, крім методів серіалізації, люди застосовують дельта-кодування з фіксованою точністю (як ми звикли в 60-х роках) у форматах, таких як Topojson. Це гарна річ. Я хотів би бачити деякі з цих речей у стандартах OGC ... тим не менше, політика навколо ОГК була дуже складною останнім часом. Ось мої почуття від двох років тому: blog.burhum.com/post/50036141569/the-ogc-is-stuck-in-1999
Ragi Yaser Burhum

23

Прямо від розробника Діно Равнича в останній публікації списку розсилки :

Не великий секрет, як ми це зробили, тому я би радий поділитися цим із вами. Ключ полягає у двох речах:

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

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

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

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

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

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


Частина, яка мене тут бентежить, полягає в тому, що, схоже, запити надсилаються до поштових служб, і замість того, щоб повернути стандартні геоджейсони з значеннями lat / long, вони здаються (в режимі реального часу) перетворенням lat / long значень в координати xyz і виплюнення їх на основі необхідного рівня збільшення та плитки карти. Як ви думаєте, що ви використовуєте для досягнення цих швидкостей?
NetConstructor.com

@netconstructor Можливо, геометрія вже зберігається в xyz геометрії, тому не потрібно конвертувати?
geographika

відносні координати xyz, ймовірно, коротші, ніж відносна ширина / довга, потребуючи меншої пропускної здатності.
Меттью Снейп

правильно, але вони перетворюють ці дані на льоту
NetConstructor.com

17

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

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

Спочатку ми почали з доставки плиток карт у вигляді SWF, а останнім часом ми просто включили вихід у JSON, щоб ми могли використовувати полотно HTML5 для візуалізації графіки. Нижче ви можете знайти еталон порівняння цього типу векторної технології з растровою технологією (mapnik). Для справедливого порівняння шукайте результати лише в режимі CGI.

http://www.giscloud.com/blog/realtime-map-tile-rendering-benchmark-rasters-vs-vectors/

Ми плануємо надати цю технологію в якості сервісу розміщення плиток для карт. Ідея полягає у розміщенні ваших геоданих у хмарі та за допомогою HTML5 доставляти їх у будь-який клієнт карти з високою швидкістю, без необхідності попереднього кешування плиток. Якщо ви зацікавлені приєднатися до цієї бета-версії, не соромтесь звертатися до нас тут: http://www.giscloud.com/contact/


1
Думка цікаво використовувати плитки для векторних даних (це виглядає як ще одне формулювання для "просторової індексації"). Як ви маєте справу з особливостями, що перетинають кілька плиток? Вони вирізані?
липень

3
так, вектори притиснуті до плитки
Діно Равнич

14

Схоже, дуже схоже питання нещодавно було задано на форумі OSGeo Open Layers , де розробники GIS Cloud описували свій підхід, що є цікавим поєднанням геометрії GeoJSON та статичних пікселів. Вони фактично генерують всі векторні плитки на льоту, замість того, щоб використовувати попередньо вбудований кеш файлів GeoJSON.

Esri реалізувала аналогічний підхід, використовуючи ArcGIS Server та Feature Layers , які дозволяють узагальнити геометрії на льоту та надсилати їх по дроту як JSON.

Для прямого методу, який ви можете реально реалізувати зараз, ви можете створити векторні плитки за допомогою Tilestache (який підтримує PostGIS ) і споживати їх у Polymaps . Полімапи використовують SVG, але продуктивність досить хороша , і CSS правила стилізації елементів карти, тому візуалізація функцій повністю залежить від вас. Ось публікація в блозі, яка працює через щось подібне до того, що ви запитуєте.


1
@wwnick - Дякую за вашу відповідь, але здається, що GisCloud.com використовує деякі додаткові методи, які дозволяють їм отримати таку дивовижну потужність обробки, не потребуючи кешування елементів, що означає, що все є в реальному часі. Я додав щедрого питання до цього питання і сподівався, що ви, можливо, захочете взяти участь у наданні глибокого рішення. Дякуємо за вашу відповідь поки що!
NetConstructor.com

6

Я провів гру з OpenLayers за допомогою Canvas і отримав розумні результати.

Як було сказано в інших відповідях: щоб доставити та показати вектори в польоті - їх потрібно узагальнити для кожного рівня масштабування та кожного набору даних. Крім того, ви можете використовувати кодування полілінії Google, щоб значно зменшити розмір.

Я використовував простий механізм доставки. Кожна геометрія була функцією JavaScript у відповіді JavaScript HTTP. не настільки просунута, як векторна доставка плитки, але проста та відкрита!

Мені не вдалося спробувати Google Maps v3 з Canvas, але я побачив пару демонстрацій New York Times, які вразили.


Проблема такого підходу полягає в тому, що це викликає не так швидко, як їх рішення, коли стосується 500 000 багатокутників, тобто продуктивність дійсно погана
NetConstructor.com

будь ласка, зверніть увагу на додану суму, і якщо ви можете надати детальне рішення. BTW New York Times, будучи дуже крутим, використовує спалах на відміну від рішення, яке використовує giscloud.com.
NetConstructor.com

ваше посилання офлайн
NetConstructor.com

Так, вибачте з цього приводу - моє «хобі» зараз закінчилося після 4 років майстерності полігонами! GISCloud показує вам, наскільки далеко зайшла технологія з моменту демонстрації перепису населення кілька років тому ... Я видалив згадки про це у вищевказаному коментарі.
мінус34,

1
Ну краще пізно, ніж ніколи! Я оновив речі, щоб вони були максимально "нестандартними" і опублікував код клієнта на GitHub . Налаштування нового коду було заблоковано . Тепер він читає багатокутники безпосередньо з PostGIS таким, який є, і застосовує проріджування на льоту через рамку веб-сервісу PostGIS RESTful ( PRWSF ) до клієнта API JavaScript JavaScript Leaflet. Тут майже не потрібно кодування!
мінус34

6

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

Ключовим рішенням для покращення швидкості передачі та візуалізації мережі векторних даних є узагальнення їх відповідно до рівня масштабування: Перенесення та візуалізація на високому рівні збільшення тисячі об'єктів, розроблених для значно нижчого рівня масштабування, дуже забирає багато часу (а також марний, оскільки кінцевий показ зазвичай не є розбірливим - див., наприклад, це зображення ). Для цього необхідно, що ваша база даних сервера postgis має бути багатомасштабною : для кожного рівня масштабування повинно бути одне представлення об'єкта, придатного для цього рівня масштабування. Ці різні уявлення можна обчислити автоматично, використовуючи методи узагальнення. Крім того, векторні дані, що надсилаються сервером клієнтові, не повинні залежати лише від просторового розширення, а й від рівня масштабування: сервер надсилає відповідні дані залежно від рівня масштабування. Такий підхід захищений у цій чудовій роботі :-)


0

Є цікавий документ, демонстраційний та вихідний код програмного забезпечення, розробленого Stanford Visualization Group, який використовує datacube для кожної плитки для візуалізації та дослідження великого географічного набору даних. Він може використовуватися лише для набору даних точок, але може бути цікавим способом.

http://vis.stanford.edu/papers/immens

Візуальність із їхньою платформою CartoDB та бібліотекою під назвою Torque також експериментують, як отримати великий об'єм даних.

http://cartodb.github.io/torque/
https://github.com/CartoDB/torque/tree/new_torque

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.