<html><body><br><p>---------- Původní zpráva ----------<br>Od: Martin Švec - OSM <osm@maatts.cz><br>Komu: OpenStreetMap Czech Republic <talk-cz@openstreetmap.org>, mkyral@email.cz<br>Datum: 8. 9. 2014 14:24:34<br>Předmět: Re: [Talk-cz] Odstávka LPIS</p><br><blockquote><div style="background-color: #FFFFFF; color: #000000">
<div>Ahoj,<br>
<br>
Dne 8.9.2014 7:10, Marián Kyral napsal(a):<br>
</div>
<blockquote>Ahoj,<br>
díky ta intenzivní testování.<br>
<br>
<p>---------- Původní zpráva ----------<br>
Od: Martin Švec - OSM <a href="mailto:osm@maatts.cz"><osm@maatts.cz></a><br>
Komu: OpenStreetMap Czech Republic
<a href="mailto:talk-cz@openstreetmap.org"><talk-cz@openstreetmap.org></a>, Marián Kyral
<a 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>
</div></blockquote><p><br></p><p>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í.</p><p><br></p><blockquote><div style="background-color: #FFFFFF; color: #000000"><br>
<blockquote>
<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>
</div></blockquote><p><br></p><p>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.<br></p><p><br></p><p> <br></p><blockquote><div style="background-color: #FFFFFF; color: #000000"><br>
<blockquote>
<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...?</div></blockquote><p><br></p><p>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.<br></p><p><br></p><p>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 ;-)</p><p><br></p><blockquote><div style="background-color: #FFFFFF; color: #000000"><br>
<br>
<blockquote>
<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>
</div></blockquote><p><br></p><p>OK. To by mělo být jednoduché. ;-)</p><p><br></p><p>Marián</p><p><br></p><blockquote><div style="background-color: #FFFFFF; color: #000000"><br>
Martin<br>
<br>
</div></blockquote></body></html>