Wydajność procesów tworzenia kafelków map Google

11

Wiem, że to pytanie jest dość niejasne, ale proszę o wyrozumiałość. Próbuję dowiedzieć się, jaki rodzaj wydajności produktu - w szczególności czas - ludzie widzieli dla różnych metodologii, których używali do tworzenia kafelków map google / bing. Istnieje wiele metod, jak to zrobić (np. Gdal2tiles, FME, maptiler itp.). Początkowa próba po prostu zrobienia dużego PNG i utworzenia kafelków za pomocą imagemagick, na całkiem przyzwoitym serwerze linux, przyniosła całkiem długi czas przetwarzania, więc chciałem zobaczyć, co inni ludzie używają w produkcji. Nowe kafelki musiałyby być generowane co najmniej codziennie, więc czas realizacji jest bardzo ważny.

Jedynym prawdziwym wymogiem jest to, że może działać na serwerze Linux. Oczywiście, darmowe jest lepsze, ale nie chcę się do tego ograniczać. Dane wejściowe mogą być surowymi danymi gridowymi / rastrowymi lub dużym obrazem. Dane wyjściowe muszą być kafelkami obrazów, które mogą być używane w stanie obecnym na mapach Google lub Bing.

Dla porównania powiem, że czasy powinny dotyczyć poziomu powiększenia mapy google 7.

Doceniam pomoc wszystkich i jeszcze raz przepraszam za to, jak niewyraźne wydaje się to pytanie.

AKTUALIZACJA: Jeśli chodzi o dane wejściowe, obecnie mam wiele (surowych) źródeł danych w różnych formatach: netCDF, GRIB, GRIB2. Oprócz samych nieprzetworzonych danych mam również możliwość generowania naprawdę dużych obrazów tych danych, które można następnie pociąć na plasterki / płytki.

Idealnie byłoby po prostu pociąć obraz, ale jestem gotów spróbować wszystkiego, co da mi najszybsze wyniki.

google-maps gdal tiles bing-maps optimization malonso
źródło
Zalecamy korzystanie z programu Adobe Fireworks w celu wysokiej optymalizacji końcowych obrazów, których używasz - adobe.com/products/fireworks - nawet eksportowanych z Photoshopa, a następnie zoptymalizowanych w programie Fireworks zmniejszonych rozmiarów plików do 75% (png)
Mapperz
@ Mapperz - opracował „zoptymalizowany w Fireworks”?
Derek Swingley,
Myślę, że musisz rozwinąć swoje dane wejściowe i jeśli potrzebujesz więcej przetwarzania lub jeśli tylko je kroisz.
Ian Turton
4
@Mapperz: Darmowy odpowiednik to pngcrush i pngnq do kwantyzacji. - Obecnie pracuję nad podobnym zadaniem i mam automatyczny łańcuch gdal2tiles> pngnq> pngcrush> pregenerujące miniatury za pomocą imagemagick dla każdego pliku, który jest wprowadzany do systemu - nie mogę twierdzić, że jest szybki, ale automatyzacja wymaga dużego obciążenia . A w moim przypadku nie ma aktualizacji, to ogień i zapomnij.
relet
1
@relet - Jakieś czasy, które możesz przekazać? Jaka jest Twoja konfiguracja sprzętowa? Dzięki
malonso,

Odpowiedzi:

3

Oto niektóre z moich wyników dla następującego pliku rastrowego:

JPEG 14456x14490 14456x14490+0+0 DirectClass 62mb

$ gdal2tiles [...]

Generating Base Tiles:
0...10...20...30...40...50...60...70...80...90...100 - done.
Generating Overview Tiles:
0...10...20...30...40...50...60...70...80...90...100 - done.

real    5m7.675s
user    5m5.070s
sys  0m2.060s

$ time [pngnq && pngcrush za każdy kafelek, łącznie 4500]

real    9m32.827s
user    18m34.190s
sys  0m27.230s

Tak, to w kilka minut - Zoptymalizowałem rozmiar wyjściowy, a nie szybkość. Maszyna to wirtualny Intel Xeon 2x3GHz, 4G pamięci. (I oczywiście gdal2tiles mógłby skorzystać z pewnej równoległości).

relet
źródło
Czy przykładowy plik jest dostępny do pobrania? Chciałbym porównać wydajność z maptiler.com
Klokan Technologies GmbH 19.04.16
Niestety, tymczasem zmieniłem pracę. Prawdopodobnie mógłbym dowiedzieć się, gdzie są opublikowane kafelki, ale nie oryginalny plik.
relet
6

Miałem gdal2tilesproblem z dość długim przetwarzaniem dość dużego tiffa (380 MB, 39 K x 10 K pikseli) na kafelki Google dla zakresów zoomu 0-12. Na Ubuntu 12.04 64bit bez wieloprocesowości przetworzenie tiffa na 1,99 miliona płytek przy 3,3 GB zajęło prawie cały dzień (8 godzin). Jak wspomniano powyżej @Stephan Talpalaru, kluczem do sukcesu jest gdal2tiles równoległe bieganie . Utwórz kopię zapasową oryginału gdal2tiles.py, a następnie zainstaluj łatkę z katalogu, w którym znajduje się gdal2tiles.py(mój był /usr/local/bin):

$ sudo patch -p0 -i gdal2tiles_parallelize_base_and_overview_tiles.patch

Teraz biegnij gdal2tilestak jak zwykle. Mam niewiarygodny wzrost wydajności, gdy wszystkie 4 moje rdzenie (Intel Core i7 3,4 GHz) są zablokowane:

$ time gdal2tiles.py -p raster -z 0-12 -w none ds1105-2235df023_23_b.tif gdal-tiles12
Generating Base Tiles:
0...10...20...30...40...50...60...70...80...90...100 - done.
Generating Overview Tiles:
0...10...20...30...40...50...60...70...80...90...100 - done.

real    39m8.242s
user    104m6.808s
sys 9m16.036s

Tak więc od ~ 8 godzin do 39 MINUT . Zmieniacz gier.

Chad Cooper
źródło
5

Wypróbuj równoległą wersję gdal2tiles.py: http://trac.osgeo.org/gdal/ticket/4379

Stefan Talpalaru
źródło
1
Czy udało Ci się uruchomić wersję równoległą w systemie Windows? Otrzymuję błędy dostępu do plików w wygenerowanych plikach tymczasowych.
Michalis Avraam,
2

Wspomniałeś o FME i jest kilka liczb na temat tworzenia kafelków map na FMEpedia

To długi artykuł, więc wyciągnąłem odpowiednie części:

Level             Tiles           Minutes (hours)
    8            24,500           18 (0.3)
   10           245,000          105 (1.75)
   11         1,000,000          384 (6.4)

Jest to proces wieloobsługowy z serwerem FME. Możesz również sprawdzić ten post autorstwa Paula Bissetta na blogu WeoGeo: http://www.weogeo.com/blog/Scaling_FME_Engines_on_WeoGeo.html

Ma świetny film pokazujący, jak przetwarzać takie dane w chmurze - w zasadzie uruchamiając kilka wirtualnych maszyn Amazon, aby rozłożyć obciążenie przetwarzania i zrobić to bardzo szybko.

Mark Ireland
źródło