Re: [Talk-cz] Administrativni hranice z RUIAN
jzvc wrote: > Vidim problem v tom, ze takhle vyrobis cosi jako totalne oddelenou > vrstvu, sniz kdokoli cokoli spoji, tak ty mu to smaznes. Ale vždyť už jsem několikrát psal, že jako nejlepší řešení vidím, že se podle logu na těch pár spojených starých objektů podívám ručně, a pokud to bude vhodné, tak je spojím zpět. Můžeš napsat konkrétně, co se ti na tomhle postupu nezamlouvá? Tohle podle mě fakt jinak než ručně (člověkem) rozhodnout nejde, pokud máš opačný názor, popiš prosím rozhodovací algoritmus (stačí slovně), který by tento problém spolehlivěe automaticky řešil. Zdraví, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Administrativni hranice z RUIAN
Dne 30.8.2012 17:56, "Petr Morávek [Xificurk]" napsal(a): > jzvc wrote: >> Aktualni stav hranic je, ze jsou dost nepresne (+- metry az desitky >> metru). Par useku sem zpresnil jak se dalo (dle KM) a je na nich note >> "nesahat, presne ..." (prevazne okres teplice). Predpokladam, ze pokud >> je bod hranice do rekneme tech 10m od bodu v RUIAN, a "sirokodaleko" >> neni zadnej jinej, lze jej prohlasit za "ten bod" a posunout jej do nove >> pozice. Na useky mezi takto detekovanymi body bych pak asi doplnil >> chybejici z RUIAN. Vyhoda je, ze nebudu nic delat s vlastni way = zadny >> aktualizace relaci ... > Nahradit v relaci jednu cestu za novou není žádný problém. > Naopak provést poctivě analýzu, jakou navrhuješ je řádově složitější > problém (a taky mnohem náchylnější na chyby). > >> Pokud takovy (posunovany) body jsou soucasti neceho dalsiho (budova, >> plot, ) je to stejne asi na nejaky polomanuelni proces. Samo, >> vytvorit novou hranici a starou odstranit by bylo jednoduchy, ale jak >> bylo receno, ztraci se informace, ktera muze a nemusi odpovidat >> stavajicimu stavu (plot, vodni tok, ...) >> >> Asi bych navrhnul zjistit: >> 1) pocet hranic, ktere jsou vedeny jako ciste samostatne objekty (= >> nikde nesdili zadny usek ani body s nicim jinym). U tech bude >> aktualizace asi celkem bezproblemova. >> 2) pocty hranic se soubeznyma cestama - mozna rozpadnout na ruzne typy >> (voda/silnice/...) >> >> A podle toho kolik z toho vypadne bych resil co s tim dal. Podle me bude >> drtiva vetsina hranic vzhledem k predchozimu importu nenapojena nikam a >> tech problematickych useku by nemuselo byt mnoho. > Bez obalu řeknu, že se mi příliš do téhle analýzy nechce... nějaký jiný > dobrovolník? Ale už nějakou dobu se snažím udržovat hranice v > konzistentním stavu, takže mám trochu přehled - objekty napojené na > hranice jsou spíše výjimkou. > > Obecně mi není moc jasné, jaký problém se snažíš vyřešit - že se při > aktualizaci ztratí informace o napojení? Rozhodnout, jestli napojení > stále platí nebo ne, stejně musí člověk. Třeba tak, že se podle logu > aktualizace podívám ručně na danou oblast. Plně automaticky to > rozhodnout fakt nejde. Nevidím žádný přínos v zesložiťování nastíněného > algoritmu aktualizace. Vidim problem v tom, ze takhle vyrobis cosi jako totalne oddelenou vrstvu, sniz kdokoli cokoli spoji, tak ty mu to smaznes. => muzem vytvorit to co tu bylo zmineno, bitmapu z RUIAN, prohlasit "tohle sou hranice" a neni co resit. A bylo by zahodno nejen zpresnit stavajici stav, ale umoznit i potencielni aktualizace do budoucnosti. Ze je to slozitejsi - no to je. BTW: Zrovna nedavno sem opravoval hranice s polskem aspon co se lv tejce (a pak sem opravil i statni hranice polakum a doplnil kus hranice na slovensku), protoze to bylo totalne rozjebly ... at zije zmena licence ... a to slovaci pokud vim ty hranice taky z neceho importovali ... > > Zdraví, > Petr Morávek aka Xificurk > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Administrativni hranice z RUIAN
jzvc wrote: > Aktualni stav hranic je, ze jsou dost nepresne (+- metry az desitky > metru). Par useku sem zpresnil jak se dalo (dle KM) a je na nich note > "nesahat, presne ..." (prevazne okres teplice). Predpokladam, ze pokud > je bod hranice do rekneme tech 10m od bodu v RUIAN, a "sirokodaleko" > neni zadnej jinej, lze jej prohlasit za "ten bod" a posunout jej do nove > pozice. Na useky mezi takto detekovanymi body bych pak asi doplnil > chybejici z RUIAN. Vyhoda je, ze nebudu nic delat s vlastni way = zadny > aktualizace relaci ... Nahradit v relaci jednu cestu za novou není žádný problém. Naopak provést poctivě analýzu, jakou navrhuješ je řádově složitější problém (a taky mnohem náchylnější na chyby). > Pokud takovy (posunovany) body jsou soucasti neceho dalsiho (budova, > plot, ) je to stejne asi na nejaky polomanuelni proces. Samo, > vytvorit novou hranici a starou odstranit by bylo jednoduchy, ale jak > bylo receno, ztraci se informace, ktera muze a nemusi odpovidat > stavajicimu stavu (plot, vodni tok, ...) > > Asi bych navrhnul zjistit: > 1) pocet hranic, ktere jsou vedeny jako ciste samostatne objekty (= > nikde nesdili zadny usek ani body s nicim jinym). U tech bude > aktualizace asi celkem bezproblemova. > 2) pocty hranic se soubeznyma cestama - mozna rozpadnout na ruzne typy > (voda/silnice/...) > > A podle toho kolik z toho vypadne bych resil co s tim dal. Podle me bude > drtiva vetsina hranic vzhledem k predchozimu importu nenapojena nikam a > tech problematickych useku by nemuselo byt mnoho. Bez obalu řeknu, že se mi příliš do téhle analýzy nechce... nějaký jiný dobrovolník? Ale už nějakou dobu se snažím udržovat hranice v konzistentním stavu, takže mám trochu přehled - objekty napojené na hranice jsou spíše výjimkou. Obecně mi není moc jasné, jaký problém se snažíš vyřešit - že se při aktualizaci ztratí informace o napojení? Rozhodnout, jestli napojení stále platí nebo ne, stejně musí člověk. Třeba tak, že se podle logu aktualizace podívám ručně na danou oblast. Plně automaticky to rozhodnout fakt nejde. Nevidím žádný přínos v zesložiťování nastíněného algoritmu aktualizace. Zdraví, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Administrativni hranice z RUIAN
Dne 29.8.2012 10:33, "Petr Morávek [Xificurk]" napsal(a): > Jakub wrote: >> V tomto souhlasím s LM, že pokud spojení dat je přidaná hodnota a tam >> kde to tak je by se neměly cesty mazat, ale upravovat. Hranice rozhodně >> autonomní entity nejsou, mohou přece mimo fyzických věcí koincidovat i s >> jinými "abstraktními" geoinformacemi - jako hranice psč nebo něco >> takového a pokud z nějaké vyhlášky koincidují tak je obrovská přidaná >> hodnota, že budou v OSM koincidovat. Navíc i koincidence s objekty jako >> ploty, zdi, přírodní útvary a podobně je také přidaná hodnota, často i >> pro upřesnění polohy těchto objektů. > S tím upravováním starých cest to není tak jednoduché. Není úplně > jednoduché analyzovat, jaké části hranice se jak změnily, a rozhodnout, > jestli se hranice posunula někam jinam, nebo jde jen o nepřesnost určení > polohy té staré. > Obecně asi takových případů příliš nebude. Upravil jsem skript podle > připomínky Lukáše, aby nemazal cesty/nody s jinými tagy, tento konflikt > mi hlásí v logu. Přijde mi jednodušší se po aktualizaci na dané místo > podívat ručně a případně daný objekt znovu sloučit s hranicí. Aktualni stav hranic je, ze jsou dost nepresne (+- metry az desitky metru). Par useku sem zpresnil jak se dalo (dle KM) a je na nich note "nesahat, presne ..." (prevazne okres teplice). Predpokladam, ze pokud je bod hranice do rekneme tech 10m od bodu v RUIAN, a "sirokodaleko" neni zadnej jinej, lze jej prohlasit za "ten bod" a posunout jej do nove pozice. Na useky mezi takto detekovanymi body bych pak asi doplnil chybejici z RUIAN. Vyhoda je, ze nebudu nic delat s vlastni way = zadny aktualizace relaci ... Pokud takovy (posunovany) body jsou soucasti neceho dalsiho (budova, plot, ) je to stejne asi na nejaky polomanuelni proces. Samo, vytvorit novou hranici a starou odstranit by bylo jednoduchy, ale jak bylo receno, ztraci se informace, ktera muze a nemusi odpovidat stavajicimu stavu (plot, vodni tok, ...) Asi bych navrhnul zjistit: 1) pocet hranic, ktere jsou vedeny jako ciste samostatne objekty (= nikde nesdili zadny usek ani body s nicim jinym). U tech bude aktualizace asi celkem bezproblemova. 2) pocty hranic se soubeznyma cestama - mozna rozpadnout na ruzne typy (voda/silnice/...) A podle toho kolik z toho vypadne bych resil co s tim dal. Podle me bude drtiva vetsina hranic vzhledem k predchozimu importu nenapojena nikam a tech problematickych useku by nemuselo byt mnoho. > >> Mimochodem jak je to tedy s tou >> definicí hranic jak se ptal LM? Jsou vždy definované body, nebo jsou >> někde oficiálně navázány na nějaké fyzické objekty. > Pokud vím, tak máme celou republiku rozparcelovanou, polygony parcel > jsou na příslušných katastrálních úřadech (resp. v různých registrech > jako třeba RUIAN), parcely se skládají do katastrálních území, > katastrální území do obcí... > Jediný "problém" může být státní hranice. > > Zdraví, > Petr Morávek aka Xificurk > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Administrativni hranice z RUIAN
Dne 30.8.2012 12:31, Mike napsal(a): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Vesměs s tebou souhlasím, ale píšu to z toho důvodu, že za rok dojde k > aktualizaci dat v CUZK, budou se zase aktualizovat data v OSM a > najednou se zjistí, že ten plot opravdu nevede po hranici, že barák > opravdu je rozdělen, přestože před tím nebyl a zase se bude řešit, co > s tím. Vždyť je to pořád dokola. Současná data jsou také import, který > měl být přesný, ale není, prostě věci se mění. Nehledě na to, že si > někdo nevšimne, že potok je součástí relace hranice, rozdělí ho, kus > tam vloží a už nepřidá do relace a hned je hranice rozbitá, což zase > rozbije vyhledávače a různé jiné programy, než si toho někdo/něco > všimne. Podle mne administrativní a fyzické objekty se nemají mixovat > dohromady z těchto důvodů, přestože to zní lákavě. Mas i nemas pravdu ... na spouste mistech je ta hranice urcena prave trebas tou zdi domu, nikoli naopak ... a to ze by se administrativni hranice posunula do domu je velmi, ale opravdu velmi nepravdepodobne ... spis sem videl spoustu mist, kde pekne klickuje po jednotlivych domech, tak, aby vzdy cely dum byl soucasti jednoho ku. A jelikoz mam sousedku, co dela na katastru, a mimo jine dlouhodobe resi prave ruzny slucovani parcel ... tak vim ze na spouste mist posunovaly hranice prave kvuli tomu, aby dum nebyl na dvou ku. Mozna by nebylo od veci pred pripadnym updatem, zkusit zjistit kolik % hranic vede soubezne s necim jinym (rozdelil bych to jeste na dva pripady - soubezna way/priblizne (+-10m rekneme)). A kdyz uz sem pisu, ad statni hranice - rozhodne mame presnejsi nez sousedi, na par mistech sem ruco zpresnoval (samo je to mravenci prace a vopruz), zpresnena hranice pak vizuelne kopirovala spravne ... (orthofoto ), takze bych se nebal je updatnout taktez. Rozhodne pak nezjednodusovat, cim presnejsi tim lepsi, navic zjednodusovani by vedlo k tomu, ze si tu hranici ja nebo nekdo dalsi nekde posune tak aby byla presne = zbytecne vygenerovana zmena, ktera povede k problematicke aktualizaci. > > On 30.8.2012 12:12, "Petr Morávek [Xificurk]" wrote: >> Mike wrote: >>> Jenže ono to tak často je, že dům stojí na dvou katastrálních >>> územích. >> Jenže o tomhle případu jsem já vůbec nepsal. ;-) >> >> Zopakuji, co jsem napsal už dříve: JESTLIŽE vede hranice přesně se >> zdí domu, tak by zjednodušení mohlo způsobit, že najednou bude roh >> domu na jedné straně a zbytek na druhé straně hranice. A přidám: >> JESTLIŽE vede hranice skrz dům, tak by zjednodušení mohlo způsobit, >> že najednou bude celý dům jen na jedné straně hranice. >> >> To samé platí o tvé připomínce k plotu z druhého mailu: JESTLIŽE >> plot vede po hranici, tak je spojení obou objektů naprosto v >> pořádku a dává dodatečnou informaci. JESTLIŽE vede plot vedle >> hranice, tak je spojení samozřejmě špatně. >> >> Opravdu si myslím, že když už ta přesná data máme, tak bysme je >> neměli zbytečně "znehodnocovat". >> >> >> Ad zjednodušení geometrií: Dělal jsem ještě nějaké testy na datech >> RUIANu a zdá se, že pokud provedu zjednodušení (Douglas-Peucker) s >> přesností na 1cm (což je taky zhruba přesnost s jakou jsou data v >> OSM uložena), tak počet nodů jde dolu o zhruba 17%. To je myslím >> celkem slušná redukce bez výrazné ztráty informace. Jen pro >> úplnost: přesnost 0.1m dává redukci 22%, 1m potom 39%. >> >> Zdraví, Petr Morávek >> >> ___ Talk-cz mailing >> list Talk-cz@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.17 (MingW32) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlA/QQIACgkQkWJlWekVrbI9IgCfSACRG2ShFMSEkVhGEyGjTPUh > M74AoIg88D0r98cG9IuxWube36ls0FtW > =T8UI > -END PGP SIGNATURE- > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Administrativni hranice z RUIAN
V tom případě je to bez problému. U hranic s odchylkou přes metr bych nečekal ani spojení s plotem, hranicí lesa apod. LM Dne 30. srpna 2012 16:20 "Petr Morávek [Xificurk]" napsal(a): > LM_1 wrote: >> Co se týče zjednodušení tak přesnost 1cm by určitě neměla být problém >> (akorát se tím posunou některé body a některé zmizí, což by mohlo >> působit problémy při aktualizaci - po změně jednoho uzlu v >> nezjednodušených datech by mohl algoritmus dojít k celkové změně, >> která by ovlivnila mnohem větší oblast. > > Kandidáty na aktualizaci vybírám podle toho, jestli se OSM hranice a > RUIAN hranice liší o více než x metrů. V první fázi jsem to pouštěl pro > x=100, abych podchytil ty největší excesy. > Do budoucna bych chtěl postupně opravit i hranice s menší chybou až do > řádově několika metrů. Taková vzdálenost celkem spolehlivě zaručuje, že > "zaokrouhlovací" chyba, kterou zmiňuješ, aktualizaci nespustí. A zrovna > tak ji nespustí drobné posunutí pár bodů uživatelem. > > Zdraví, > Petr Morávek aka Xificurk > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Administrativni hranice z RUIAN
LM_1 wrote: > Co se týče zjednodušení tak přesnost 1cm by určitě neměla být problém > (akorát se tím posunou některé body a některé zmizí, což by mohlo > působit problémy při aktualizaci - po změně jednoho uzlu v > nezjednodušených datech by mohl algoritmus dojít k celkové změně, > která by ovlivnila mnohem větší oblast. Kandidáty na aktualizaci vybírám podle toho, jestli se OSM hranice a RUIAN hranice liší o více než x metrů. V první fázi jsem to pouštěl pro x=100, abych podchytil ty největší excesy. Do budoucna bych chtěl postupně opravit i hranice s menší chybou až do řádově několika metrů. Taková vzdálenost celkem spolehlivě zaručuje, že "zaokrouhlovací" chyba, kterou zmiňuješ, aktualizaci nespustí. A zrovna tak ji nespustí drobné posunutí pár bodů uživatelem. Zdraví, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Administrativni hranice z RUIAN
JOSM i Potlatch přidají do relace obě výsledné cesty po rozdělění. Tam by problém být neměl. Hranice (nebo jiné objekty) se v OSM mění když se změní v realitě nebo když jsou zpřesněny. Druhá varianta je u hranic (tam kde jsou obnovené katastrální mapy) celkem nepravděpodobná a první variantu řeší dobře přístup změny jen tagů a relacích patřících ke hranici. Dost dobře si nedovedu představit jak by měla vypadat přesná mapa s nezávislými hranicemi - různé body přes sebe? náhodná odchylka aby přes sebe nebyly? sdílené jen body (už nejsou nezávislé)? Co se týče zjednodušení tak přesnost 1cm by určitě neměla být problém (akorát se tím posunou některé body a některé zmizí, což by mohlo působit problémy při aktualizaci - po změně jednoho uzlu v nezjednodušených datech by mohl algoritmus dojít k celkové změně, která by ovlivnila mnohem větší oblast. Lukáš Matějka (LM_1) Dne 30. srpna 2012 13:39 "Petr Morávek [Xificurk]" napsal(a): > Mike wrote: >> Vesměs s tebou souhlasím, ale píšu to z toho důvodu, že za rok dojde k >> aktualizaci dat v CUZK, budou se zase aktualizovat data v OSM a >> najednou se zjistí, že ten plot opravdu nevede po hranici, že barák >> opravdu je rozdělen, přestože před tím nebyl a zase se bude řešit, co >> s tím. Vždyť je to pořád dokola. Současná data jsou také import, který >> měl být přesný, ale není, prostě věci se mění. > > Zas tak černě bych to neviděl. Starý import probíhal z řádově méně > přesných data. Teď máme konečně k dispozici rozumně přesný (a udržovaný) > zdroj dat ve vhodném formátu. > Hájím přístup, že pokud se zjistí (větší) změna hranice, tak se prostě > hranice nahraje znova a staré cesty/body se ponechají jen pokud nesou > nějakou jinou informaci. > Takhle, když někdo spojí plot s hranicí (protože tam prostě ta hranice > vede), tak ten plot zůstane spojený tak dlouho, dokud se průběh hranice > výrazně nezmění... a až se změní, tak se prostě ta hranice posune na > nové místo a plot zůstane. Žádné řešení stejného problému pořád dokola. > >> Nehledě na to, že si >> někdo nevšimne, že potok je součástí relace hranice, rozdělí ho, kus >> tam vloží a už nepřidá do relace a hned je hranice rozbitá, což zase >> rozbije vyhledávače a různé jiné programy, než si toho někdo/něco >> všimne. > > Tuhle připomínku už jsem párkrát slyšel a můj názor je, že tohle by měl > řešit editor! Asi jsem rozmazlený z Merkaartoru, kde při rozdělení > cesty, která je součástí nějaké relace, se automaticky do dané relace > přidá i nově vytvořený úsek. Jestliže tohle nějaký editor neumí, tak by > to asi chtělo dát vědět autorům, že taková funkce chybí. > > A zrovna u těch administrativních hranic, můžu s celkem slušnou jistotou > říct, že si takových chyb všimnu ;-) > > Zdraví, > Petr Morávek aka Xificurk > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Administrativni hranice z RUIAN
Mike wrote: > Vesměs s tebou souhlasím, ale píšu to z toho důvodu, že za rok dojde k > aktualizaci dat v CUZK, budou se zase aktualizovat data v OSM a > najednou se zjistí, že ten plot opravdu nevede po hranici, že barák > opravdu je rozdělen, přestože před tím nebyl a zase se bude řešit, co > s tím. Vždyť je to pořád dokola. Současná data jsou také import, který > měl být přesný, ale není, prostě věci se mění. Zas tak černě bych to neviděl. Starý import probíhal z řádově méně přesných data. Teď máme konečně k dispozici rozumně přesný (a udržovaný) zdroj dat ve vhodném formátu. Hájím přístup, že pokud se zjistí (větší) změna hranice, tak se prostě hranice nahraje znova a staré cesty/body se ponechají jen pokud nesou nějakou jinou informaci. Takhle, když někdo spojí plot s hranicí (protože tam prostě ta hranice vede), tak ten plot zůstane spojený tak dlouho, dokud se průběh hranice výrazně nezmění... a až se změní, tak se prostě ta hranice posune na nové místo a plot zůstane. Žádné řešení stejného problému pořád dokola. > Nehledě na to, že si > někdo nevšimne, že potok je součástí relace hranice, rozdělí ho, kus > tam vloží a už nepřidá do relace a hned je hranice rozbitá, což zase > rozbije vyhledávače a různé jiné programy, než si toho někdo/něco > všimne. Tuhle připomínku už jsem párkrát slyšel a můj názor je, že tohle by měl řešit editor! Asi jsem rozmazlený z Merkaartoru, kde při rozdělení cesty, která je součástí nějaké relace, se automaticky do dané relace přidá i nově vytvořený úsek. Jestliže tohle nějaký editor neumí, tak by to asi chtělo dát vědět autorům, že taková funkce chybí. A zrovna u těch administrativních hranic, můžu s celkem slušnou jistotou říct, že si takových chyb všimnu ;-) Zdraví, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vrcholy kopců
Nevidím důvod proč by nemohla, je to úřední dílo, které má svou vyhlášku 31/1995 Sb. Bohužel hromadné na 50 bodů výstupy nejsou bezúplatné. MK > Nicmene by bylo dobre, kdyby nekdo se znalosti formalnich procesu > v GISech dal vedet, zda se ta bodova pole smi pouzivat jako zdroj > dat ci nikoli. > > Diky, > Petr > > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Administrativni hranice z RUIAN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vesměs s tebou souhlasím, ale píšu to z toho důvodu, že za rok dojde k aktualizaci dat v CUZK, budou se zase aktualizovat data v OSM a najednou se zjistí, že ten plot opravdu nevede po hranici, že barák opravdu je rozdělen, přestože před tím nebyl a zase se bude řešit, co s tím. Vždyť je to pořád dokola. Současná data jsou také import, který měl být přesný, ale není, prostě věci se mění. Nehledě na to, že si někdo nevšimne, že potok je součástí relace hranice, rozdělí ho, kus tam vloží a už nepřidá do relace a hned je hranice rozbitá, což zase rozbije vyhledávače a různé jiné programy, než si toho někdo/něco všimne. Podle mne administrativní a fyzické objekty se nemají mixovat dohromady z těchto důvodů, přestože to zní lákavě. On 30.8.2012 12:12, "Petr Morávek [Xificurk]" wrote: > Mike wrote: >> Jenže ono to tak často je, že dům stojí na dvou katastrálních >> územích. > > Jenže o tomhle případu jsem já vůbec nepsal. ;-) > > Zopakuji, co jsem napsal už dříve: JESTLIŽE vede hranice přesně se > zdí domu, tak by zjednodušení mohlo způsobit, že najednou bude roh > domu na jedné straně a zbytek na druhé straně hranice. A přidám: > JESTLIŽE vede hranice skrz dům, tak by zjednodušení mohlo způsobit, > že najednou bude celý dům jen na jedné straně hranice. > > To samé platí o tvé připomínce k plotu z druhého mailu: JESTLIŽE > plot vede po hranici, tak je spojení obou objektů naprosto v > pořádku a dává dodatečnou informaci. JESTLIŽE vede plot vedle > hranice, tak je spojení samozřejmě špatně. > > Opravdu si myslím, že když už ta přesná data máme, tak bysme je > neměli zbytečně "znehodnocovat". > > > Ad zjednodušení geometrií: Dělal jsem ještě nějaké testy na datech > RUIANu a zdá se, že pokud provedu zjednodušení (Douglas-Peucker) s > přesností na 1cm (což je taky zhruba přesnost s jakou jsou data v > OSM uložena), tak počet nodů jde dolu o zhruba 17%. To je myslím > celkem slušná redukce bez výrazné ztráty informace. Jen pro > úplnost: přesnost 0.1m dává redukci 22%, 1m potom 39%. > > Zdraví, Petr Morávek > > ___ Talk-cz mailing > list Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA/QQIACgkQkWJlWekVrbI9IgCfSACRG2ShFMSEkVhGEyGjTPUh M74AoIg88D0r98cG9IuxWube36ls0FtW =T8UI -END PGP SIGNATURE- ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Administrativni hranice z RUIAN
Doufám, že to pak po jednoduchém simplify nevypadá jako na třetím obrázku... :-) http://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology MK - Original Message - From: "Petr Morávek [Xificurk]" [mailto:p...@pada.cz] To: OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org] Sent: Thu, 30 Aug 2012 12:12:14 +0200 Subject: Re: [Talk-cz] Administrativni hranice z RUIAN > Mike wrote: > Jenže ono to tak často je, že dům stojí na dvou > katastrálních územích. Jenže o tomhle případu jsem já vůbec > nepsal. ;-) Zopakuji, co jsem napsal už dříve: JESTLIŽE vede hranice > přesně se zdí domu, tak by zjednodušení mohlo způsobit, že najednou > bude roh domu na jedné straně a zbytek na druhé straně hranice. A > přidám: JESTLIŽE vede hranice skrz dům, tak by zjednodušení mohlo > způsobit, že najednou bude celý dům jen na jedné straně hranice. To > samé platí o tvé připomínce k plotu z druhého mailu: JESTLIŽE plot > vede po hranici, tak je spojení obou objektů naprosto v pořádku a dává > dodatečnou informaci. JESTLIŽE vede plot vedle hranice, tak je spojení > samozřejmě špatně. Opravdu si myslím, že když už ta přesná data > máme, tak bysme je neměli zbytečně "znehodnocovat". Ad zjednodušení > geometrií: Dělal jsem ještě nějaké testy na datech RUIANu a zdá se, > že pokud provedu zjednodušení (Douglas-Peucker) s přesností na 1cm > (což je taky zhruba přesnost s jakou jsou data v OSM uložena), tak počet > nodů jde dolu o zhruba 17%. To je myslím celkem slušná redukce bez > výrazné ztráty informace. Jen pro úplnost: přesnost 0.1m dává redukci > 22%, 1m potom 39%. Zdraví, Petr > Morávek ___ Talk-cz mailing > list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Administrativni hranice z RUIAN
Mike wrote: > Jenže ono to tak často je, že dům stojí na dvou katastrálních územích. Jenže o tomhle případu jsem já vůbec nepsal. ;-) Zopakuji, co jsem napsal už dříve: JESTLIŽE vede hranice přesně se zdí domu, tak by zjednodušení mohlo způsobit, že najednou bude roh domu na jedné straně a zbytek na druhé straně hranice. A přidám: JESTLIŽE vede hranice skrz dům, tak by zjednodušení mohlo způsobit, že najednou bude celý dům jen na jedné straně hranice. To samé platí o tvé připomínce k plotu z druhého mailu: JESTLIŽE plot vede po hranici, tak je spojení obou objektů naprosto v pořádku a dává dodatečnou informaci. JESTLIŽE vede plot vedle hranice, tak je spojení samozřejmě špatně. Opravdu si myslím, že když už ta přesná data máme, tak bysme je neměli zbytečně "znehodnocovat". Ad zjednodušení geometrií: Dělal jsem ještě nějaké testy na datech RUIANu a zdá se, že pokud provedu zjednodušení (Douglas-Peucker) s přesností na 1cm (což je taky zhruba přesnost s jakou jsou data v OSM uložena), tak počet nodů jde dolu o zhruba 17%. To je myslím celkem slušná redukce bez výrazné ztráty informace. Jen pro úplnost: přesnost 0.1m dává redukci 22%, 1m potom 39%. Zdraví, Petr Morávek ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vrcholy kopců
No já to dělám podle STRM nebo jak se to jmenuje, což je licenčně v pořádku. Ale vždy ještě s místní znalostí, takže žádné hromadné vkládání. On 30.8.2012 11:25, Petr Holub wrote: >> Většinou to dělám podle vrstevnic + dle znalosti terénu případně >> koriguji. Není to zrovna naprosto přesný, ale pro účely mapy to stačí. >> >> >> On 25.8.2012 14:57, Jan Kučera wrote: >>> Dají se opisovat z nějakého volného zdroje, nebo musí člověk mapovat v >>> terénu s GPSkou? > > Nicmene by bylo dobre, kdyby nekdo se znalosti formalnich procesu > v GISech dal vedet, zda se ta bodova pole smi pouzivat jako zdroj > dat ci nikoli. > > Diky, > Petr > > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vrcholy kopců
> Většinou to dělám podle vrstevnic + dle znalosti terénu případně > koriguji. Není to zrovna naprosto přesný, ale pro účely mapy to stačí. > > > On 25.8.2012 14:57, Jan Kučera wrote: > > Dají se opisovat z nějakého volného zdroje, nebo musí člověk mapovat v > > terénu s GPSkou? Nicmene by bylo dobre, kdyby nekdo se znalosti formalnich procesu v GISech dal vedet, zda se ta bodova pole smi pouzivat jako zdroj dat ci nikoli. Diky, Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vrcholy kopců
Většinou to dělám podle vrstevnic + dle znalosti terénu případně koriguji. Není to zrovna naprosto přesný, ale pro účely mapy to stačí. On 25.8.2012 14:57, Jan Kučera wrote: > Dají se opisovat z nějakého volného zdroje, nebo musí člověk mapovat v > terénu s GPSkou? > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] rúian - struktura dat adresních bodů
Také mám stejný názor, to že Nominatim nehledá podřetězec, ale celý řetězec, je jeho chyba a měla by se opravit. On 29.8.2012 2:32, Jakub Sykora wrote: > >> Při příležitosti importu bych rád znovu otevřel debatu o stuktuře >> addr:housenumber. Osobně jsem odpůrce uvádění obou čísel (678/1) v tomto > > osobne jsem naopak priznivcem. OSM je prakticky jedina mapa, ktera mi > umoznuje vizualne vyhledat dum, at uz znam cislo jakekoliv vc. evidencniho. > >> tagu. Jako daleko vhodnější mi přijde do housenumber dát číslo >> orientační, protože to je číslo, které je přímo z jeho definice určeno k >> orientaci při dohledávání domu (a číslo evidenční pokud orientační číslo >> není přiděleno). Jelikož je dvojité číslování ve světě relativně méně >> časté a jelikož se nedá očekávat, že by renderery studovaly adresní >> systémy jednotlivých zemí je realita taková, že renderery očekávají v >> housenuber to co mají zobrazit na mapě (pokud je dostatečný zoom), takže >> volbou použití použití obou čísel zároveň určujeme, že v rendererech se >> budou zobrazovat obě čísla mapa bude vypadat takto: > > ano, renderery renderuji zpravidla housenumber. A jsem pro to, aby tam > zustala cela informace. I informace, ze se jedna o ev.c je skvela a > mnoho map ji nerozlisuje. Pritom na vesnicich se stane, ze jsou budovy > se stejnym popisnym a evidencnim cislem. > >> >> Vím, že se nemá tagovat pro renderer, ale domnívám se, že toto není ten >> případ. Protože informace jsou již v adresním bodu uvedeny jako údaje >> addr:streetnumber a addr:conscriptionnumber, takže housenumber už >> informci duplikuje a víceméně reálně určuje to co je považováno za >> "hlavní" informaci zobrazenou v rendererech.Přitom ve všech mapách co >> znám jsou u ulic v městech (tedy v případech kdy jsou přidělena obě >> čísla) zobrazena jen čísla orentační a v řadě případů jen čísla >> orientační v rozích bloků (ale to už je jiné téma). Myslím si, že tento > > to je nejvetsi ptakovina, na kterou jsem kdy narazil - cisla na rozich > jsou sice hezka graficky, ale kdyz je kilometr dlouha rada domu, tak > stejne nevim, kde mnou hledany dum je. > >> fakt má svůj lety prověřený smysl a troufám si tvrdit, že odborníci na >> grafiku map by k tomu měli spoustu odborných argumentů toto >> podporujících. > > krome toho, ze je toho v mape mene a je mozna prehlednejsi me moc > argumentu nenapada (aniz bych se pasoval na odbornika v grafice) > >> >> Poslední podpůrný detail k tomuto názoru jsou vyhledávače a navigace. >> Zkoušel jsem jich několik a bohužel řada z nich prostě nezvládne údaje v >> housenumber rozdělit na dvě čísla podle lomítka (je to prostě světově >> hodně nestandardní). Takže adresu prostě nevyhledá ani posle >> orientačního ani podle evidenčního čísla, ale jen pomocí obou dvou >> zadaných s lomítkem ve správném pořadí a to je podle mě to nejméně častí >> co uživatel použije / má k dipozici. Pro ilustraci: >> http://maps.cloudmade.com/ => Search the map => Vyplňte "1","Na >> Slovance","Praha" do polí (House #,Street Name,City) a nenajdete nic. > > OSM Nominatim najde 1803, na slovance, praha vcelku bez problemu. > Nenajde ale 1, na slovance, praha. Vyresi tvuj navrh toto? > >> Možná že víte evidenční číslo (nebo si ho najdete na googlemaps ;-) ) >> tak můžete zadat "1803","Na Slovance","Praha" ani to nic nenajde. >> Jedině "1803/1","Na Slovance","Praha" najde daný dům. Kdyby housnumber >> obsahovalo orientační číslo, najde dům hned při prvním (a dle mne >> nejčastějším) požadavku. > > Nevim, u me jsou pozadavky na popisne a orientacni cislo tak 50/50. > Nekteri lide ani netusi, ktere je ktere, kdyz mi adresu diktuji. > Typickym prikladem budiz treba Udolni 18/53, Praha. Tam by clovek cekal > 18 jako orientacni a 53 jako popisne a je to presne naopak. V Udolni > > Cloudmate je platforma která poskytuje api >> stovkám dalších aplikací, takže to nelze brát na lehkou váhu. A to není >> jediný příklad. >> >> Vím že v minulosti ke shodě nedošlo, ale když už se chystá velký import >> adresních bodů mám za to, že by bylo dobré to ho dělat tak aby výsledek >> byl co nejlepší. >> >> Jakub >> >> >> >> ___ >> Talk-cz mailing list >> Talk-cz@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Administrativni hranice z RUIAN
On 28.8.2012 10:10, LM_1 wrote: > Dne 28. srpna 2012 7:24 hanoj napsal(a): >>> Geometrii bych určitě nezjednodušoval, to je celkem >>> zbytečná nepřesnost. >> *** uplne bych se tomu nebranil, presna hranice ma smysl pokud pracuji >> s katastralni mapou (aby 1 parcela nebyla ve 2 k.u.). Chyba 1 metr je >> v nasich potrebach dostacujici. > To bych netvrdil. Tam, kde jsou přesné katastrální mapy je přesnost > mnohem vyšší než v metrech a očekával bych, že se bude spíš zvyšovat. > >> >>> Staré uzly a cesty bych mazal jen pokud nemají >>> kromě hranice žádný jiný tag. S těmi co mají bych možná vůbec nehýbal >>> automaticky (hranice vedoucí středem řeky apod.) >> *** to doufam nemaji, hranice byly vytvoreny jako balik autonomnich >> entit tj. nezavisly na fyzickych prvcich mapy. A pokud se tak v >> editacich useru stalo, mela by se data opet stat autonomni. > > S tím nesouhlasím. Úplně nezávislou vrstvu dat by si ostatně mohl > každý použít přímo ze zdroje. To, že se data spojí - hranice vedoucí > plotem nebo zdí domu - je přidaná hodnota. Navíc je tím zajištěno > zarovnání. > Žádný balík autonomních entit nemá v osm moc co dělat, jak se jednou > importuje tak splývá s ostatními daty. > Něco jako Co jednou peklo schvátí, to už nikdy nenavrátí. :) > S tím zase nesouhlasím já. Je naprosto běžné, skoro pravidlem, že plot se postavil podle starého zaměření, podle nového je ale o metr vedle, než vede hranice. Další příklad - u nás se teď má přesouvat potok o cca 3 metry, takže posunu potok a co ta hranice? Tu přece nemůžu posunout... ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Administrativni hranice z RUIAN
Jenže ono to tak často je, že dům stojí na dvou katastrálních územích. Raději bych to nezačleňoval do jiných prvků, ať se s tím dá v budoucnu lépe manipulovat. On 28.8.2012 9:06, "Petr Morávek [Xificurk]" wrote: > hanoj wrote: >>> Geometrii bych určitě nezjednodušoval, to je celkem >>> zbytečná nepřesnost. >> *** uplne bych se tomu nebranil, presna hranice ma smysl pokud pracuji >> s katastralni mapou (aby 1 parcela nebyla ve 2 k.u.). Chyba 1 metr je >> v nasich potrebach dostacujici. > > Já si zas říkám, že ty nody se dají případně zrecyklovat i na další věci > (vzhledem k tomu, že vedou po hranicích parcel). Jestliže vede hranice > přesně se zdí domu, tak by zjednodušení mohlo způsobit, že najednou bude > roh domu na jedné straně zbytek na druhé straně hranice. > V podstatě jediný důvod pro zjednodušení je redukce většího množství > nodů... což mi nepřijde jako příliš silný argument. > >>> Staré uzly a cesty bych mazal jen pokud nemají >>> kromě hranice žádný jiný tag. S těmi co mají bych možná vůbec nehýbal >>> automaticky (hranice vedoucí středem řeky apod.) >> *** to doufam nemaji, hranice byly vytvoreny jako balik autonomnich >> entit tj. nezavisly na fyzickych prvcich mapy. A pokud se tak v >> editacich useru stalo, mela by se data opet stat autonomni. > > Občas bohužel mají... už jsem na to v minulosti při opravách narazil. > > Zdraví, > Petr Morávek aka Xificurk > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Administrativni hranice z RUIAN
Co jsem tak vysledoval, tak to máme přesněji než třeba Němci, kteří to importovali z nějakého soukromého mapového zdroje, ne moc přčsného. Ale stejně - onehdá jsem hejbnul kouskem hranice, protože byla očividně mimo a to bylo křiku... Tak hodně štěstí. Mike On 28.8.2012 16:40, "Petr Morávek [Xificurk]" wrote: > Petr Kadlec wrote: >> 2012/8/27 LM_1 : >>> To je otázka, která mě už delší zajímá, ale zatím jsem nenašel >>> uspokojivou odpověď - Kde jsou definované hranice (od katastrálního >>> území po státní)? Je opravdu hranice dána definičně řadou souřadnic >>> nebo spíš popsána pomocí fyzických objektů (řeka, hřeben, silnice, >>> hraniční kámen...) a ty souřadnice jsou jen odvozeným vyjádřením pro >>> praktické účely? >> >> U státní hranice může být pravda obojí, záleží, jak je přesně hranice >> definována v příslušných mezinárodních smlouvách, resp. hraničním >> dokumentárním díle: může to být jak pomocí lomových bodů (potažmo >> hraničních znaků), tak hraničním vodním tokem, hraniční cestou atp. >> (viz zákon č. 312/2001 Sb.). Některé části hranice jsou tak >> nepohyblivé, některé se mohou pohybovat např. přirozenou změnou polohy >> koryta hraničního vodního toku (viz např. 246/1997 Sb.). > > Státní hranice je trochu spešl případ, proto na ni také radši nechci moc > šahat. Na mnoha místech příliš nesedí s tím, co je v RUIAN. Třeba > německá a rakouská hranice se zdá, že je importovaná z nějakého jejich > zdroje, takže by časem bylo dorbé zjistit, jestli je přesnější jejich > nebo náš RUIAN (jestli to vůbec lze rozhodnout vzhledem k charakteru > definice státních hranic). > Ale uvnitř státu máme snad vše rozparcelováno a definováno relativně > přesně pomocí polygonů, tak jak to je v RUIAN, tj. nezávisle na tom kudy > zrovna vede cesta nebo teče potok. > > Zdraví, > Petr Morávek aka Xificurk > > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Evropsky významné lokality
Má někdo tip, jak ja mapovat? Problém je, že se někde překrývají se současnými ZCHÚ (ty jsou většinou jejich podmnožinou)... napadá mě mapovat je jako boundary=national_park, tedy bez výplně typu leisure=nature_reserve... ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
