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 <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 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@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-cz
--------------------------------------------------------------------------------Talk-cz
mailing
listTalk-cz@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.
_______________________________________________
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
