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ő (Mo-Fr 08:30-16:30) 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, majd elérhetőséggel együtt otthagyni a meghajtót. A másolás kb. egy hét alatt történik meg.

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 2015-ös 40 centis képek helyigénye szintén 1,7 TB, a 20 centis járásoké 340 GB.

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.

2015-ben egy éven belül fényképezték végig az egész országot, így csak egyetlen 2015_o_mepar_RGB könyvtár van.

Ugyanezen év őszén-telén 0,2 m/pixel felbontású lombtalan ortofotók készültek 6 járásról. Ezek szintén 15 000×10 000 pixeles (3×2 km-es), Egységes Országos Vetületű, tömörítetlen TIFF file-ok, egyenként 430 MB méretben. A nagyobb felbontás miatt az EOTR szelvényszámból még egy számjegy bekerül az állományok nevébe, pl. 63-431-1_o_2015.tif. Ezek az állományok a 2015_o_nkp_RGB könyvtárban érkeztek, a két különálló terület szelvényei ömlesztve. Az egyik rész a Győri és Pannonhalmi járás, a másik pedig a Kecskeméti, Tiszakécskei, Kunszentmártoni és Szarvasi járások.

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.

A 2015-ös felvételek az egységes minőség mellett jóval telítettebbek, kiegyensúlyozott fényerejűek, élesebbek, mint a 2011-2014-es sorozat.

A 2015-ös 20 centis felbontású képek a november-decemberi fotózás miatt erős és hosszú árnyékokkal rendelkeznek.

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.

A 20 cm/pixeles lombtalan ortofotók felbontása z19-nek felel meg.

Formátumok

• WEBP: Kb. a forrás TIFF negyede lesz a csempepiramis. A JOSM csak pluginnal támogatja. :(
• JPEG: Másfélszerese a WEBP-nek (a TIFF fele).
• PNG: Tízszerese a WEBP-nek.

A WEBP és PNG támogatják az átlátszóságot, aminek az országhatáron (illetve a 20 cm-eseknél a járáshatáron) átnyúló csempéknél van jelentősége. Az ország belsejében is fordulnak elő teljesen fehér pixelek, amik átlátszóvá lyukasztva esetleg zavaróak lehetnek.

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 kisimulnak, 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 (minél újabb, de legalább 3.6).
• Javító rácsháló a pontosabb EOV-transzformációhoz
• Forrás ortofotók
• 2 TB szabad hely a forrásnak, 1 TB a köztes TIFF-nek, 256 GB a WEBP csempéknek.

Az etrs2eov_notowgs.gsb javító rácshálót másold be a proj könyvtárába (/usr/share/proj).

Scriptek:

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

A szelvényekből összeállítunk egy az egész országot lefedő virtuális rasztert, ez a VRT. A GDAL programok ezt ugyanúgy kezelik, mintha fizikai képfájl lenne.

gdalbuildvrt \
  -allow_projection_difference \
  -a_srs "+init=EPSG:23700 +nadgrids=etrs2eov_notowgs.gsb" \
  -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ő, átfedő területek miatt fontos a könyvtárak explicit felsorolása és sorrendje.
• A futás ideje pár perc.
• A vrtnodata mondja meg, hogy mely képpontokat tekintse átlátszónak. Erre azért van szükség, mert az eredeti tifekben nincs se átlátszóság, se maszk definiálva, viszont az országhatár körül az üresen maradt területek fehérek.

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

Az EOV rasztert át kell vetíteni Web Mercator vetületbe.

A vetítést megtehetnék az előző lépéshez hasonlóan, VRT-be írva az adatokat, így a lenti parancs futásideje csak pár perc lenne. Viszont a tapasztalatok azt mutatják, hogy egy ilyen, mindössze a transzformációs paramétereket tartalmazó virtuális raszterből a következő lépés, a csempézés akár 4-5-ször annyi ideig tartana, mert a vetítést csempénként kell elvégezze. Emiatt az alábbi parancs TIFF fájlba írja a vetített állományt, melynek mérete a tömörítésnek köszönhetően durván fele az eredetinek. Ez a fájl a csempegyártás végeztével törölhető.

gdalwarp \
  -t_srs "EPSG:3857" \
  -tr 0.5971642834779396 0.5971642834779396 \
  -tap \
  -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 200 \
  -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 rasztert nem elég Mercator vetületbe transzformálni, a pixelméretét is igazítani kell a megcélzott zoomszinthez. Az eredeti Google Mercator specifikáció tartalmazta ezeket a Mercator méter – pixel arányszámokat. z0-án az értéke 156543.0339280410, és innen számítható a többi: 156543.0339280410 / 2^zoom, vagyis z18-on 0.5971642834779396, z19-en 0.2985821417389697.
• -tap (Target Aligned Pixels) megadásával a kép dimenzióit az előző méretezésnek megfelelő raszterrácshoz igazítja.
• A cubic újramintavételezés kellően jó eredményt ad. A lanczos alig észrevehetően jobbat csinál, ellenben 2x lassabb. A bicubic gyorsabb, de elmosottabb.
• 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. Tömörítés nélküli forrásból valamivel lassabb a csempepiramis gyártása is.
• Í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.
• Ha a kimenet tömörített, a -co TILED=YES kb. 30%-ot gyorsít a feldolgozáson, és a kimenet is kb 10%-al kisebb. A -co BLOCKXSIZE nem befolyásolja az időt és méretet.
• 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). A -wm 200 MB-ra emelés gyorsít valamennyit, a további növelés (TILED=YES esetén) értelmetlen, sőt, lassította. A --config GDAL_CACHEMAX növelése (mekkora blokkokban írja ki diskre) nem módosított a futásidőn.

Teszthez kivágás a nagy képből: -te_srs EPSG:4326 -te 17.797 47.388 17.803 47.392

3. A csempepiramis gyártása

gdal2tiles.py \
  --zoom=8-18 \
  --tiledriver WEBP \
  --webp-quality 85 \
  --processes 10 \
  --webviewer=none \
  --xyz \
  --resume \
  --exclude \
  fomi_3857.tif \
  tiles_webp

Megjegyzések:

• A JPEG csempékhez --tiledriver JPEG szükséges, és szükség szerint --jpeg-quality. Értelemszerűen.
• A webviewer kapcsolóval kérhető, egy HTML fájl, amivel böngészőben könnyedén ellenőrizhető az elkészült állomány. Ehhez none helyett az értéke leaflet kell legyen.
• A --exclude gondoskodik arról, hogy a teljesen üres csempéket ne tároljuk el fölöslegesen.
• --processes: hány szálon fusson a csempézés. Jelentősen befolyásolja a futásidőt.
• Ha valamiért meg kéne állítani a csempézést, a --resume kapcsolóval folytatható, ilyenkor a már készeket nem gyártja le újra.

20cm-es orotofotók feldolgozása

A járásokról készült ortofotók általában egy éven belül is tartalmaznak különálló területeket. Részben emiatt, részben a nagyobb felbontás miatt a fenti parancsokat pár paraméterben módosítani kell.

2015, győri és pannonhalmi járás:

gdalbuildvrt \
  -allow_projection_difference \
  -a_srs "+init=EPSG:23700 +nadgrids=etrs2eov_notowgs.gsb" \
  -vrtnodata 255 \
  index_gyor.vrt \
  2015_o_nkp_RGB/{72-*,73-*,62-*,63-*,53-*}

Web Marcatorba transzformálás z19-nek megfelelő felbontásban:

gdalwarp \
  -t_srs "EPSG:3857" \
  -tr 0.2985821417389697 0.2985821417389697 \
  -tap \
  -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 200 \
  index_gyor.vrt \
  gyor_3857.tif

gdal2tiles.py \
  --zoom=8-19 \
  --resampling=cubic \
  --tiledriver WEBP \
  --webp-quality 85 \
  --processes 10 \
  --webviewer=leaflet \
  --xyz \
  --resume \
  --exclude \
  gyor_3857.tif \
  tiles

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.)

Pontosság ellenőrzés

Bizonyos konverziós paraméterekből többet is kipróbáltunk, és a végeredmény pontosságát ellenőriztük.

RTK referencia pontok

Szelvény	Hely	Elcsúszás 2011-2014	Elcsúszás 2015
14-113-213	Abaliget - Orfű	1,0÷1,5 m →	0,4÷0,8 m ↑
14-134-414	Pécs	0,8 m →	< 1 px ↓
41-132-432	Szentgotthárd	0,5 m ↘	0,1 m ↖
41-413-243	Zalalövő	0,8 m ↓	0,4 m ↑
43-341-321	Révfülöp	0,5 m ←	0,5 m ↙
63-431-434	Bakonyszentlászló	0,5 m →	0,2 m ↙
65-123-334	Nagykovácsi	0,5 m ↑	0,9 m ↙
65-124-421	Üröm	0,7 m ↖	0,2 m ↖
65-144-234	Bp., Pasaréti tér	< 1 px	0,8 m ↑
65-323-434	Törökbálint	0,4 m ↙	< 1 px
65-412-122	Bp., Örs vezér tere	0,5 m ↖	< 1 px
69-231-234	Debrecen	0,15 m →	0,2 m ↓
75-133-344	Esztergom	< 1 px ↘	0,7 m ↘
75-244-333	Penc	0,5 m ↘	0,5 m →
75-433-211	Szentendre	<1 px	0,6 m ↗
75-441-232	Vácrátót	0,5 m ↙	0,4 m ↑
79-123-331	Hajdúnánás	0,3 m ↓	0,2 m →
86-342-131	Hollókő	Mind ~0,3 m ↖ (Még épült.)
88-134-414	Miskolc	0,7 m ↘	< 0,1÷0,3 m ↓
97-221-332	Aggtelek	1,2 m ↙	1,5 m ↙
99-213-343	Sátoraljaújhely	- (Még nem volt.)	? (Még épült.)
108-333-142	Szögliget	0,2 m →	0,8 m ↓

A FÖMI 2011-2014 nagyobb eltérései az MK-tól

Szelvény	Hely	Elcsúszás 2011-2014	Elcsúszás 2015
51-231-241	89-es felüljáró a 87133 felett (47.2499,16.5500)	1,7 m ↖	0,6 m ↑
69-241-243	48 Haláp - Nagycsere (47.5273,21.7990)	2,2 m ↓	1,8 m ↓
86-232-423	21 Salgótarján (48.1264,19.8072)	2,3÷3,3 m ↘ (nem illeszthető)	1,1 m ↘
88-224-131	37 Szerencs körforgalmak (48.1537,21.1960)	1,5 m ↘	0,7 m ↘
99-424-433	381 Cigánd, Fő utcai körforgalom (48.2634,21.8918)	1,3 m ↓	0,8 m ↓

2025-ös feldolgozás

• grin/FÖMI 2025

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

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 tulajdonságok dokumentációja: https://josm.openstreetmap.de/wiki/Maps#Documentation

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> segítségével kell megadni az ortofotó terjedelmét. Országos lefedettségűeknél ez másolható a korábbi évekből. Ettől eltérő ortofotók esetén el kell készíteni a körvonalat:

• ha az ortofotó valamilyen közigazgatási határt követ, érdemes ezt OSM-ből letölteni (Overpass)
• a lefedett területet a gdal is ki tudja számolni: gdal_footprint -t_srs EPSG:4326 input.tif boundary.geojson. Nagy területnél időigényes.

Ha megvan a határvonal poligon(ok), a következő feldolgozási soron futtattuk végig QGIS-ben:

• Összevonás (szomszédos határvonalak esetén)
• Réteg más vetületbe: átvetítés EPSG:23700-ba
• Övezet: 60 méter, 1 szegmens. (Azért kell ,mert az OSM közigazgatási határok általában pontatlanok.)
• Egyszerűsítés: 500 m² tolerancia, Visvalingam
• Lyukak törlése (az övezet és az egyszerűsítés is tud lyukakat létrehozni)
• Réteg más vetületbe: átvetítés EPSG:4326-ba
• Exportálás GeoJSON formátumba, mezők nélkül, COORDINATE_PRECISION=5, RFC7946=YES beállításokkal (az RCF7946 az iD editor miatt kell).

A GeoJSON-t meg kell nyitni JOSM-ben, telepíteni az imagery-xml-bounds bővítményt, kijelölni a vonalakat, majd a Kijelölés panelen jobb klikk, és XML légi felvétel határok.

OSM Editor Layer Index (iD)

Az iD Editor (Vespucci, Potlatch, stb.) az editor-layer-index repóból veszi a rétegeket, az új ortofotót ide kell felvenni. 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.

A JOSM ezt a tárházat nem használja, viszont van egy összehasonlító oldala, ahol láthatóak a két lista közti eltérések.

É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 2015-es képek ebből a szempontból is sokkal jobbak. A 40 centis szelvényekből 3, a 20 centisekből 2 van, amin valamilyen szerkesztési hiba miatt lyukas egy-egy szántóföld. Beégés a 20 centis szelvényeken sehol sincs, a 40 centiseken az egész országban kevesebb mint 150 pixel fordul elő - ezek mind teherautó és furgon tetők, illetve egy íves hídtartó.

A 2011-2014-esben a legcsúnyább beégést eddig Debrecenben találtam.

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. (Ez megoldódott. Valaki elírta a parancssorban.)

Forrás hiba

A képen az Örs vezér tere látszik a BKK gomba környékével. A 2011-2014-es 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.

Az összes illeszkedési adatot ld. feljebb, a táblázatban!

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.

Hibás csempék

Már a 2011-2014-es csempék éles gyártása során is keletkeztek ilyen félig fekete, félig inverz furcsa csempék. Akkor azt hittem, a 3.6-os GDAL hibázott. Azonban a 2015-ös szelvényekből, 3.10.1-es GDAL-lal gyártva is, különböző helyeken, különböző nagyításoknál is jelentkezik a probléma. Elvileg ugyanúgy legyártva másnak épp ott nem lesz hibás. Egyelőre nem tudjuk az okát.

Maguk a csempék jók, böngészővel vagy külső képnézegetővel. Ez valami JOSM megjelenítési bug.