Hungary/Magyar állami (FÖMI, Lechner) ortofotók felhasználása

Ez az oldal gyűjti össze a magyar állami (egykor a Földmérési és Távérzékelési Intézet – FÖMI, később Lechner Tudásközpont Nonprofit Kft. kezelésében levő) ortofotók OpenStreetMap szerkesztéshez való felhasználásának lépéseit, tudnivalóit, a konverzió során felmerült szempontokat, tapasztalatokat és döntéseket.

A felhasználás jogi háttere

A Lechner Tudásközpont által kezelt légifelvételek a földmérési és térképészeti tevékenységről szóló 2012. évi XLVI. törvény (Fttv) 3. § (1) bekezdés f) pontja szerint az állami alapadatok adatbázisainak részei, míg az archív analóg és digitális légifelvételek az Fttv. 3. § (1) bekezdés i) pontja szerint szerinti az állami alapadatok adatbázisainak részét képezik.

Az adatok azok keletkezése után 10 évvel archívvá válnak (22. § (4)), így ingyenesen hozzáférhetőek. (6. § (19))

A közzétételhez a minisztériumtól kell engedély. „Az adatfelhasználás engedélyezője az Fttv. 32. § (3) bekezdése szerint a térképészetért felelős (közigazgatási és területfejlesztési) miniszter.” ([1]] legalja.)

Feltütetendő Copyright szöveg: Valaki próbálja meg értelmezni, az Fttv. 6/B. §-ban foglaltak szerint pontosan mit kell kiírnunk.

Az állományok megszerzése

Az összefonódások miatt nehéz megmondani, pontosan melyik intézményhez (Kormányhivatal, Lechner, geoshop.hu) milyen mértékben tartozó ügyfélszolgálatra kell bemenni. Mindenesetre helyileg a Geodézia irodaház (1149 Budapest, Bosnyák tér 5.) Nagy Lajos király út felőli bejáratán kell belépni akár sima SATA meghajtóval, akár külső USB-s tárhellyel. A nyitvatartási idő ugyan a hivatalihoz igazodik, de a délelőttöt javasolták.

Vagy szemben a kisablakos kuckóból, vagy balra a két székes, üveglap mögötti ügyintézők fogják megkérdezni, mi járatban. Itt elő kell adni, hogy ingyenes ortofotókért jött az ember (ettől kiül a visszafogott undor az amúgy sem túl lelkes arcokra), majd elérhetőséggel együtt otthagyni a meghajtót. A másolásra kb. egy hetet ígértek – engem két hét után sem hívtak, így bementem érte.

A kért formátum lehet TIFF és/vagy JPEG, illetve RGB vagy infra. A 2011-2014 évekre összesen 8,7 TB méretet mondtak - infra nélkül 5,5 TB-t. Végül csak a TIFF-eket kaptam meg („Ugye, jó lesz?”), ami 2,0 TB körüli helyet foglal.

A forrás állományok

A kapott állományok 0,4 m/pixel felbontású, 15 000×10 000 pixeles (6×4 km-es), Egységes Országos Vetületű, tömörítetlen TIFF file-ok, egyenként 430 MB méretben. A georeferálás a TIFF-ekben is megtalálható, de külön .tfw állományokban is elérhető.

Az állományok évenkénti könyvtárakban érkeztek (pl. 2011_o_mepar_RGB). Ezeken belül a nevek EOTR szelvényszámmal kezdődnek, az "o" valószínűleg az ortó rövidítése, végül az évszám következik (pl. 107-441_o_2011.tif). Némelyik állomány neve _m-re végződik, ezeken Photoshoppal módosítás történt (pl. a szupertitkos területekre középzöld kitöltéssel hívják fel a figyelmet).

Az egyes évjáratok között van némi átfedés, amire a feldolgozás sorrendjénél figyelni érdemes.

Egy próba területen (Kány) a FÖMI 2010-nek kb. 2 méter elcsúszása van az újhoz képest. A Közutas adatok alapján az új tűnik jónak.

Egyelőre még csak véletlenszerűen próbálkozva a budapesti 2013-as képek halványzöld színben tündökölnek. Kolesár András sztorizott még arról, hogy az egyik évben a FÖMI egy osztrák céggel próbálkozott fényképeztetni, de nem lett túl jó a minőség. Ha tippelnünk kellene, ez volt az az év.

Archiválás

Felmerült, hogy az egyszerűség és a biztonság kedvéért a forrás állományok is legyenek több példányban archiválva. Többféle tömörítés végigpróbálása után a bzip2 tűnik célravezetőnek, ami az eredeti méret 60%-ára tapossa össze ezeket az állományokat.

Előzetes gondolatok

Felbontás

Az ortofotó felbontása 40 cm/pixel. Magyarország területén egy z18-as TMS csempe átlagosan 41 cm/pixeles felbontású, így a csempegyártásnál ezt a zoomszintet érdemes megcélozni.

Formátumok

• WEBP: Kb. a forrás TIFF negyede lesz a csempepiramis. A JOSM csak pluginnal támogatja. :(
• JPEG: Kétszerese a WEBP-nek (a TIFF fele). Alapból nem tudja a gdal2tiles, de van egy várakozó PR, ami működni látszik.
• PNG: Tízszerese a WEBP-nek.

A WEBP és PNG támogatják az átlátszóságot, aminek az országhatáron átnyúló csempéknél van jelentősége. Sajnos az ország belsejében is fordulnak elő teljesen fehér pixelek, amik átlátszóvá lyukasztva esetleg zavaróak lehetnek. Vagy lehet első menetben a határ menti szelvényeket átlátszósítani, és ezt egybegyúrni a többi, teli képpel.

WEBP tömörítési szint: az alapértelmezett 75-ös szint látható és zavaró információvesztéssel jár, a finom részletek kisimultnak, a kontrasztok gyengülnek. A 85-ös tömörítés már kielégítő, a 90-es pedig alig különböztethető meg a veszteségmentestől. Méretben az utóbbi kettő között kb. 20% a különbség.

Ötletek:

• Esetleg lehetnek párhuzamosan WEBP és JPEG csempék, előreláthatólag 0,25+1 TB tárhelyen.
• Másik megoldás, hogy csak WEBP-t gyártunk, de ha JPEG-re érkezik kérés, azt a szerver on-the-fly generálná. Így az iD (és ami támogatja) kaphatná a kisebb adatforgalommal járó WEBP-t, a JOSM pedig hackelés nélkül is meg tudná jeleníteni az ortót, illetve pluginnel akár a WEBP-t is.

Felmerült, hogy 512×512 pixeles csempéket gyártsunk. Ennek előnye, hogy minél nagyobb a csempe, annál hatékonyabban tömöríthető, vagyis egy 512-es csempe kisebb, mint négy 256-os. Sajnos az 512-es csempe minden szoftvernek HiDPI-t jelent, vagyis 256 pixel méretű helyen jeleníti meg az 512-es csempét, illetve a gdal2tiles is így generálja le. A JOSM ezt még tudná is kezelni, de más megjelenítők valószínűleg nem. ⇒ Elvetve

Feldolgozás

Szükséges hozzávalók

• GDAL (lehetőleg legalább 3.6, ld. lejjebb!).
• javító rácsháló
• Forrás ortofotók
• 2 TB szabad hely

Eddigi tapasztalatok

• Lazy raster processing (gdalwarp GDAL Virtual Formatba [VRT], majd ebből gyártani a csempéket) nem jó; a végeredmény csempék sávosan torzultak lesznek.

Scriptek:

1. Egy közös VRT létrehozása a forrás állományokból

gdalbuildvrt \
  -allow_projection_difference \
  -a_srs epsg:23700 \
  -vrtnodata 255 \
  fomi_index.vrt \
  2011_o_mepar_RGB/*.tif \
  2012_o_mepar_RGB/*.tif \
  2013_o_mepar_RGB/*.tif \
  2014_o_mepar_RGB/*.tif

Megjegyzések:

• A több évjáratban is meglevő területek miatt fontos a könyvtárak explicit felsorolása és sorrendje.
• A futás ideje pár perc.

2. A képek átvetítése Web Mercatorba

gdalwarp \
  -s_srs "+init=EPSG:23700 +nadgrids=etrs2eov_notowgs.gsb" \
  -t_srs epsg:3857 \
  -r cubic \
  -of GTiff \
  -co TILED=YES \
  -co COMPRESS=ZSTD \
  -co ZSTD_LEVEL=1 \
  -co PREDICTOR=2 \
  -co BIGTIFF=YES \
  -multi \
  -wo NUM_THREADS=ALL_CPUS \
  -wm 1000 \
  --config GDAL_CACHEMAX 1000 \
  -overwrite \
  fomi_index.vrt \
  fomi_3857.tif

Megjegyzések:

• A közvetlen EOV → Web Mercator konverzió hibás, pl. Magyarország legészakibb részén (108-323, 109-314 szelvények) egy ugrást tesz az átvetített képbe. Ennek javításához receptet kell adni a proj-nak, azaz az egyszerű -s_srs EPSG:23700 helyett pl. -s_srs "+init=EPSG:23700 +towgs84=52.684,-71.194,-13.975,0.312,0.1063,0.3729,1.0191". A még jobb pontossághoz töltsd le a javító rácshálót, és másold be a proj könyvtárába (/usr/share/proj). A fenti parancs már erre hivatkozik.
• A cubic újramintavételezés kellően jó eredményt ad. A lanczos még egy kicsit élesebb, de a különbség kicsi, ellenben sokkal lassabb. A bicubic gyorsabb, de elmosottabb.
• Az srcnodata mondja meg, hogy az átvetítésnél a szélén üresen maradt részek ugyanúgy fehérek legyenek, mint a határon átlógó területek.
• Ezt a közbülső állományt tömörített TIFF-be írjuk, hogy az újabb 2 TB helyett elég legyen „csak” 1,3 TB.
• Írási/olvasási sebességben a -co COMPRESS=ZSTD -co ZSTD_LEVEL=1 a legjobb (a tömörítettek közül). Nagyobb tömörítési szintnél sem lesz sokkal kisebb a fájl, viszont lassabb a létrehozás és az olvasás is. A -co PREDICTOR=2 a fájlméreten csökkent még kb. 20%-ot.
• A -co BIGTIFF=YES muszáj, mert 4 GB-nál mindenképp nagyobb lesz a végeredmény.
• NUM_THREADS sokat gyorsít rajta, minél több, annál jobb (8 szál 3,5× gyorsabb az 1 szálnál), de min. GDAL 3.6 kell hozzá. A dokumentáció szerint -wm és GDAL_CACHEMAX további növelése nem jelent előnyt, ekkora blokkokban írja ki diskre.
• A futás ideje kb. 48 óra (még két szállal, Ryzen3 3100, 16 GB RAM [Dockerben], USB3 külső SATA vinyó).

3. A csempepiramis gyártása

gdal2tiles.py \
  --zoom=8-19 \
  --resampling=lanczos \
  --tiledriver WEBP \
  --webp-quality 85 \
  --processes 10 \
  --webviewer=leaflet \
  --xyz \
  --resume \
  fomi_3857.tif \
  tiles_webp

(A JPEG csempékhez --tiledriver JPEG lenne szükséges a PR felrakása után.)

Megjegyzések:

• Különböző formátumok és különböző tömörítések végignézése után ez a minőség tűnik elfogadhatónak szerkesztéshez.
• A felbontásból kiindulva elég lenne z18-ig gyártani a csempéket, de így egyes csempehatárokon durva elcsúszások tapasztalhatóak, amit az egyel nagyobb zoomszint teljesen megold.
• A Leaflet csak a kipróbáláshoz kerül mellé egy HTML állomány formájában. Lehet helyette none is.
• A futás ideje: egy héten belül.
• Teszthez kivágás a nagy képből: gdalbuildvrt -te 2122100 6050500 2124600 6052600 orto_test.vrt fomi_3857.tif

A gyártás tapasztalatai

A gyártás egy mással is foglalkozó serveren készült, így az idők nem „színtiszta mérések”, hanem hozzávetőleges értékek.

A kiindulás a FÖMI által átadott 1.8 TB adat (2011: 583 GB, 2012: 437 GB, 2013:554 GB, 2014: 266 GB).

1. Az első fázis a VRT előállítása. Ez gyors, gyakorlatilag annyi idő, míg a gép átnézte a file-okat.
   • 2 perc (cpu: 7 sec), disk IO igényes
2. A második fázis a warp, vagyis EOV-ből WGS84/Web Mercatorba alakítás, aminek során előáll egy nagy TIF.
   • A futási ideje 79 óra volt (4729 valós perc, user 31760 perc, ami 529 óra; eszerint a folyamat átlagosan 7 szálat használt), akkor 8 GB fizikai RAM állt rendelkezésére és a „régebbi” (3.6.xx) gdal-lal ment.
   • Az előállított TIF mérete 1021 GB
3. A harmadik fázis a tile piramis előállítása volt, z8-z18 között.
   • A folyamat elvileg mindent szeretne (cpu, disk, memória), de a régi gdal nem használta ki az összes CPU szálat és a memóriát is egy idő után kevesellte. Zramswappal kicsit jobb volt, de nem sokkal. Emiatt ezt 55% körül, 20 óra 40 perc után megállítottam.
     • A file-ok felolvasása ebből kb. 30 perc volt.
   • A második menetben az új gdal (3.9.xx) 16 GB RAM-mal ment, plusz az említett zramswap, ami javított az eredményein. Így 26.6 órát futott, 14313 perc CPU-val ami 9 szál körülre jött ki (a 20-ból). (Ez ugye már kb. 55%-nál indult, és csak a maradékot gyártotta le.)
   • A második indításból már 1.5 óra volt a felolvasás, mert meg kellett keresnie elég sok már elkészített tile adatait is. Ezután 15 percet számolt, majd 8 órán át a z18-as kiindulási tile-ok maradékát csinálta meg, utána pedig 15 óra volt a piramis felépítés z8-ig.
   • Így összesen 47 órát futott, és mind a disket mint a CPU-t mind a memóriát használta.

A teljes folyamat így, webp tile gyártással 126 órát tartott, és a végeredmény 245 GB:

folyamat	futási idő	második futtatás
vrt	2 perc	2 perc
warp	79 óra	83 óra
piramis	47 óra	70 óra (48 z18 + 22 piramis)

z8	320 KB
z9	1.2 MB
z10	4.5 MB
z11	16 MB
z12	57 MB
z13	210 MB
z14	804 MB
z15	3.2 GB
z16	13 GB
z17	52 GB
z18	177 GB

z19

A z19-es réteget a Tirex készíti on the fly a bazi TIF-ből, és cache-eli. Ez csak webp-ben érhető el jelenleg (nem akarok dupla méretű cache-t), és első ránézésre 3-5 másodperc egy csempecsoport legyártása.

(A z20 réteg beállítása csak tesztelésből készült el, de valószínűleg le fogjuk kapcsolni, mert homályosabb, mint a nagyított 19-es, és új részletek nem lesznek rajta.)

Bekerülés a szerkesztő programokba

Ha készen van a csempepiramis, és az első tesztek alapján jól sikerült a konverzió, akkor nincs más hátra, mint közkinccsé tenni.

A hivatalos URL:

• https://orto1.tile.openstreetmap.hu/fomi2011-2014/{z}/{x}/{y}.webp

JOSM TMS formában:

• TMS[18]:https://orto1.tile.openstreetmap.hu/fomi2011-2014/{z}/{x}/{y}.webp
  • A zoom19 és 20 csak bétatesztereknek érhető el, lassított felvételen.

JOSM

Egyszerűen a JOSM Wikiben egy nagy XML-be fel kell venni az új réteget, <category>photo</category> beállítással. A többi érték vagy értelemszerű, vagy leshető a többi változatból, legrosszabb esetben elolvasható a dokumentációban.

Ha egy korábbi ortofotó újabb változatáról van szó (esetünkben a 2007-2010-et váltjuk le a 2011-2014-gyel), akkor a régi verziót érdemes <category>historicphoto</category> értékre átállítani.

Időszak esetén a kezdő- és vég dátumot is egy mezőbe kell felvenni, de kötőjel helyett pontosvesszővel (ez itt nem felsorolást jelent), pl. <date>2011;2014</date>.

A <bounds> és <shape> pontosítható, vagy jó lesz az körülbelül úgy, mint a régi.

Layer index

Fel kell venni a layer indexbe is, az editor-layer-index repón keresztül. Kell egyet forkolni (és változtatásonként új branchet csinálni). Itt a sources/europe/hu könyvtárba kell létrehoznunk egy új GeoJSON állományt.

A "category": "photo" és "category": "historicphoto" ugyanúgy működik, mint a JOSM-nél.

A start_date és end_date értékekbe dátum(részlet) is megadható, így Lechner esetén a pontos fényképezési időszak is.

Itt szintén min_zoom és max_zoom értékek vannak.

A végén commit, push, PR küldés.

Az nem teljesen tiszta, a JOSM automatikusan vesz-e át innen adatot. Ennek a reponak a nyitólapján azt írják, hogy opcionálisan, de a JOSM fenti szerkesztése elegendő volt az ottani megjelenéshez.

iD Editor

A PR elfogadása helyett azt írják, a Layer indexbe dolgozzon az ember, és majd ők onnan veszik át.

Az iD repójából kell fork/branch, majd lehozás után a data/imagery.json állományt szerkeszteni.

A "category": "photo" és "category": "historicphoto" ugyanúgy működik, mint a JOSM-nél.

Érdemes lehet megadni zoomExtent tartományt.

Szintén érdekes lehet a startDate és endDate értékek megadása is.

A végén commit, push, PR küldés.

Észrevételek, megoldandó problémák

A végeredmény és a régi FÖMIhez igazított dolgok között országszerte előfordul 1, max. 2 méter eltérés. Általában – de nem kizárólag – az új illeszkedik jobban a Magyar Közúthoz.

Átlátszóság

A szép országhatár érdekében a WEBP csempéket átlátszósággal gyártjuk. Ezeken a részeken a teljesen fehér (#FFFFFF) szín jelzi az érvénytelen adatokat. Azonban az ország belsőbb részeiben is fordulnak elő ilyen pixelek, tipikusan túlexponált helyeken, mint egy fehér furgon tetejéről megcsillanó nap. A legcsúnyább beégést eddig Debrecenben találtam.

Vagy figyelmen kívül hagyjuk ezt a szépséghibát, vagy a VRT összerakásakor kell egy lista a határmenti szelvényekről, hogy csak azokon tegyük átlátszóvá a fehér színt.

További adalék: Jelenleg épp az országhatár környéke megmarad „fehérnek”. Egy próba szelvényen valamiért a 255 helyett 254 lett az üres pixelek értéke a Mercatorba forgatás után.

Forrás hiba

A képen az Örs vezér tere látszik a BKK gomba környékével. A forrás állományok keresésénél feltűnt, hogy itt épp egy szelvényhatár fut. Először azt hittem, valamit mi rontottunk el az átvetítés vagy a csempegyártás során. De aztán kiderült, hogy már az eredeti 65-234-es szelvény alján is ott van a 65-412 tetejéből átmásolt csík.

Pontosság

A Magyar Közúthoz való illeszkedés mellett végignéztem, a statikusan mért RTK referencia pontjaimra mennyire illeszkednek az új ortofotók. Elég szépen. Eddig az egyetlen számottevő eltérést Aggteleken találtam. De itt látszik is az elhúzásból, hogy a felszíni domborzatmodellre való korrekciónál mekkorát erőlködött a FÖMI algoritmusa.

Torzulás

Egy helyen a Mercatorba átvetítés során így, sávosan torzul a kép. Az eredeti 38-214-es szelvényen teljesen jól néz ki.

Hasonló a helyzet Szombathelytől keletre, a szintén észak-déli irányú 86-87-es útnál.

Aktuális GDAL-lal átvetítve a probléma nem jelentkezik. A mostani csempék gyártásakor grinnél régi, 3.6-os volt; valószínűleg ez okozta a problémát. A többi téma véglegesítése után valószínűleg újragyártásra kerül minden.

• A 3.9-es gdal sokat javított a helyzeten; úgy tűnik, a z19 esetében a hiba maradékai is eltűntek.