<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Ahoj,<br>
<br>
Dne 8.9.2014 7:10, Marián Kyral napsal(a):<br>
</div>
<blockquote cite="mid:43R.ZFl7.7gYavDLARGh.1K3Jej@seznam.cz"
type="cite">Ahoj,<br>
díky ta intenzivní testování.<br>
<br>
<p>---------- Původní zpráva ----------<br>
Od: Martin Švec - OSM <a class="moz-txt-link-rfc2396E" href="mailto:osm@maatts.cz"><osm@maatts.cz></a><br>
Komu: OpenStreetMap Czech Republic
<a class="moz-txt-link-rfc2396E" href="mailto:talk-cz@openstreetmap.org"><talk-cz@openstreetmap.org></a>, Marián Kyral
<a class="moz-txt-link-rfc2396E" href="mailto:mkyral@email.cz"><mkyral@email.cz></a><br>
Datum: 8. 9. 2014 1:28:45<br>
Předmět: Re: [Talk-cz] Odstávka LPIS</p>
<br>
<blockquote>Ahoj,<br>
<br>
tak jsem potrápil nejnovější LPIS tracer, díky za pěknou práci
:-)) Pár postřehů:<br>
<br>
(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?<br>
</blockquote>
<p><br>
</p>
<p>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. <br>
</p>
</blockquote>
<br>
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í.<br>
<br>
<blockquote cite="mid:43R.ZFl7.7gYavDLARGh.1K3Jej@seznam.cz"
type="cite">
<blockquote><br>
(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.<br>
</blockquote>
<p>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í.<br>
</p>
<p>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? <br>
</p>
</blockquote>
<br>
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 :-)<br>
<br>
<blockquote cite="mid:43R.ZFl7.7gYavDLARGh.1K3Jej@seznam.cz"
type="cite">
<blockquote><br>
(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ě.<br>
</blockquote>
<p><br>
</p>
<p>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 ;-)<br>
</p>
</blockquote>
<br>
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...?<br>
<br>
<blockquote cite="mid:43R.ZFl7.7gYavDLARGh.1K3Jej@seznam.cz"
type="cite">
<blockquote>(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ří.</blockquote>
<p>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.<br>
</p>
</blockquote>
<br>
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.<br>
<br>
Martin<br>
<br>
</body>
</html>