[Talk-cz] Tracer LPIS - drobne relikty puvodnich drivev ymapovanych poli a luk po pretrasovani podle LPIS

Martin Švec - OSM osm na maatts.cz
Středa Leden 27 12:03:46 UTC 2016


Ahoj,

(1) Přetrasovávání ručně nakreslených polí je dost velká piplačka, která vyžaduje pečlivost a zabere
mraky času. Vím o čem mluvím :-) Takže ji spíš nedoporučuju. Rozhodně se nesmí dělat stylem klikač
úderník. Obvykle stará data předem promažu, případně jak psal Marián natrasuju pole s Ctrl a sloučím
přes ContourMerge s původním, abych zachoval historii objektu a kredit původního autora pole.

Pozor, stará data jsou často zakreslena hodně kreativními způsoby, podle stylu práce autora. Našel
jsem i oblast, kde asi mapper trpěl fóbií z uzlů sdílených mezi více cestami. Takže místo aby každé
pole mělo jednu cestu kolem dokola a sdílelo uzly s okolím, hranice mezi poli rozsekal na spojité
segmenty a ty poslepoval do multipolygonů.

(2) Ty odřezky polí co zůstávají po ořezech bychom měli vyřešit :-( Netýká se to jen přetrasování
starých dat, ale i přetrasování LPIS polí které mezitím výrazně změnily geometrii. Algoritmy jsou
hotové, viz trasování budov. Akorát když jsem zahazování odřezků před rokem zkoušel použít v LPISu,
nepodařilo se mi najít vhodná kritéria co ještě zahodit a co prohlásit za regulérní plochu, byť
hodně malou. Pokud by se našel dobrovolník, který by si pohrál s testováním a laděním parametrů,
můžu mazání odřezků kdykoliv zapojit i v LPISu.

Martin

Dne 26.1.2016 v 20:38 Pavel Bokr napsal(a):
> OK,
>  
> ale prosim nedelat pri tom ty kousky – ja kdyz se koukam kolem sebe tak postizeno je vetsi uzemi
> nez jsem myslel, mame napriklad i utrzky poli kolem luk a naopak:
> https://www.openstreetmap.org/#map=18/49.98447/14.02426
> https://www.openstreetmap.org/#map=18/49.99286/13.99835
> https://www.openstreetmap.org/#map=18/49.99137/14.03235
> a ty relikty jsou na celkem velkem uzemi – postupne se to snad opravi, ale pokud mozno netvorit uz
> nove.
>  
> Ano z dnesniho pohledu jsem spatne urcil louku/pole a to by se melo aktualizovat, ale bez tech
> reliktu – to je snad IMHO lepe kdyby nebyla ta hranice uplne presna dle LPIS ale nebyly v mape ty
> relikty (k presnosti ja se snad vetsinu snazil trasovat podrobne a bez zjednoduseni; snazil jsem
> se i dle KM nastavovat posun podkladu).
>  
>  
>  
>  
> Samozrejme souhlasim, ze LPIS je obecne presnejsi – paradoxne zakresy do nej jsou mnohdy trasovany
> podle ortofota cuzk (o kterem se zde vedly diskuze jestli muzeme - nemuzeme). Takze to co urednik
> nebo farmar otrasuje dle ortofota cuzk do LPISu tak pak muzeme pouzivat v OSM Veselý obličej
>  
> Na druhou stranu ne vse z LPISu je vhodne prejimat za ucelem aktualizace, protoze tam jsou vedeny
> i plochy, ktere nejsou spravne (treba kde uz se stavi nove domy, nebo jsou spojeny pole, ktere
> jsou ve skutecnosti rozdelene mezi s cestou a prikopem a mam je rozdelene i v OSM – dokud to nekdo
> neotrasuje z LPISu) a treba louky se mohou v LPISu kreslit radeji mensi, aby pak nevznikl
> zemedelci problem, ze obhospodaruje mensi vymeru nez vyjde z LPISu (proto treba se v lukach
> vynechavaji “diry” i pro jednotlive stromy i kdyz trava roste i pod stromem a pro OSM by dle meho
> nazoru bylo vhodnejsi louku nechat a dat do ni strom jako bod ze proste uvnitr te louky roste
> strom, urednici ale sleduji v LPIS jine ucely nez sleduje OSM).
>  
>  
>  
>  
> Takze tam kde je mapovano rucne muze byt asi nejvhodnejsi nejaky kompromis, to co je OK prevzit z
> LPIS to co, ale neni vhodne z LPISu prebirat tak to do OSM “netahat”. Je to ale casove narocnejsi
> nez naklikat co LPIS nabizi. Otrasovanim vseho by se neco urcite zpresnilo a neco urcite
> znepresnilo – resp. zavedly by se do OSM i vetsi chyby nez jsou nepresnosti ve soucasne rucne
> vznikle mape. K tomu je ale treba osobni znalost nebo si konkrolovat spravnost a aktualnost LPIS
> podle ortofot.
>  
> Pri takovem kompromisnim mapovani (vzit si z LPISu jen to dobre) se ale ne vsechno co je v LPISu
> prenese do OSM a nebylo by dobre aby tam pak nekdo dodelal i ty chybejici prvky z LPISu co treba
> nekdo zamerne netrasoval, aby do OSM nevnesly vetsi nepresnosti. Nebo se muze stat ze se neceo
> pretrasuje z LPISu, pak se rucne upravi geometrie aby byla v OSM byla spravnejsi nez v LPISu, ale
> pokud nekdo za nejaky cas opet provede pretrasovani tak to rucni vylepseni OSM oproti LPISu zrusi.
>  
> Ve vysledku to vychazi tak, ze pretrasovani rucni mapy (pokud byla delana podrobne) to chce trochu
> vice peclivosti, aby to byla opravdu aktualizace pokud mozno jen k lepsimu. To je pak k reseni
> vice vez jen to jestli nahodou nezustavaji relikty nebo diry.
>  
>  
>  
> Kdyz na ten LPIS koukam tak treba u velkych celku slozenych z vice dilcich casti nevim jestli neni
> porad lepsi mit v OSM velke pole jako jeden rucne mapovany celek bez napojeni na LPISu, podle
> LPISu treba jen rucne upravit – zpresnit vnejsi hranici (tedy pokud pole neni fakticky preruseno a
> je to jeden celek – jedno dilci pole tesne sousedi s druhym a je to porad to same
> farmland/meadow). K teto uvaze me vede kdyz vidim, ze jsou primo i v LPISu mezi jednotlivymi
> castmi “velkeho pole” diry ci jine divne geometricke tvary nebo artefatky, ktere ale ve
> skutecnosti neexistuji a v OSM by byly jen “balastem” v datech. V LPISu se na nejakou topologii
> asi moc nehraje – prekryvy si asi hlidaji, ale diry ktere nenarokuje zadny farmar asi neresi. Nebo
> v tech velkych polich jsou casti, ktere nejsou v LPISu zrejme protoze farmar v nejede v tom co s
> LPISem souvisi. Z tohoto pohledu porad rucni mapovani vytvari cistsi data nez trasovani (teda
> samozrejme tam kde je rucne mapovano).
>  
>  
>  
> Pokud je aktualizace dle LPISu potreba jak pise Marian, tak se nechci hadat (i kdyz ja se teda
> snazil puvodne byt geometricky celkem presny; co je louka/pole to se ale urcovalo blbe), a jestli
> budu mit cas tak se tedy pokusim zkusit hrat i s pretrasovavanim rucni prace a treba nakonec ve
> svem okoli take neco sam pretrasuji - navic s vyuzitim mistni znalosti a pokusim se nenechavat
> relikty ani diry (tam kde diry z “topologickeho” pohledu nemaji byt tim ze sousedici prvky spolu i
> ve skutecnosti tesne sousedi a neni mezi nimi jiny prvek).
>  
>  
>  
> Mimochodem neni nekde mapovy podklad, ktery by byl barvene odlisen podle “kultury” v LPISu? Neco
> jako je barevne rozliseni ploch v RUIAN Lands? Pro spise rucni hrani si s daty a vybirani si z
> LPISu jen to lepsi by se hodilo mit vrstvu barevne rozbarvenou podle toho co to v LPISu je.
>  
>  
>  
> Pavel Bokr
>  
>  
> P.S. sorry za dlouhe maily
>  
>  
>  
>  
>  
>  
>  
>  
> *From:* Marián Kyral <mailto:mkyral na email.cz>
> *Sent:* Tuesday, January 26, 2016 6:07 PM
> *To:* OpenStreetMap Czech Republic <mailto:talk-cz na openstreetmap.org> ; Pavel Bokr
> <mailto:osm na kraluvdvur.cz>
> *Subject:* Re: [Talk-cz] Tracer LPIS - drobne relikty puvodnich drivevymapovanych poli a luk po
> pretrasovani podle LPIS
>  
> Ahoj.
> To je lákavá představa, ale pokud budou všichni jen čekat, tak se lepšího traceru nikdy nedočkají.
> Bez používání nebude motivace v něm cokoli vylepšovat.
>
> Já osobně taky přetrasovávám jen jako vedlejší produkt jiných úprav mapy.
>
> Já vím. Někdo si s tím dal práci, je to barevné a hezky to vypadá. ALE. Data jsou více či méně
> zastaralá a bylo to natrasováno dle starých UHUL ortofoto snímků nebo všelijak posunutých fotek
> Bingu. Aktualizace je potřeba. Nehledě na to, že jsou ty polygony různé zjednodušeny a mnohdy
> hodně nepřesné. To, že se doplní lpis údaje je až vedlejší produkt. Není to hlavní cíl.
>
> Marian
>
> ----------------------------------------------------------------------------------------------------
> *Odesílatel:* Pavel Bokr <osm na kraluvdvur.cz>
> *Odesláno:* 26. ledna 2016 16:20:38 SEČ
> *Komu:* OpenStreetMap Czech Republic <talk-cz na openstreetmap.org>
> *Předmět:* Re: [Talk-cz] Tracer LPIS - drobne relikty puvodnich drivevymapovanych poli a luk po
> pretrasovani podle LPIS
>
> Ahoj,
>
> a nebylo by rozumne se domluvit na tom, ze LPIS tracerem se zatim nebudou 
> resit drive rucne zmapovane plochy, pokud to nebude uplne nezbytne. Treba se 
> tracer jeste docka takovych vylepseni, ze treba poradi i s temito problemy 
> vcetne navaznosti na okoli - viz to co pise Petr Holub.
>
> Tedy domluvit se na tom jestli je vubec nyni vhodne trasovat v jiz 
> zmapovanem - jestli je smyslem mit co nejdrive vsechny pole/louky rozdelene 
> podle toho kdo jak kde hospodari obohacena o dalsi atributy (crop, meadow) a 
> navazana na ID v LPISu i za cenu komplikace s relikty, "dirkami" nebo jinymi 
> vecmi co to muze delat v jiz zmapovanem uzemi nebo jestli trasovani na jiz 
> zmapovanem uzemi (co uz nejsou "bila mista") zatim moc neprovadet a nechat 
> tam zatim "scelena" pole (tak jak jsou fyzicky v krajine ne jak kdo na jake 
> casti hospodari nebo jak tu ci onu cast louky posoudi urednik - na nasi 
> louce
> urednik napriklad "vyrezaval" nejake soliterni stromy) zatim bez 
> navazani na LPIS a cekat na pripadne budouci vylepseni nastroju.
>
>
> Kdo by presto citil potrebu neco co uz existuje podle LPIS pretrasovat tak 
> by mohl postupovat tak a tak, aby po pretrasovani z LPIS nezustaly v mape 
> relikty [sam ted nejsem schopen ted napsat jak postupovat protoze sam jsem 
> to ani nezkousel si s tim hrat, ale uz jste to tady psali; treba se k tomu 
> take nekdy sam dostanu, jak jsem psal zatim jsem do toho nechtel moc vrtat i 
> z obav (mozna zbytecnych), ze nekde by LPIS udelal horsi data nez rucni 
> mapovani].
>
> Pavel Bokr
>
>
>
> -----Původní zpráva----- 
> From: Petr Holub
> Sent: Tuesday, January 26, 2016 11:51 AM
> To: 'OpenStreetMap Czech Republic'
> Subject: Re: [Talk-cz] Tracer LPIS - drobne relikty puvodnich 
> drivevymapovanych poli a luk po pretrasovani podle LPIS
>
> Ahoj,
>
>     Co se mi osvědčilo nejlépe, je starý polygon zcela nahradit (nenechávat zbytky) a okolní
>     polygony "přilepit" pomocí ContourMerge pluginu [3] - ten je pro mne nepostradatelný. Stejně
>     tak se s ním krásně vyplňují díry pokud se tato skládá z více cest. 
>
>
> jeste by hodne pomohlo efektivite tohoto procesu, kdybychom umeli 
> "odecitani" polygonu:
> v podstate "jen" vyrazne zefektivneni toho procesu s ContourMerge. tam je 
> problem,
> ze kdyz dany les navazuje na nekolik poli (typicky takove ty "roznudlovane 
> pole"
> na Jizni Morave), tak clovek musi pres ContourMerge delat jeden po druhem, 
> casto
> se blbe hledaji ty koncove body, atd. Pokud by se ten les dal pretahnout 
> tak, aby
> vsechna ty pole prekryl a pak se jen ta pole odecetla, tak by to byla velka 
> pomoc.
>
> Jeste dalsi vylepseni by pak byl "rozliv" polygonu, ktery by ho automaticky 
> dotahl
> ke vsem dalsim polygonum, ktere se s nim dotykaji alespon ve dvou mistech. 
> Tim by
> se resily takove ty zapomenute "zdibce", kterych si clovek kolikrat ani 
> nevsimne
> a pak na ne ContourMerge neaplikuje.
>
> Ja na to bohuzel taky ted nemam cas, a to bohuzel ani na vedeni jako skolni 
> prace :(
> Kdyby si to nekdo vzal, bylo by to super...
>
> Petr
>
>
> ----------------------------------------------------------------------------------------------------
>
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz 
>
>
> ----------------------------------------------------------------------------------------------------
>
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> -- Odesláno z mého telefonu s Androidem pomocí pošty K-9 Mail. Omluvte prosím moji stručnost.
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz




Další informace o konferenci talk-cz