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.[1]
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.[2] - 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).
- 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
- 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
- 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 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 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.
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 ↓ |
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
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.
Jegyzetek
- ↑ 2π ∙ fél-nagytengely ∙ cos(szélesség) / 2 (zoomszint + 8), vagyis 2π × 6378137 × cos(47) ÷ (2^(18+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.
- ↑ Saját mérések és az alábbi cikk alapján: Guide to GeoTIFF compression and optimization with GDAL