[Talk-cz] Odstávka LPIS

Pondělí Září 8 19:18:58 UTC 2014

Dne 8.9.2014 14:58, Marián Kyral napsal(a):
>
> ---------- Původní zpráva ----------
> Od: Martin Švec - OSM <osm na maatts.cz>
> Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org>,
> mkyral na 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é.  ;-)
>
>

Tak hotovo. Bohužel nový způsob distribuce aktualizací momentálně
nefunguje [1]. Tak tady je prozatímní odkaz:
http://osm.kyralovi.cz/bin/Tracer-testing.jar

Bacha: změnil jsem název na Tracer-testing. Doporučuji smazat starý
Tracer.jar v .josm/plugins adresáři. A pak je potřeba v konfiguraci
znova povolit plugin Tracer-testing. Doufám, že se problém brzo vyřeší a
pak se bude tracer aktualizovat sám, skrz oficiální kanál. A skončí
lovení aktuální verze pluginu v hloubi konference. Někteří si to
neužívají a mně se to taky moc nelíbí.

Marián

[1] http://permalink.gmane.org/gmane.comp.gis.openstreetmap.josm.devel/5934

> Marián
>
>
>
>     Martin
>
>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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