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

From OpenStreetMap Wiki
Jump to navigation Jump to search

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.[1]

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

Csempegyártás

Szükséges hozzávalók

  • GDAL (lehetőleg legalább 3.6, ld. lejjebb!).
  • 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
  -hidenodata
  -vrtnodata 255
  -overwrite
  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 "+proj=somerc +lat_0=47.14439372222222 +lon_0=19.04857177777778 +k_0=0.99993 +x_0=650000 +y_0=200000 +ellps=GRS67 +nadgrids=etrs2eov_notowgs.gsb +units=m"
  -t_srs epsg:3857
  -r cubic
  -srcnodata 255
  -dstnodata 255
  -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 "+proj=somerc +lat_0=47.1443937222222 +lon_0=19.0485717777778 +k_0=0.99993 +x_0=650000 +y_0=200000 +ellps=GRS67 +towgs84=52.684,-71.194,-13.975,0.312,0.1063,0.3729,1.0191 +units=m +no_defs +type=crs". A még jobb pontossághoz töltsd le a 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.[2]
  • 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-18
  --tiledriver WEBP
  --webp-quality 90
  --processes 8
  -w leaflet
  --xyz
  -e
  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 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

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.

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.

Jegyzetek

  1. ↑ 2π ∙ fél-nagytengely ∙ cos(szélesség) / 2 (zoomszint + 8), vagyis 2π × 6378137 × cos(47) ÷ (2^(19+8)) = 0,407265 méter. Az ország déli és északi határán ez az érték 0,417 és 0,396 méter.
  2. ↑ Saját mérések és az alábbi cikk alapján: Guide to GeoTIFF compression and optimization with GDAL
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Magyar_állami_(FÖMI,_Lechner)_ortofotók_felhasználása&oldid=2702579"