Taktinen kenttäsovellus elää tai kuolee pohjakarttansa varassa. Kun puhelinta pitelevä sotilas on laaksossa ilman matkapuhelinverkkoa, ilman satelliittiyhteyttä ja akun täytyy kestää koko tehtävä, kartan on jo oltava laitteessa — jokainen laatta, jokainen korkeuskäyrä, jokainen tie pakattuna tiedostoon, joka ladattiin ennen kuin operaattori lähti tukikohdasta. Kysymys siitä, mikä konttiformaatti pitää tätä karttaa sisällään, ei ole pelkkä kosmeettinen seikka. Se määrittää tallennustilabudjetit, renderöinnin suorituskyvyn, putkesi tarvitsemat työkalut ja sen, valuuko data suoraan ATAKiin vai vaatiiko se muunnosvaiheen kentällä. Tämä on insinöörivertailu kolmesta merkityksellisestä formaatista: GeoPackage, MBTiles ja PMTiles.

1. offline-pohjakartan ongelma

Kenttäsovelluksen määräävä rajoite on yhteyden puute. Ei ole laattapalvelinta, johon soittaa, ei CDN:ää, ei elävää API:a. Kaiken, mitä renderöijä koskaan piirtää, on oltava paikallisessa tallennustilassa ennen kuin laite jää pimeään. Tämä muuttaa karttojen toimituksen pakkausongelmaksi: tarvitset yksittäisen, kopioitavan, todennettavan artefaktin, joka pitää sisällään kokonaisen alueen karttadatan ja jota mobiilirenderöijä voi kysellä nopeasti flash-tallennustilasta.

Tallennustila on rajallinen ja kiistelty. Karaistu Android-päätelaite saattaa varata 16–64 Gt tehtävädatalle, joka jaetaan kuvamateriaalin, korkeusdatan, full-motion-videoleikkeiden ja pohjakartan kesken. Operaatioalueen laajuinen rasteripohjakartta käyttökelpoisilla zoomaustasoilla voi yksinään yltää kymmeniin gigatavuihin. Niinpä konttiformaatti ei ole pelkkä kääre — sen pakkauskäyttäytyminen, sen laattapyramidin rakenne ja sen kyselykustannus määräävät suoraan, kuinka paljon karttaa voit kantaa ja kuinka nopeasti se piirtyy.

2. MBTiles — SQLite-laattakontti

MBTiles on formaatti, joka teki offline-kartoituksesta arkipäiväistä. Pohjimmiltaan se on SQLite-tietokanta sovitulla skeemalla: tiles-taulu, jonka avaimina ovat zoomaustaso, sarake ja rivi, sekä metadata-taulu nimi/arvo-pareista, jotka kuvaavat rajat, min/maks-zoomin, formaatin ja attribuution. Nerokkuus on sen yksinkertaisuudessa — mikä tahansa alusta, jolla on SQLite-kirjasto (eli jokainen mobiilialusta), voi avata ja kysellä sitä ilman erityistä ajuria.

MBTiles sisältää joko rasterilaattoja (PNG, JPEG, WebP) tai vektorilaattoja (Mapbox Vector Tiles, gzip-pakattu protobuf). Rasteri-MBTiles on se, mitä useimmat kenttäoperaattorit ovat itse asiassa käyttäneet: esirenderöityjä kuvia tai skannattuja topografisia karttalehtiä, leikattuna standardiin Web Mercator -laattapyramidiin ja tungettuna tietokantaan. metadata-taulun format-kenttä kertoo asiakkaalle, odottaako se muotoa png vai pbf, ja TMS-rivinumerointikäytäntö (y-akselin osalta käännetty XYZ:hen verrattuna) on se yksi pysyvä sudenkuoppa, joka puraisee jokaista uutta toteuttajaa kerran.

Sen kaikkialla läsnäolo on otsikkojuttu. MBTiles on de facto -standardi vuosikymmenen työkalujen tukemana, ja se on avoimen offline-kartoitusekosysteemin lingua franca. Jos sinun on valittava formaatti, jonka jokin myöhemmässä vaiheessa varmasti ymmärtää, MBTiles on turvallinen veto.

3. PMTiles — yhden tiedoston pilvioptimoitu formaatti

Brandon Liun luoma PMTiles ratkaisee ongelman, johon MBTiles ei kykene: laattojen tarjoamisen suoraan staattisesta tallennustilasta ilman tietokantaprosessia. PMTiles-arkisto on yksittäinen tiedosto, jonka edessä on tiivis hakemisto ja takana laattadata, aseteltuna niin, että asiakas voi noutaa minkä tahansa yksittäisen laatan HTTP range -pyynnöllä. Laita tiedosto tavalliseen objektivarastoon tai flash-kortille, ja asiakas lukee hakemiston kerran ja sitten tavualuepyynnöillä noutaa vain tarvitsemansa laatat — ei laattapalvelinta, ei SQLite-prosessia, ei purkamista.

Kenttäsovellukselle tästä on kaksi erillistä hyötyä. Yhteydellisessä valmisteluverkossa staattisessa ämpärissä oleva PMTiles-arkisto korvaa kokonaisen laattapalvelinpinon, mikä on yksi asia vähemmän otettavaksi käyttöön ja akkreditoitavaksi. Laitteessa sama yhden tiedoston, vain-lisäys-rakenne kopioituu ja tarkistussummautuu siististi ja on ystävällinen mmap-tyylisille luennoille. Formaatin klusteroitu hakemisto pitää indeksin pienenä jopa planeetan kokoisille arkistoille, joten laattakohtainen haku pysyy halpana. Kompromissit, jotka liittyvät MBTiles- ja PMTiles-offline-karttoihin, kiteytyvät siihen, puhuuko renderöijäsi range-pyyntöjen käyttömallia natiivisti vai odottaako se SQLite-kahvaa.

Keskeinen oivallus: MBTiles, PMTiles ja laatoitettu GeoPackage koodaavat kaikki täsmälleen saman Web Mercator -laattapyramidin — samat PNG- tai vektorilaattatavut. Formaattisota ei koske laattoja; se koskee niiden edessä olevaa indeksiä. Valitse indeksi, joka vastaa sitä, miten renderöijäsi lukee tallennustilaa: SQLite-kysely, HTTP range vai OGC-ominaisuuskäyttö. Pikselit ovat identtisiä.

4. GeoPackage — OGC-standardi

GeoPackage (GPKG) on kolmesta ainoa, joka on muodollinen avoin standardi, jonka Open Geospatial Consortium on julkaissut ja joka on omaksuttu Yhdysvaltain kansallisen geospatiaalisen tiedusteluviraston ja NATOn kannalta relevantiksi kontiksi. Kuten MBTiles, se rakentuu SQLiten päälle, mutta on paljon kunnianhimoisempi: yksittäinen GeoPackage-tiedosto voi pitää sisällään rasterilaattapyramideja, vektoriominaisuustauluja täydellä geometrialla ja attribuuteilla, paikkaindeksejä (R-tree) ja metadatan, joka kuvaa kaiken tämän. Yksi tiedosto voi olla sekä pohjakarttasi että vektoripeitteesi — omien joukkojen jäljet, valvontamitat, nimetyt kiinnostusalueet — yhdessä kyseltävässä, muokattavassa tietokannassa.

Tuo laajuus on syy siihen, miksi GeoPackage hallitsee muodollisessa puolustusgeospatiaalisessa maailmassa. Kun geospatiaalinen solu lähettää tehtävädatapaketin, GeoPackage antaa kuvalaattojen ja attribuoidun ominaisuusdatan kulkea yhdessä yhtenä tilivelvollisena artefaktina, jolla on dokumentoitu skeema, jonka vastaanottava järjestelmä on sopimuksellisesti velvollinen lukemaan. Hinta on se, että GeoPackage on raskaampi tuottaa ja että sen täysi ominaisuusmalli on enemmän kuin puhdas pohjakartta tarvitsee — kannat standardia, joka on rakennettu muokattavalle GIS-datalle, ei pelkälle laattavälimuistille.

5. koon ja suorituskyvyn kompromissit

Formaattivalinta muuttaa tiedostokokoa vähemmän kuin ihmiset olettavat, koska hallitseva kustannus ovat laattatavut, ja ne ovat pitkälti samat eri konttien välillä. Todelliset vivut ovat ylävirrassa: laattaformaatti (WebP voittaa PNG:n 25–35 % yhtäläisellä laadulla), zoomaustason rajaus ja se, tarjoatko vektoria vai rasteria.

Vektorilaatat ovat se iso voitto. Maan rasteripohjakartta zoomilla 0–16 voi olla 20–40 Gt; vastaava vektorilaattajoukko, jossa geometria koodataan kerran ja tyylitellään renderöintihetkellä, asettuu rutiininomaisesti 1–3 Gt:hen samalla peitolla. Vektori antaa laitteen myös uudelleentyylitellä lennossa — päivä-/yöpaletit, tehtäväkohtaiset tasokytkimet — ilman laattojen uudelleenrenderöintiä. Hinta on GPU ja CPU piirtohetkellä: laite kokoaa kuvan ruutu kerrallaan sen sijaan, että blittaisi esivalmistetun kuvan, mikä on juuri sellaista reaaliaikaisen karttarenderöinnin budjettia, joka on profiloitava todellisella kohdelaitteistolla, ei kehittäjän kannettavalla.

Kyselykustannuksen osalta kolmikko on käytännössä lähellä toisiaan. SQLite-pohjaiset MBTiles ja GeoPackage ratkaisevat laatan indeksoidulla pääavainhaulla — mikrosekunteja lämpimästä välimuistista. PMTiles ratkaisee tiedostonsisäisen hakemiston kautta, mikä on yksi tai kaksi luentaa, myös merkityksetön, kun juurihakemisto on välimuistissa. Mikään näistä ei ole pullonkaula; tallennustilan I/O ja dekoodaus/renderöinti ovat. Rehellinen insinöörijohtopäätös: valitse formaatti työkalujen ja integroinnin sopivuuden perusteella ja käytä sitten suorituskykypanoksesi laattaformaattiin, zoombudjettiin ja renderöijään.

6. ATAK/TAK- ja kenttäsovellustuki

TAK-ekosysteemille vastaus on konkreettinen. ATAK lukee MBTilesia ja GeoPackagea natiivisti pohjakarttalähteinä — pudota tiedosto oikeaan hakemistoon tai tuo se pakettienhallinnan kautta, ja se ilmestyy valittavissa olevana karttatasona. Rasteri-MBTiles on taistelutestatuin polku ja se, jonka useimmat operaattorit valitsevat. GeoPackage on oikea valinta, kun tarvitset kuvamateriaalin ja attribuoidut vektoriominaisuudet yhdessä tuotavassa tehtäväpaketissa, mikä on vakiintunut tapa, jolla muodolliset datatuotteet saavuttavat asiakkaan.

PMTiles on uudempi tulokas. Sitä tuetaan yhä enemmän laajennusten kautta ja moderneissa MapLibre-pohjaisissa asiakkaissa, mutta se ei vielä ole oletusarvoinen natiivi pohjakartan tuonti jokaisessa TAK-buildissa, joten varmista tietty asiakasversio ennen kuin standardisoit sen kentällä olevaan ohjelmaan. Pragmaattinen työnkulku, jota monet tiimit ajavat: tuota ja säilytä PMTilesissa sen yhden tiedoston tarjoiluetujen vuoksi, vie sitten MBTilesiin tai GeoPackageen lopullista laitepakettia varten, kun kohdeasiakas sitä vaatii.

7. työkalut

Muunnosputki on se, mihin insinöörituntien aika oikeasti menee. Vektorilaattoja varten tippecanoe — alun perin Mapboxilta, nyt Feltin ylläpitämä — on työjuhta: se muuntaa GeoJSONin tai muut vektorilähteet optimoiduksi MBTiles- tai PMTiles-vektorilaattajoukoksi, hoitaen ominaisuuksien pudottamisen, yhdistämisen ja zoomaustasokohtaisen yleistämisen niin, että tiheä data pysyy renderöitävänä matalalla zoomilla. Se on yksittäinen tärkein työkalu offline-vektoriputkessa.

Kaikkeen muuhun GDAL on universaali adapteri. Sen rasteri- ja vektoriapuohjelmat muuntavat formaattien välillä, rakentavat laattapyramideja ja lukevat tai kirjoittavat GeoPackagea, MBTilesia ja (nykyisissä julkaisuissa) PMTilesia. ogr2ogr siirtää vektoriominaisuudet GeoPackage-ominaisuustauluihin; gdal_translate ja gdaladdo rakentavat rasteri-GeoPackage-laattapyramideja; gdal2tiles leikkaa kuvamateriaalin standardipyramidiin. Tyypillinen tuotantoputki ketjuttaa lähdedata → GDAL tai tippecanoe → kontti → eheystarkistus → tehtävädatapaketti, skriptattuna ja toistettavana niin, että sama alue rakentuu uudelleen tavu tavulta. PMTilesin komentorivityökalu täydentää sen, muuntaen MBTilesin PMTilesiksi ja tarkastaen arkistohakemistoja.

8. valinta kenttäsovellukselle

Päätös tiivistyy kolmeen kysymykseen. Ensiksi, rasteri vai vektori? Jos voit tuottaa ja tyylitellä vektorilaattoja päästä päähän, tee se — 10-kertainen koon pienennys ja laitteella tapahtuva uudelleentyylittely ovat ratkaisevia tallennustilarajoitteisille laitteille. Turvaudu rasteriin vain silloin, kun lähde on kuvamateriaalia tai skannattuja karttalehtiä, joilla ei ole vektorivastinetta.

Toiseksi, yhden tiedoston tarjoilu vai ominaisuuksien rikkaus? Jos tarvitset kuvamateriaalia sekä attribuoituja, muokattavia vektoriominaisuuksia yhdessä tilivelvollisessa artefaktissa — muodollinen tehtävädatapakettitapaus — GeoPackage on vastaus, ja sen OGC-standardiasema on se, mikä saa sen hyväksytyksi koalition laajuisesti. Jos toimitat puhdasta pohjakarttaa ja haluat kevyimmän tarjoilutarinan, PMTilesin yhden tiedoston, palvelimeton malli voittaa.

Kolmanneksi, mitä asiakas lukee tänään? Nyt kenttään vietäville TAK-ohjelmille rasteri- tai vektori-MBTiles pohjakartalle ja GeoPackage yhdistetyille kuva-plus-ominaisuus-paketeille on pragmaattinen oletus — molemmat tuovat natiivisti, molemmat ovat taistelutestattuja. Ota PMTiles käyttöön siellä, missä renderöijäsi jo puhuu range-pyyntöjä ja hallitset asiakasversiota. Mitä tahansa valitsetkin, pidä formaatti ydindomeenisi ulkopuolella: säilytä kanoninen karttadata kerran ja kohtele MBTilesia, PMTilesia ja GeoPackagea keskenään vaihdettavina vientikohteina yhdestä toistettavasta putkesta. Kontti on pakkauspäätös, ei arkkitehtuuri, johon sinun tulisi lukkiutua.