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:mky...@email.cz> > *Sent:* Tuesday, January 26, 2016 6:07 PM > *To:* OpenStreetMap Czech Republic <mailto:talk-cz@openstreetmap.org> ; Pavel > Bokr > <mailto:o...@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 <o...@kraluvdvur.cz> > *Odesláno:* 26. ledna 2016 16:20:38 SEČ > *Komu:* OpenStreetMap Czech Republic <talk-cz@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz > > > ---------------------------------------------------------------------------------------------------- > > Talk-cz mailing list > Talk-cz@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz _______________________________________________ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
