hanoj napsal(a): > Pokud jsem to dobre pochopil, tak tvoje uprava umi predzpracovat velkou > datovou sadu a nasledne ji pred vykreslovanim efektivne redukovat na > zobrazene okno + odpovidajici detaily meritku.
DataSet jako takovy jsem zatim optimalizoval jen na spotrebu pameti. Ale oddelil jsem vizualizacni vrstvu, ktera uz o tech datech neco vi - cachuje promitnute souradnice a platny styl. Rychle filtrovani (selekce) je zatim trivialni jen na subset podle jedne osy (popr. jen tagovane nody), pak se filtruje iterativne do skutecneho vyrezu. To je dulezite pro rychle vykresleni nodu (snadne kresleni, ale obrovsky pocet). To same pro selekci (zkuste si v puvodnim josm s czechia.osm jen vybrat node, trva to 100-300ms na silnem stroji). Redukce vykreslovanych detailu se uz pak deje nazivo pri kresleni cest (tech neni tolik, ale >1px siroke renderovani je dost drahe), a to tak, ze: 1. Cesty pod 1px se nemaluji. 2. transformuje se bbox cesty na obrazovku, pokud je mensi nez 5 pixelu, maluje se jen primy segment mezi zacatkem a koncem (cili pod 5px mizi kulataky) 3. dynamicky se vynechavaji nody, ktere jsou blize nez 5px od minuleho nodu (krom posledniho). Zubata cesta se tim narovna. Pokud je jen klikata, rozdil bude minimalni ;-) 4. pri malem zoomu se snizuje sirka na 1px - rendrovani takovych linek je vyrazne levnejsi Navic veskera matematika kolem malovani a selekce je celociselna. Kubajz napsal(a): > Michal Grézl napsal(a): >> No faktem je, ze ti patlalove, co ted bastli josm, nikdy v zivote >> nevideli vektorovy editor a nejsou schopni udelat ani rozumne >> ovladani, a chtit po nic nejakou zmenu vykreslovaciho jadra je asi >> trosku moc. Asi stejne prejdu na merkaator:) >> >> > Takhle bych to nerekl. Ja si vazim kazde prace na tom editoru. Od > zacatku udelal velky kus prace a neni mozne jim zazlyvat, ze to nedelaji > 100% dobre. V dobe, kdy zacali s vyvojem, tak asi malokdo tusil, na jak > velkych datasetech to pobezi. A pokud nekdo jako Petr do toho vidi a Tak jako tak projekt nekolikrat zmenil "majitele" a riznout do toho radikalne neni uplne jednoduche z duvodu mnozstvi stavajici funkcionality a pluginu. A co se tyce velkych datasetu, uprimne receno mam to stesti, ze je cechy jsou jeste tak malo zmapovane. germany.osm obsahuje 10x tolik dat a vsech jeho 4.5M nodu neudrzim v rozumnem mnozstvi pameti. I na to bych ale nasel v novem modelu odpoved, otazka je jestli je to use case. > optimalizuje to, tak je to super. Patlaly bych je nazval az v pripade, > kdy by odmitli tyto zmeny do trunku. To bych pak mozna pouzil i silnejsi > vyrazivo... Bohuzel nejde o zmeny, ale o cleanroom implementaci. Pred tim nez jsem zacal tenhle experiment tak takovy typ zmeny v datovych strukturach zamitli (nekomu jinemu,a ne prilis stastne udelanou, ja jsem byl v projektu prilis novy na to, abych si mohl dovolit takovou zmenu sam navrhnout, prestoze jsem o jeji nutnosti vedel od zacatku). Mozna je presvedci vysledky, i kdyz velky dataset stejne neni primarni use case. Zatim se ale mail do josm-dev s .jarem zasekl u moderatora :-) Tak jako tak dokazu nektere optimalizace na mappaint aplikovat. Lepsi rozdeleni dat a vizualizace by si pral i owner projeku a poslouchatelnost na modelu bych dokazal vynutit i bez (tolik v JOSM chybejici) encapsulace (diky tomu, ze kolega Bloch ty collections navrhl docela dobre). Ale bez prechodu z ChangeCommand na primy zapis do DataSetu s automatickym vytvarenim UndoableEditu bych jen tezko po vsech certech honil kde ktery Command pohnul s nodem ve ktere ceste a ja musim prepocitat bbox (popr zmenil atributy a ja musim prepocitat styl)... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! _______________________________________________ Talk-cz mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
