[Talk-cz] Odstávka LPIS

Pondělí Září 8 14:27:33 UTC 2014

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 <mkyral na email.cz>:
>
> ---------- Původní zpráva ----------
> Od: Martin Švec - OSM <osm na maatts.cz>
> Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org>,
> mkyral na email.cz
> 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 <osm na maatts.cz>
> Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org>, Marián Kyral
> <mkyral na email.cz>
> 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
> Talk-cz na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>