[Talk-cz] Odstávka LPIS

Martin Švec - OSM osm na maatts.cz
Pondělí Září 8 12:24:30 UTC 2014


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í.

>
>     (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 :-)

>
>     (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...?

>     (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.

Martin

------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140908/4214b055/attachment.html>


Další informace o konferenci talk-cz