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