turistautak.hu térképrészleteK+ jelzés GPS-szel
[ english
Előzmények

zaczhozzászólásai | válasz erre | 2009.09.29 08:44:26 (33531)
Gerecse, (Pilis) bevállalom. Az mpwizt még nem ismerem.
[előzmény: (33519) Hajo, 2009.09.28 21:27:23]

Hajohozzászólásai | válasz erre | 2009.09.28 21:27:23 (33519)
Szuper! Köszi! Egyelőre elküldöm az mpwiz leírását.
Kérlek nézd meg az alább hivatkozott wiki leírásokat a CLC bővítésről.
[előzmény: (33518) zayd, 2009.09.28 21:17:27]

zaydhozzászólásai | válasz erre | 2009.09.28 21:17:27 (33518)
A környékbeli tájegységekre (Bükk, Aggtelek, Zemplém) én is jelentkezem, mpwiz tapasztalatom még nincs, de fogékony vagyok az újdonságokra:).
[előzmény: (33511) Hajo, 2009.09.28 20:35:46]

Hajohozzászólásai | válasz erre | 2009.09.28 20:35:46 (33511)
talána kézi javításra kellene egy kicsit rugalmasabb határidő ill egy kis fejlesztés, hogy akár többen is javíthassunk

Ilyen fejlesztésen gondolkodom. Amit alább leírtam.
Úgy képzelem el, hogy az mpwiz megmondaná (egy DoNotUpload poi-val megjelölné), hogy hol vannak átfedések. Az átfedéseket viszont már kézzel kellene javítani.
(Nehezen tudom elképzelni, hogyan lehet automatizálni azt, hogy melyik poligon maradjon és melyiket kell vágni. Az egyik megoldás az, hogy abból csippentünk el, amiben nincs id=xxxx rész, mert azt most szúrtuk be, tehát a jelenleg a tuhuban levő poligon marad változatlanul. Mi a véleményetek erről?) Szóval itt kell még fejleszteni.

Biztosan marad azonban még kézi munka bőven.

Szerintem azonban nem olyan 'hibák' maradnak, ami miatt hetekig kell zárolva tartani a tájegységeket. Nem történik semmi akkor sem, hogy ha pár napig (urambocsá' hétig) benne maradnak az átfedések az éles anyagban. Gopndoljunk csak a település poligonokra. A tuhu indulása óta pár hónappal ezelőttög hektáros nagyságrendű átfedések voltak. Mégsem zavartak senkit.

Az biztos, hogy ha hárman maradunk 26(?!) tájegységre, akkor bele se kezdjünk, mert szilveszterig se végzünk. Én magam 3-4 környékbeli tájegységet bevállalok (bakony, vértes, mezőföld, velencei).

Szóval legalább 8-10 avatott rajzolóra volna szükség. Szükség volna némi mpwiz tapasztalatra, és/vagy sok türelemre/szabadidőre.
[előzmény: (33509) pgyp, 2009.09.28 20:19:17]

pgyphozzászólásai | válasz erre | 2009.09.28 20:19:17 (33509)
természetesen a mindent belére szavazok:-)

a határidők rendben vannak, mert azok egy része tőlem független, talána kézi javításra kellene egy kicsit rugalmasabb határidő ill egy kis fejlesztés, hogy akár többen is javíthassunk, ne egy emberen és az ő (változó) szabadidején múljon a javítás. Nekem kimondottan nem szimpatikus az, hogy mondjuk 1 hétig 1 ember napi sok órában ezt csinálja, mert ez kitolás vele és a többi rajzolóval is.
jelentkezés: felső-tisza és alsó-tisza jöhet, a kézi javítgatásban segítséget elfogadok.
[előzmény: (33506) Hajo, 2009.09.28 20:04:25]

Hajohozzászólásai | válasz erre | 2009.09.28 20:04:25 (33506)
CLC poligonok azonosítói:
baggio szerintem arra gondolt, hogy jó volna megoldás arra, hogy összepárosíthatóak legyenek az eredeti és a tuhuban levő clc poligonok. Ezt csak geometriai elven tudom jelenleg elképzelni, pedig jó lenne azért, hogy pl. nyomon tudjuk követni egy-egy poligon változásait.

A poligonok beemelése utáni kisebb átfedéseket/hézagokat a snap polygons lekezeli a paraméterként kapott távolságig - tipikusan pár méter. (Valóban nem bírkózik meg minden illesztési hibával az automata, de valamennyi maradtat is benne. Pár hónapja még tízezerszám volt a tuhu poligonjai között illesztési hiba mégsem dőlt össze a világ ;-) Jelenleg kevés van. A bővítés után max megint lesz pár tízezer, amiből az automata lekezeli a háromnegyedét. Csodálom a türelmedet. Nekem elfogyott, amikor a negyedik tájegységet böngésztem végig a snap polygons fejlesztése közben. Aztán rájöttem, hogy még így is sokat javít a helyzeten).

A nagyobb polygon átfedéseket viszont jelenleg nem tudjuk automatikus módon detektálni.
Miből adódhatnak nagyobb átfedések?
- Korábban manuálisan beemelt CLC felületek.
- Korábban megrajzolt felületek
- Korábban kihúzott felületek
- stb.
Amikor a további CLC felületeket beemeljük, nyilván átfedések lesznek.
Olyan kiegészítést tervezek az mpwiz-hez, ami ellenőrzi az összes poligont, hogy van-e átfedés köztük.
Ez viszont sajnos nagyon erőforrásigényes vizsgálat és ezért nagyon sokáig fog futni. Gyanítom, hogy több órás futási ideje lenne egy-egy tájegységénél. Persze idő kellene a leprogramozásához is. Az elv és a függvények zöme már megvan az mpwizben

"Ezek egy esetleges generalizálás után "leválhatnak" az útról, sok rajzoló, kézi munkáját tönkretéve"
Ez valóban egy veszély. Megnézem az mpwiz leírását. Hátha van okosság benne erre az esetre.

A snap polygons esetében ugyanez megvan. Viszont az fel van készítve, hogy bizonyos objektumtípusokat és/vagy extra=érték párossal rendelkező objektumokat érinthetetlennek tekint.
(Tehát pl. a backgound poligon és a tervezős utak nem módosíthatók, tehát nem fognak elválni a javított poligon éltől, hanem inkább ahhoz tapasztja a poligont). Sajnos a Neked küldött parancssor (paraméterezés) lehet, hogy csak kiszűrte a poligonokon kívül az összes típust, így azokat nem is vette figyelembe... (Ezt viszont tömegesen nem teszteltem. Csak azt a verziót, amit Neked is küldtem.)

pgyp!
A bemelendő típusokra Te is a "mindent beemelni"-re szavazol?

Határidő kérdés:
Az alábbi ütemezést javaslom:
- 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.

Így gyakorlatilag bő két héten belül be lennének emelve a poligonok. Az utómunkálatokkal 'elpiszmogunk' még további két hetet.

Aztán jöhet a reform. Az turistautak_typeset javaslat is szerepel az előzményben hivatkozott xls-ben.
[előzmény: (33503) pgyp, 2009.09.28 19:18:41]

pgyphozzászólásai | válasz erre | 2009.09.28 19:18:41 (33503)
5.) már van typelt kimenetünk, az OMP-n, szóval az bevezetve, ráadásul ott már van keresés is;-)

CLC poligonok azonosítói: van nekik ill. a bővítményeknek csak lesz. Adatbázis-hozzáférés kellene a későbbi módosítás/bővítéshez, de ezt szerintem néhányan simán lekezelik néhányan a rajzolók közül, ha kapnak jogosultságot.. Jó lenne a közeljövőben összehozni (befejezni) a bővítési how-to-t, hogy egyszerre és egységesen legyen elvégezve. Addig is a legfontosabb, hogy ne bántsuk a poligonokat, mert csak felesleges munkát adnak a bővítés után. Határidőben is jó lenne megegyezni.
[előzmény: (33500) baggio, 2009.09.28 18:45:03]

baggiohozzászólásai | válasz erre | 2009.09.28 18:45:03 (33500)
1.) Az összes, Magyarországon alkalmazható polygon beemelését támogatom.

3.) Az mpwiz snap polygons futtatása után rá kellet jönnöm, hogy az automata se tökéletes, így az általa javított hibákat egyenként át kellet néznem, és több helyen manuálisan belejavítani. Persze mellette rengeteg számára javíthatatlan hibákat kellet orvosolni. Mivel az automatikus hibajavítások jelölései (amik akár hibás javításokat is jelölhetnek) feltöltés után elütnek, legközelebbi mpwiz futtatás után már nem jelennek meg, mivel a progi már nem jelöli hibának miközben a valóságban még az lehet. Ezért egy mpwiz futtatás után az összes javítást és hibát át kell nézni feltöltés előtt!
Ez nekem a múltkori CLC-zéskor 6 napig, napi 4 óra elfoglaltságot jelentett! :-)

4.) Körösvidék bővítése után főleg a már meglévő folyó/csatorna polygonoknál találtam, Tundra (0x52, felület) és Orchard/plantation (0x4e, felület) által történt jelentős mértékű lefedéseket. Volt, hogy teljes holtágat, folyószakaszt takartak ki!

5.) Figyelembe kell venni, hogy Typ nélkül egyes felülettípusok azonosnak látszanak.
...a Typ bevezetéséig. Már megint azok a reformok... :-)


Sajnos a tuhu-n fennlevő mostani felületekben sok kisebb-nagyobb változás van.

Soproniban néhol egész nagy eltéréseket tapasztaltam a jelenleg meglévő, és a CLC2000-es poligonjai között. Látszott a több helyen manuálisan, vagy a mapedittel elvégzett generalizálás, de ezek minimálisak voltak, így nem lehet számlájukra írni a nagyobb eltéréseket. Úgy gondolom, ezek (főleg erdő poligonoknál) a természetes változások miatt vannak. Településsel közvetlen határos poligonoknál garantálható a változás, mivel a régi és a CLC-s településpoligonok között jelentős eltérés van.
Ezért fontosnak tartom a bővítés mellet a már meglévő poligonok ellenőrzését/ frissítését is. Ez településeknél már több tájegységben megtörtént, a többi poligon típus ellenőrzése még várat magára.

Az adhesive generalizálás előnyei ellenére (csökken az mp méret) azzal a hátránnyal járhat, hogy megnehezítheti a legközelebbi CLC frissítést/bővítést. Kérdéses számomra még az is, hogy ez a funkció csak a poligonok között generalizál? Mi van a polylineokra igazított polygonokkal?! Ezek egy esetleges generalizásál után "leválhatnak" az útról, sok rajzoló, kézi munkáját tönkretéve! Már snap polygonsnál is tapasztaltam ilyet. Van erre valami megoldás?

Hajo!
Nincs minden CLC poligonoknak egyedi azonosítója? Nagyban megkönnyítené a későbbi frissítéseket.
[előzmény: (33446) Hajo, 2009.09.27 16:10:50]

Hajohozzászólásai | válasz erre | 2009.09.27 16:10:50 (33446)
Az ebben az xls-ben leírtam annó, hogy melyik CLC típusok lettek annó beemelve a tuhuba, illetve melyeket szeretnénk még beemelni. (Az előbb linkekt helyről elérhető ez is)
Annó kialakult egy vita arról, hogy mit emeljünk be:
- 'Beemelni 1' oszlopban látható CLC ttípusok beemelését lényegében mindenki támogatja
- 'Beemelni 2' oszlopban levőket nem mindenki
- Az 'Összes beemelendő' az összes értelmesen beemelhető típust tartalmazza.

A részleteket leírtuk a 'CLC bővítési javaslat' és a 'CLC bővítés végrehajtása' wiki szócikkekben.

Tehát, hogy most már ne csak a levegőbe beszéljünk:

1.) Most meg kell határozni a bővítésre szánt CLC típusok körét (az előbb linkelt xls alapján). Legyen a határidő a vitára péntek éjfél (2009.10.02 23:59).
2.) Ezután a tájegységenkénti CLC200-ből meghagyjuk az előbb eldöntött típusokat és egy külön helyre elhelyezzük. Így már csak onnan Ctrl-A jelleggel be kell másolni az adott tájegység mp-be.
3.) Ellenőrizni kell az illeszkedéseket, részbeni automatikus javítással (mpwiz snap polygons funkció). Kézi előre is szükség lesz.
4.) Ellenőrizni kell az esetleges nagyobb poligon átfedéseket. (Jó volna hozzá automatizált megoldás. Az mpwiz-nek függyvénykészlete van hozzá, de kész funkciója nincs.) Az átfedéseket lehetőnek mielőbb javítani kellene.
5.) Figyelembe kell venni, hogy Typ nélkül egyes felülettípusok azonosnak látszanak.

(Kérem, hogy aki hozzá kíván szólni tényleg tanulmányozza előtte a tárgyi wiki szócikkeket, mert sok részlet és lehetsége probléma felvetése ott már megtörtént.)
[előzmény: (33445) kepenu, 2009.09.27 15:38:15]

kepenuhozzászólásai | válasz erre | 2009.09.27 15:38:15 (33445)
Picit pontosabban meg kellene határozni a bővítési feladatot.
- CLC 312 fenyőerdőket betenni
- CLC 313-ra visszaírni a vegyes erdőket (amik sok helyen CLC 311-et kaptak)

Mit kell még bővíteni?

Feniteket most megcsináltam a Kisalföldön, visszatöltés után látni fogjuk az eredményt.
[előzmény: (33436) Hajo, 2009.09.27 08:32:13]

Hajohozzászólásai | válasz erre | 2009.09.27 08:32:13 (33436)
Old Eye!
Ezek a nagyon közeli pontok sajnos az eredeti CLC2000-ben is ugyanígy benne vannak. (Lehet, hogy programhiba, de akkor az övék ;-) ). Fontos, hogy a túl közeli pontok szomszédos poligonok esetén mindkettőben azonosan vannak meg, tehát most node-ról modera illeszkednek.

Kepenu!
Az mpwiz-es adhesive generalizálás tervbe van véve.
Viszont szerintem se az 1m-nél közelebbi pontok törlését, se a generalizálást ne most csináljuk meg. Előbb az eddig hiányzó Tipus=CLC xxx extrajú felületeket tegyük be a tuhu-ra. (Az mpwiz adhesive generalizálása akkor tud tökéletesen működni, hogy ha noderól-nodera illeszkednek a szomszédos poligonok.) A beillesztés közben a tuhuban most meglevő felületek és az újak (amennyiben a tuhusokat nem változtatta meg senki) pontosan illeszkedni fognak. Ha mégsem illeszkedenk (mert megváltozott a tuhu felület), akkor az mpwiz snap polygons funkcióval lehet javítani az illeszkedési hibák nagy részét, maradékot pedig kézzel.
Az adhesive generalizálást ez után kell/lehet elvégezni szerintem.
(Talán van aki nem ismeri: Az adhegive generalizálás megkeresi akozak a nodeokat ahol három v. több poligon illeszkedik. Ezeket a 'sarkokat' érintetlenül hagyja, majd a többi illeszkedő szomszédos 'él'-ből annyi pontot elhagy, hogy az eredeti éltől a paraméterként kapott távolságnál ne kerüljön messzebbre. Így töredékére csökkenthető a nodeok száma. A felületek nyilván megváltoznak, de a hasznos információtartalon csak kismértékben változik).

Így hézagmentesen illeszkedő és felesleges nodeokat nem tartalmazó felületeket kapunk.

Sajnos a tuhu-n fennlevő mostani felületekben sok kisebb-nagyobb változás van.
- Van ahol az általad jelzett paraméter változtatás történt (valaki átírta a Tipus=CLC xxx extra-t).
- Van ahol a szomszédos erdőpoligonokat, amelyek Tipus= extra-ja eredetileg eltérő volt simán join-olta valaki.
- Nagyon gyakori, hogy tavat/nyiladékot/tisztást razzoltunk az erdőde és lyukasztottuk az erdőpoligont (Ez persze nem baj, de ettől is változott az eredeti)
- Nagyon gyakori, hogy az erdő/település stb. szélén futó út miatt módosítottuk a poligon szélét.
- Előfordult sajnos, hogy a poligont egyszerűen arrébbtolta valaki. (Volt 800m-es elcsúszás is.) Ezeknek a túlnyomó többségét kézzel és/vagy az mpwiz snap polygons funkcióval javítottam. Biztos mások is javítottak ilyet).
- van olyan tájegység (valahol az északi khg-ben), ahol már minden felület gereralizálva lett és nem is adhesive generalizálás. Ezértsok helyen nem illeszkedtek nodera a szomszédok. (Ezeket is javítottam snap polygons-al)
stb.
A lényeg, hogy a tuhu mostani felületei számtalan módon térnek el az eredeti CLC-től.

Keresünk rajzolókat, akik vállalják, hogy egy-egy tájegységben végrehajtják a felületek bővítését, a visszaellenőrzést és részben automatizált részben kézi visszajavítást.

Eddigi jelentkezők:
- Hajo
- Baggio
- pgyp
[előzmény: (33435) kepenu, 2009.09.27 07:42:27]

kepenuhozzászólásai | válasz erre | 2009.09.27 07:42:27 (33435)
Köszi! Igen, ez kellett.

Old-Eye! Ha az 1 méteres pontokat egymásra tudnád varázsolni, akkor Trackman mpwiz progija meg tudná csinálni a generalizálást tetszőleges értékkel (OpenMapson 10 métert használtunk) úgy, hogy a felületek illeszkedése megmarad.

Szerintem érdemes lenne továbbvinni ezt a vonalat (is)
[előzmény: (33433) Hajo, 2009.09.26 21:18:59]

Hajohozzászólásai | válasz erre | 2009.09.26 21:18:59 (33433)
Kepenu,
Itt van az általam előkészített CLC 2000. Ez minden CLC típust tartalmaz (gyak. a szántó kivételével). Ez nem shp, hanem már mp. (Ha szüksége, akkor valahogy el tudom küldeni az shp szelvényeket is, bár gondolom az mp pont jó lesz Neked is).

Pont azért készült, hogy az eddig hiányzó CLC típusokat beemeljük belőlük. Lásd CLC bővítési javaslat valamint a CLC bővítés végrehajtása

A CLC 312 (fenyőerdő) pont ilyen (az valahogy annó kimaradt a tuhuból), de még sok más is is beemelésre vár.
[előzmény: (33432) kepenu, 2009.09.26 20:37:22]

kepenuhozzászólásai | válasz erre | 2009.09.26 20:37:22 (33432)
Megvan-e valakinek az eredeti CLC2000 shp?

Tudom, hogy van egy mp formátumú konvertált (http://turistautak.hu/tracks.php?id=1304) itt, most nem ez kellene.

1) az egész országban nincs rendes kiterjedésű fenyőerdő? A fenti CLC2000-ben nincs 312-es értékű objektum?

2) a Kisalföld régióban néztem, de lehet, hogy az egész országban érvényes: a CLC=313-ból 311 lett az idők során, pedig az a fenti fájlban még jó volt. Lehet tudni, hogy miért?


Bejelentkezés név:  jelszó:   tárolás [regisztráció]

Felhasználónevedet és jelszavadat a geocaching.hu oldalon is használhatod!

[ kezdőlap ] [ térkép ] [ + felmérések ~ ] [ + útvonalak ~ ] [ + poi ~ ] [ belépés ] [ faq ] [fórum] [email]

A weboldal működése és tartalma folyamatos fejlesztés alatt áll, köszönettel vesszük az észrevételeket a fejlesztési ötletek oldalon.
A turistautak.hu-ra feltöltött track-eket és a letölthető térképeket, azaz térképi adatbázist az ODbL licencnek megfelelően bárki használhatja.
Minden egyéb anyag előzetes írásbeli engedély nélkül csak magáncélra használható fel. jogi tudnivalók