> 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. >> >> >> >> >> >> No podpora geometrických operací v Traceru, díky Martinovi, je. Jak moc složité by bylo >> upravit Contour Merge netuším.Ale asi to bude nad mé síly. >> >> >> >> >> Ale můžeš to simulovat tak, že si ten les nejprve vytáhneš do polí a až pak pole přetrasuješ. > Jo, ale problem je s existujicimi poli - smazat vsechno, roztahnout les > a pak pretrasovat (ale zase by tim clovek stoupal ve statistikach > zmen ;o))) ). Pokud bychom to meli i jako samostatnou funkcionalitu > na existujicich objektech, tak by to bylo super - mozna by to nemuselo > byt tolik prace, kdyz uz to vlastne v Traceru mas. > >> 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. >> >> >> >> >> Který polygon by se dotáhnul kam? > To by chtelo rozmalovat a presneji dorozmyslet jednotlive pripady, ale > zhruba takto (nerucim za spravny desing, uz mam ponekud unavenou hlavu): > stav 1: vyberu rozlivany objekt (uzavrena cesta) - editor prejde do stavu 2 > stav 2: editor postupne proiteruje vsechny diry, ktere jsou tvorene: > a) plochami (uzavrenymi cestami) ktere se rozlevaneho objektu dotykaji > ve dvou bodech, ale mezi temito dvema body existuje po neblizsich > cestach (nikoli nutne nejkratsi ve smyslu poctu bodu, ale nejkratsi > ve smyslu delky segmentu - to by melo fungovat, musi se ale zkontrolovat, > ze plocha sama sebe nekrizi) nesdileny bod na jedne nebo druhe ceste > b) na sebe navazujicim plochami (navazujici = sdili aspon 1 bod), z nichz > krajni plochy sdili s rozlivanym objektem alespon jeden bod - a opet > po nejkratsich cestach je tam 1 nebo vice nesdilenych bodu > stav 3: proiteruje vsechny diry a nabidne je k zaceleni uzivateli (zobrazi > diru a zepta se "zacelit - ano/ne"

> > Petr > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

> 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