Ahoj, > (1) Občas vyhodí NullPointerException kdesi hluboko ve stacku swingu uvnitř > volání > org.openstreetmap.josm.gui.progress.PleaseWaitProgressMonitor$4.run(PleaseWaitProgressMonitor.java:172). > Dělá to ještě někomu?
Tohle se stava, kdyz se provadi zmeny na GUI componentach z jineho nez EDT vlakna. Swing neni threadsafe, veskere updaty GUI by se meli volat pres SwingUtilities.invokeLater. V Josm byval checker, ktery pri kazdem pristupu do GUI ze spatneho vlakna vypsal do konzole stacktrace (zapinalo se to pres propertu a defaultne v svn verzi), ale kdyz jsem ted kratce kouknul, tak ho tam nevidim. >(2) Občas JOSM po kliknutí naráz vyžere celý heap Javy a současně pár giga >paměti X server procesu. Zabitím JOSM procesu se vše zas uvolní. Zkouším ještě >předchozí verzi JOSM, jestli není bug spíš někde mezi nejnovějším >JOSM, >Xserverem a nvidia driverem. Pust josm s paremetry -Xmx2048m -XX:+HeapDumpOnOutOfMemoryError (pripadne mensi heap, jde o to, aby pri te chybe pretekl). JOSM spadne a udela java<pid>.hprof soubor s heapdumpem, do kteryho pak muzem kouknout, co sezralo veskerou pamet. V heapdumpu bude citelna veskera pamet JOSM, takze jestli jeste nepouzivas OsmAuth, tak na nej prejdi, jinak by slo (snadno) vycist tvoje heslo. -- Jirka 2014-09-08 14:58 GMT+02:00 Marián Kyral <[email protected]>: > > ---------- Původní zpráva ---------- > Od: Martin Švec - OSM <[email protected]> > Komu: OpenStreetMap Czech Republic <[email protected]>, > [email protected] > Datum: 8. 9. 2014 14:24:34 > Předmět: Re: [Talk-cz] Odstávka LPIS > > > Ahoj, > > Dne 8.9.2014 7:10, Marián Kyral napsal(a): > > Ahoj, > díky ta intenzivní testování. > > ---------- Původní zpráva ---------- > Od: Martin Švec - OSM <[email protected]> > Komu: OpenStreetMap Czech Republic <[email protected]>, Marián Kyral > <[email protected]> > Datum: 8. 9. 2014 1:28:45 > Předmět: Re: [Talk-cz] Odstávka LPIS > > > Ahoj, > > tak jsem potrápil nejnovější LPIS tracer, díky za pěknou práci :-)) Pár > postřehů: > > (1) Občas vyhodí NullPointerException kdesi hluboko ve stacku swingu uvnitř > volání > org.openstreetmap.josm.gui.progress.PleaseWaitProgressMonitor$4.run(PleaseWaitProgressMonitor.java:172). > Dělá to ještě někomu? > > > Tak tohle jsem ještě neviděl. Některé verze JOSM mi vyhazovaly NPE někde v > hloubi gui.painter. Ale už se mi to nějakou dobu nestalo. > > > Dělal mi to už kdysi RUIAN tracer, pak to zmizelo. Nezjistil jsem, jestli to > bylo upgradem traceru nebo upgradem z IcedTea na Oraclí Javu. Přijde mi to > jako nějaký race, když klikám rychleji než tracer stíhá zavírat dialog. > Zkusím večer chvíli klikat z PC v práci s Win7, jestli se něco objeví. > > > No já mám stále IcedTea - teď momentálně 7.2.4.7. Máš poslední verzi JOSM? > Tam už ten problém s informačními dialogy nějak opravili - Normálně klikám a > když přestanu, tak se ještě nějakou dobu bubliny postupně objevují. > > > > > (2) Občas JOSM po kliknutí naráz vyžere celý heap Javy a současně pár giga > paměti X server procesu. Zabitím JOSM procesu se vše zas uvolní. Zkouším > ještě předchozí verzi JOSM, jestli není bug spíš někde mezi nejnovějším > JOSM, Xserverem a nvidia driverem. > > Taky se mi ještě nestalo. Dokonce ani nemám tu doporučovanou volbu -Xmx...m. > Ale zase na druhou stranu, mám na všech počítačích minimálně 4GB. Na tom > nejnovějším dokonce 16G. Nicméně jsem si všiml, že u hodně velkých polí trvá > ta automatika docela dlouho. Nejprve se vypíše, že bylo natrasováno pole, > ale ještě pár sekund trvá, než se zobrazí. > > Dělá ti to u nějakých velkých lánů? Nebo i u pidi políček? Nebo při > napojování malého políčka na nějaký obrovský lán, případně les? > > > Je to jasný zacyklený memory leak, mám 6GB RAM ale nezáleží kolik paměti > Javě dám, během pár sekund sežere celý heap. Systém jsem v tom zatím > nenašel, někdy malé políčko, někdy velký lán. Nejvíc ramky si ale vezme > Xorg, možná jen tracer zviditelnil chybu někde hlouběji. No, moje gentoo je > směska verzí různých balíků, asi by to chtělo po 7mi letech rolling updates > reinstall od nuly :-) > > > Tak tohle se mi fakt ještě nestalo. Na jednom stroji Gentoo ~amd64, kernel > 3.16.0-gentoo, X (1.15.1) a nvidia (340.32). Na druhé zkouším stable. > Grafika tam je intel. > > > > > > (3) Ořezávání okolních polygonů je obecně super, ale místy dělá psí kusy :-) > Semtam si vybere špatný směr v cestě LPIS polygonu a místo ořezu udělá > zmrveninu připomínající sjednocení. Viz screenshot v příloze -- uprostřed > byl remízek v polích, místo ořezu se ve vyznačeném místě rozlezl přes > natrasovaný polygon. Ještě častější je vznik části cesty, která leze do > hrany mezi dva LPIS polygony a vrací se zpátky sama po sobě. > > > Jo o tom vím. Dokonce to umím i nasimulovat. Co zatím neumím, je to správně > vyřešit. Musím si na to sednout, nachystat si testovací příklady a zkoušet > možnosti. Mám nějaký nápad, uvidím, jestli zafunguje. Doufám, že se k tomu > tento týden dostanu. Na ocásky se snad taky dostane. Zase musím dávat bacha, > abych neusekl ten nesprávný kousek ;-) > > > Možná blbý dotaz -- nesnažíš se zbytečně vymýšlet kolo? Základní operace nad > (multi)polygony a další geospatial funkce musí přece být dávno někde > implementované, včetně ošetření těch okrajových situací. V červenci jsem > letmo mrknul na dokumentaci JTS+GeoTools a nevypadá to špatně, navíc tracer > už je má jako závislost. Pokud by geometrie JTS šla obalit vrstvou > převádějící datový model JOSM tam a zpátky...? > > > No možné to je. Nikdy jsem si s JTS/Geo nehrál. On je trochu problém v > implementaci. Ono se to nedělá přímo v tom changesetu. Ale dávkově, aby > fungovalo undo na celou operaci. Takže na začátku si vytáhnu seznam cest a > bodů do polí se kterými budu pracovat. a pak přidám natrasovanou cestu a > hledám kolize, slučuji body a "řežu" do okolních cest. Všechny operace > (přidání/smazání/přesun bodu, změna cesty) si přitom ukládám do seznamu, > který vrátím a následně dle toho JOSM provede skutečné operace v aktivní > vrstvě. Takže si musím udržovat všechny vazby cesta/uzel, jinak smažu uzel, > který se smazat nemá a je problém. > > > Zkusím se na to mrknout, jestli by se JTS/Geo daly nějak více použít. Zítra > ráno cestou do Prahy bude dost času. Případně, jestli se v tom vyznáš, > nějaká pomoc by mi bodla ;-) > > > > > (4) Šlo by udělat, aby při stisknuté klávese Ctrl se vynechala funkce ořezu > a navázání na "cizí" polygony? Bylo by to fajn u LPISu i RUIANu. Někdy je > rychlejší ručně napojit okolí na čistý polygon, než zkoumat a opravovat > následky "automatiky". LPIS viz výše. RUIAN zase typicky vykusuje zářezy do > sousedících budov co nejsou v RUIANu, nakreslených nepřesně podle KM. Takže > musím likvidovat ocásek vyrobený v místě průniku, přitom by stačilo jen > ručně posunout uzel sousední budovy kam patří. > > Určitě. V tom původním traceru se modifikátory používaly. Já to většinou > dělám tak, že dám "zpět", bod posunu a znova to natracuji. Ale musím si toho > všimnout. > > > Já přilehlé non-RUIAN budovy preventivně posouvám pryč z dosahu traceru, > pokud předem tuším problémy ;-) Ten modifikátor by se hodil. > > > OK. To by mělo být jednoduché. ;-) > > > Marián > > > > Martin > > > _______________________________________________ > Talk-cz mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-cz > _______________________________________________ Talk-cz mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-cz
