2010-02-05 29 views
7

SpatialKey generuje kilka naprawdę ładnie wyglądających map ciepła i przyglądamy się temu, co jest zaangażowane w to w wewnętrznym projekcie wizualizacji dużych ilości punktów. Szukam opinii na temat pomysłów, od czego zacząć (i jest to naprawdę interesujący problem).Generowanie map gęstości/ciepła, takich jak SpatialKey

SpatialKey heatmap http://img697.imageshack.us/img697/7964/resolutiondays508x17550.jpg

Wiemy, że są one za pomocą Flash, i od tego, co możemy powiedzieć, że HeatMap są interaktywne zamiast być renderowane z serwera płytek. Naszym pierwszym przypuszczeniem co do tego, w jaki sposób jest to realizowane, jest to, że serwer dostarcza klientowi Flasha siatkę - każda komórka ma licznik obliczony przez serwer. Następnie klient Flash dokonuje interpolacji na podstawie wartości komórek w siatce, aby uzyskać ładny wynik, który widzisz powyżej.

Na tym etapie interesuje mnie tylko to, w jaki sposób mogą one wydajnie generować sieć po stronie serwera (jeśli nasze założenia dotyczące ich wdrożenia są poprawne). Wydaje się, że wiązałoby się to:

  1. Wykonywanie kwerendy dla tego, co jest aktualnie na mapie granice
  2. Wykonywanie podkwerenda agregacji dla każdej komórki w tych granicach (robi liczenia, sumę lub średnią, jak w powyższym przykładzie) .

Throw robi to na wielu poziomach powiększenia przy rozsądnej rozdzielczości siatki i wydaje się, że potrzebujesz niestandardowego indeksu przestrzennego, aby ten efekt był efektywny.

Czy ktoś wytłumaczy alternatywną trasę? Jeśli to ma znaczenie, jesteśmy przyzwyczajeni tutaj do przechowywania naszych danych w PostgreSQL z PostGIS dla indeksu przestrzennego, ale jestem otwarty na próbowanie czegokolwiek.

Odpowiedz

5

Przypuszczam, że wyobrażam sobie, że zaimplementowali bibliotekę GIS we Flashu po stronie klienta i używają tego do wyświetlania współrzędnych szerokości i długości geograficznej w przestrzeni piksela. Następnie agregują po pikselu, aby określić "wysokość" każdego piksela i renderować go tak, jak renderowałbyś okrąg, ale stosując wypełnienie gradientowe z przezroczystością, z kolorami początkowymi i końcowymi wypełnienia gradientowego określonymi przez wysokość piksel. Wielokrotne okręgi nałożone jedna na drugą stworzą jaśniejsze piksele.

Alternatywą może być zrobienie tego w skali szarości, a następnie odwzorowanie wartości jasności na skalę kolorów. To może być najbardziej wydajne.

Sprzedajemy bardziej tradycyjne mapy ciepła treemap do użytku integracyjnego w aplikacjach do analizy wizualnej (np. SDK map ciepła), a teraz mamy geograficzne mapy ciepła, które koloryzują obszary. Czytamy standardowe mapy ESRI Shapefile i wykonujemy wszystkie projekcje i renderowanie po stronie klienta (w Javie, nie Flash, ale w tej samej koncepcji). Myślę, że SpatialKey robi to samo, ponieważ obsługuje renderowanie wypełnione obszarami, co nie może być zrobione, jeśli używasz serwera kafelkowego, takiego jak Google Maps.

Nie robimy jeszcze takich map gęstości, ale przeprowadziliśmy kilka testów przy użyciu statycznych obrazów jako tła. Jeśli chcesz uzyskać więcej informacji, daj mi znać, a ja mogę zapytać programistę, jak to zrobiliśmy. Wiem, że jesteśmy obecnie w fazie rozwoju w oparciu o więcej funkcji opartych na punktach, ale nie wiem, gdzie mapy gęstości gęstości są jeszcze w harmonogramie.

SpatialKey właśnie napisał dobry post na różnych mapach obszaru wypełnionych ciepłem (np. Mapy tematyczne) i mapach gęstości gęstości. Możesz to sprawdzić pod numerem http://blog.spatialkey.com/2010/02/comparing-thematic-maps-with-density-heatmaps/.

Jeśli wymyślisz dobry sposób tworzenia map ciepła gęstości, chciałbym dowiedzieć się, jak to zrobiłeś, ponieważ byłoby to cennym dodatkiem do naszego zestawu SDK do analizy wizualnej. Powodzenia.

+0

Właśnie zdałem sobie sprawę, że mogłem źle zinterpretować pytanie. Pojawia się pytanie, w jaki sposób uzyskać zestaw danych, który zawiera szerokość, długość i wysokość, a nie jak to zrobić. Ponownie, nie wiedząc, jak SpatialKey to robi, myślę, że masz przynajmniej częściowo rację. Zamiast wykonywać podzapytania dla każdej komórki, które mogą szybko przytłoczyć bazę danych (sieć 10x10 wymagałaby 100 podkwerend), można wykonać następujące czynności: - Po stronie klienta przejść przez szerokość i wysokość powierzchni renderowania wraz ze skalą na długości i szerokości geograficznej –

+0

- Oblicz rozdzielczość długości i szerokości geograficznej, wykonując mapowanie odległości między długością i szerokością geograficzną oraz szerokością i wysokością. To pokazuje efektywną szerokość i wysokość kosza dla każdej komórki z perspektywy szerokości i długości geograficznej - Zapytanie o wszystkie punkty w granicach długości i szerokości geograficznej - Powtórz po kolei każdy punkt i zaokrąglenie do najbliższej długości geograficznej i szerokości geograficznej - Zapisz w wyniku wyszukiwania hashtable z kluczem będącym długość i szerokość geograficzną, a wartość jest liczbą –

+0

- Wynik wyniku jako zestaw danych z trzema kolumnami: długość, szerokość i liczba (np .: wysokość) Klient może wtedy łatwo renderuj ten zestaw danych za pomocą biblioteki GIS na interfejsie użytkownika. Możesz też wstępnie zaprojektować punkty i wysłać je do front-endu za pomocą współrzędnych X, Y pikseli. [Uwaga: Właśnie zdałem sobie sprawę, że moje użycie terminu "wysokość" może być mylące. Dzieje się tak dlatego, że mapa gęstości to zasadniczo kolorowa mapa tolopogiczna z kolorem przedstawiającym wysokość każdego punktu.] –

0

MapReduce dla rzeczywistych łącznej sumy map i coś z Geopatial Indexing dla bazy danych - aby zasilić te zadania MapReduce. Zastanawiam się nad wdrożeniem tego samego podejścia, ale w przypadku interfejsów zamiast map :) MongoDB wydaje się być w tej chwili dobrym rozwiązaniem.