Re: [Talk-cz] Tracer LPIS - drobne relikty puvodnich drivev ymapovanych poli a luk po pretrasovani podle LPIS
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 >
Re: [Talk-cz] Tracer LPIS - drobne relikty puvodnich drivev ymapovanych poli a luk po pretrasovani podle LPIS
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 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 Sent: Tuesday, January 26, 2016
Re: [Talk-cz] Tracer LPIS - drobne relikty puvodnich drivev ymapovanych poli a luk po pretrasovani podle LPIS
Ahoj, při pohledu na některé moravské vinice tě chápu. http://www.openstreetmap.org/#map=16/48.8652/16.9001 Navíc - ruční aktualizace natrasovaných území může být někde problém - nevím k čemu jsou ref, která se i po drobné změně polygonu mění - problémem jsou i překrývající se plochy https://www.openstreetmap.org/way/334303196#map=17/48.86319/16.90110 Přesto bych nikoho neomezoval. Mirek ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
