CLC bővítés végrehajtása

CLC bővítés állapota tájegységenként

Tájegység	CLC település csere	By	CLC bővítés	By	Snap polygons?	By	Kész?	Megjegyzés
aggtelek	2009.07.13 23:24	Hajo			2009.07.13 23:24	Hajo	kész	CLC bővítés után új snap polygons szükséges
also-tisza	2009.03.09 20:46	pgyp					részleges?
bakony	2009.05.06 12:48	Hajo			2009.02.13 22:02	Hajo	kész	CLC bővítés után új snap polygons szükséges
balaton	2009.04.01 18:37	Hajo			2009.02.16 20:34	Hajo	részleges	CLC bővítés után új snap polygons szükséges
borzsony	2009.07.17 13:35	Hajo			2009.07.17 13:35	Hajo	teljes	CLC bővítés után új snap polygons szükséges
budai	2009.07.17 19:00 *	Hajo			2009.05.14 15:42	Hajo	teljes	CLC bővítés után új snap polygons szükséges
bukk	2009.07.18 12:34	Hajo			2009.07.18 12:34	Hajo	teljes	CLC bővítés után új snap polygons szükséges
cserhat	2009.07.18 14:06 *	Hajo			2009.07.18 14:06	Hajo	teljes	CLC bővítés után új snap polygons szükséges
felso-tisza	2009.04.22 22:46	pgyp					részleges
gerecse	2009.07.22 ell	Hajo			2009.02.22 15:12	Hajo	teljes	CLC bővítés után új snap polygons szükséges
godolloi	2009.09.30 21:03*	baggio
karancs-medves	2009.07.19 08:04	Hajo			2009.07.19 08:04	Hajo	teljes	CLC bővítés után új snap polygons szükséges
kisalfold	2009.05.15 18:03	Hajo			2009.05.15 18:03	Hajo	kész	CLC bővítés után új snap polygons szükséges
korosvidek	2009.05.21 0:23	baggio	2009.07.07 23:18	baggio	2009.09.07 01:23	baggio	teljes
koszegi
matra	2009.04.29 22:16	Hajo					részleges
mecsek
mezofold	2009.05.06 17:21	Hajo			2009.02.13 23:06	Hajo	kész	CLC bővítés után új snap polygons szükséges
orseg
pilis					2009.07.12 21:40	Hajo		CLC bővítés után új snap polygons szükséges
somogy	2009.04.17 0:55	Hajo			2009.04.17 23:22	Hajo	részleges?	CLC bővítés után új snap polygons szükséges
soproni	2009.09.09 11:52	baggio	2009.10.01 20:16	baggio			részleges
tisza-to	2009.09.28 19:18	baggio					részleges	település csere teljes
velencei	2009.05.06 21:07	Hajo			2009.02.16 19:20	Hajo	kész	CLC bővítés után új snap polygons szükséges
vertes	2007.02.04 10:08	András			2009.02.16 18:39	Hajo	részleges?	CLC bővítés után új snap polygons szükséges
zala	2009.04.01 18:35	Hajo					részleges?
zemplen	2009.09.08 23:47	baggio					részleges

(* - Teljes, de néhány dokumentált települést később kézzel kell rendezni.)

(e - poligonátfedés vizsgálattal ellenőrizve)

A Wiki-n hónapok óta megvan a szócikk (CLC bővítési javaslat). Valójában a Gyenesdiási munkamegbeszélésre készült el bár jóval korábban felvetődött itt a fórumon.

Az alapelv az, hogy a CLC-ben (ahonnan a tuhu-n jelenleg alkalmazott poligonok többsége származik) sokkal több és sokrétűbb poligontípus van, mint amennyit most használunk. Gondolom ennek jórész erőforrásbéli okai voltak. (2001-2002-ben erősen korlátozott memóriájú GPS készülékek; szerveridő a kimenetek gyártásakor; mp fileméret stb.)

Felmerült, hogy jó volna pl a bózót stb. felületeket is beemelni a tuhu-ba. Volt olyan erdőtípus, amit a CLC külön kezelt, de annó nem került bele (pl fenyves). Erre mndtad, hogy background poligonban mész a GPS szerint közben pedig bozótban vagy épp egy sűrű fenyvesben.

Gyenesdiáson pgyp előterjesztése után döntés született, hogy meglépjük a bővítést a szervercsere után

Azóta több kolléga közreműködésével folyt némi háttérmunka.

1. Elkészült Trackman kolléga kiváló mpwiz programjának span polygons funkciója, ami lehetővé teszi, hogy a meglévő (és többnyire módosított poligonok) közti véletlen hézagok megszűnjenek. (Az eredeti CLC poligonok hézag nélkül illeszkednek egymáshoz). A további CLC poligonok beemelése után ugyanez a funkció teszi lehetővé a beemelt poligonok hézagmentesítését. Sok tájegységnél ez a művelet végrehajtásra került. (Feltöltési logokban dokumentáltuk).
2. A tuhu-n tavaly a településpoligonok jelentős része még nem CLC szerinti volt (főleg falvak, községek esetében). Ezeket sok tájegységben kicseréltük. Lehetnek még ilyen tájegységek. Ezekben még ki kell cserélni a településpoligonokat.
3. Peter68 kolléga vezetésével (a poi reform mellett) előkészítettük a felületreformot is. Elkészült a konverziós függvény. Emlékeim szerint beépítettük a bővítésre szánt típusokat is, hogy azok összerendelődjenek a majdani turistautak typeset felületkategóriáihoz.
4. Hajo, pgyp és baggio kollégák elkezdték a településpolygonok cseréjét, a bővítés előkészítéseként.
5. Lezajlott az első bővítés a Körösvidéken, sok értékes tapasztalatot nyerve a további bővítéshez.

Településpoligonok cseréje CLC szerintire

Településpoligonok cseréje CLC szerintire úgy, hogy az utólag berajzolt lyukasztások (parkok, tavak stb.) megmaradjanak.

1.) A CLC fileból az összes település poligon kiválasztása: Type=0x0d

• CLC file megnyitása.
• Szerkesztés - Kiválasztás - Minden felület
• Szerkesztés - Kijelölés törlése - Típus alapján (0x0d Reservation)
• Szerkesztés - Kijelölés törlése - Típus alapján (0x4b Background)
• Szerkesztés - Törlés nyom nélkül (Ctrl-Del)

2.) Ha a tájegységet több CLC szelvény fedi le, akkor a másik szelvényből is be kell másolni a település poligonokat. A szelvényezettség miatt két vagy több részből álló településpoligonokat össze kell vonni. (Extra értékeket vágólapra helyezni. Mindkét felületek kijelölni. Az egyiken jobb gomb, majd Felületek egyesítése. Ctrl-Enter, majd vágólapról az extra értékek visszamásolása).

3.) Kijelölni az összes CLC településpoligont. Szerkesztés - Kiválasztás - Típus alapján (0x0d reservation)

4.) Mindegyikhez hozzáfűzni egy új extra értéket.

• Ctrl-Enter, majd beírni: Tajegyseg=CLC
• Mindegyik kijelölt településpoligont a vágólapra másolni.
• Szerkesztés - Másolás (Ctrl-C)

5.) A településpoligonokat bemásolni a tájegység mp-be

6.) Egyeségel végignézni az összes településpoligont, hogy fedik-e egymást?

• --> Átlátszó felületeknél nagyon kiabál, hogy ha nem. Az is nagyon látható, hogy ha eredetileg CLC poligon volt, de módosítva lett valamiért a körvonal. Ilyenkor inkább jobb nem bántani. A rajzoló nyilván tudta, hogy mit csinál.

7.) Ha cserélni kell, akkor - fontos! - a legkülső kontúr (rendszerint az első felület) minden pontját kell kicserélni a CLC szerintire (amelyiknek nincs labelje az a CLC szerinti). A kijelölt forrás CLC poligon esetén Enter, majd Alkotórészek fül, 1. kontúr kiválsztása, másolás (Ctrl-C). Label-lel rendelkező településpoligon kijelöl, majd Enter, Alkotórészek fül, 1. kontúr, beillesztés (Ctrl-V). (Ekkor a külső kontúr minden pontját kicserltük a CLC szerintire. Ha voltak településen belüli utólagos lyukasztások, akkor azok megmaradnak amennyiben az új kontúron belülre esnek).

8.) Amikor minden településpoligon készen van, akkor Ctrl-E -vel kiválasztottam az összes Tajegyseg=CLC extra értékkel rendelkező poligont (az bemásolt eredeti CLC poligonokat), majd Ctrl-DEL-let kitöröltem azokat. (Fontos, hogy ne maradjanak benne, mert akkor duplázódnak a poligonok. Igaz CLC nevű tájegység nincs).

Mik a további lépések?

1. Településpoligon cserék befejezése minden tájegységben. (Részletesen lásd alább.)
2. A CLC poligonokat tájegyságenként vágva elkészítettem (Hajo)
3. A bővítésre kijelölt poligonokat be kell emelni tájegységenként a tuhu-ba. (Ezen a ponton javaslom az összeset beemelni).
4. A beemelt poligonokra ellenőrizni kell, hogy pontosan illeszkednek-e a meglevőkhöz. Ahol nem ott javítani kell. Ez mpwiz snap polygons funkcióval jórészt automatizálható, de számottevő kézi munkára is szükség van + mpwiz gyakorlatra.
5. Célszerű volna egy adhesive generalizálást ráengedni az összesített poligonokra. Mindannyian ismerjük, hogy a CLC poligonok pár méteren belül 3-5 pontot is tartalmazhatnak. A generalizálással nagyban csökkenthetjük az adattömeget, miközben az információtartalom lényegében nem vész el. (Igaz, hogy a cgmpmapper is generalizál a kimenet elkészítésekor, így a GPS készülékre végső soron nem jut kevesebb adat). Ez mpwiz-zel megoldható úgy, hogy közben a szomszédos poligonok illeszkedése megmarad (adhesive generalizálás funkció).
6. Ha b) pontban minden poligont beemeltünk, itt lehetőségünk van a kimenetekbe nem szánt poligonokat kivenni, vagy megjelölni az adatbázisban talonba rakottként. (Miért jó ez? Ha esetleg később mégis szükség volna további - akár átmeneti - bővítésre, akkor már lesz koherensen illeszkedő generalizált poligonkészletünk).
7. Célszerű meglépni a felületreformot a közeljövőben (bár ez nem kifejezett feltétel).
8. Jó volna typ-et használni a Garmin kimenetnél, hogy a bővítés után igazán szép eredményt lássunk a GPS készülékeken. (Az omp már most is képes megjeleníteni a bővítés utáni típuskészletet).

Jelentkezők (CLC bővítés végrehajtása munkára):

• Hajo
• pgyp
• baggio
• zayd
• kovrob
• Stimm
• Fgg (kézi)
• Fairy

Határidők:

• október 2 (péntek) 23:59 beemelendő típusok vita lezárása. (úgyis mindent beemelünk ;-) ), jelentkezők toborzása
• október 9 (péntek) 23:59 beemelendő poligonok előkészítése. (Lényegében csak meg kell szűrni Tipus=CLC xxx szerint, hogy csak a bővítésre szánt típusok maradjanak).
• október 16 (péntek) 23:59 tájegységenként beemelni a poligonokat.
• október 30 (péntek) utánmunkálatok. Lásd fenti leírás.

A CLC településpoligonok cseréjekor elromlott egy településpoligon. Mi a teendő?

1.) A CLC 2000 sem tökéletes. kb 100 m-en belül pontosnak kell azonban lennie. (A gyakorlatban 20-em belül pontos, de 100m-nél keskenyebb részleteket nem nagyon tartalmaz --> "geometriai hibák"). Elvétve lehetnek felületkódolási problémák, de a hivatalos adatok szerint ezek kb 1% alatt vannak.

Az ilyen jellengű tapasztalatokban a gondot, az jelenti, hogy egyelőre gyümölcsös típussal jelöli a tuhu a CLC 242 kódú (Complex cultivation patterns) területeket, ami a neve ellenére leginkább kertvárosi vagy zártkertü övezeteket jelöl. Itt elsősorban nem geometriai hibáról, hanem kódolási hibáról beszélhetünk. Mondhatnám, hogy majd a reform megoldja, de erre a reformnak sincs egyelőre kész megoldása. Nincs nagy gond. Egyszerűen létre kellene hozni egy kertváros / zártkerti övezet felületet.

Most a tuhun gyümölcsösként jelöljük az alábbi CLC típusokat:

• CLC221/Szőlőskert,
• CLC222/gyümölcsös

A bővítés során jobb híján gyümölcsössé vált:

• CLC242/complex culvivation pattern

A reform idején a Tipus=CLC 242 poligonokat tehát át kell kódolni egy egyelőre nem létező felülettípussá (lásd Vita:Felület-reform).

2.) Előfordulhat, hogy eltűnt egy korábban településpoligon által lefedett zártkerti/pihenőőövezet. Nagy valószínűséggel azt történt, hogy az azt lefedő CLC242 felület még nem lett beemelve. Ha nem súrgős, akkor kérünk várd meg, amíg a teljes bővítést el nem végezzük.

3.) A poligoncserék alkalmával megpróbáljuk megőrizni a rajzolók által korábban elvégzett módosításokat (pl. külső kontúrban útra illesztések illetve főleg a belső lyukasztások stb.) A cserét kézzel végezzük, ami azért biztonságosabb, mint ha automata végezné, de előfordulhatnak hibák.

4.) Mit tegyek ha ennek ellenére problémát tapsztalok? Kérünk jelezd a fórumban. Természetesen szabadon módosíthatod a településpoligont, illetve a cserét végző rajzoló mentéséből vissza is tudjuk állítani az eredeti poligont. Ez viszont a bővítés végrehajtásakor jelenthet problémát, amit majd újból kézzel kell orvosolni.

mpwiz Snap polygons

Segédlet az mpwiz program, címben említett funkciójának egyszerűsített használatához, és az utána végzendő műveletekhez.

A funkció röviden a kontúrok laza és pontos illeszkedését méri fel, elemzi és javítja. Kontúrok, vagyis poligon-poligon, és poligon-vonal közt is javíthat illesztéséi hibákat. Hajonak köszönhető mpwiz ezen kiegészítése, aki CLC bővítéshez szükséges (nem egyszerű) paraméter készletet bat-fileba tette, így egyszerűsítve kezdők számra használatát.

Teendők:

1. Előkészített készletett tartalmazó mpwiz.zip letöltése innen: http://turistautak.hu/tracks.php?id=20710
2. Tartalmának kitömörítése egy könyvtárba, ami legyen most mpwiz.
3. Tájegység, és track-jeinek letöltése, kitömörítése az mpwiz könyvtárba.
4. Letöltött mp átnevezése "1.mp" –re.
5. mpwiz_clc_boviteshez_jav_par.bat file futtatása
6. Az eredményül kapott "2.mp" file átnézése, kézi javítása.
7. 2.mp visszatöltése a szerverre.

A 2.mp file-t megnyitva sok új POI-t találunk, amik az elvégzett javításokat, és a laza illesztéskete jelölik (Soproni tájegységben 6298db csak az eltéréseket jelölő POI!). A kézi javítás abból áll, hogy egyenként, az összes POI-val jelölt helyen meg kell vizsgálni, az illesztést, és szükség esetén kézzel javítani rajta. Mivel a progi se tud minden hibát számunkra megfelelően javítani, az automatikus javítás ellenőrzése se maradhat el. Az új POI-kat feltöltéskor a szerver eldobja, így azok nem kerülnek be az adatbázisba. Ez egy részről jó nekünk, más részről viszont nem. Ha egy automatikusan javított pont, számunkra még hibás maradt, újbóli letöltés utáni újra futtatáskor már nem jelentkezik, mert a progi már nem érzékeli hibának, így azt meg se jelöli. Ez azt jelenti, hogy egy letöltés alatt kellene javítani az összes (több ezernyi) hibát, ami nem kis feladat. Javításkor ne csak a POI-val jelzet hiba közvetlen közelét javítsuk, hanem tekintsünk egy kicsit távolabbra is. Pl. egy úttal párhuzamosan poligon kontúrnál csak egy helyen jelzi a laza illesztést, akkor javítsuk az egész útnál, ne végezzünk félmunkát. A program alapos, de így is lehetnek olyan hibák, amiket nem észlel. Ezeket is javítsuk, ha már felfedeztük.

POI-k következőket jelölik: - 0x1a11 (zöld navaid) poi jelöli a pontosan egymást fedő poligonokat,0x1a13 (sárga navaid) poi jelöli a félig pontosan fedő poligonokat (min 50%-ban pontos illeszkedés) - 0x0000 (kérdőjel) poi-val megjelöli az azonosított laza illeszkedéseket - 0x1a15 (kék navaid) pár m-en belüli két node egymásra illesztése történt (nem összekeverendő a 0x1b15 tájegységek közötti útilleszkedést jelző POI-val!) - 0x1a13 (narancs navaid) node elhagyásával javított illeszkedés - 0x1a16 (piros-fehér-zöld navaid) node beszúrásával javított illeszkedés

Jó munkát! :-)