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

johann g (Lud)hozzászólásai | válasz erre | 2009.04.17 16:17:01 (29683)
a CLC adatbázist most pár év után újra előhúzni és rátolni a térképre több, mint rizikós.
sok polygon lett igazítva úthoz stb. én spec rajzoltam újakat is, de gondolom sokan mások is. rakjuk be a hiányzó fenyveseket, meg kitudjamit aztán ha köhög az mpwiz, legföljebb kézzel betoljuk a helyére. léehet hogy lesz átlapolódás, de ahol aktívan rajzolunk ott előbb-utóbb elrendeződik minden. ahol meg nem ott feltehetőleg eddig se piszáltuk agyon a CLC-s polikat.
[előzmény: (29682) baggio, 2009.04.17 16:01:06]

baggiohozzászólásai | válasz erre | 2009.04.17 16:01:06 (29682)
A polygon reform állítólag a szerverbővítésre vár. Szinte az összes felület ki lesz cserélve az új CLC-sre, és néhol bizony újra kell igazítani. Főleg település polygonok maradhatnak meg, azokban sok a változás.
A POI-reform pedig egy progi lefutatására vár, ami a szerverbővítés után remélhetőleg megtörténik. Utána itt is lesz javítani való.
Én ennyit tudok, de majd az illetékesek megmondják a tutit! :-)
[előzmény: (29680) oli_b, 2009.04.17 15:03:10]

oli_bhozzászólásai | válasz erre | 2009.04.17 15:03:10 (29680)
A kütyükről adott info hasznos volt, köszi, csak félig-meddig tudtam ezeket (a leveleket ismertem, de hogy raszterez is a garmin, azt nem).
No de vissza a polygonokra:
Igaz, hogy eredetileg mind a 7 erdőcafatnak más-más CLC-je volt, de most mindnek egyforma van az adatbázisban (Ez vajon mikor és miért íródhatott át egyformára?). Igy hiába lesz meg a felület-reform, hiába lesz többféle, látványosabb felület, ez a 7 darabka mind egyforma lesz, mert mindegyikük CLC 311 és mindegyikük 0x14, tehát nincs olyan ismertetőjegyük, ami alapján meg bírnád különböztetni őket. Emiatt mondtam eredetileg azt, hogy ilyen esetben ha összevonnánk őket kézzel, akkor nem jelentene adatvesztést, illetve a felületreformot ugyanúgy véghez lehet vinni rajta, legfeljebb nem 7 kicsi 0x14 cafrangból lesz lombhullató erdő, hanem 1 nagyból.
Vagy úgy gondolod, hogy az eredeti CLC készlet alapján vissza lennének írva az eredeti CLC kódok, amik anno ki lettek hagyva / menet közben elvesztek a rendszerből? És mi van ott, ahol már piszkálva lett a polygon?

Illetve még egy észrevétel:
Irod, hogy az eredeti CLC adatbázis olyan egymással pontosan összefekvő polygonokat tartalmazott, melyek az országot pontosan, lyuk nélkül lefedik. Namármost 100-szor találkoztam olyan helyzettel, hogy a település, az erdő, és a gyümölcsös polygon össze-vissza átfed, mindegyik mindegyikkel, sőt mindhárman egymással. Ez most vajon az eredeti CLC adatbázisból jött le hibásan, vagy valaki ilyet rajzolt bele ???

Megint végigolvastam az itt leírtakat, mert a Gyenesi összeröfi óta nem nagyon emlékszem már, hogy mit mire akartunk változtatni. Nasszóval ha mindez ilyen szépen össze van szedve, le van írva, elvileg megcsinálható. Mire várunk gyakorlatilag? Túl nagy és merész falat, és nem merjük meglépni?
Bár szerény véleményem szerint az "égetőségi" sorrend (azazhogy mi mennyire égető probléma) szerint az első helyen a POI reform lenne. Ott látok akkora gubancokat, hogy égnek áll a hajam. Minden POI mindenféle gány iconnal meg típussal van berajzolva, brrrr! Aztán másodiknak lehetne ez a felületkészlet-bővítés, aztán a vonalreform. De mi a gátja? Tudjuk, hogy mit akarunk, tudjuk a mikéntjét, egyet is értünk, mindenki bólogat hogy kéne, aztán jövőre meg nem a tuhu-nak vágjuk fel az 5éves tortáját, hanem a reformtörekvéseknek :-D
[előzmény: (29669) Hajo, 2009.04.17 11:18:48]

Hajohozzászólásai | válasz erre | 2009.04.17 11:18:48 (29669)
Az a helyzet, hogy az eredeti clc-ben (megnézheted itt) az általad jelzett helyen csupa különböző clc típus van. 311,312, 313. (Ebből a 312 a tuhun nem látszik, mert annó kimaradtak a fenyvesek). Tehát valami elb.. volt azon a helyen. Gyanítom, hogy máshol is, ha egyforma Tipus=CLC XXX értékek vannak egymás mellett.

A clc bővítés folyamatának egyik lépése az, hogy a nodepontok számát csökkentjük. De csak a bővítés után van értelme. A clc eredetileg egy az országot lyuk/hézag nélkül lefedő poligon készlet. Ezt módosítottuk kisebb-nagyobb mértékben több helyen már. Szeretnénk több / differenciáltabb felületeket látni. Mivel a clc poligonok illeszkednek egymáshoz a bővítés elvileg nem okoz problémát. Ha azonban az eddigiekben is már módosított poligonokat nagymértékben generalizáljuk (egyszerűsítjük), akkor a bővítés nem lesz lehetséges. A bővítés után, amikor már egymás mellett vannak a szinte tökéletesen illeszkedő poligonok, akkor első lépésben az mpwiz-ben létrehozott snap poligons funkcióval javítani lehet az apró illeszkedési hibákat. Ezután már igen nagy százalékban tökéletesen illeszkedni fognak az új poligonok a régiekhez. Ekkor már lehet egyszerűsíteni az mpwiz adhesive generalizálás funkciójával. Ez figyelembe veszi azt, hogy az illeszkedő poligonokat egyformán generalizálja.

A kütyükön (Garmin-ról beszélek) soha nem olyan részletesek a vonalak és felületek, mint az mp-ben. A Garmin kimenet készítésekor a cgpsmapper egyrészt feldarabolja az elemeket egy rácsba (pont azért, hogy egy óriás erdőpoligont, ami Sümegtől, Várpalotáig tart ne kelljen egyszerre kezelnie a szűkre szabott számítási teljesítményű kütyünek), másrészt egyszerűsíti a nodepontokat. Ráadásul több "zoom szintet" (levelt) hoz létre. Mivél távolabbról nézed a térképet, annál kevesebb vonalat és a megjelenőkön is egyre kevesebb részletet látsz. Nyiss meg egy img filet Mapedittel. Jól láthatóak a fentiek.
(Oda akarok kilyukadni, hogy a nodepontok csökkentésével önmagában nem biztos, hogy a kütyün csökken a számítási igény)
[előzmény: (29663) oli_b, 2009.04.17 10:36:45]

oli_bhozzászólásai | válasz erre | 2009.04.17 10:36:45 (29663)
Nem hinnéd, de a koszegi pl. DUGIG van ilyen esetekkel (Azonos CLC-k egymás mellett). Sőt, szinte csak ilyen eset van! Pl a balaton tájegységben is nézegettem, ott szépen 311-ek és 313-ak vannak egymás mellett, meg sem fogalmazódott bennem, hogy összevonjam a 0x14-eket. De a koszegi-ben nagy lehetőséget látok ebben.
Csináltam egy nagyon apró próbát: a Vát-Bögöt-Szeleste háromszögben van egy erdőfolt. Hét, azaz 7db polygon alkotja, teljesen lyukmentesen egymáshoz fekszenek. Mindegyik 0x14, mindegyik Tipus=CLC 311. És természetesen jó kacifántos határvonallal csatlakoznak egymáshoz, jó sok node ponttal. Márpedig minden belső, szükségtelen node pont 2-szer fog szerepelni, hiszen mindkét (egymással összefekvő) polygon pontjai között bent lesznek. Az mp-ből kivettem csak ezt a 7 objektumot, és kimentettem: 19,4 kB. Ezután egyesítettem a felületeket egy naggyá, és pótoltam a hiányzó extra paramétereket, majd így kimentve, és a mentett mp-ből az egy szál polygont kiemelve: 12,0 kB.
És akkor még nem is vettem figyelembe azt az optimalizációs lehetőséget, hogy a külső körvonalat alkotó, egymástól néhány / vagy néhány 10 / méterre levő pontokat kiritkítani 5-ödére, 10-edére (miközben az eredeti polygon formája teljesen megmarad, illetve 5-10 m-nél nagyobb eltérés nem lesz). Ilyen módszerrel le lehetne venni a méretet 7-8 kB -ra!
Ennek számos előnye lenne:
a) - kisebb adatbázis méret a serveren, kevesebb adatbáziselem, az elemek kisebb méretűek
b) - kisebb mp méret, kevesebb objektum, gyorsabb betöltés és rajzolás mapedit-ben
c) - amikor lefordul a kimenetekre, kisebb kimeneti fájl, ez gyorsabb betöltést és animációs sebességet okoz a kütyükön, kevesebbet számol, gyorsabban rajzol. Kisebb lesz a memóriaigény is.

Az automatizált megoldást viszont kizárólag a körvonal pontjainak ritkítására használnám, az összevonásra viszont nem.
Azért, mert kétféle sarkalatos erdőfoszlányt ismerek:
1 - a nagyon apró fecnik, egymásnak fekszenek, együtt alkotnak egy nagyobb foltot - na ezeket marhára össze kéne vonni.
2 - igen kacifántos, összetett, hatalmas területeket átfogó (több településen túlnyúló), egybefüggő 0x14. Na ehhez én már nemigen vonnék hozzá semmit, mert így is elég geb@szos ilyenkor rajzolni vele. Kijelölöd, oszt fél óráig pöttyözi a mapedit. És nem tudom, hogy egy kütyünek is mennyire jó ekkora polygonokkal dolgozni, azazhogy simán 30-szorosan lelóg a látott képről a poly, de a kütyü szenved, mert ki kell számolnia, hogy valóban az egész képet beborítja az erdő. Ilyen esetben nem tudom, hogy egy kettévágás egy egyenes mentén esetleg indokolt lenne-e? (nem növeli a pontok számát és az adatbázis méretét, de kezelhetőbbé válik)
Szóval ez utóbbi eset miatt nem alkalmaznék automatizált megoldást a polygon-összevonásra, mert ha az algoritmus csak azt nézi, hogy hol fekszenek össze egymással azonos CLC-jű 0x14-ek, akkor ész nélkül össze fog vonni mindent, és akkor jaj neked, mapedites rajzolás!
[előzmény: (29646) Hajo, 2009.04.16 17:47:16]

Hajohozzászólásai | válasz erre | 2009.04.16 17:47:16 (29646)
Tervezem a kidolgozását egy módszernek, amivel könnyen, egyszerűen és bakimentesen lehet azonos CLC-jű, egymással érintkező erdőfoszlány -polygonokat összevonni (anélkül hogy túl nagyok lennének).

mpwiz a te barátod. Nézd meg a join (-j) művelet leírását.

Az azonos clc-jű erdőfoszlányok elvileg nem nagyon lehetnének a clc szerint egymás mellett (pl két db Tipus=CLC 311 poligon egymás mellett), bár nem tartom kizártnak. A jelenleg azonos type (national park 0x14), de eltérő Tipus=CLC ... poligonokat viszont ne vonjuk össze, mert a felületreform után több típus esetében eltérő kinézetet fognak kapni.
[előzmény: (29645) oli_b, 2009.04.16 17:34:38]

oli_bhozzászólásai | válasz erre | 2009.04.16 17:34:38 (29645)
Hi!
Egyirányúsítottam a koszegi összes vízfolyását. Ahol kellett, ott az irányokat is beforgattam.
Illetve a víz típusát is átállítgattam: csak a Répce, Gyöngyös, Perint, Zala, Pinka lettek folyók, minden más csak patak.
Kérdés: a Pinkánál 1-2 helyen (mivel többször átmegy Ausztriába, ezért szakad) nem az Utcanev-ben volt a folyó neve, hanem a Label-ben. Megnéztem a PDA-mon Russában: mindegy neki, mindkét módon ugyanazt mutatja. Ettől függetlenül mindent áttettem Utcanev-be, és kitöröltem a Label-ből.
Nyugtassatok meg, hogy ez a helyes konvenció, már hogy Utcanev-be tesszük.

Tervezem a kidolgozását egy módszernek, amivel könnyen, egyszerűen és bakimentesen lehet azonos CLC-jű, egymással érintkező erdőfoszlány -polygonokat összevonni (anélkül hogy túl nagyok lennének). Nyomatok róla egy howto-t, mert szerintem erősen lehetne redukálni a tájegység adatbázis méreteken.

Más: KiVi, Kolesár, többiek: tájegység-felelősi ügyben nincs előrelépés? Kőszegit szívesen elvállalnám.


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