GeoPackage vs MBTiles vs PMTiles do taktycznych map offline

Taktyczna aplikacja polowa stoi i upada na swoim podkładzie mapowym. Gdy żołnierz trzymający telefon znajduje się w dolinie bez zasięgu komórkowego, bez łącza satelitarnego i z baterią, która musi wystarczyć na całą misję, mapa musi już być na urządzeniu — każdy kafelek, każda warstwica, każda droga, spakowane w plik wczytany, zanim operator opuścił bazę. Pytanie o to, który format kontenera przechowuje tę mapę, nie jest kosmetyczne. Decyduje o budżetach przechowywania, wydajności renderowania, narzędziach, których potrzebuje twój pipeline, oraz o tym, czy dane wpadają prosto do ATAK, czy też wymagają konwersji w terenie. To inżynierskie porównanie trzech formatów, które się liczą: GeoPackage, MBTiles i PMTiles.

1. problem podkładu offline

Definiującym ograniczeniem aplikacji polowej jest brak łącza zwrotnego. Nie ma serwera kafelków, do którego można zadzwonić, nie ma CDN, nie ma działającego API. Wszystko, co renderer kiedykolwiek narysuje, musi znajdować się w pamięci lokalnej, zanim urządzenie straci łączność. To zamienia dostarczanie map w problem pakowania: potrzebujesz pojedynczego, kopiowalnego, weryfikowalnego artefaktu, który mieści dane mapowe całego regionu i który mobilny renderer może szybko odpytywać z pamięci flash.

Pamięć jest skończona i wymaga rywalizacji. Wzmocnione urządzenie końcowe z Androidem może przydzielić 16–64 GB na dane misji, dzielone między obrazy, dane wysokościowe, klipy wideo i podkład mapowy. Rastrowy podkład obejmujący cały teatr działań na użytecznych poziomach zoomu może sam zajmować dziesiątki gigabajtów. Format kontenera nie jest więc tylko opakowaniem — jego zachowanie kompresji, struktura piramidy kafelków i koszt zapytań bezpośrednio decydują, ile mapy możesz nieść i jak szybko się ona renderuje.

2. MBTiles — kontener kafelków SQLite

MBTiles to format, który uczynił mapowanie offline czymś powszednim. W swej istocie jest to baza danych SQLite z uzgodnionym schematem: tabela tiles kluczowana poziomem zoomu, kolumną i wierszem, plus tabela metadata z parami nazwa/wartość opisującymi granice, min./maks. zoom, format i atrybucję. Geniusz tkwi w prostocie — każda platforma z biblioteką SQLite (czyli każda platforma mobilna) może go otworzyć i odpytać bez specjalnego sterownika.

MBTiles przechowuje albo kafelki rastrowe (PNG, JPEG, WebP), albo kafelki wektorowe (Mapbox Vector Tiles, protobuf skompresowany gzip). Rastrowe MBTiles to to, czego operatorzy polowi faktycznie najczęściej używali: wstępnie wyrenderowane obrazy lub zeskanowane arkusze topograficzne, pocięte na standardową piramidę kafelków Web Mercator i wciśnięte do bazy danych. Pole format w tabeli metadata mówi klientowi, czy spodziewać się png czy pbf, a konwencja numeracji wierszy TMS (odwrócona w osi y względem XYZ) to ta jedna uporczywa pułapka, która raz dopadnie każdego nowego implementatora.

Powszechność to jego główny atut. MBTiles jest de facto standardem z dekadą narzędzi za sobą i jest lingua franca otwartego ekosystemu mapowania offline. Jeśli musisz wybrać format, który coś dalej w łańcuchu na pewno zrozumie, MBTiles jest bezpiecznym wyborem.

3. PMTiles — pojedynczy plik zoptymalizowany pod chmurę

PMTiles, stworzony przez Brandona Liu, rozwiązuje problem, którego MBTiles nie potrafi: serwowanie kafelków bezpośrednio z pamięci statycznej bez procesu bazodanowego. Archiwum PMTiles to pojedynczy plik z kompaktowym katalogiem na początku i danymi kafelków za nim, ułożonymi tak, by klient mógł pobrać dowolny pojedynczy kafelek za pomocą HTTP range request. Umieść plik w zwykłym magazynie obiektowym lub na karcie flash, a klient odczyta katalog raz, a potem żąda zakresami bajtów tylko tych kafelków, których potrzebuje — bez serwera kafelków, bez procesu SQLite, bez rozpakowywania.

Dla aplikacji polowej daje to dwie odrębne korzyści. W podłączonej sieci przygotowawczej archiwum PMTiles w statycznym buckecie zastępuje cały stos serwera kafelków, czyli o jedną rzecz mniej do wdrożenia i akredytacji. Na urządzeniu ten sam układ — pojedynczy plik, tylko-do-dopisywania — kopiuje się i sumuje kontrolnie czysto oraz jest przyjazny odczytom w stylu mmap. Sklastrowany katalog formatu utrzymuje indeks mały nawet dla archiwów w skali planety, więc wyszukanie pojedynczego kafelka pozostaje tanie. Kompromisy wokół map offline MBTiles i PMTiles sprowadzają się do tego, czy twój renderer natywnie posługuje się wzorcem dostępu range-request, czy oczekuje uchwytu SQLite.

4. GeoPackage — standard OGC

GeoPackage (GPKG) to jedyny z tych trzech, który jest formalnym otwartym standardem, opublikowanym przez Open Geospatial Consortium i przyjętym jako kontener istotny dla amerykańskiej National Geospatial-Intelligence Agency oraz NATO. Podobnie jak MBTiles, jest zbudowany na SQLite, ale jest znacznie ambitniejszy: pojedynczy plik GeoPackage może mieścić rastrowe piramidy kafelków, wektorowe tabele obiektów z pełną geometrią i atrybutami, indeksy przestrzenne (R-tree) oraz metadane opisujące to wszystko. Jeden plik może być zarazem twoim podkładem i nakładką wektorową — śladami sił własnych, środkami kontroli, nazwanymi rejonami zainteresowania — w jednej odpytywalnej, edytowalnej bazie danych.

Ta wszechstronność jest powodem, dla którego GeoPackage dominuje w formalnym świecie geoprzestrzennym obronności. Gdy komórka geoprzestrzenna wysyła pakiet danych misji, GeoPackage pozwala kafelkom obrazów i atrybutowanym danym obiektów podróżować razem w jednym rozliczalnym artefakcie z udokumentowanym schematem, który system odbierający jest umownie zobowiązany odczytać. Kosztem jest to, że GeoPackage jest cięższy w produkcji i że jego pełny model obiektów to więcej, niż potrzebuje czysty podkład — niesiesz standard zbudowany dla edytowalnych danych GIS, a nie tylko pamięć podręczną kafelków.

5. kompromisy rozmiaru i wydajności

Wybór formatu zmienia rozmiar pliku mniej, niż ludzie się spodziewają, ponieważ dominującym kosztem są bajty kafelków, a te są w dużej mierze takie same w różnych kontenerach. Prawdziwe dźwignie są wcześniej: format kafelka (WebP bije PNG o 25–35% przy równej jakości), próg odcięcia poziomu zoomu oraz to, czy serwujesz wektor czy raster.

Kafelki wektorowe to wielka wygrana. Rastrowy podkład kraju w zoomie 0–16 może mieć 20–40 GB; równoważny zestaw kafelków wektorowych, gdzie geometria jest kodowana raz i stylizowana w czasie renderowania, rutynowo mieści się w 1–3 GB dla tego samego pokrycia. Wektor pozwala też urządzeniu restylować w locie — palety dzień/noc, przełączniki warstw specyficzne dla misji — bez ponownego renderowania kafelków. Kosztem jest GPU i CPU w czasie rysowania: urządzenie składa obraz na każdą klatkę zamiast przerzucać wstępnie wypieczony obraz, co jest dokładnie tym rodzajem budżetu renderowania map w czasie rzeczywistym, który musisz profilować na docelowym sprzęcie, a nie na laptopie programisty.

Pod względem kosztu zapytań te trzy są w praktyce zbliżone. MBTiles i GeoPackage oparte na SQLite rozwiązują kafelek indeksowanym wyszukaniem klucza głównego — mikrosekundy z ciepłej pamięci podręcznej. PMTiles rozwiązuje przez wewnątrzplikowy katalog, czyli jeden lub dwa odczyty, również pomijalne, gdy katalog główny jest w pamięci podręcznej. Żaden z nich nie jest wąskim gardłem; są nim wejście/wyjście pamięci oraz dekodowanie/renderowanie. Uczciwy wniosek inżynierski: wybierz format pod kątem dopasowania narzędzi i integracji, a potem przeznacz wysiłek wydajnościowy na format kafelka, budżet zoomu i renderer.

6. wsparcie ATAK/TAK i aplikacji polowych

Dla ekosystemu TAK odpowiedź jest konkretna. ATAK natywnie czyta MBTiles i GeoPackage jako źródła podkładu — wrzuć plik do właściwego katalogu lub zaimportuj go przez menedżer pakietów, a pojawi się jako wybieralna warstwa mapy. Rastrowy MBTiles to najlepiej sprawdzona w boju ścieżka i ta, po którą sięga większość operatorów. GeoPackage jest właściwym wyborem, gdy potrzebujesz obrazów i atrybutowanych obiektów wektorowych w jednym importowalnym pakiecie misji, co jest standardowym sposobem, w jaki formalne produkty danych docierają do klienta.

PMTiles to nowszy przybysz. Jest coraz częściej wspierany przez wtyczki i w nowoczesnych klientach opartych na MapLibre, ale nie jest jeszcze domyślnym natywnym importem podkładu w każdej kompilacji TAK, więc zweryfikuj konkretną wersję klienta, zanim ustandaryzujesz go dla programu polowego. Pragmatyczny przepływ pracy, który stosuje wiele zespołów: twórz i przechowuj w PMTiles dla jego zalet serwowania z pojedynczego pliku, a następnie eksportuj do MBTiles lub GeoPackage na finalny pakiet urządzenia, gdy docelowy klient tego wymaga.

7. narzędzia

To w pipelinie konwersji faktycznie idą roboczogodziny inżynierskie. Dla kafelków wektorowych workhorse'em jest tippecanoe — pierwotnie z Mapbox, teraz utrzymywane przez Felt: zamienia GeoJSON lub inne źródła wektorowe w zoptymalizowany zestaw kafelków wektorowych MBTiles lub PMTiles, obsługując odrzucanie obiektów, scalanie i generalizację poziomów zoomu, tak by gęste dane pozostawały renderowalne przy niskim zoomie. To pojedyncze najważniejsze narzędzie w pipelinie wektorów offline.

Dla wszystkiego innego GDAL jest uniwersalnym adapterem. Jego narzędzia rastrowe i wektorowe konwertują między formatami, budują piramidy kafelków oraz czytają i zapisują GeoPackage, MBTiles i (w bieżących wydaniach) PMTiles. ogr2ogr przenosi obiekty wektorowe do tabel obiektów GeoPackage; gdal_translate i gdaladdo budują rastrowe piramidy kafelków GeoPackage; gdal2tiles tnie obrazy na standardową piramidę. Typowy produkcyjny pipeline łączy dane źródłowe → GDAL lub tippecanoe → kontener → kontrola integralności → pakiet danych misji, oskryptowany i odtwarzalny tak, by ten sam region przebudowywał się bajt w bajt. Narzędzie wiersza poleceń PMTiles dopełnia całość, konwertując MBTiles do PMTiles i inspekcjonując katalogi archiwów.

8. wybór dla aplikacji polowej

Decyzja sprowadza się do trzech pytań. Po pierwsze: raster czy wektor? Jeśli potrafisz tworzyć i stylizować kafelki wektorowe od początku do końca, zrób to — 10-krotna redukcja rozmiaru i restylowanie na urządzeniu są rozstrzygające dla urządzeń o ograniczonej pamięci. Sięgnij po raster tylko wtedy, gdy źródłem są obrazy lub zeskanowane arkusze, które nie mają wektorowego odpowiednika.

Po drugie: serwowanie z pojedynczego pliku czy bogactwo obiektów? Jeśli potrzebujesz obrazów plus atrybutowanych, edytowalnych obiektów wektorowych w jednym rozliczalnym artefakcie — przypadek formalnego pakietu danych misji — GeoPackage jest odpowiedzią, a jego status standardu OGC sprawia, że jest akceptowany w całej koalicji. Jeśli wysyłasz czysty podkład i chcesz najlżejszej historii serwowania, wygrywa model PMTiles — pojedynczy plik, bez serwera.

Po trzecie: co klient odczytuje dziś? Dla programów TAK wprowadzanych do służby teraz pragmatycznym domyślnym wyborem jest rastrowy lub wektorowy MBTiles na podkład oraz GeoPackage na łączone pakiety obrazów-plus-obiektów — oba importują się natywnie, oba są sprawdzone w boju. Wdrażaj PMTiles tam, gdzie twój renderer już posługuje się range requests i kontrolujesz wersję klienta. Cokolwiek wybierzesz, trzymaj format z dala od swojej głównej domeny: przechowuj kanoniczne dane mapowe raz i traktuj MBTiles, PMTiles i GeoPackage jako wymienne cele eksportu z jednego odtwarzalnego pipelinu. Kontener to decyzja o pakowaniu, a nie architektura, w której powinieneś być uwięziony.