[Talk-cz] Odstávka LPIS

Marián Kyral mkyral na email.cz
Pondělí Září 8 12:58:07 UTC 2014



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


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


Další informace o konferenci talk-cz