« zpět na výpis měsíce |

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

Vlákno 26.1. - 29.1.2016, počet zpráv: 9


26.1.2016 09:38:15 (#1)
gravatar

Marián Kyral

<mkyral at email.cz>
2270 2475
Ahoj, souhlasím, že nějakou názornou dokumentaci by to chtělo. Líbilo by se mi to stylem MapBox - povídání a animované gify [1]. Ale čas nějak není :-( Jakákoli iniciativa v tomto směru vítána. Podle mne stačí začít a pak už se to postupně doplní o speciální případy. Jinak doporučuji zkusit nejnovější verzi Traceru [2].  Udělal jsem teď o víkendu pár změn, hlavně co se týče možností přetrasovávání starých před- LPIS polí. Ty kousky jsou následek toho, že si Tracer všímal jen lpis objektů a ostatní ignoroval. Nově by se to už mělo chovat mnohem lépe a kousky by, v běžných případech, vznikat neměly. Zatím stále chybí (a hned tak asi nebude) přetrasovávání multipolygonů. 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. Aktualizace multipolygonu je trochu složitější, ale taky to jde. To natrasuji lpis polygon jako nezávislý objekt (CTRL + klik) a pak postupně nahradím jednotlivé outer a inner cesty pomocí příkazu "Nahradit geometrii" z utilsplugin2 [4]. Prázdnou relaci pak smažu. [1] https://github.com/mapbox/mapping/wiki/Mapping-with-OpenStreetMap [2] http://permalink.gmane.org/gmane.comp.gis.openstreetmap.region.cz/13259 [3] http://wiki.openstreetmap.org/wiki/JOSM/Plugins/ContourMerge [4] https://wiki.openstreetmap.org/wiki/JOSM/Plugins/utilsplugin2#Replace_ geometry_.28Ctrl.2BShift.2BG.29 Marián
---------- Původní zpráva ---------- Od: Pavel Bokr <osm at kraluvdvur.cz> Komu: talk-cz at openstreetmap.org Datum: 26. 1. 2016 0:35:21 Předmět: [Talk-cz] Tracer LPIS - drobne relikty puvodnich drive vymapovanych poli a luk po pretrasovani podle LPIS " Ahoj,   Predem se omlouvam pokud se ptam na neco co uz bylo receno, diskuze k trasovani LPIS je na me velmi obsahla a s odstupem casu uz dosti neprehledna.       V okoli meho mestecka (Kraluv Dvur) a nasledne i v sirsim okoli Berouna jsem od roku 2011 “rucne” mapoval mimo jine i landuse vcetne poli a luk (z pocatku podle UHULu, pozdeji snad byl nekde i Bing). Tohle jsem udelal na uzemi cca 20x20 km, ukazku jak asi vypadal vysledek v mape jsem si ulozil jen pro me mesto [1]. Jo kdyby tehdy byl tracer ... Veselý obličej   Pak prisel Tracer LPIS. Sam jsem s nim zkousel trasovat pole nekde na Rokycansku - tam kde tyto plochy zatim zmapovany nebyly a byly tam tedy “ bila mista” (to jeste tracer toho asi jeste neumel tolik co dnes). Do toho co uz jsem mel na Berounsku rucne zmapovane jsem se nepoustel ani jsem o tom radeji zatim neuvazoval.       Postupne si ale vsimam, ze k pretrasovani puvodnich rucne mapovanych ploch misty dochazi. Problem podle me vznika tam kde polygon dle LPIS je mensi nez puvodni a vznikne tak relikt – kolem velkeho pole jsou male prouzky pole, pripadne pokud se zmeni kultura (coz je klidne mozne, podle UHULu nebylo rozhodovani uplne jednoznacne) tak po okrajich louky jsou misty prouzky puvodniho pole. Screenshot z JOSM viz [2], odkaz na zivou mapu viz [3] – koukejte po okrajich pole a louky   Jeste nez se toto pripadne jeste vice rozsiri tak bych rad vznesl dotaz jestli je nejaky idealne snadno nalezitelny navod (nejlepe na wiki co by bylo snadno, rychle a bez sloziteho prohledavani pristupne uzivatelum LPIS traceru, kteri chteji zkusit pretrasovavat) jak tomuto predejit nebo jak nejlepe pracovat s LPIS tracerem v jiz zmapovane oblasti?         Vsiml jsem si ze se tracer stale vylepsuje (a diky moc za to!!!) a pak jde o to aby byl vhodne pouzivan s tim vsim co ted umi (ja osobne se priznam ze jsem zatim pretrasovani dle LPIS nezkousel). Pokud by se ale opakovane pretrasovavalo jako na uvedenych ukazkach, tak by nam vznikali v mape relikty a to asi neni dobre (i kdyz se to da treba vyrenderovat tak, aby to nebylo poznat tak IMHO neni uplne spravne to mit v datech). I vlastni LPIS je zivy system a zakresy (geometrie) v nem se postupne meni (sam jsem v nem take upravoval nase male louky).     Hlavne bych se zde nerad nekoho dotknul (sam mam nejspis na necem v OSM take maslo na hlave), akorat mi jde o to jestli lze rici a nejlepe nekam viditelne (treba na wiki) napsat, jak postupovat pripadne jake ficury pouzivat, aby se pokud mozno v mape neobjeovaly dalsi relikty luk/poli kolem vetsich luk/poli. Pripadne dodat jak to opravit tam, kde to uz je – ja osobne bych relikt louky/pole sloucil se sousednim objektem (napr. krovi nebo les) pokud byla louka/pole puvodne moc roszahla; pokud neni sousedni objekt pak bych relikt smazal a stejne tak v pripade ze je ve skutecnosti mezi loukou/polem a sousednim objektem (napr lesem) nejaka mezera – treba prikop, pripadne bych relikt zmenil na krovi/grassland apod., nebo bych relikt louky/pole sloucil k “velke”louce/”velkemu”poli pokud by byl puvodni zakres spravnejsi oproti LPIS (coz bude asi mene casto).       [1] http://osm.kraluvdvur.cz/2011-08-13-osm-kraluv-dvur.pdf (http://osm.kraluvdvur.cz/2011-08-13-osm-kraluv-dvur.pdf) [2] http://osm.kraluvdvur.cz/osm-tracer-lpis-relikty.png (http://osm.kraluvdvur.cz/osm-tracer-lpis-relikty.png) [3] https://www.openstreetmap.org/#map=17/49.96520/13.98907 (https://www.openstreetmap.org/#map=17/49.96520/13.98907) https://www.openstreetmap.org/#map=17/49.97227/13.97435 (https://www.openstreetmap.org/#map=17/49.97227/13.97435) https://www.openstreetmap.org/#map=18/49.95781/13.96725 (https://www.openstreetmap.org/#map=18/49.95781/13.96725)     Pokud uz se toto nekde popsalo a vyresilo tak fakt sorry pokud jsem to nenasel   Pavel Bokr     _______________________________________________ Talk-cz mailing list Talk-cz at openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz" ------------- další část --------------- HTML příloha byla odstraněna... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20160126/9ca584f1/attachment-0001.html> ------------- další část --------------- A non-text attachment was scrubbed... Name: wlEmoticon-smile[1].png Type: image/png Size: 1046 bytes Desc: [žádný popis není k dispozici] URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20160126/9ca584f1/attachment-0001.png>

26.1.2016 11:51:11 (#2)
gravatar

Petr Holub

<hopet at ics.muni.cz>
289 3608
Ahoj, zobrazit citaci
> 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

26.1.2016 04:20:38 (#3)
gravatar

Pavel Bokr

<osm at kraluvdvur.cz>
66 1559
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, zobrazit citaci
> 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 at openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz

26.1.2016 06:07:56 (#4)
gravatar

Marián Kyral

<mkyral at email.cz>
2270 2475
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 -------- Původní zpráva -------- Odesílatel: Pavel Bokr <osm at kraluvdvur.cz> Odesláno: 26. ledna 2016 16:20:38 SEČ Komu: OpenStreetMap Czech Republic <talk-cz at 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, zobrazit citaci
> 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 at openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz _______________________________________________ Talk-cz mailing list Talk-cz at 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. ------------- další část --------------- HTML příloha byla odstraněna... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20160126/f885ab44/attachment.html>

26.1.2016 08:38:12 (#5)
gravatar

Pavel Bokr

<osm at kraluvdvur.cz>
66 1559
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 6:07 PM To: OpenStreetMap Czech Republic ; Pavel Bokr 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 at kraluvdvur.cz> Odesláno: 26. ledna 2016 16:20:38 SEČ Komu: OpenStreetMap Czech Republic <talk-cz at 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 HolubSent: Tuesday, January 26, 2016 11:51 AMTo: 'OpenStreetMap Czech Republic'Subject: Re: [Talk-cz] Tracer LPIS - drobne relikty puvodnich drivevymapovanych poli a luk po pretrasovani podle LPISAhoj, 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, castose blbe hledaji ty koncove body, atd. Pokud by se ten les dal pretahnout tak, abyvsechna 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 dotahlke vsem dalsim polygonum, ktere se s nim dotykaji alespon ve dvou mistech. Tim byse resily takove ty zapomenute "zdibce", kterych si clovek kolikrat ani nevsimnea 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 listTalk-cz at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-cz --------------------------------------------------------------------------------Talk-cz mailing listTalk-cz at openstreetmap.orghttps://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. ------------- další část --------------- HTML příloha byla odstraněna... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20160126/d32d3b36/attachment.html> ------------- další část --------------- A non-text attachment was scrubbed... Name: wlEmoticon-smile[1].png Type: image/png Size: 1046 bytes Desc: [žádný popis není k dispozici] URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20160126/d32d3b36/attachment.png>

26.1.2016 08:52:43 (#6)
gravatar

Mirek Dlask

<dlask.m at gmail.com>
79
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20160126/6ac32b80/attachment-0001.html>

27.1.2016 12:42:48 (#7)
gravatar

Martin Švec - OSM

<osm at maatts.cz>
109
Dne 26.1.2016 v 23:09 Petr Holub napsal(a): zobrazit citaci
>> 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"
Na tohle téma jsme si psali tuším loni na jaře. IMHO tenhle postup je jednodušší, praktičtější a máme pro něj v Traceru spoustu kódu hotovou: (1) Vybrat rozlívaný objekt A, zapnout funkci rozlivu. (2) Editor přejde do režimu "freehand výběru". (3) Myší zhruba nakreslit "bramboru" B kam všude se má objekt A rozlít, s dostatečnými přesahy přes okolní objekty včetně objektu A. (4) Spočítat sjednocení polygonů A + B = polygon C. (5) Ořezat polygon C ořezovou funkcí která je v Traceru. (6) Vrátit se do bodu (2), nebo opustit funkci rozlivu přepnutím na jinou funkci JOSM. Tím zakreslením přibližné plochy B kam se má rozlívat odpadá problematická detekce "děr" a "průlivů do nekonečna". Není ani potřeba dotazovat se na každou díru, roztahování plochy se dá udělat na pár rychlých čmárnutí myší. Základní koncept je jednoduchý, ale cítím tam spoustu drobných zádrhelů, které se budou muset ošetřit a sežerou nejvíc času :-) Taky ta funkce nemůže být vyloženě univerzální -- musí existovat předdefinované sady tagů, které okolní polygony mají rozliv ořezávat a které se mají ignorovat. Sežeň si studenta který to odprogramuje, rád mu poradím, ale sám na to čas nemám. Hlavně na to ladění zádrhelů. Martin zobrazit citaci
> > Petr > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

27.1.2016 01:03:46 (#8)
gravatar

Martin Švec - OSM

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

29.1.2016 02:24:52 (#9)
gravatar

Pavel Bokr

<osm at kraluvdvur.cz>
66 1559
Ahoj, jeste jsem se vice koukal na ten LPIS a jeho trasovani u nas na Berounsku a mohu k tomu dodat i vizualizace konkretnich prikladu a pritom dale uvazuji jak asi nejlepe vyuzit LPIS, abych na Berounsku mapu pri aktualizaci pokud mozno vylespil a ne ji spise “pokazil” a co by se k tomu jeste hodilo (viz. nize – na konci). STAVAJICI STAV RUCNIHO MAPOVANI PRED LPISEM Kdyz se podivam na Berounsko tak zadne zjednoduseni pri rucnim mapovani se snad nedelalo, mozna si fandim, ale myslim ze mapovani je celkem podrobne dle podkladu ktere byly (jak uz jsem psal, co jsem delal ja tak jsem delal korekce posunu), jo skoda ze nejde trasovat dle ortofoto cuzk, to si myslim, ze by pak presnost byla srovnatelna s LPISem. Co je ve skutecnosti u sebe tak vetsinou sdili stejne hranicni body, tam kde byla mezi plochami cesta jsem ja treba nechaval mezeru. Neclenil jsem velka pole na mala po jednotlivych polickach, pokud k tomu nebyl duvod (rozdeleni mezi nebo odlisny typ landuse). Jak tady u nas vypadaji puvodni rucne mapovane plochy ve srovnani LPISem je videt na prikladech: http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis1.pdf http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis2.pdf http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis3.pdf http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis4.pdf Snad to neni tak hrozne, IMHO to neni zas tak spatne a proto resim, aby po dalsim pripadnem rozvoji pretrasovani nebyl stav OSM naopak horsi nez je toto. (kdyby ta rucni prace byla zjednodusena nebo odflaknuta bylo by to jednodusii ji “zahodit” a rovnou trasovat a neresit problemy). VYSLEDKY PRETRASOVANI PUVODNE RUCNE MAPOVYCH OBLASTI PODLE LPISU Nevim jestli vetsina dosavadnich trasovani nebyla na Berounsku vzhledem ke stavajicim datum spise k horsimu viz: Relikty: http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis-trasovani-relikty1.pdf http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis-trasovani-relikty2.pdf http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis-trasovani-relikty3.pdf http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis-trasovani-relikty4.png Prekryvy (na ne uz bylo upozorneno, me to ale uplne doslo az kdyz jsem videl tohle): http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis-trasovani-prekryvy1.pdf http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis-trasovani-prekryvy2.pdf http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis-trasovani-prekryvy3.png http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis-trasovani-prekryvy4.png Nevim jak bych byl potesen z takovych dat kdybych si je z OSM stahnul k nejakemu vyuziti nebo analyze.... Na druhou stranu trasovat se evidentne da i lepe – bez reliktu a bez prekryvu, kdyz se asi vi jak na to (je berounsku jeden takovy kousek kde jsou plochy z tohoto pohledu OK): http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis-trasovani-bez-reliktu-bez-prekryvu.png Nastesti vetsina ploch v okoli Berouna jeste takto pretrasovana neni http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis-netrasovano.png a snad prave proto jsem vyprovokoval tuto diskuzi a i sam o tom stale uvazuji, aby pak Berounsko nebylo plne podobnych ci jinych vad a jeste nez se za ucelem aktualizace pripadne pretrasuje dalsi cast tak, aby se resilo jak to pripadne delat/nedelat. Pokud by nekdo chtel videt tato data “dynamicky” tak nabizim ke stazeni projekt v QGISu z nehoz obrazky pochazi nebo alespon videozaznam z QGISu: http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis-qgis.zip https://www.youtube.com/watch?v=zlsXDcI_GSI (to ze vam v qgisu nebudou pri vetsim zvetseni zcela presne sedet hrany na sobe je mozna tim, ze jsem OSM data reprojektoval z WGS do JTSK tim co QGIS nabizi a je tam asi nejaka mala nepresnost) NE VSE CO JE V LPISU BYCHOM ASI CHTELI MIT V OSM Uz jsem zminoval ze se mi v LPISu neco nezda, ted k tomu spise skutecne ukazky: zbytecne diry mezi poli (ve skutecnosti neexistuji), zbytecne “artefatky” v geometriich (opet ve skutecnosti neexistuji), chybejici pole (tam treba davat pozor a dodelat rucne) apod: http://osm.kraluvdvur.cz/lpis-berounsko/lpis-diry1.png http://osm.kraluvdvur.cz/lpis-berounsko/lpis-diry2.jpg http://osm.kraluvdvur.cz/lpis-berounsko/lpis-artefakt1.png http://osm.kraluvdvur.cz/lpis-berounsko/lpis-artefakt2.png http://osm.kraluvdvur.cz/lpis-berounsko/lpis-strom-v-louce1.jpg http://osm.kraluvdvur.cz/lpis-berounsko/lpis-strom-v-louce2.jpg http://osm.kraluvdvur.cz/lpis-berounsko/lpis-nekde-chybi-cast-pole-jinde-pole-zahrnuje-i-mez-se-stouhou.jpg Tam kde se podrobne rucne nemapuje to jsou opravu detaily, mozna by se dalo rici i “kraviny”, ale tam kde jsem treba podrobne mapoval uvazuji jestli natrasovat tyto veci a jit pryc nepovede ke zhorseni OSM dat (vyrezane jednotlive stromy v louce kde trava rosta i pod nimi asi nejsou zavazne chyby, ale nevim jestli takovehle detaily v OSM chceme). Tyto priklady jsou jen z okoli nasi “vesnice”, kde to znam. JAK AKTUALIZOVAT RUCNE TVORENOU MAPU DLE LPIS A PRITOM JI NEZHORSIT? Ja osobne si puvodni rucni mapy landuse na Berounsku celkem vazim (mozna proto, ze jsem do toho dal dost casu a snazil jsem se byt podrobny a presny – nekdy snad i vic nez urednik co klika LPIS, akorat jsem mel horsi podklady). Jestli jsem az moc precitlively na svoji praci tak sorry... Soucasne jsem si zkusil i pretrasovani LPISu v tom co uz je rucne mapovano (tracer uz nedela relikty, ale smaze i cely zbytek pole, to se samozrejme dotrasuje ze sousednich LPIS ploch ovsem je nutne davat pozor, zda-li jsou v LPISu vsechny, nektere pole/louky nebo jejich casti tam chybi). 1) Jednodussi vidim situaci u jednotlivych poli/luk – ty bude vetsinou asi vyhodnejsi pretrasovat a rucne pak doupravit pripadne detaily, ci je zpresnit (uz jsem si zkusil). 2) U velkych (“multi”) poli/luk mi prijde lepsi zachovat v OSM “scelene” lany (ty kdy mezi nimi nejsou meze a jsou to lany stejneho typu). Do OSM se tak nedostanou neexistujici mezery ani geometricke “artefakty” (navic by zbytecne narostly data). Nebude ani treba resit jestli nahodou tam pak nechybi neco co v LPIS neni a pri pretrasovani by se mohlo ztratit (farmar “nejede” ve vecech co potrebuji LPIS). U tech “multi” poli/luk co byly podrobne rucne zmapovany bych velmi dulezitou roli videl v prvni rade kontrolu kultury – farmland/meadow/orchard apod., pripadne tag crop. To bude asi nejzasadnejsi chyba v rucnim mapovani (obzvlaste u toho co je ze stareho cernobileho uhulu). To bych v ramci multi poli/luk spise nez trasovanim resil rucnim delenim/spojovanim stavajicich ploch. Pak bych videl za potrebnou kontrolu a upravu prubehu vnejsi hranice (coz asi znamena opet rucni praci) – ze by se dle LPISu aktualizoval vnejsi obvod multi pole/louky – ale nejak rozumne, trochu plynule bez neodduvodnenych “odskoku”, ktere v LPISu byvaji. U multi poli/luk by tak byly spolecne plochy pro vice jednotlivych LPIS polygonu, tim by ale nebyly navazany na IDcka (ref) v LPISu (vadi/nevadi ???). Nebylo by to tedy rozsekabe dle LPISu, mozna bude nazornejsi animace: http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis-scelene-rozdelene-plochy.gif (samostatne obrazky jsou http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis-zachovane-celky-poli-a-luk.png a http://osm.kraluvdvur.cz/lpis-berounsko/osm-lpis-rozdelene-celky-poli-a-luk.png ) Je toto spravne nebo spatne (pro uzemi kde je podrobna rucni mapa a soucasne cas se o ni rucne starat lepe nez klikat z LPISu)??? Ja osobne bych asi toto ve svem okoli preferoval jako zpusob aktualizace stavajicich dat s vyuzitim LPIS, ale jsem zvedav na nazor a pripominky ostatnich. Uz jsem si to i zkusil na https://www.openstreetmap.org/relation/1659752 (mimochodem nektere inner prvky jsem resil trasovanim z LPISu a jejich vtelenim do teto relace, outer jsem upravil rucnim posunem bodu dle podkladu z WMS), pokud to neuznate jako pitomost muzu to zkusit i jinde... CO BY SE K TAKOVE RUCNI SPRAVE MOHLO HODIT? 1) Pokud by vyse uvedeny pristup nebyl spatny (treba tam, kde bych to chtel mit rozumne spravovane) tak by hoooodne pomohla nejaka podkladova mapa, ve ktere by byly barvou nebo srafou odliseny jednotlive “kultury”/”vyuziti” pudy pro kontrolu co je louka/pole/sad (pripadne pro kontrolu tagu crop) jestli je to tak i v OSM a nebo ne. Jak nekdo psal, ze trasovani v jiz zmapovanem neni jednoduche tak toto by pomohlo rozhodnout ze je na miste trasovat/rucne opravit chybu v typu landuse. Pokud uz je toto k dispozici tak budu rad za link. 2) Pro rucni upravu vnejsich hranic multi poli/luk by se asi hodilo i neco co by umelo pretrasovat hranici po jednotlivych bodech podobne jako funguje klavesa F co nasleduje jiz existujici linii v OSM nebo tomuto nejak pomohlo ze by treba vytvorilo cestu z lomovych bodu v LPISu az treba po misto kde se v LPISu hranice rozdvojuje a ta cesta by se nejakymi nastroji zakomponovala do plochy. Tohle uz ale ted trochu placam, zas tolik rucnich uprav jsem podle LPISu neudelal, abych mohl byt presny, jen v podstate delam pretrasovani vnejsi hranice ze linii v OSM pasuji na grafickou predlohu tech zelenych linii (uzitecna je k tomu funkce W – rezim zvysovani presnosti cest), akorat to proste delam rucne. Snad me za moje maily a moje stourani do trasovani LPISu jeste uplne neproklinate ... kdyz budu trochu v klidu spat ze se nebudou v datech v mem rozlezat chyby a vady tak dam pokoj :-) Pavel Bokr

« zpět na výpis měsíce