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

2016-01-26 Tema obsahu Petr Holub
>   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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


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

2016-01-26 Tema obsahu Mirek Dlask
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


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

2016-01-26 Tema obsahu Pavel Bokr
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

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

2016-01-26 Tema obsahu Marián Kyral


-- Původní zpráva --
Od: Petr Holub 
Komu: 'OpenStreetMap Czech Republic' 
Datum: 26. 1. 2016 11:52:13
Předmět: Re: [Talk-cz] Tracer LPIS - drobne relikty puvodnich drive 
vymapovanych 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.
"



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š. 


 
"
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?



"

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...
"



+1

Marián



"
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


Re: [Talk-cz] Tracer LPIS - drobne relikty puvodnich drivevymapovanych poli a luk po pretrasovani podle LPIS

2016-01-26 Tema obsahu Marián Kyral
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 
Odesláno: 26. ledna 2016 16:20:38 SEČ
Komu: OpenStreetMap Czech Republic 
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


Re: [Talk-cz] Hospoda Brno 2016.01

2016-01-26 Tema obsahu Tom Ka
Dne 24. ledna 2016 20:18 Tom Ka  napsal(a):
> Ahoj, uz jsme se zase delsi dobu nevideli v Brne. Jak jste na tom?
> http://doodle.com/poll/iwb2u65p9yhkqamp

Ucast nic extra, zkusil jsem tedy dat nejake terminy na dalsi tyden a
tento si kazdej dejte skopek povinne doma ;-)

Prosim o doplneni/aktualizaci hlasovani, adresa zustava.

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [Talk-cz] Tracer LPIS - drobne relikty puvodnich drivevymapovanych poli a luk po pretrasovani podle LPIS

2016-01-26 Tema obsahu Pavel Bokr

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


Re: [Talk-cz] Podivna relace budovy

2016-01-26 Tema obsahu Marián Kyral
Ahoj,
opraveno.

Nejprve jsem budovu vyjmul z relace, pak jsem přenesl tagy (v JOSM bez 
problémů - označit tagy, pak kopírovat a vložit), smazal již zbytečnou 
relaci a ten podivný kousek a na závěr natrasoval tvar z RUIAN.

Marián


-- Původní zpráva --
Od: Ondrej Steiner 
Komu: talk-cz@openstreetmap.org
Datum: 26. 1. 2016 13:12:45
Předmět: [Talk-cz] Podivna relace budovy

"Ahoj,

Narazil jsem na podivnou relaci budovy, ktera je podle vseho nespravna
a vznikla asi omylem pouzitim automatizovanych nastroju:

http://www.openstreetmap.org/relation/3639269

Bohuzel jsem zjistil, ze nevim jak prenest tagy z relace na uzavrenou cestu.
Muzete se na to podivat a pripadne opravit?

Diky.

Ondra

___
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


[Talk-cz] Podivna relace budovy

2016-01-26 Tema obsahu Ondrej Steiner
Ahoj,

Narazil jsem na podivnou relaci budovy, ktera je podle vseho nespravna
a vznikla asi omylem pouzitim automatizovanych nastroju:

http://www.openstreetmap.org/relation/3639269

Bohuzel jsem zjistil, ze nevim jak prenest tagy z relace na uzavrenou cestu.
Muzete se na to podivat a pripadne opravit?

Diky.

Ondra

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


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

2016-01-26 Tema obsahu Petr Holub
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


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

2016-01-26 Tema obsahu Marián Kyral
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 
Komu: talk-cz@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/2