> ahoj, > > pr(idal jsem do map na http://maps.fordfrog.com/ ješte( mapy z osm a z > katastru a taky overlay vrstvu adresních bodu* z rúian, takže lze napr(. v > mape( porovnávat polohu adresních bodu* oproti osm. opravil jsem taky > funkcionalitu permalinku, takže už by me(l fungovat. > > mapy ted( jsou (a ješte( chvíli budou) pomalejší, protože tam importuju > osm planet data a znovu (opravené) multipointy do databáze rúian. > > ff

> > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> ahoj, > > přidal jsem do map na http://maps.fordfrog.com/ ještě mapy z osm a z > katastru a taky overlay vrstvu adresních bodů z rúian, takže lze např. v > mapě porovnávat polohu adresních bodů oproti osm. opravil jsem taky > funkcionalitu permalinku, takže už by měl fungovat. > > mapy teď jsou (a ještě chvíli budou) pomalejší, protože tam importuju > osm planet data a znovu (opravené) multipointy do databáze rúian. > > ff >

> Cus, > > nemel by nahodou katastr vychazet ze stejnych dat? Ja ze v RUIAN sou > nejaky adresni body navrch (ony tam baraky fakt sou), a nektery sou > ruzne lehce posunuty ...

> > BTW: Chtelo by to trebas nejak barevne rozlisit cislo popisny/evidencni.

> Vypadá to velmi pěkně, jen dotaz - v RUIAN jsou jen čísla popisná, > nebo i orientační? Adresu v terénu většinou hledám podle orientačního > a to uvedeno i na většině map ...

> Jakub

> Dne 24.7.2012 15:22, jzvc napsal(a): >> Cus, >> >> nemel by nahodou katastr vychazet ze stejnych dat? Ja ze v RUIAN sou >> nejaky adresni body navrch (ony tam baraky fakt sou), a nektery sou >> ruzne lehce posunuty ... > > no, rúian vychází z katastru, jenže jednak v osm to nemusí být nutne( > úplne( aktuální, a pak taky ten import adresních bodu* asi me(l své > mouchy, tr(eba du*m, kde ted( bydlím, má c(íslo už asi tak 50 let, ale > v osm není :-)

> >> >> BTW: Chtelo by to trebas nejak barevne rozlisit cislo popisny/evidencni. > > provedeno. c(ervená = c(p, modrá = ev, žlutá = bez c(ísla, olivová = > všechny ostatní ... platí do té doby, než to náhodou v rámci zme(ny > nálady zme(ním :-P

> > ff > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Dne 24.7.2012 20:43, Miroslav Šulc napsal(a): >> Dne 24.7.2012 15:22, jzvc napsal(a): >>> Cus, >>> >>> nemel by nahodou katastr vychazet ze stejnych dat? Ja ze v RUIAN sou >>> nejaky adresni body navrch (ony tam baraky fakt sou), a nektery sou >>> ruzne lehce posunuty ... >> >> no, rúian vychází z katastru, jenže jednak v osm to nemusí být nutne( >> úplne( aktuální, a pak taky ten import adresních bodu* asi me(l své >> mouchy, tr(eba du*m, kde ted( bydlím, má c(íslo už asi tak 50 let, >> ale v osm není :-) > > OSM neresim, porovnaval sem ten overlay (predpokladam z RUIAN) a KM - > rozdily byly prave tam.

> Dne 24.7.2012 21:23, jzvc napsal(a): > > Dne 24.7.2012 20:43, Miroslav Šulc napsal(a): > > Dne 24.7.2012 15:22, jzvc napsal(a): > > Cus, > > nemel by nahodou katastr vychazet ze stejnych dat? Ja ze v RUIAN sou > nejaky adresni body navrch (ony tam baraky fakt sou), a nektery sou ruzne > lehce posunuty ... > > > no, rúian vychází z katastru, jenže jednak v osm to nemusí být nutně úplně > aktuální, a pak taky ten import adresních bodů asi měl své mouchy, třeba > dům, kde teď bydlím, má číslo už asi tak 50 let, ale v osm není :-) > > > OSM neresim, porovnaval sem ten overlay (predpokladam z RUIAN) a KM - > rozdily byly prave tam. > > > aha, tak to netuším. já si určitě nové adresní body v db nevymyslel, takže > se asi přecejen ty katastrální mapy s rúian rozcházejí. možná to souvisí se > způsobem aktualizace map, nevím, třeba něco vyčteš tady: > http://www.cuzk.cz/Dokument.aspx?AKCE=DOC:10-WMS_PRO_KM > > ff > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >

> dají se nějak data z RUIAN dostat po jednotlivých katastrech do JOSM a > následně po kontrole např vůči Bingu poslat do OSM

> Pražák

> ------------ Původní zpráva ------------ > Od: Miroslav Šulc <fordfrog na fordfrog.com> > Předmět: Re: [Talk-cz] rúian mapy - vylepšení > Datum: 25.7.2012 19:10:59 > ---------------------------------------- > Dne 25.7.2012 18:58, Zdeněk Pražák napsal(a): > > dají se nějak data z RUIAN dostat po jednotlivých katastrech do JOSM a > > následně po kontrole např vůči Bingu poslat do OSM > > jaká data konkrétně? adresní body? budovy? nebo nějaká jiná? samozřejmě > "není problém" vyexportovat data z databáze s určitým filtrem (obec, > extent apod) do osm formátu, ale pokud už data jsou i v osm, tak by se > musely duplicity odstranit. a to moc netuším jak. > > a pak je tu ještě druhá věc. pokud bychom něco takového dělali, tak by > to podle mě chtělo jednak udržovat přehled, co už je naimportováno a co > ne, a za druhé by bylo fajn zachovat nějakou referenční vazbu na > originální data (rúian), abychom případně v budoucnu mohli data v rúian > a v osm porovnávat (co je nového apod). > > a pak je tu ještě třetí věc, a to posoudit, na čem má smysl trávit svůj > čas a co automatizovat (a čas využít na něco lepšího). > > > Pražák > > ff > > >

> no já zatím pomocí pluginu tracer kreslím v katastrálních územích s digitální mapou budovy, tak jsem si myslel jestli bych nemohl využít uvedených dat > >> ------------ Původní zpráva ------------ >> Od: Miroslav Šulc <fordfrog na fordfrog.com> >> Předmět: Re: [Talk-cz] rúian mapy - vylepšení >> Datum: 25.7.2012 19:10:59 >> ---------------------------------------- >> Dne 25.7.2012 18:58, Zdeněk Pražák napsal(a): >>> dají se nějak data z RUIAN dostat po jednotlivých katastrech do JOSM a >>> následně po kontrole např vůči Bingu poslat do OSM >> jaká data konkrétně? adresní body? budovy? nebo nějaká jiná? samozřejmě >> "není problém" vyexportovat data z databáze s určitým filtrem (obec, >> extent apod) do osm formátu, ale pokud už data jsou i v osm, tak by se >> musely duplicity odstranit. a to moc netuším jak. >> >> a pak je tu ještě druhá věc. pokud bychom něco takového dělali, tak by >> to podle mě chtělo jednak udržovat přehled, co už je naimportováno a co >> ne, a za druhé by bylo fajn zachovat nějakou referenční vazbu na >> originální data (rúian), abychom případně v budoucnu mohli data v rúian >> a v osm porovnávat (co je nového apod). >> >> a pak je tu ještě třetí věc, a to posoudit, na čem má smysl trávit svůj >> čas a co automatizovat (a čas využít na něco lepšího). >> >>> Pražák >> ff >> >> >> > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> no, tak to by rozhodně mělo ušetřit čas, protože jestli se nepletu, tak > když je budova v digitální mapě kú, tak bude i v rúian a dala by se snad > jednoduše naimportovat. podle mě by to ale chtělo udělat nějak > systematicky. samozřejmě můžu udělat nějakou webovou stránku, odkud si > kdokoliv bude moct stáhnout osm soubor s budovama pro daný výběr (třeba > ten katastr) a nechat tomu volný průběh, ale pokud bychom tomu dali > nějaký řád, tak by to asi bylo lepší. > > máte někdo nějaké návrhy? > > ff > > Dne 25.7.2012 19:28, Zdeněk Pražák napsal(a): > > no já zatím pomocí pluginu tracer kreslím v katastrálních územích s > digitální mapou budovy, tak jsem si myslel jestli bych nemohl využít > uvedených dat > > > >> ------------ Původní zpráva ------------ > >> Od: Miroslav Šulc <fordfrog na fordfrog.com> > >> Předmět: Re: [Talk-cz] rúian mapy - vylepšení > >> Datum: 25.7.2012 19:10:59 > >> ---------------------------------------- > >> Dne 25.7.2012 18:58, Zdeněk Pražák napsal(a): > >>> dají se nějak data z RUIAN dostat po jednotlivých katastrech do JOSM a > >>> následně po kontrole např vůči Bingu poslat do OSM > >> jaká data konkrétně? adresní body? budovy? nebo nějaká jiná? samozřejmě > >> "není problém" vyexportovat data z databáze s určitým filtrem (obec, > >> extent apod) do osm formátu, ale pokud už data jsou i v osm, tak by se > >> musely duplicity odstranit. a to moc netuším jak. > >> > >> a pak je tu ještě druhá věc. pokud bychom něco takového dělali, tak by > >> to podle mě chtělo jednak udržovat přehled, co už je naimportováno a co > >> ne, a za druhé by bylo fajn zachovat nějakou referenční vazbu na > >> originální data (rúian), abychom případně v budoucnu mohli data v rúian > >> a v osm porovnávat (co je nového apod). > >> > >> a pak je tu ještě třetí věc, a to posoudit, na čem má smysl trávit svůj > >> čas a co automatizovat (a čas využít na něco lepšího). > >> > >>> Pražák > >> ff > >> > >> > >> > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz na openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >

> ahoj, > > pr(idal jsem do map na http://maps.fordfrog.com/ ješte( mapy z osm a z > katastru a taky overlay vrstvu adresních bodu* z rúian, takže lze napr(. v > mape( porovnávat polohu adresních bodu* oproti osm. opravil jsem taky > funkcionalitu permalinku, takže už by me(l fungovat. > > mapy ted( jsou (a ješte( chvíli budou) pomalejší, protože tam importuju > osm planet data a znovu (opravené) multipointy do databáze rúian. > > ff > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> no kdyby se pr(ipravily stránky se zdrojovými údaji pro budovy pro > jednotlivá katastrální území, pak by bylo možné vytvor(it stránky na > wiki s odkazy na stažení jednotlivých souboru*. zájemce by si stáhl > data pro požadované katastrální území, provedl kontrolu napr( vu*c(i > bingu (odstranil ru*zné chyby - napr(íklad neexistující budovy, budovy > s jiným tvarem, doplnil by budovy ve skutec(nosti existující a > neobsažené v datech RUIAN) a poté opravená data odeslal na OSM. > V tabulce na wiki by zaznamenal provedení exportu a pr(ípadné problémy > Pražák > > Dne 25. c(ervence 2012 19:34 Miroslav Šulc <fordfrog na fordfrog.com > <mailto:fordfrog na fordfrog.com>> napsal(a): > > no, tak to by rozhodne( me(lo ušetr(it c(as, protože jestli se > nepletu, tak > když je budova v digitální mape( kú, tak bude i v rúian a dala by > se snad > jednoduše naimportovat. podle me( by to ale chte(lo ude(lat ne(jak > systematicky. samozr(ejme( mu*žu ude(lat ne(jakou webovou stránku, > odkud si > kdokoliv bude moct stáhnout osm soubor s budovama pro daný výbe(r > (tr(eba > ten katastr) a nechat tomu volný pru*be(h, ale pokud bychom tomu dali > ne(jaký r(ád, tak by to asi bylo lepší. > > máte ne(kdo ne(jaké návrhy? > > ff > > Dne 25.7.2012 19:28, Zdene(k Pražák napsal(a): > > no já zatím pomocí pluginu tracer kreslím v katastrálních > územích s digitální mapou budovy, tak jsem si myslel jestli bych > nemohl využít uvedených dat > > > >> ------------ Pu*vodní zpráva ------------ > >> Od: Miroslav Šulc <fordfrog na fordfrog.com > <mailto:fordfrog na fordfrog.com>> > >> Pr(edme(t: Re: [Talk-cz] rúian mapy - vylepšení > >> Datum: 25.7.2012 19:10:59 > >> ---------------------------------------- > >> Dne 25.7.2012 18:58, Zdene(k Pražák napsal(a): > >>> dají se ne(jak data z RUIAN dostat po jednotlivých katastrech > do JOSM a > >>> následne( po kontrole napr( vu*c(i Bingu poslat do OSM > >> jaká data konkrétne(? adresní body? budovy? nebo ne(jaká jiná? > samozr(ejme( > >> "není problém" vyexportovat data z databáze s urc(itým filtrem > (obec, > >> extent apod) do osm formátu, ale pokud už data jsou i v osm, > tak by se > >> musely duplicity odstranit. a to moc netuším jak. > >> > >> a pak je tu ješte( druhá ve(c. pokud bychom ne(co takového > de(lali, tak by > >> to podle me( chte(lo jednak udržovat pr(ehled, co už je > naimportováno a co > >> ne, a za druhé by bylo fajn zachovat ne(jakou referenc(ní vazbu na > >> originální data (rúian), abychom pr(ípadne( v budoucnu mohli > data v rúian > >> a v osm porovnávat (co je nového apod). > >> > >> a pak je tu ješte( tr(etí ve(c, a to posoudit, na c(em má smysl > trávit svu*j > >> c(as a co automatizovat (a c(as využít na ne(co lepšího). > >> > >>> Pražák > >> ff > >> > >> > >> > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> > > http://lists.openstreetmap.org/listinfo/talk-cz > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> já jsem nad tím ještě včera přemýšlel, a dospěl jsem k tomuhle: > > * aplikace by měla umožňovat nejen jednorázový import, ale i následné > aktualizace podle změn v rúian > * evidence provádění importů by měla být součástí aplikace tak, aby se na ní > nezapomínalo, současně by měla být co nejjednodušší > * z aplikace by mělo být zřejmé, co už je hotové a co ještě ne, případně kde > jsou nějaké změny v rúian > * aplikace by měla fungovat naprosto samostatně, bez nutnosti nějaké obsluhy > > takhle nějak by ta aplikace mohla vypadat: > > * byla by webová aplikace, kde by se podle katastrálních území daly stahovat > osm soubory s obrysy budov (a případně i s adresními body) > * aplikace by zobrazovala u každého kú, zda je naimportovaný nebo ne a > jestli v rúian došlo k nějakým změnám + možnost filtrování (okres, stav > importu, název kú) - v případě budov by aplikace zobrazovala jen kú, kde je > definovaný obrys alespoň jedné budovy > * v aplikaci by se evidovalo, kdo a kdy jaký soubor naimportoval do osm + > poznámky k importu > * aplikace by umožňovala sledovat změny v rúian (tj. pokud někdo stáhne a > naimportuje nějaké budovy do osm, tak info zanese do aplikace, aplikace pak > bude vědět, že k danému datu jsou budovy naimportované a umožní příště > vyexportovat pouze rozdíl mezi posledním naimportovaným stavem a současným > stavem v rúian) a exportovat pouze změny (včetně informace o odstraněných > objektech) > * z aplikace také bude zřejmé, kdo zrovna na čem dělá > * aplikace by mohla také zobrazovat historii importů (tj. kdo, kdy a co), > kdo má co rozdělané a jak dlouho, kolik toho zbývá naimportovat apod. > > přemýšlel jsem o tom, jak pořešit, aby nebylo nutné se do aplikace > registrovat a současně zajistit určitou míru autorizace při zadávání > informací o provedení importu a napadlo mě následující: > > 1) když si budu chtít stáhnout data z určitého kú, tak si to kú vyhledám, > zadám svůj mail a jestli chci komplet soubor nebo rozdílový soubor a > aplikace mi soubor pošle na mail, včetně linku pro zanesení informace o > provedení importu do aplikace > 2) naimportuju budovy do osm (vizuální kontrola, opravy apod.) > 3) když mám naimportováno, kliknu na link z mailu, zobrazí se mi webový > formulář, já tam zadám poznámky k importu a odešlu > 4) systém si informace spáruje s předchozím exportem a bude vědět, že až po > určité datum jsou budovy naimportované, takže bude moct jednoduše sledovat > rozdíly > > máte k tomu někdo nějaké připomínky nebo podněty? > > pak mám ještě jeden technický dotaz. tušíte někdo, jak převést data z > postgis geometry do osm formátu? s body předpokládám problém nebude, ale > netuším, jak s polygony. rúian se neomezuje jen na čáry, takže tam asi bude > nutné provést nějakou konverzi. ideální by byla nějaká knihovna, která vezme > postgis geometry a udělá z ní osm xml. zkoušel jsem něco vygooglovat, ale > asi jsem zadával špatná klíčová slova. > > ff > > Dne 26.7.2012 08:50, Zdeněk Pražák napsal(a): > > no kdyby se připravily stránky se zdrojovými údaji pro budovy pro jednotlivá > katastrální území, pak by bylo možné vytvořit stránky na wiki s odkazy na > stažení jednotlivých souborů. zájemce by si stáhl data pro požadované > katastrální území, provedl kontrolu např vůči bingu (odstranil různé chyby - > například neexistující budovy, budovy s jiným tvarem, doplnil by budovy ve > skutečnosti existující a neobsažené v datech RUIAN) a poté opravená data > odeslal na OSM. > V tabulce na wiki by zaznamenal provedení exportu a případné problémy > Pražák > > Dne 25. července 2012 19:34 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): >> >> no, tak to by rozhodně mělo ušetřit čas, protože jestli se nepletu, tak >> když je budova v digitální mapě kú, tak bude i v rúian a dala by se snad >> jednoduše naimportovat. podle mě by to ale chtělo udělat nějak >> systematicky. samozřejmě můžu udělat nějakou webovou stránku, odkud si >> kdokoliv bude moct stáhnout osm soubor s budovama pro daný výběr (třeba >> ten katastr) a nechat tomu volný průběh, ale pokud bychom tomu dali >> nějaký řád, tak by to asi bylo lepší. >> >> máte někdo nějaké návrhy? >> >> ff >> >> Dne 25.7.2012 19:28, Zdeněk Pražák napsal(a): >> > no já zatím pomocí pluginu tracer kreslím v katastrálních územích s >> > digitální mapou budovy, tak jsem si myslel jestli bych nemohl využít >> > uvedených dat >> > >> >> ------------ Původní zpráva ------------ >> >> Od: Miroslav Šulc <fordfrog na fordfrog.com> >> >> Předmět: Re: [Talk-cz] rúian mapy - vylepšení >> >> Datum: 25.7.2012 19:10:59 >> >> ---------------------------------------- >> >> Dne 25.7.2012 18:58, Zdeněk Pražák napsal(a): >> >>> dají se nějak data z RUIAN dostat po jednotlivých katastrech do JOSM a >> >>> následně po kontrole např vůči Bingu poslat do OSM >> >> jaká data konkrétně? adresní body? budovy? nebo nějaká jiná? samozřejmě >> >> "není problém" vyexportovat data z databáze s určitým filtrem (obec, >> >> extent apod) do osm formátu, ale pokud už data jsou i v osm, tak by se >> >> musely duplicity odstranit. a to moc netuším jak. >> >> >> >> a pak je tu ještě druhá věc. pokud bychom něco takového dělali, tak by >> >> to podle mě chtělo jednak udržovat přehled, co už je naimportováno a co >> >> ne, a za druhé by bylo fajn zachovat nějakou referenční vazbu na >> >> originální data (rúian), abychom případně v budoucnu mohli data v rúian >> >> a v osm porovnávat (co je nového apod). >> >> >> >> a pak je tu ještě třetí věc, a to posoudit, na čem má smysl trávit svůj >> >> čas a co automatizovat (a čas využít na něco lepšího). >> >> >> >>> Pražák >> >> ff >> >> >> >> >> >> >> > _______________________________________________ >> > Talk-cz mailing list >> > Talk-cz na openstreetmap.org >> > http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Ahoj, > > teď z toho nechápu, zda si aplikaci představuješ jen jako evidenční > nebo zda aplikace má provádět vlastní import (resp. s ním výrazně > pomáhat).

> Tedy za zásadní považuji porovnání současných OSM dat s daty RUIAN a > následné provedení změn (posuny stávajících bodů, opravy tagů, > zachování stávajících tagů, doplnění chybějících tagů, ...). > Samozřejmě s tím, že proces bude pod manuální kontrolou člověka, který > bude import provádět (tedy nikoli plně automatický, ale > poloautomatický). O těchto funkcích se v popisu nezmiňuješ.

> Honza

> Dne 27.7.2012 13:20, Jan Bilak napsal(a): >> Ahoj, >> >> teď z toho nechápu, zda si aplikaci představuješ jen jako evidenční >> nebo zda aplikace má provádět vlastní import (resp. s ním výrazně >> pomáhat). > > aplikace "pouze" připraví data z rúian, samotný import provede mapper. > tj. aplikace pro import připraví data, ale nebude import provádět, ten > se bude dělat ručně. i kdybychom (pokud vůbec, to vyplyne z ručních > importů) v budoucnu uvažovali o nějaké automatizaci, tak v prvním kroku > se to stejně musí udělat ručně, abychom věděli, nakolik je rúian > spolehlivý zdroj, jaké problémy lze očekávat apod. pro kontinuální práci > s daty z rúian je pak potřeba ta evidenční část. > >> Tedy za zásadní považuji porovnání současných OSM dat s daty RUIAN a >> následné provedení změn (posuny stávajících bodů, opravy tagů, >> zachování stávajících tagů, doplnění chybějících tagů, ...). >> Samozřejmě s tím, že proces bude pod manuální kontrolou člověka, který >> bude import provádět (tedy nikoli plně automatický, ale >> poloautomatický). O těchto funkcích se v popisu nezmiňuješ. > vycházel jsem hlavně z importu budov tam, kde je nemáme, to je asi ta > nejjednodušší varianta. co se týče importu budov do míst, kde už nějaké > jsou, nebo importu adresních bodů, tak se přiznám, že nevím, jestli v > josm existují nástroje na zobrazení rozdílů ve vrstvách, na slučování > objektů (a tagů) z různých vrstev apod. s tím zkušenosti nemám. ale > určitě se tu najde někdo, kdo to vědět bude nebo aspoň bude vědět, kde > hledat. > > ten můj nástřel je v podstatě (podle mě) asi to nejnutnější minimum pro > to, aby se dala data z rúian využít pro manuální importy. nad tím potom > lze dělat další nadstavby, které práci zjednoduší a zrychlí. něco určitě > vyplyne i ze zkušeností se samotnými importy. >> Honza > ff > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Otázka je, jak by měla vypadat ta připravená data. V případě importu > nových věcí tak, kde žádné nebyly, je to celkem primitivní. Ale mnohem > náročnější bude import do míst, kde již nějaká data jsou. Tam bude > třeba něco starého odstranit, něco modifikovat, něco přidat... Lze v > OSM formátu postihnout nějak všechny tyto typy změn (odstranění, > modifikace, přidání nových objektů)? A pokud lze, je možné to pak > nějak rozumně vizualizovat, aby to člověk mohl projít a rozhodovat > "tohle je ok, tohle zamítnu a zůstane při starém, tohle bude ještě > trochu jinak..." pomocí stávajících nástrojů? Nevím, jaké jsou > možnosti.

> Např. u adresních bodů by bylo podle mě vhodné, aplikace provedla > nějaké "inteligentní" matchování adresních bodů v OSM a RUIAN, > zobrazovala původní a nový bod vizuálně propojený šipkou, jinak > vyznačené body, které jsou pouze v OSM a naopak jinak vyznačené body, > které jsou pouze v RUIAN. Uživatel by mohl vždy zvolit, zda ponechat > novou nebo starou polohu bodu (zde by bylo možné i volit vlastní > polohu - jde o primitivní úkon) atd. Nakonec by aplikace vytvořila OSM > patch, který by obsahoval požadované úpravy včetně vhodně zmergovaných > tagů (ty by možná bylo třeba také kontrolovat v aplikaci) atd.

> Otázka je, jak by měla vypadat ta připravená data. V případě importu > nových věcí tak, kde žádné nebyly, je to celkem primitivní. Ale mnohem > náročnější bude import do míst, kde již nějaká data jsou. Tam bude > třeba něco starého odstranit, něco modifikovat, něco přidat... Lze v > OSM formátu postihnout nějak všechny tyto typy změn (odstranění, > modifikace, přidání nových objektů)? A pokud lze, je možné to pak > nějak rozumně vizualizovat, aby to člověk mohl projít a rozhodovat > "tohle je ok, tohle zamítnu a zůstane při starém, tohle bude ještě > trochu jinak..." pomocí stávajících nástrojů? Nevím, jaké jsou > možnosti. > > Pokud nic vhodné stávajícího není, tak bych to viděl spíše na > interaktivní aplikaci, která zobrazí ty rozdíly ve vhodné podobě, u > každé umožní se rozhodnout, zda ponechat stará data, nová data, > automaticky zmergovat nebo ručně upravit. Ruční úpravu by ta aplikace > přímo nepodporovala, protože by to bylo příliš náročné (vlastně by > bylo třeba vytvořit obdobu editoru jako JOSM), ale poznačilo by to > nutnost ruční editace do dat nějakými tagy, aby výsledek, který z > aplikace vypadne, bylo možné otevřít např. v JOSM a ručně provést > potřebné úpravy. > > Např. u adresních bodů by bylo podle mě vhodné, aplikace provedla > nějaké "inteligentní" matchování adresních bodů v OSM a RUIAN, > zobrazovala původní a nový bod vizuálně propojený šipkou, jinak > vyznačené body, které jsou pouze v OSM a naopak jinak vyznačené body, > které jsou pouze v RUIAN. Uživatel by mohl vždy zvolit, zda ponechat > novou nebo starou polohu bodu (zde by bylo možné i volit vlastní > polohu - jde o primitivní úkon) atd. Nakonec by aplikace vytvořila OSM > patch, který by obsahoval požadované úpravy včetně vhodně zmergovaných > tagů (ty by možná bylo třeba také kontrolovat v aplikaci) atd. > > U budov to bude samozřejmě výrazně složitější. > > Obecně čistě ručního importu se celkem obávám. Dat je vetší než malé množství. > > Honza > > > Dne 27. července 2012 13:41 Miroslav Šulc<fordfrog na fordfrog.com> napsal(a): >> Dne 27.7.2012 13:20, Jan Bilak napsal(a): >>> Ahoj, >>> >>> teď z toho nechápu, zda si aplikaci představuješ jen jako evidenční >>> nebo zda aplikace má provádět vlastní import (resp. s ním výrazně >>> pomáhat). >> aplikace "pouze" připraví data z rúian, samotný import provede mapper. >> tj. aplikace pro import připraví data, ale nebude import provádět, ten >> se bude dělat ručně. i kdybychom (pokud vůbec, to vyplyne z ručních >> importů) v budoucnu uvažovali o nějaké automatizaci, tak v prvním kroku >> se to stejně musí udělat ručně, abychom věděli, nakolik je rúian >> spolehlivý zdroj, jaké problémy lze očekávat apod. pro kontinuální práci >> s daty z rúian je pak potřeba ta evidenční část. >> >>> Tedy za zásadní považuji porovnání současných OSM dat s daty RUIAN a >>> následné provedení změn (posuny stávajících bodů, opravy tagů, >>> zachování stávajících tagů, doplnění chybějících tagů, ...). >>> Samozřejmě s tím, že proces bude pod manuální kontrolou člověka, který >>> bude import provádět (tedy nikoli plně automatický, ale >>> poloautomatický). O těchto funkcích se v popisu nezmiňuješ. >> vycházel jsem hlavně z importu budov tam, kde je nemáme, to je asi ta >> nejjednodušší varianta. co se týče importu budov do míst, kde už nějaké >> jsou, nebo importu adresních bodů, tak se přiznám, že nevím, jestli v >> josm existují nástroje na zobrazení rozdílů ve vrstvách, na slučování >> objektů (a tagů) z různých vrstev apod. s tím zkušenosti nemám. ale >> určitě se tu najde někdo, kdo to vědět bude nebo aspoň bude vědět, kde >> hledat. >> >> ten můj nástřel je v podstatě (podle mě) asi to nejnutnější minimum pro >> to, aby se dala data z rúian využít pro manuální importy. nad tím potom >> lze dělat další nadstavby, které práci zjednoduší a zrychlí. něco určitě >> vyplyne i ze zkušeností se samotnými importy. >>> Honza >> ff >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >

> Otázka je, jak by měla vypadat ta připravená data. V případě importu > nových věcí tak, kde žádné nebyly, je to celkem primitivní. Ale mnohem > náročnější bude import do míst, kde již nějaká data jsou. Tam bude > třeba něco starého odstranit, něco modifikovat, něco přidat... Lze v > OSM formátu postihnout nějak všechny tyto typy změn (odstranění, > modifikace, přidání nových objektů)? A pokud lze, je možné to pak > nějak rozumně vizualizovat, aby to člověk mohl projít a rozhodovat > "tohle je ok, tohle zamítnu a zůstane při starém, tohle bude ještě > trochu jinak..." pomocí stávajících nástrojů? Nevím, jaké jsou > možnosti. > > Pokud nic vhodné stávajícího není, tak bych to viděl spíše na > interaktivní aplikaci, která zobrazí ty rozdíly ve vhodné podobě, u > každé umožní se rozhodnout, zda ponechat stará data, nová data, > automaticky zmergovat nebo ručně upravit. Ruční úpravu by ta aplikace > přímo nepodporovala, protože by to bylo příliš náročné (vlastně by > bylo třeba vytvořit obdobu editoru jako JOSM), ale poznačilo by to > nutnost ruční editace do dat nějakými tagy, aby výsledek, který z > aplikace vypadne, bylo možné otevřít např. v JOSM a ručně provést > potřebné úpravy. > > Např. u adresních bodů by bylo podle mě vhodné, aplikace provedla > nějaké "inteligentní" matchování adresních bodů v OSM a RUIAN, > zobrazovala původní a nový bod vizuálně propojený šipkou, jinak > vyznačené body, které jsou pouze v OSM a naopak jinak vyznačené body, > které jsou pouze v RUIAN. Uživatel by mohl vždy zvolit, zda ponechat > novou nebo starou polohu bodu (zde by bylo možné i volit vlastní > polohu - jde o primitivní úkon) atd. Nakonec by aplikace vytvořila OSM > patch, který by obsahoval požadované úpravy včetně vhodně zmergovaných > tagů (ty by možná bylo třeba také kontrolovat v aplikaci) atd. > > U budov to bude samozřejmě výrazně složitější. > > Obecně čistě ručního importu se celkem obávám. Dat je vetší než malé množství. > > Honza > > > Dne 27. července 2012 13:41 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): >> Dne 27.7.2012 13:20, Jan Bilak napsal(a): >>> Ahoj, >>> >>> teď z toho nechápu, zda si aplikaci představuješ jen jako evidenční >>> nebo zda aplikace má provádět vlastní import (resp. s ním výrazně >>> pomáhat). >> aplikace "pouze" připraví data z rúian, samotný import provede mapper. >> tj. aplikace pro import připraví data, ale nebude import provádět, ten >> se bude dělat ručně. i kdybychom (pokud vůbec, to vyplyne z ručních >> importů) v budoucnu uvažovali o nějaké automatizaci, tak v prvním kroku >> se to stejně musí udělat ručně, abychom věděli, nakolik je rúian >> spolehlivý zdroj, jaké problémy lze očekávat apod. pro kontinuální práci >> s daty z rúian je pak potřeba ta evidenční část. >> >>> Tedy za zásadní považuji porovnání současných OSM dat s daty RUIAN a >>> následné provedení změn (posuny stávajících bodů, opravy tagů, >>> zachování stávajících tagů, doplnění chybějících tagů, ...). >>> Samozřejmě s tím, že proces bude pod manuální kontrolou člověka, který >>> bude import provádět (tedy nikoli plně automatický, ale >>> poloautomatický). O těchto funkcích se v popisu nezmiňuješ. >> vycházel jsem hlavně z importu budov tam, kde je nemáme, to je asi ta >> nejjednodušší varianta. co se týče importu budov do míst, kde už nějaké >> jsou, nebo importu adresních bodů, tak se přiznám, že nevím, jestli v >> josm existují nástroje na zobrazení rozdílů ve vrstvách, na slučování >> objektů (a tagů) z různých vrstev apod. s tím zkušenosti nemám. ale >> určitě se tu najde někdo, kdo to vědět bude nebo aspoň bude vědět, kde >> hledat. >> >> ten můj nástřel je v podstatě (podle mě) asi to nejnutnější minimum pro >> to, aby se dala data z rúian využít pro manuální importy. nad tím potom >> lze dělat další nadstavby, které práci zjednoduší a zrychlí. něco určitě >> vyplyne i ze zkušeností se samotnými importy. >>> Honza >> ff >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> v souvislosti s tím co píšeš mě napadlo udělat to komplet jako josm > plugin. tj. serverová část by zůstala tak jak jsem psal, ale všechno > ostatní by se dělalo přímo z josm pluginu. ten by si stáhl data přes api > ode mě ze serveru z aktuální databáze rúian, provedl by porovnání s > datovou vrstvou z osm a vyhodil by nějaké info o rozdílech v osm a v > rúian s tím, že mapper by si vybíral varianty a potvrzoval je, případně > by sáhnul přímo do osm vrstvy a udělal úpravy tam. při uploadu změn do > osm by se pak zapsalo i info ke mně na server o provedení importu. do > pluginu by se pak dala přidávat funkcionalita dle potřeby. > > ff > > Dne 27.7.2012 14:18, Jan Bilak napsal(a): >> Otázka je, jak by měla vypadat ta připravená data. V případě importu >> nových věcí tak, kde žádné nebyly, je to celkem primitivní. Ale mnohem >> náročnější bude import do míst, kde již nějaká data jsou. Tam bude >> třeba něco starého odstranit, něco modifikovat, něco přidat... Lze v >> OSM formátu postihnout nějak všechny tyto typy změn (odstranění, >> modifikace, přidání nových objektů)? A pokud lze, je možné to pak >> nějak rozumně vizualizovat, aby to člověk mohl projít a rozhodovat >> "tohle je ok, tohle zamítnu a zůstane při starém, tohle bude ještě >> trochu jinak..." pomocí stávajících nástrojů? Nevím, jaké jsou >> možnosti. >> >> Pokud nic vhodné stávajícího není, tak bych to viděl spíše na >> interaktivní aplikaci, která zobrazí ty rozdíly ve vhodné podobě, u >> každé umožní se rozhodnout, zda ponechat stará data, nová data, >> automaticky zmergovat nebo ručně upravit. Ruční úpravu by ta aplikace >> přímo nepodporovala, protože by to bylo příliš náročné (vlastně by >> bylo třeba vytvořit obdobu editoru jako JOSM), ale poznačilo by to >> nutnost ruční editace do dat nějakými tagy, aby výsledek, který z >> aplikace vypadne, bylo možné otevřít např. v JOSM a ručně provést >> potřebné úpravy. >> >> Např. u adresních bodů by bylo podle mě vhodné, aplikace provedla >> nějaké "inteligentní" matchování adresních bodů v OSM a RUIAN, >> zobrazovala původní a nový bod vizuálně propojený šipkou, jinak >> vyznačené body, které jsou pouze v OSM a naopak jinak vyznačené body, >> které jsou pouze v RUIAN. Uživatel by mohl vždy zvolit, zda ponechat >> novou nebo starou polohu bodu (zde by bylo možné i volit vlastní >> polohu - jde o primitivní úkon) atd. Nakonec by aplikace vytvořila OSM >> patch, který by obsahoval požadované úpravy včetně vhodně zmergovaných >> tagů (ty by možná bylo třeba také kontrolovat v aplikaci) atd. >> >> U budov to bude samozřejmě výrazně složitější. >> >> Obecně čistě ručního importu se celkem obávám. Dat je vetší než malé množství. >> >> Honza >> >> >> Dne 27. července 2012 13:41 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): >>> Dne 27.7.2012 13:20, Jan Bilak napsal(a): >>>> Ahoj, >>>> >>>> teď z toho nechápu, zda si aplikaci představuješ jen jako evidenční >>>> nebo zda aplikace má provádět vlastní import (resp. s ním výrazně >>>> pomáhat). >>> aplikace "pouze" připraví data z rúian, samotný import provede mapper. >>> tj. aplikace pro import připraví data, ale nebude import provádět, ten >>> se bude dělat ručně. i kdybychom (pokud vůbec, to vyplyne z ručních >>> importů) v budoucnu uvažovali o nějaké automatizaci, tak v prvním kroku >>> se to stejně musí udělat ručně, abychom věděli, nakolik je rúian >>> spolehlivý zdroj, jaké problémy lze očekávat apod. pro kontinuální práci >>> s daty z rúian je pak potřeba ta evidenční část. >>> >>>> Tedy za zásadní považuji porovnání současných OSM dat s daty RUIAN a >>>> následné provedení změn (posuny stávajících bodů, opravy tagů, >>>> zachování stávajících tagů, doplnění chybějících tagů, ...). >>>> Samozřejmě s tím, že proces bude pod manuální kontrolou člověka, který >>>> bude import provádět (tedy nikoli plně automatický, ale >>>> poloautomatický). O těchto funkcích se v popisu nezmiňuješ. >>> vycházel jsem hlavně z importu budov tam, kde je nemáme, to je asi ta >>> nejjednodušší varianta. co se týče importu budov do míst, kde už nějaké >>> jsou, nebo importu adresních bodů, tak se přiznám, že nevím, jestli v >>> josm existují nástroje na zobrazení rozdílů ve vrstvách, na slučování >>> objektů (a tagů) z různých vrstev apod. s tím zkušenosti nemám. ale >>> určitě se tu najde někdo, kdo to vědět bude nebo aspoň bude vědět, kde >>> hledat. >>> >>> ten můj nástřel je v podstatě (podle mě) asi to nejnutnější minimum pro >>> to, aby se dala data z rúian využít pro manuální importy. nad tím potom >>> lze dělat další nadstavby, které práci zjednoduší a zrychlí. něco určitě >>> vyplyne i ze zkušeností se samotnými importy. >>>> Honza >>> ff

> Ja bych nadhodil nekolik otazek treba pro adresni body: > > * Kolik je adresnich bodu? 2.500.000

> * Kolik mapperu se bude ucastnit takove prace? Prvni desitky.

> * Jak dlouho to bude trvat? ...

> * Jaka cast dat by mela byt mappery pridavana tam kde nikdy nebyla? Vetsina.

> * Jak budou uzivatele hodnotit (ne)kvalitu dat jiz v OSM? Na zaklade > dat CUZK a u par stovek bodu ze znalosti z terenu kde bydli.Tezko ale > suplovat: > http://www.cuzk.cz/GenerujSoubor.ashx?NAZEV=10-POROVNANIADRES > > Opravdu je individualni prace na vetsine uzemi republiky cesta, jak > data RUIAN dostat do OSM?

> h.anoj

> Ja bych nadhodil nekolik otazek treba pro adresni body:

> adresnich bodu? 2.500.000

> Prvni desitky.

> mappery pridavana tam kde nikdy nebyla? Vetsina.

> hodnotit (ne)kvalitu dat jiz v OSM? Na zaklade

> ze znalosti z terenu kde bydli.Tezko > ale

> je individualni prace na vetsine uzemi republiky cesta, jak

> dostat do OSM?

> <fordfrog na fordfrog.com> napsal(a): > v souvislosti s tím co píšeš mě > napadlo udělat to komplet jako josm > plugin. tj. serverová část by > zůstala tak jak jsem psal, ale všechno > ostatní by se dělalo přímo z > josm pluginu. ten by si stáhl data přes api > ode mě ze serveru z > aktuální databáze rúian, provedl by porovnání s > datovou vrstvou z > osm a vyhodil by nějaké info o rozdílech v osm a v > rúian s tím, že > mapper by si vybíral varianty a potvrzoval je, případně > by sáhnul > přímo do osm vrstvy a udělal úpravy tam. při uploadu změn do > osm by > se pak zapsalo i info ke mně na server o provedení importu. do > pluginu > by se pak dala přidávat funkcionalita dle potřeby. > > ff > > Dne > 27.7.2012 14:18, Jan Bilak napsal(a): >> Otázka je, jak by měla vypadat ta > připravená data. V případě importu >> nových věcí tak, kde žádné > nebyly, je to celkem primitivní. Ale mnohem >> náročnější bude import > do míst, kde již nějaká data jsou. Tam bude >> třeba něco starého > odstranit, něco modifikovat, něco přidat... Lze v >> OSM formátu > postihnout nějak všechny tyto typy změn (odstranění, >> modifikace, > přidání nových objektů)? A pokud lze, je možné to pak >> nějak > rozumně vizualizovat, aby to člověk mohl projít a rozhodovat >> "tohle > je ok, tohle zamítnu a zůstane při starém, tohle bude ještě >> trochu > jinak..." pomocí stávajících nástrojů? Nevím, jaké jsou >> > možnosti. >> >> Pokud nic vhodné stávajícího není, tak bych to viděl > spíše na >> interaktivní aplikaci, která zobrazí ty rozdíly ve vhodné > podobě, u >> každé umožní se rozhodnout, zda ponechat stará data, > nová data, >> automaticky zmergovat nebo ručně upravit. Ruční úpravu > by ta aplikace >> přímo nepodporovala, protože by to bylo příliš > náročné (vlastně by >> bylo třeba vytvořit obdobu editoru jako JOSM), > ale poznačilo by to >> nutnost ruční editace do dat nějakými tagy, aby > výsledek, který z >> aplikace vypadne, bylo možné otevřít např. v > JOSM a ručně provést >> potřebné úpravy. >> >> Např. u adresních > bodů by bylo podle mě vhodné, aplikace provedla >> nějaké > "inteligentní" matchování adresních bodů v OSM a RUIAN, >> zobrazovala > původní a nový bod vizuálně propojený šipkou, jinak >> vyznačené > body, které jsou pouze v OSM a naopak jinak vyznačené body, >> které > jsou pouze v RUIAN. Uživatel by mohl vždy zvolit, zda ponechat >> novou > nebo starou polohu bodu (zde by bylo možné i volit vlastní >> polohu - > jde o primitivní úkon) atd. Nakonec by aplikace vytvořila OSM >> patch, > který by obsahoval požadované úpravy včetně vhodně zmergovaných >> > tagů (ty by možná bylo třeba také kontrolovat v aplikaci) atd. >> >> U > budov to bude samozřejmě výrazně složitější. >> >> Obecně čistě > ručního importu se celkem obávám. Dat je vetší než malé > množství. >> >> Honza >> >> >> Dne 27. července 2012 13:41 Miroslav Šulc > <fordfrog na fordfrog.com> napsal(a): >>> Dne 27.7.2012 13:20, Jan Bilak > napsal(a): >>>> Ahoj, >>>> >>>> teď z toho nechápu, zda si aplikaci > představuješ jen jako evidenční >>>> nebo zda aplikace má provádět > vlastní import (resp. s ním výrazně >>>> pomáhat). >>> aplikace "pouze" > připraví data z rúian, samotný import provede mapper. >>> tj. aplikace > pro import připraví data, ale nebude import provádět, ten >>> se bude > dělat ručně. i kdybychom (pokud vůbec, to vyplyne z ručních >>> > importů) v budoucnu uvažovali o nějaké automatizaci, tak v prvním > kroku >>> se to stejně musí udělat ručně, abychom věděli, nakolik je > rúian >>> spolehlivý zdroj, jaké problémy lze očekávat apod. pro > kontinuální práci >>> s daty z rúian je pak potřeba ta evidenční > část. >>> >>>> Tedy za zásadní považuji porovnání současných OSM > dat s daty RUIAN a >>>> následné provedení změn (posuny stávajících > bodů, opravy tagů, >>>> zachování stávajících tagů, doplnění > chybějících tagů, ...). >>>> Samozřejmě s tím, že proces bude pod > manuální kontrolou člověka, který >>>> bude import provádět (tedy > nikoli plně automatický, ale >>>> poloautomatický). O těchto funkcích > se v popisu nezmiňuješ. >>> vycházel jsem hlavně z importu budov tam, > kde je nemáme, to je asi ta >>> nejjednodušší varianta. co se týče > importu budov do míst, kde už nějaké >>> jsou, nebo importu adresních > bodů, tak se přiznám, že nevím, jestli v >>> josm existují nástroje > na zobrazení rozdílů ve vrstvách, na slučování >>> objektů (a tagů) > z různých vrstev apod. s tím zkušenosti nemám. ale >>> určitě se tu > najde někdo, kdo to vědět bude nebo aspoň bude vědět, kde >>> > hledat. >>> >>> ten můj nástřel je v podstatě (podle mě) asi to > nejnutnější minimum pro >>> to, aby se dala data z rúian využít pro > manuální importy. nad tím potom >>> lze dělat další nadstavby, které > práci zjednoduší a zrychlí. něco určitě >>> vyplyne i ze zkušeností > se samotnými importy. >>>> Honza >>> > ff

> list

> možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat > automaticky, akorát případy, kdy už adresní bod existuje a je od toho v > rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by > nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak > moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco > vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a > uvidíme, co tu vlastně řešíme.

> On 28.7.2012 23:15, Miroslav Šulc wrote: >> >> možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat >> automaticky, akorát případy, kdy už adresní bod existuje a je od toho v >> rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by >> nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak >> moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco >> vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a >> uvidíme, co tu vlastně řešíme. > > Zdravím, navrhuji udělat možnost vyřadit oblast z automatického > importu/aktualizace. V naší vesnici jsou některé adresní body chybně > umístěné, některé chybí úplně. Asi bych nebyl nadšený, kdyby mi je nějaký > bot stále dokola automaticky přesouval/mazal (zrovna dnes jsem doplňoval > jedno č.p. podle nálepky na popelnici, což je možné jen v neděli večer :) ) > > LuKo > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Zdravím, > > metainformace o tom, že se něco nemá importovat z RUIAN, protože je to > tam špatně, by podle mě chtělo mít přímo v OSM. A to včetně informace > o tom, odkud konkrétně ta spolehlivější informace pochází.

> Honza > > PS: Doplňování čp. podle čísla na popelnici nemusí být moc spolehlivé, > protože občas někdo popelnici prodá/koupí, ukradne, ... a číslo > neodpovídá.

> Dne 30. července 2012 0:59 Lukas Kohout<luko na luko.name> napsal(a): >> On 28.7.2012 23:15, Miroslav Šulc wrote: >>> možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat >>> automaticky, akorát případy, kdy už adresní bod existuje a je od toho v >>> rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by >>> nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak >>> moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco >>> vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a >>> uvidíme, co tu vlastně řešíme. >> Zdravím, navrhuji udělat možnost vyřadit oblast z automatického >> importu/aktualizace. V naší vesnici jsou některé adresní body chybně >> umístěné, některé chybí úplně. Asi bych nebyl nadšený, kdyby mi je nějaký >> bot stále dokola automaticky přesouval/mazal (zrovna dnes jsem doplňoval >> jedno č.p. podle nálepky na popelnici, což je možné jen v neděli večer :) ) >> >> LuKo >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> On 28.7.2012 23:15, Miroslav Šulc wrote: >> možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat >> automaticky, akorát případy, kdy už adresní bod existuje a je od toho v >> rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by >> nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak >> moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco >> vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a >> uvidíme, co tu vlastně řešíme. > Zdravím, navrhuji udělat možnost vyřadit oblast z automatického > importu/aktualizace. V naší vesnici jsou některé adresní body chybně > umístěné, některé chybí úplně. Asi bych nebyl nadšený, kdyby mi je > nějaký bot stále dokola automaticky přesouval/mazal (zrovna dnes jsem > doplňoval jedno č.p. podle nálepky na popelnici, což je možné jen v > neděli večer :) )

> > LuKo > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Dne 30.7.2012 00:59, Lukas Kohout napsal(a): >> On 28.7.2012 23:15, Miroslav Šulc wrote: >>> možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat >>> automaticky, akorát případy, kdy už adresní bod existuje a je od toho v >>> rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by >>> nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak >>> moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco >>> vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a >>> uvidíme, co tu vlastně řešíme. >> Zdravím, navrhuji udělat možnost vyřadit oblast z automatického >> importu/aktualizace. V naší vesnici jsou některé adresní body chybně >> umístěné, některé chybí úplně. Asi bych nebyl nadšený, kdyby mi je >> nějaký bot stále dokola automaticky přesouval/mazal (zrovna dnes jsem >> doplňoval jedno č.p. podle nálepky na popelnici, což je možné jen v >> neděli večer :) ) > chybně umístěné znamená co přesně? posunuté o kolik metrů? podle my bě > skript neměl měnit body, které jsou od sebe vzdáleny víc jak x metrů (tj > rúian vs osm), ale měl by je někam vypsat. tyhle by se pak museli > zkontrolovat ručně. kolik jich bude, by mělo vyplynout z analýzy rozdílů > mezi rúian a osm, kterou mám v plánu udělat. > > k těm chybějícím bodům? znamená to, že tam máte nějaká čp, o kterých > rúian neví?

> jinak někde na osm wiki jsem četl o tagu "bot" nebo tak nějak (teď to > nemůžu najít). podle mě automaticky spravované adresní body by měly > tenhle tag mít. pokud by pak někdo bod přesunul, protože je umístěný > špatně, tak by mu ten tag smazal a tím pádem by skript ten bod přestal > aktualizovat, max by někam vypsal změny pro daný bod, pokud k nim dojde. > takových bodů bude v porovnání s těmi cca třemi miliony minimum, takže > případné změny (kterých taky asi bude minimum) by se daly zvládat ručně, > pokud bude potřeba je do osm zanést. > >> LuKo >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Materiály ke zkoumání: > http://maps.fordfrog.com/?lat=50.05843&lon=15.19497&zoom=18&layers=0B0FTF > (nástroj > špatně zpracovává permalink, tedy stejný link pro orientaci: > http://www.openstreetmap.org/?lat=50.05843&lon=15.19497&zoom=18 > <http://www.openstreetmap.org/?lat=50.05843&lon=15.19497&zoom=18>) - Do > pozornosti doporučuji čísla 125, 126, 127, 133, 162 (ty 3 "rozestavěné" > > domy u hlavní jsou již minimálně rok obydlené, zítra je obejdu se > psem) > a ve střední části vesnice pak 16, 7, 9, 10 - tam rúian označuje > čísla > (zbořených) stodol. > > Naopak ve vedlejší obci je předchozí import nějak rozházený, něco > tam i > chybí a tam by změna podle rúian znamenala značné zlepšení: > http://maps.fordfrog.com/?lat=50.05772&lon=15.21386&zoom=18&layers=0B0FTF

> Existuje k tomuto účelu nějaký tag "zjištěno při procházce se psem"?

> On 30.7.2012 2:20, Miroslav Šulc wrote: >> Dne 30.7.2012 00:59, Lukas Kohout napsal(a): >>> On 28.7.2012 23:15, Miroslav Šulc wrote: >>>> možná nejlepší r(ešení by bylo adresní body naimportovat/zaktualizovat >>>> automaticky, akorát pr(ípady, kdy už adresní bod existuje a je od toho v >>>> rúian vzdálený víc než x jednotek by se r(ešily poloautomaticky. možná by >>>> nebylo špatné napsat si ne(jaký testovací skript, který by zjistil, jak >>>> moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco >>>> vyc(íst. až se mi doimportují osm data do db, tak to mu*žu zkusit napsat a >>>> uvidíme, co tu vlastne( r(ešíme. >>> Zdravím, navrhuji ude(lat možnost vyr(adit oblast z automatického >>> importu/aktualizace. V naší vesnici jsou ne(které adresní body chybne( >>> umíste(né, ne(které chybí úplne(. Asi bych nebyl nadšený, kdyby mi je >>> ne(jaký bot stále dokola automaticky pr(esouval/mazal (zrovna dnes jsem >>> dopln(oval jedno c(.p. podle nálepky na popelnici, což je možné jen v >>> nede(li vec(er :) ) >> chybne( umíste(né znamená co pr(esne(? posunuté o kolik metru*? podle my be( >> skript neme(l me(nit body, které jsou od sebe vzdáleny víc jak x metru* (tj >> rúian vs osm), ale me(l by je ne(kam vypsat. tyhle by se pak museli >> zkontrolovat ruc(ne(. kolik jich bude, by me(lo vyplynout z analýzy rozdílu* >> mezi rúian a osm, kterou mám v plánu ude(lat. >> >> k te(m chybe(jícím bodu*m? znamená to, že tam máte ne(jaká c(p, o kterých >> rúian neví? > Materiály ke zkoumání: > http://maps.fordfrog.com/?lat=50.05843&lon=15.19497&zoom=18&layers=0B0FTF > (nástroj špatne( zpracovává permalink...

> Do pozornosti doporuc(uji c(ísla 125, 126, 127, 133, 162 (ty 3 > "rozestave(né" domy u hlavní jsou již minimálne( rok obydlené, zítra > je obejdu se psem) a ve str(ední c(ásti vesnice pak 16, 7, 9, 10 - tam > rúian oznac(uje c(ísla (zbor(ených) stodol.

> > Naopak ve vedlejší obci je pr(edchozí import ne(jak rozházený, ne(co > tam i chybí a tam by zme(na podle rúian znamenala znac(né zlepšení: > http://maps.fordfrog.com/?lat=50.05772&lon=15.21386&zoom=18&layers=0B0FTF

>> jinak ne(kde na osm wiki jsem c(etl o tagu "bot" nebo tak ne(jak (ted( to >> nemu*žu najít). podle me( automaticky spravované adresní body by me(ly >> tenhle tag mít. pokud by pak ne(kdo bod pr(esunul, protože je umíste(ný >> špatne(, tak by mu ten tag smazal a tím pádem by skript ten bod pr(estal >> aktualizovat, max by ne(kam vypsal zme(ny pro daný bod, pokud k nim dojde. >> takových bodu* bude v porovnání s te(mi cca tr(emi miliony minimum, takže >> pr(ípadné zme(ny (kterých taky asi bude minimum) by se daly zvládat ruc(ne(, >> pokud bude potr(eba je do osm zanést. >> >>> LuKo

> Dne 30.7.2012 03:02, Lukas Kohout napsal(a): > > On 30.7.2012 2:20, Miroslav Šulc wrote: > > Dne 30.7.2012 00:59, Lukas Kohout napsal(a): > > On 28.7.2012 23:15, Miroslav Šulc wrote: > > možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat > automaticky, akorát případy, kdy už adresní bod existuje a je od toho v > rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by > nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak > moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco > vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a > uvidíme, co tu vlastně řešíme. > > Zdravím, navrhuji udělat možnost vyřadit oblast z automatického > importu/aktualizace. V naší vesnici jsou některé adresní body chybně > umístěné, některé chybí úplně. Asi bych nebyl nadšený, kdyby mi je > nějaký bot stále dokola automaticky přesouval/mazal (zrovna dnes jsem > doplňoval jedno č.p. podle nálepky na popelnici, což je možné jen v > neděli večer :) ) > > chybně umístěné znamená co přesně? posunuté o kolik metrů? podle my bě > skript neměl měnit body, které jsou od sebe vzdáleny víc jak x metrů (tj > rúian vs osm), ale měl by je někam vypsat. tyhle by se pak museli > zkontrolovat ručně. kolik jich bude, by mělo vyplynout z analýzy rozdílů > mezi rúian a osm, kterou mám v plánu udělat. > > k těm chybějícím bodům? znamená to, že tam máte nějaká čp, o kterých > rúian neví? > > Materiály ke zkoumání: > http://maps.fordfrog.com/?lat=50.05843&lon=15.19497&zoom=18&layers=0B0FTF > (nástroj špatně zpracovává permalink... > > > ten permalink jsem opravil. včera jsem předělával zobrazení souřadnic, aby > bylo v epsg:4326 (tj stejné jako osm) a rozbil jsem tím permalink. > > > Do pozornosti doporučuji čísla 125, 126, 127, 133, 162 (ty 3 "rozestavěné" > domy u hlavní jsou již minimálně rok obydlené, zítra je obejdu se psem) a ve > střední části vesnice pak 16, 7, 9, 10 - tam rúian označuje čísla > (zbořených) stodol. > > > ty posuny jsou dost znatelné, to by se mělo dát odchytit. co se týká těch > čísel nezanesených do rúian, tam bych asi volil nějaký tag typu "nobot", > který by bod chránil před botem. body tohohle typu by navíc měly vyjet z > toho porovnávacího skriptu, takže by se daly před importem ručně > odkontrolovat (pokud jich nebude moc) a otagovat tagem "nobot", aby na ně > bot nesahal. > > > > Naopak ve vedlejší obci je předchozí import nějak rozházený, něco tam i > chybí a tam by změna podle rúian znamenala značné zlepšení: > http://maps.fordfrog.com/?lat=50.05772&lon=15.21386&zoom=18&layers=0B0FTF > > > koukám, že ta tvoje oblast je ideální na příklady nesrovnalostí :-) > > > jinak někde na osm wiki jsem četl o tagu "bot" nebo tak nějak (teď to > nemůžu najít). podle mě automaticky spravované adresní body by měly > tenhle tag mít. pokud by pak někdo bod přesunul, protože je umístěný > špatně, tak by mu ten tag smazal a tím pádem by skript ten bod přestal > aktualizovat, max by někam vypsal změny pro daný bod, pokud k nim dojde. > takových bodů bude v porovnání s těmi cca třemi miliony minimum, takže > případné změny (kterých taky asi bude minimum) by se daly zvládat ručně, > pokud bude potřeba je do osm zanést. > > LuKo > > ff > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Nejsou systémy s tagováním bot/nobot moc komplikované? Co kdyby se bot > podíval na autora poslední změny daného bodu a pokud by to byl on sám > tak by ho upravil podle potřeby, pokud by to byl někdo jiný tak by jen > vygeneroval upozornění. > LM_1

> Zdravím, > > stále se v OSM rozkoukávám a nyní řeším, jak zpracovat poměrně zásadní > dvouměsíční uzavírku I/38 v Kolíně. Viz > http://www.mukolin.cz/cz/o-meste/06598-planovana-uzavirka-silnice-c-i-38-vjezd-do-kolina-od-kutne-hory.html > . Vytvořit uzavírku (snad) umím. Dají se do mapy vložit i objízdné trasy, > aby s nimi počítala navigace? Díky za případnou radu či nakopnutí směrem k > tématu, kde se to již řešilo (zatím jsem nebyl v hledání úspěšný). > > LuKo > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> o tomhle jsem taky uvažoval, má to ale jednu nevýhodu. neumožňuje to bod > vrátit do správy botovi. stejně tak pokud by někdo jen přidal nějaký > další tag k adresnímu bodu, tak by se bot taky přestal o ten bod starat, > i když by se o něj měl starat dál. > > ff > > Dne 31.7.2012 14:15, LM_1 napsal(a): >> Nejsou systémy s tagováním bot/nobot moc komplikované? Co kdyby se bot >> podíval na autora poslední změny daného bodu a pokud by to byl on sám >> tak by ho upravil podle potřeby, pokud by to byl někdo jiný tak by jen >> vygeneroval upozornění. >> LM_1 > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Objízdné trasy (oražovými značkami vymezená trasa po existující > silnici, ne provizorně budované nové silnice) by nemělo být potřeba > zakreslovat, navigace by měla sama zvolit vhodnou objízdnou trasu. > Kudy vedou doporučené průjezdní trasy (ve větších městech) taky v mapě > není. A navigace často zvolí jinou trasu (třeba kratší přes město, > odkud má značená trasa odvést dopravu) > > Lukáš Matějka (LM_1) > > Dne 31. července 2012 15:11 Lukas Kohout<luko na luko.name> napsal(a): >> Zdravím, >> >> stále se v OSM rozkoukávám a nyní řeším, jak zpracovat poměrně zásadní >> dvouměsíční uzavírku I/38 v Kolíně. Viz >> http://www.mukolin.cz/cz/o-meste/06598-planovana-uzavirka-silnice-c-i-38-vjezd-do-kolina-od-kutne-hory.html >> . Vytvořit uzavírku (snad) umím. Dají se do mapy vložit i objízdné trasy, >> aby s nimi počítala navigace? Díky za případnou radu či nakopnutí směrem k >> tématu, kde se to již řešilo (zatím jsem nebyl v hledání úspěšný). >> >> LuKo >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Právě z důvodu, že jsou objížďky kvůli kamionům tak dlouhé (viz > http://www.mukolin.cz/prilohy/Zpravy/598/37dio_kolin_i_38_vedeni_objizd_tras.pdf), > jsem chtěl o nich dát vědět řidičům předem. Jeli by pak třeba rovnou po > Černokostelecké a zbytečně nezatěžovali již tak přetížené objízdné trasy. > Navigace sama může najít krátkou objížďku, která je příjezdová do pískovny a > jezdí tam těžké kamiony, avšak nyní tam bude omezení na 7 tun. > > LuKo > > > > > On 31.7.2012 22:54, LM_1 wrote: >> >> Objízdné trasy (oražovými značkami vymezená trasa po existující >> silnici, ne provizorně budované nové silnice) by nemělo být potřeba >> zakreslovat, navigace by měla sama zvolit vhodnou objízdnou trasu. >> Kudy vedou doporučené průjezdní trasy (ve větších městech) taky v mapě >> není. A navigace často zvolí jinou trasu (třeba kratší přes město, >> odkud má značená trasa odvést dopravu) >> >> Lukáš Matějka (LM_1) >> >> Dne 31. července 2012 15:11 Lukas Kohout<luko na luko.name> napsal(a): >>> >>> Zdravím, >>> >>> stále se v OSM rozkoukávám a nyní řeším, jak zpracovat poměrně >>> zásadní >>> dvouměsíční uzavírku I/38 v Kolíně. Viz >>> >>> http://www.mukolin.cz/cz/o-meste/06598-planovana-uzavirka-silnice-c-i-38-vjezd-do-kolina-od-kutne-hory.html >>> . Vytvořit uzavírku (snad) umím. Dají se do mapy vložit i objízdné trasy, >>> aby s nimi počítala navigace? Díky za případnou radu či nakopnutí směrem >>> k >>> tématu, kde se to již řešilo (zatím jsem nebyl v hledání úspěšný). >>> >>> LuKo >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Dalo by se uvažovat o posuzování jednotlivých argumentů (tagů, pozice) > individuálně (člověk posune - bot už hýbat nebude, ale klidně změní > číslo při přečíslování ulice nebo název při změně názvu) > > Změna ve zdrojových datech by mohla sloužit pro navrácení dané hodnoty > do správy botovi - když se změní hodnota ve zdrojových datech, > předpokládáme i změnu v realitě a tím zneplatnění původní lidské > úpravy. To by mělo vyloučit většinu soubojů mezi člověkem a strojem. > > Lukáš Matějka (LM_1) > > Dne 31. července 2012 14:44 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): >> o tomhle jsem taky uvažoval, má to ale jednu nevýhodu. neumožňuje to bod >> vrátit do správy botovi. stejně tak pokud by někdo jen přidal nějaký >> další tag k adresnímu bodu, tak by se bot taky přestal o ten bod starat, >> i když by se o něj měl starat dál. >> >> ff >> >> Dne 31.7.2012 14:15, LM_1 napsal(a): >>> Nejsou systémy s tagováním bot/nobot moc komplikované? Co kdyby se bot >>> podíval na autora poslední změny daného bodu a pokud by to byl on sám >>> tak by ho upravil podle potřeby, pokud by to byl někdo jiný tak by jen >>> vygeneroval upozornění. >>> LM_1 >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> ono by se to třeba i dalo nějak vymyslet, aby to fungovalo bez tagu, ale > postrádalo by to jednu důležitou vlastnost - jednoduchost. jednak bot by > se musel rozhodovat na základě složitějších pravidel než jen "bot=yes" > => můžu měnit, "bot=no" => nesahat, což by mohlo způsobovat > chyby/nedorozumnění/mylné předpoklady. a to samé by se týkalo i mapperů. > nikdo si nebude pamatovat složitá pravidla, na základě jakých se bot o > body stará. ale jednoduché pravidlo "bot=yes" => bot se o bod stará, > "bot=no" => bot na bod sahat nebude, pouze pošle info pro případný ruční > zásah, to si myslím z toho tagu vyplývá samo a i nový mapper bota > neznající by měl bez problému tenhle závěr z toho tagu vyvodit. > > píšu tu o tagu "bot", ale v praxi by to možná mohl být spíš tag > "ruian:bot=yes|no". z toho by bylo zřejmé, že tag se týká jen a pouze > bota, který pracuje nad rúian daty. stejně tak by asi mohl existovat tag > "ruian:id=<kod z ruian>" (jeho asi jediný přínos ale vidím v tom, že v > případě přejmenování ulice/změny čísla by se zachovala historie, jinak > pro fungování bota asi není nezbytný). nicméně zatím nevím, jak je to > přesně s custom tagy, sice jsem něco na osm wiki našel, ale nevyplynulo > mi z toho nějaké pravidlo nebo předepsaný postup. > > ff > > Dne 31.7.2012 23:00, LM_1 napsal(a): >> Dalo by se uvažovat o posuzování jednotlivých argumentů (tagů, pozice) >> individuálně (člověk posune - bot už hýbat nebude, ale klidně změní >> číslo při přečíslování ulice nebo název při změně názvu) >> >> Změna ve zdrojových datech by mohla sloužit pro navrácení dané hodnoty >> do správy botovi - když se změní hodnota ve zdrojových datech, >> předpokládáme i změnu v realitě a tím zneplatnění původní lidské >> úpravy. To by mělo vyloučit většinu soubojů mezi člověkem a strojem. >> >> Lukáš Matějka (LM_1) >> >> Dne 31. července 2012 14:44 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): >>> o tomhle jsem taky uvažoval, má to ale jednu nevýhodu. neumožňuje to bod >>> vrátit do správy botovi. stejně tak pokud by někdo jen přidal nějaký >>> další tag k adresnímu bodu, tak by se bot taky přestal o ten bod starat, >>> i když by se o něj měl starat dál. >>> >>> ff >>> >>> Dne 31.7.2012 14:15, LM_1 napsal(a): >>>> Nejsou systémy s tagováním bot/nobot moc komplikované? Co kdyby se bot >>>> podíval na autora poslední změny daného bodu a pokud by to byl on sám >>>> tak by ho upravil podle potřeby, pokud by to byl někdo jiný tak by jen >>>> vygeneroval upozornění. >>>> LM_1 >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Rozumím tomu, proč bych jako řidič chtěl vědět, kudy vede oficiální > objízdná trasa, ale co vím tak žádná navigace tuto možnost > nepodporuje.

> Vlastní tagy obecně nejsou problém, ale měly by být popsané. Určitě > bych byl pro zachování nějaké jednoznačné identifikace ruian:id nebo > ref:ruian, to je jedno. > Ty tagy pro bota se mi moc nelíbí proto, že nevypovídají nic o objektu > na kterém jsou a není to ani dočasné řešení jako bylo odbl=clean. > Srozumitelnost existujícího tagu pro neseznámené by asi byla jasná, > ale způsob způsob jak dojít od bodu který se mi občas někam chybně > přesune k tomu, že mám použít zvláštní tag už tak jasná není. Možá > bych volil kompromis, že by bot hlídal posledního autora (to by > nemuselo být tak složité) a nebo svůj bot=yes tag, který by při > editaci odstranil - stal by se posledním autorem a nebyl by už > potřeba. Nikomu by neutíkaly body.

> LM > > Dne 1. srpna 2012 0:56 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): >> ono by se to třeba i dalo nějak vymyslet, aby to fungovalo bez tagu, ale >> postrádalo by to jednu důležitou vlastnost - jednoduchost. jednak bot by >> se musel rozhodovat na základě složitějších pravidel než jen "bot=yes" >> => můžu měnit, "bot=no" => nesahat, což by mohlo způsobovat >> chyby/nedorozumnění/mylné předpoklady. a to samé by se týkalo i mapperů. >> nikdo si nebude pamatovat složitá pravidla, na základě jakých se bot o >> body stará. ale jednoduché pravidlo "bot=yes" => bot se o bod stará, >> "bot=no" => bot na bod sahat nebude, pouze pošle info pro případný ruční >> zásah, to si myslím z toho tagu vyplývá samo a i nový mapper bota >> neznající by měl bez problému tenhle závěr z toho tagu vyvodit. >> >> píšu tu o tagu "bot", ale v praxi by to možná mohl být spíš tag >> "ruian:bot=yes|no". z toho by bylo zřejmé, že tag se týká jen a pouze >> bota, který pracuje nad rúian daty. stejně tak by asi mohl existovat tag >> "ruian:id=<kod z ruian>" (jeho asi jediný přínos ale vidím v tom, že v >> případě přejmenování ulice/změny čísla by se zachovala historie, jinak >> pro fungování bota asi není nezbytný). nicméně zatím nevím, jak je to >> přesně s custom tagy, sice jsem něco na osm wiki našel, ale nevyplynulo >> mi z toho nějaké pravidlo nebo předepsaný postup. >> >> ff >> >> Dne 31.7.2012 23:00, LM_1 napsal(a): >>> Dalo by se uvažovat o posuzování jednotlivých argumentů (tagů, pozice) >>> individuálně (člověk posune - bot už hýbat nebude, ale klidně změní >>> číslo při přečíslování ulice nebo název při změně názvu) >>> >>> Změna ve zdrojových datech by mohla sloužit pro navrácení dané hodnoty >>> do správy botovi - když se změní hodnota ve zdrojových datech, >>> předpokládáme i změnu v realitě a tím zneplatnění původní lidské >>> úpravy. To by mělo vyloučit většinu soubojů mezi člověkem a strojem. >>> >>> Lukáš Matějka (LM_1) >>> >>> Dne 31. července 2012 14:44 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): >>>> o tomhle jsem taky uvažoval, má to ale jednu nevýhodu. neumožňuje to bod >>>> vrátit do správy botovi. stejně tak pokud by někdo jen přidal nějaký >>>> další tag k adresnímu bodu, tak by se bot taky přestal o ten bod starat, >>>> i když by se o něj měl starat dál. >>>> >>>> ff >>>> >>>> Dne 31.7.2012 14:15, LM_1 napsal(a): >>>>> Nejsou systémy s tagováním bot/nobot moc komplikované? Co kdyby se bot >>>>> podíval na autora poslední změny daného bodu a pokud by to byl on sám >>>>> tak by ho upravil podle potřeby, pokud by to byl někdo jiný tak by jen >>>>> vygeneroval upozornění. >>>>> LM_1 >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Dne 1.8.2012 01:08, LM_1 napsal(a): >> Vlastní tagy obecně nejsou problém, ale měly by být popsané. Určitě >> bych byl pro zachování nějaké jednoznačné identifikace ruian:id nebo >> ref:ruian, to je jedno. >> Ty tagy pro bota se mi moc nelíbí proto, že nevypovídají nic o objektu >> na kterém jsou a není to ani dočasné řešení jako bylo odbl=clean. >> Srozumitelnost existujícího tagu pro neseznámené by asi byla jasná, >> ale způsob způsob jak dojít od bodu který se mi občas někam chybně >> přesune k tomu, že mám použít zvláštní tag už tak jasná není. Možá >> bych volil kompromis, že by bot hlídal posledního autora (to by >> nemuselo být tak složité) a nebo svůj bot=yes tag, který by při >> editaci odstranil - stal by se posledním autorem a nebyl by už >> potřeba. Nikomu by neutíkaly body. > > jestli jsem to dobře pochopil, tak navrhuješ, že pro bota by znamenalo, > že se o bod má starat v případě, že buď je posledním editorem nebo je na > bodu tag "ruian:bot=yes". takže jakákoliv editace bodu by znamenala, že > se o něj bot přestane starat. pro navrácení bodu botovi by pak bylo > nutné přidat "ruian:bot=yes". to podle mě zní rozumně. sice to postrádá > tu úplnou jednoduchost, letmým pohledem není zřejmé, jestli se bot o ten > bod stará nebo ne (člověk musí znát pravidlo o posledním editorovi, což > většina mapperů asi vědět nebude), ale na druhou stranu mapper o botovi > nemusí vůbec vědět a i tak by vše mělo fungovat správně, tj pokud je bod > umístěný špatně, tak ho mapper zedituje a tím ho vyjme z kontroly bota. > jak ho vrátit botovi už vědět nebude, ale to se dá někde popsat (třeba v > tom mailu, který bude bot generovat). výhoda je určitě ta, že se u > většiny bodů nebudou osm data zanášet dalším tagem. akorát při prvotním > importu bude muset bot tohle pravidlo ignorovat, jinak by nic neudělal. > a před importem bude potřeba ručně otagovat body, které jsou v rúian > špatně umístěné, tagem "ruian:bot=no". > > ff > >> LM >> >> Dne 1. srpna 2012 0:56 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): >>> ono by se to třeba i dalo nějak vymyslet, aby to fungovalo bez tagu, ale >>> postrádalo by to jednu důležitou vlastnost - jednoduchost. jednak bot by >>> se musel rozhodovat na základě složitějších pravidel než jen "bot=yes" >>> => můžu měnit, "bot=no" => nesahat, což by mohlo způsobovat >>> chyby/nedorozumnění/mylné předpoklady. a to samé by se týkalo i mapperů. >>> nikdo si nebude pamatovat složitá pravidla, na základě jakých se bot o >>> body stará. ale jednoduché pravidlo "bot=yes" => bot se o bod stará, >>> "bot=no" => bot na bod sahat nebude, pouze pošle info pro případný ruční >>> zásah, to si myslím z toho tagu vyplývá samo a i nový mapper bota >>> neznající by měl bez problému tenhle závěr z toho tagu vyvodit. >>> >>> píšu tu o tagu "bot", ale v praxi by to možná mohl být spíš tag >>> "ruian:bot=yes|no". z toho by bylo zřejmé, že tag se týká jen a pouze >>> bota, který pracuje nad rúian daty. stejně tak by asi mohl existovat tag >>> "ruian:id=<kod z ruian>" (jeho asi jediný přínos ale vidím v tom, že v >>> případě přejmenování ulice/změny čísla by se zachovala historie, jinak >>> pro fungování bota asi není nezbytný). nicméně zatím nevím, jak je to >>> přesně s custom tagy, sice jsem něco na osm wiki našel, ale nevyplynulo >>> mi z toho nějaké pravidlo nebo předepsaný postup. >>> >>> ff >>> >>> Dne 31.7.2012 23:00, LM_1 napsal(a): >>>> Dalo by se uvažovat o posuzování jednotlivých argumentů (tagů, pozice) >>>> individuálně (člověk posune - bot už hýbat nebude, ale klidně změní >>>> číslo při přečíslování ulice nebo název při změně názvu) >>>> >>>> Změna ve zdrojových datech by mohla sloužit pro navrácení dané hodnoty >>>> do správy botovi - když se změní hodnota ve zdrojových datech, >>>> předpokládáme i změnu v realitě a tím zneplatnění původní lidské >>>> úpravy. To by mělo vyloučit většinu soubojů mezi člověkem a strojem. >>>> >>>> Lukáš Matějka (LM_1) >>>> >>>> Dne 31. července 2012 14:44 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): >>>>> o tomhle jsem taky uvažoval, má to ale jednu nevýhodu. neumožňuje to bod >>>>> vrátit do správy botovi. stejně tak pokud by někdo jen přidal nějaký >>>>> další tag k adresnímu bodu, tak by se bot taky přestal o ten bod starat, >>>>> i když by se o něj měl starat dál. >>>>> >>>>> ff >>>>> >>>>> Dne 31.7.2012 14:15, LM_1 napsal(a): >>>>>> Nejsou systémy s tagováním bot/nobot moc komplikované? Co kdyby se bot >>>>>> podíval na autora poslední změny daného bodu a pokud by to byl on sám >>>>>> tak by ho upravil podle potřeby, pokud by to byl někdo jiný tak by jen >>>>>> vygeneroval upozornění. >>>>>> LM_1 >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Uvažoval jsem přesně takto. > Není i dnes většina adresních bodů z importů? Ty ručně dělané budou > pravděpodobně správně... > LM

> Uvažoval jsem přesně takto.

> importů? Ty ručně dělané budou

> no, tady u nás je editorem bodů účet lpechacek, tak nevím, jestli to > importoval tenhle uživatel. > > ff > > Dne 1.8.2012 14:48, LM_1 napsal(a): > > Uvažoval jsem přesně takto. > > Není i dnes většina adresních bodů z importů? Ty ručně dělané budou > > pravděpodobně správně... > > LM >

> _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Otázka je, jak by měla vypadat ta připravená data. V případě importu > nových věcí tak, kde žádné nebyly, je to celkem primitivní. Ale mnohem > náročnější bude import do míst, kde již nějaká data jsou. Tam bude > třeba něco starého odstranit, něco modifikovat, něco přidat... Lze v > OSM formátu postihnout nějak všechny tyto typy změn (odstranění, > modifikace, přidání nových objektů)? A pokud lze, je možné to pak > nějak rozumně vizualizovat, aby to člověk mohl projít a rozhodovat > "tohle je ok, tohle zamítnu a zůstane při starém, tohle bude ještě > trochu jinak..." pomocí stávajících nástrojů? Nevím, jaké jsou > možnosti. > > Pokud nic vhodné stávajícího není, tak bych to viděl spíše na > interaktivní aplikaci, která zobrazí ty rozdíly ve vhodné podobě, u > každé umožní se rozhodnout, zda ponechat stará data, nová data, > automaticky zmergovat nebo ručně upravit. Ruční úpravu by ta aplikace > přímo nepodporovala, protože by to bylo příliš náročné (vlastně by > bylo třeba vytvořit obdobu editoru jako JOSM), ale poznačilo by to > nutnost ruční editace do dat nějakými tagy, aby výsledek, který z > aplikace vypadne, bylo možné otevřít např. v JOSM a ručně provést > potřebné úpravy. > > Např. u adresních bodů by bylo podle mě vhodné, aplikace provedla > nějaké "inteligentní" matchování adresních bodů v OSM a RUIAN, > zobrazovala původní a nový bod vizuálně propojený šipkou, jinak > vyznačené body, které jsou pouze v OSM a naopak jinak vyznačené body, > které jsou pouze v RUIAN. Uživatel by mohl vždy zvolit, zda ponechat > novou nebo starou polohu bodu (zde by bylo možné i volit vlastní > polohu - jde o primitivní úkon) atd. Nakonec by aplikace vytvořila OSM > patch, který by obsahoval požadované úpravy včetně vhodně zmergovaných > tagů (ty by možná bylo třeba také kontrolovat v aplikaci) atd. > > U budov to bude samozřejmě výrazně složitější. > > Obecně čistě ručního importu se celkem obávám. Dat je vetší než malé množství. > > Honza > > > Dne 27. července 2012 13:41 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): >> Dne 27.7.2012 13:20, Jan Bilak napsal(a): >>> Ahoj, >>> >>> teď z toho nechápu, zda si aplikaci představuješ jen jako evidenční >>> nebo zda aplikace má provádět vlastní import (resp. s ním výrazně >>> pomáhat). >> aplikace "pouze" připraví data z rúian, samotný import provede mapper. >> tj. aplikace pro import připraví data, ale nebude import provádět, ten >> se bude dělat ručně. i kdybychom (pokud vůbec, to vyplyne z ručních >> importů) v budoucnu uvažovali o nějaké automatizaci, tak v prvním kroku >> se to stejně musí udělat ručně, abychom věděli, nakolik je rúian >> spolehlivý zdroj, jaké problémy lze očekávat apod. pro kontinuální práci >> s daty z rúian je pak potřeba ta evidenční část. >> >>> Tedy za zásadní považuji porovnání současných OSM dat s daty RUIAN a >>> následné provedení změn (posuny stávajících bodů, opravy tagů, >>> zachování stávajících tagů, doplnění chybějících tagů, ...). >>> Samozřejmě s tím, že proces bude pod manuální kontrolou člověka, který >>> bude import provádět (tedy nikoli plně automatický, ale >>> poloautomatický). O těchto funkcích se v popisu nezmiňuješ. >> vycházel jsem hlavně z importu budov tam, kde je nemáme, to je asi ta >> nejjednodušší varianta. co se týče importu budov do míst, kde už nějaké >> jsou, nebo importu adresních bodů, tak se přiznám, že nevím, jestli v >> josm existují nástroje na zobrazení rozdílů ve vrstvách, na slučování >> objektů (a tagů) z různých vrstev apod. s tím zkušenosti nemám. ale >> určitě se tu najde někdo, kdo to vědět bude nebo aspoň bude vědět, kde >> hledat. >> >> ten můj nástřel je v podstatě (podle mě) asi to nejnutnější minimum pro >> to, aby se dala data z rúian využít pro manuální importy. nad tím potom >> lze dělat další nadstavby, které práci zjednoduší a zrychlí. něco určitě >> vyplyne i ze zkušeností se samotnými importy. >>> Honza >> ff >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 2012/7/31 LM_1 <flukas.robot+osm na gmail.com>: >> Rozumím tomu, proč bych jako řidič chtěl vědět, kudy vede oficiální >> objízdná trasa, ale co vím tak žádná navigace tuto možnost >> nepodporuje. > V Německu mají takové ty trvalé předpřipravené objízdné trasy, kde > beru, že asi dává smysl je mít v mapě nějak reprezentované. A vskutku: > http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Bedarfsumleitung > > Ale nejsem si jist, jestli dává nějaký velký smysl mapovat běžné ad > hoc objížďky, ani se nedivím navigacím, že takovou potřebu nemají.

> > -- Petr Kadlec / Mormegil > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> :) Zrovna jsem se chtěl ozvat. > > Za svojí prací si stojím, investoval jsem hodně úsilí do korektnosti importů. > Na druhou stranu vím, že některé importy nejsou až tak důkladně provedené. > > Nemám nic proti přepsání svých importů daty z RÚIAN, obsahově by měly být > totožná.

> > Libor > > On Wed 01-08-12 16:58:38, Miroslav Šulc wrote: >> no, tady u nás je editorem bodů účet lpechacek, tak nevím, jestli to >> importoval tenhle uživatel. >> >> ff >> >> Dne 1.8.2012 14:48, LM_1 napsal(a): >>> Uvažoval jsem přesně takto. >>> Není i dnes většina adresních bodů z importů? Ty ručně dělané budou >>> pravděpodobně správně... >>> LM > > >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >

> Já jsem pro hromadný import, případně následně pro vytvoření robota na údržbu. Minimálně u adresních bodů. > > MK

> > ----- Original Message ----- > From: hanoj [mailto:ehanoj na gmail.com] > To: > OpenStreetMap Czech Republic [mailto:talk-cz na openstreetmap.org] > Sent: Sat, > 28 Jul 2012 22:35:08 +0200 > Subject: Re: [Talk-cz] import budov > > >> Ja bych nadhodil nekolik otazek treba pro adresni body: > * Kolik je >> adresnich bodu? 2.500.000 > * Kolik mapperu se bude ucastnit takove prace? >> Prvni desitky. > * Jak dlouho to bude trvat? ... > > * Jaka cast dat by mela byt >> mappery pridavana tam kde nikdy nebyla? Vetsina. > * Jak budou uzivatele >> hodnotit (ne)kvalitu dat jiz v OSM? Na zaklade > dat CUZK a u par stovek bodu >> ze znalosti z terenu kde bydli.Tezko >> ale > suplovat: > http://www.cuzk.cz/GenerujSoubor.ashx?NAZEV=10-POROVNANIADRES > > Opravdu >> je individualni prace na vetsine uzemi republiky cesta, jak > data RUIAN >> dostat do OSM? > > h.anoj > > > Dne 27. července 2012 17:17 Miroslav Šulc >> <fordfrog na fordfrog.com> napsal(a): >> v souvislosti s tím co píšeš mě >> napadlo udělat to komplet jako josm >> plugin. tj. serverová část by >> zůstala tak jak jsem psal, ale všechno >> ostatní by se dělalo přímo z >> josm pluginu. ten by si stáhl data přes api >> ode mě ze serveru z >> aktuální databáze rúian, provedl by porovnání s >> datovou vrstvou z >> osm a vyhodil by nějaké info o rozdílech v osm a v >> rúian s tím, že >> mapper by si vybíral varianty a potvrzoval je, případně >> by sáhnul >> přímo do osm vrstvy a udělal úpravy tam. při uploadu změn do >> osm by >> se pak zapsalo i info ke mně na server o provedení importu. do >> pluginu >> by se pak dala přidávat funkcionalita dle potřeby. >> >> ff >> >> Dne >> 27.7.2012 14:18, Jan Bilak napsal(a): >>> Otázka je, jak by měla vypadat ta >> připravená data. V případě importu >>> nových věcí tak, kde žádné >> nebyly, je to celkem primitivní. Ale mnohem >>> náročnější bude import >> do míst, kde již nějaká data jsou. Tam bude >>> třeba něco starého >> odstranit, něco modifikovat, něco přidat... Lze v >>> OSM formátu >> postihnout nějak všechny tyto typy změn (odstranění, >>> modifikace, >> přidání nových objektů)? A pokud lze, je možné to pak >>> nějak >> rozumně vizualizovat, aby to člověk mohl projít a rozhodovat >>> "tohle >> je ok, tohle zamítnu a zůstane při starém, tohle bude ještě >>> trochu >> jinak..." pomocí stávajících nástrojů? Nevím, jaké jsou >> možnosti. >>> Pokud nic vhodné stávajícího není, tak bych to viděl >> spíše na >>> interaktivní aplikaci, která zobrazí ty rozdíly ve vhodné >> podobě, u >>> každé umožní se rozhodnout, zda ponechat stará data, >> nová data, >>> automaticky zmergovat nebo ručně upravit. Ruční úpravu >> by ta aplikace >>> přímo nepodporovala, protože by to bylo příliš >> náročné (vlastně by >>> bylo třeba vytvořit obdobu editoru jako JOSM), >> ale poznačilo by to >>> nutnost ruční editace do dat nějakými tagy, aby >> výsledek, který z >>> aplikace vypadne, bylo možné otevřít např. v >> JOSM a ručně provést >>> potřebné úpravy. >>> >>> Např. u adresních >> bodů by bylo podle mě vhodné, aplikace provedla >>> nějaké >> "inteligentní" matchování adresních bodů v OSM a RUIAN, >>> zobrazovala >> původní a nový bod vizuálně propojený šipkou, jinak >>> vyznačené >> body, které jsou pouze v OSM a naopak jinak vyznačené body, >>> které >> jsou pouze v RUIAN. Uživatel by mohl vždy zvolit, zda ponechat >>> novou >> nebo starou polohu bodu (zde by bylo možné i volit vlastní >>> polohu - >> jde o primitivní úkon) atd. Nakonec by aplikace vytvořila OSM >>> patch, >> který by obsahoval požadované úpravy včetně vhodně zmergovaných >> tagů (ty by možná bylo třeba také kontrolovat v aplikaci) atd. >>> U >> budov to bude samozřejmě výrazně složitější. >>> Obecně čistě >> ručního importu se celkem obávám. Dat je vetší než malé >> množství. >>> Honza >>> >>> >>> Dne 27. července 2012 13:41 Miroslav Šulc >> <fordfrog na fordfrog.com> napsal(a): >>>> Dne 27.7.2012 13:20, Jan Bilak >> napsal(a): >>>>> Ahoj, >>>>> >>>>> teď z toho nechápu, zda si aplikaci >> představuješ jen jako evidenční >>>>> nebo zda aplikace má provádět >> vlastní import (resp. s ním výrazně >>>>> pomáhat). >>>> aplikace "pouze" >> připraví data z rúian, samotný import provede mapper. >>>> tj. aplikace >> pro import připraví data, ale nebude import provádět, ten >>>> se bude >> dělat ručně. i kdybychom (pokud vůbec, to vyplyne z ručních >> importů) v budoucnu uvažovali o nějaké automatizaci, tak v prvním >> kroku >>>> se to stejně musí udělat ručně, abychom věděli, nakolik je >> rúian >>>> spolehlivý zdroj, jaké problémy lze očekávat apod. pro >> kontinuální práci >>>> s daty z rúian je pak potřeba ta evidenční >> část. >>>>> Tedy za zásadní považuji porovnání současných OSM >> dat s daty RUIAN a >>>>> následné provedení změn (posuny stávajících >> bodů, opravy tagů, >>>>> zachování stávajících tagů, doplnění >> chybějících tagů, ...). >>>>> Samozřejmě s tím, že proces bude pod >> manuální kontrolou člověka, který >>>>> bude import provádět (tedy >> nikoli plně automatický, ale >>>>> poloautomatický). O těchto funkcích >> se v popisu nezmiňuješ. >>>> vycházel jsem hlavně z importu budov tam, >> kde je nemáme, to je asi ta >>>> nejjednodušší varianta. co se týče >> importu budov do míst, kde už nějaké >>>> jsou, nebo importu adresních >> bodů, tak se přiznám, že nevím, jestli v >>>> josm existují nástroje >> na zobrazení rozdílů ve vrstvách, na slučování >>>> objektů (a tagů) >> z různých vrstev apod. s tím zkušenosti nemám. ale >>>> určitě se tu >> najde někdo, kdo to vědět bude nebo aspoň bude vědět, kde >> hledat. >>>> ten můj nástřel je v podstatě (podle mě) asi to >> nejnutnější minimum pro >>>> to, aby se dala data z rúian využít pro >> manuální importy. nad tím potom >>>> lze dělat další nadstavby, které >> práci zjednoduší a zrychlí. něco určitě >>>> vyplyne i ze zkušeností >> se samotnými importy. >>>>> Honza >> ff > _______________________________________________ > Talk-cz mailing >> list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Dne 2.8.2012 10:54, Libor Pechacek napsal(a): > > :) Zrovna jsem se chtěl ozvat. > > > > Za svojí prací si stojím, investoval jsem hodně úsilí do korektnosti importů. > > Na druhou stranu vím, že některé importy nejsou až tak důkladně provedené. > > > > Nemám nic proti přepsání svých importů daty z RÚIAN, obsahově by měly být > > totožná. > > Tim bych si nebyl tak jisty ... ;D, opakovane sem narazel na spatne > nazvy ulic (u importovanych adres) - v tom smyslu, ze tam byly zkratky, > blbe mala/velka pismena, pripadne nekde byly pouzity starsi nez aktualni > nazvy ...

> Zkratky a neaktuální názvy jdou na účet MVČR, nesprávně malá/velká písmena jsou > chybou importovacího softwaru. Sice jsem software opravil, ale původní názvy > už v mapě zůstaly. ;)

> ony ty registry občas taky obsahují blbosti. Můj oblíbený příklad je KÚ > z UIR-ZSJ jménem "Krupá u Kostelce nad Černýni Lesy" ;-)

>> Já jsem pro hromadný import, případně následně pro vytvoření robota na údržbu. Minimálně u adresních bodů. >> >> MK > > A dopadne to jako potoky, ktery nejsou spraveny doted.

>> ony ty registry občas taky obsahují blbosti. Můj oblíbený příklad je KÚ >> z UIR-ZSJ jménem "Krupá u Kostelce nad Černýni Lesy" ;-) > *** to neni blbost, to je fakt. KU maji unikatni nazvy napric CR.

>>> Já jsem pro hromadný import, případně následně pro vytvoření robota na údržbu. Minimálně u adresních bodů. >>> >>> MK >> >> A dopadne to jako potoky, ktery nejsou spraveny doted. > *** Jestli si mam vybrat mezi: > * rucne s chybami=nikdy > * import s chybami=letos > > tak vyber je jasnej.... > > h. > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Ja si myslim, ze se automatizovanemu importu nevyhneme. Tohle fakt rucne > delat asi nejde :) > > K > > Dne 2.8.2012 15:18, hanoj napsal(a): > >>>> Já jsem pro hromadný import, případně následně pro vytvoření robota na >>>> údržbu. Minimálně u adresních bodů. >>>> >>>> MK >>> >>> >>> A dopadne to jako potoky, ktery nejsou spraveny doted. >> >> *** Jestli si mam vybrat mezi: >> * rucne s chybami=nikdy >> * import s chybami=letos >> >> tak vyber je jasnej.... >> >> h. >> hanoj >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Dne 1.8.2012 10:32, Petr Kadlec napsal(a): >> 2012/7/31 LM_1 <flukas.robot+osm na gmail.com>: >>> Rozumím tomu, proč bych jako řidič chtěl vědět, kudy vede oficiální >>> objízdná trasa, ale co vím tak žádná navigace tuto možnost >>> nepodporuje. >> V Německu mají takové ty trvalé předpřipravené objízdné trasy, kde >> beru, že asi dává smysl je mít v mapě nějak reprezentované. A vskutku: >> http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Bedarfsumleitung >> >> Ale nejsem si jist, jestli dává nějaký velký smysl mapovat běžné ad >> hoc objížďky, ani se nedivím navigacím, že takovou potřebu nemají. > > Tohle uz se tu taky tusim nekdy resilo. OSM je navrhovana na trvale > platne mapovani, aktualne nema zadnou "vrstvu" s docasnymi daty, coz by > prave podobny veci pokryvalo. > Chtelo by to podobnou vrstvu nad temi daty, ktera by nebyla beznou > soucasti dat, a kazdy zaznm by tam mel nejak omezenou platnost (od:do), > a po skonceni platnosti se sam vyhodil. > > Silnici lze sice zavrit, ale stejne si to sosne jen minimum navigaci, > specielne pokud je to opravdu jen kratkodoby (14dnu ...). Kdyby > existovala da docasna vrstva, tak jelikoz bude mit radove min dat, daj > se aktualizace sosat i pres nase uzasne FUPy (a navic by se do toho daly > ladovat nejspis i data o nehodach ...).

> Ja si myslim, ze se automatizovanemu importu nevyhneme. Tohle fakt rucne > delat asi nejde :) > > ...

> Dne 2. srpna 2012 13:29 jzvc <jzvc na tpfree.net> napsal(a): >> Dne 1.8.2012 10:32, Petr Kadlec napsal(a): >>> 2012/7/31 LM_1 <flukas.robot+osm na gmail.com>: >>>> Rozumím tomu, proč bych jako řidič chtěl vědět, kudy vede oficiální >>>> objízdná trasa, ale co vím tak žádná navigace tuto možnost >>>> nepodporuje. >>> V Německu mají takové ty trvalé předpřipravené objízdné trasy, kde >>> beru, že asi dává smysl je mít v mapě nějak reprezentované. A vskutku: >>> http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Bedarfsumleitung >>> >>> Ale nejsem si jist, jestli dává nějaký velký smysl mapovat běžné ad >>> hoc objížďky, ani se nedivím navigacím, že takovou potřebu nemají. >> >> Tohle uz se tu taky tusim nekdy resilo. OSM je navrhovana na trvale >> platne mapovani, aktualne nema zadnou "vrstvu" s docasnymi daty, coz by >> prave podobny veci pokryvalo. >> Chtelo by to podobnou vrstvu nad temi daty, ktera by nebyla beznou >> soucasti dat, a kazdy zaznm by tam mel nejak omezenou platnost (od:do), >> a po skonceni platnosti se sam vyhodil. >> >> Silnici lze sice zavrit, ale stejne si to sosne jen minimum navigaci, >> specielne pokud je to opravdu jen kratkodoby (14dnu ...). Kdyby >> existovala da docasna vrstva, tak jelikoz bude mit radove min dat, daj >> se aktualizace sosat i pres nase uzasne FUPy (a navic by se do toho daly >> ladovat nejspis i data o nehodach ...). > > Dočasně by šlo mapovat les. Teď je to mýtina, za 3 roky hustník, > po dalších X letech les (jde zjistit statisticky?). Po vykácení stejné > části lesa někdo oblast resetuje na mýtinu... Předpokládám, že se > nekácí náhodné kusy lesa? > > F. > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> V celem Liberci to bylo take uplne stejne posunute nahoodne o nekolik domu, > ale pritom korektne otagovane. Mnoho desitek adres jsem tehdy opravoval > rucne, kdyz jsem na to narazil. > > JB > > Dne 2.8.2012 16:35 "LM_1" <flukas.robot+osm na gmail.com> napsal/a: > > O jakých chybách se tady bavíme? V Brně bylo spostu adresních bodů > pěkně vyplněných, ale posunutých o třy čtyři domy vedle. Pro > navigaci > lepší než nic, ale pro opravy celkem peklo (navíc oproti prázdnotě > hledání původního bodu). > LM > > Dne 2. srpna 2012 16:20 Jakub Sykora <kubajz na kbx.cz> napsal(a): > > > Ja si myslim, ze se automatizovanemu importu nevyhneme. Tohle fakt rucne > > delat asi nejde :) > > > > ... >

> Předpokládám, že tehdy při importu UIR-ADR nikdo chybu při převodu JTSK>WGS84 neřešil. :-) > > http://grass.fsv.cvut.cz/wiki/images/c/c6/Dopnul_wgs84_jtsk_xyerr.png > > MK

> O jakých chybách se tady bavíme? V Brně bylo spostu adresních bodů > pěkně vyplněných, ale posunutých o třy čtyři domy vedle. Pro navigaci > lepší než nic, ale pro opravy celkem peklo (navíc oproti prázdnotě > hledání původního bodu). > LM

> Dne 2. srpna 2012 16:20 Jakub Sykora <kubajz na kbx.cz> napsal(a): >> Ja si myslim, ze se automatizovanemu importu nevyhneme. Tohle fakt rucne >> delat asi nejde :) >> >> K >> >> Dne 2.8.2012 15:18, hanoj napsal(a): >> >>>>> Já jsem pro hromadný import, případně následně pro vytvoření robota na >>>>> údržbu. Minimálně u adresních bodů. >>>>> >>>>> MK >>>> >>>> A dopadne to jako potoky, ktery nejsou spraveny doted. >>> *** Jestli si mam vybrat mezi: >>> * rucne s chybami=nikdy >>> * import s chybami=letos >>> >>> tak vyber je jasnej.... >>> >>> h. >>> hanoj >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Ja vam tady do toho lehce vstoupim - moje predstava, jak by to mohlo > docela pekne fungovat = upravit soucasny tracer plugin, a to tak, ze > nebude trasovat z bitmapy, ale veme vektor/body. > > => zdroj zi zobrazim jako podklad, a pokud klipnu "do budovy", tak ji to > bafne a vlozi do aktivniho layeru. Melo by to samo mit funkci "merge" => > pokud chci slucovat, melo by jit nastavit zda poloha bude stavajici nebo > ze zdroje + to drapne vsechny stavajici tagy + to samo prida IDcko ze > zdroje a omarkuje pokud je poloha z OSM (aby se to v pripade zmeny ve > zdroji nemenilo). Tohle by melo fungovat tak, ze klipnu (vyberu) dva > objekty stejnyho typu a on je automaticky podle danych pravidel slouci. > > Zjistovani rozdilu = vemu objekty danyho typu v danym boxu a podivam se, > zda mam v OSM vsechny objekty danyho typu s danym ID. Ty co tam nejsou > vyrenderuju jako rozdil. > Dale u tech co tam jsou overim, zda maji stejne souradnice (a pripadne > dalsi parametry) jako ve zdroji (pokud ne = rozdil), pripadne zda sou > oznaceny (= v RUIAN je blbost). > Pokud to bude v podobe podkladu (trebas vrstva toho WMS generovanyho z > RUIAN), tak se da velmi snadno a rychle najit kde co chybi. Melo by to > mit nejakou moznost zpetne prohlasit ze v RUIAN je blbost, a takovej > objekt by se neresil, dokud nebude v RUIAN zmenen (pripadne by to mohla > byt dalsi vrstva). > > Ad adresni body - me osobne se nelibi, protoze jak uz sem psal vejs, > pokud ma budova definovany vchody, da se navigovat ke vchodu i z jiny > ulice nez te, kde ma adresu. Pokud je tam bod, tak kazda navigace povede > do ulice, kam ta adresa patri. Dovedu si to predstavit prave pro > oznaceni mist, kde z nejakyho duvodu budova neni, neni tam digitalini > km, ... protoze tam budovy neni moc jak vykreslit. > > V takovym pripade bych si asi doved predstavit, ze (v ramci upraveneho > pluginu) vyberu trebas nejaky box a prohlasim ze do nej chci vlozit > vsechny adresni body ze zdroje. S matchovanim to asi bude vselijaky, neb > sem svyho casu podobny veci delal, uspesnost asi nepreleze 80 - 85%. Ale > opet, lze renederovat nejaky rozdil, a postupne se to da dokupy. Hlavne > musi byt nekde videt co kde chybi. > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

> Dobrý nápad, jenže pokud budu chtít zmapovat budovy v celém městě/vesnici, > kde zatím vůbec žádné nejsou, bude to stále ještě hodně pracné. Nebylo by > pro tyto případy lepší provést tento import podobně jako import UIR-ZSJ? > Pomocí skriptu by se vytvořil .osm soubor obsahující budovy z RÚIAN z daného > katastru. Otevřel by se v JOSM jako nová vrstva. Tato vrstva by se porovnala > s jinými zdroji a nesrovnalosti by se ručně opravily. Soubor by se uložil a > dalším skriptem (který by doplnil source=ruian apod.) poslal do databáze > OSM. > O programování toho ale moc nevím, takže možná navrhuju něco, co není > prakticky proveditelné. > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Dne 2.8.2012 16:34, LM_1 napsal(a): > > O jakých chybách se tady bavíme? V Brně bylo spostu adresních bodů > > pěkně vyplněných, ale posunutých o třy čtyři domy vedle. Pro navigaci > > lepší než nic, ale pro opravy celkem peklo (navíc oproti prázdnotě > > hledání původního bodu). > > LM > > To je presne o cem se bavime, ze se tam naimportuje hromada dat, ktery > nikdy nikdo neopravi - naprosto totez jako aktualne zmena licence, to > nikdy nikdo neopravi, protoze se to nijak rozumne opravit neda. je totiz > daleko jednodussi mapovat prazdny misto nez opravovat ho. A neni to samo > jen posun, chyb tam bude IMO celkem hromada (sak je to registr ala CR). > > Takze ja sem radsi pro poloprazdnou, ale spravnou mapu, nez pro mapu > stejne blbou, jako vsechny ostatni.

> Martin Kokeš wrote: > > Předpokládám, že tehdy při importu UIR-ADR nikdo chybu při převodu > JTSK>WGS84 neřešil. :-) > > > > http://grass.fsv.cvut.cz/wiki/images/c/c6/Dopnul_wgs84_jtsk_xyerr.png > > > > MK > > Ahoj, > > to jsou odchykly v centimetrech, ne? To je/bylo pro import adresních > bodů celkem irrelevantní. > U importu budov už by možná mělo smysl přemýšlet nad přesnější > transformací s nadgrids=czech. Na některých místech by ten necelý metr > už mohl být znát, ale i tak by to asi nebyla žádná velká tragédie. > > Petr >

> Bohužel v metrech. :-) Např. Pardubice cca 20 metrů SV-JZ. > > MK

> Martin Kokeš wrote: > > Bohužel v metrech. :-) Např. Pardubice cca 20 metrů SV-JZ. > > > > MK > > Určitě? V porovnání s čím? > Sice mám v tomhle směru fakt limitované znalosti, ale když jsem stáhnul > grid [1] a zkusil transformovat pár bodů z Ostravska, tak se výsledek > oproti definici [2] lišil cca o 0.5m (plus opačná znaménka). > > Petr > > [1] http://grass.fsv.cvut.cz/wiki/index.php/S-JTSK-Grid > [2] http://spatialreference.org/ref/sr-org/czech-s-jtsk-epsg2065/proj4/ > >

> S tou sedmiprvkovou transformací je to samozřejmě přesnější. Jde o to, jestli byla při > importu UIR-ADR použita... :-)

> Blbost to je, i když snadno přehlédnutelná, diffni si tyhle dva řetězce: > > Krupá u Kostelce nad Černýni Lesy > Krupá u Kostelce nad Černými lesy

> Dne 2.8.2012 13:19, jzvc napsal(a): > > Ja vam tady do toho lehce vstoupim - moje predstava, jak by to mohlo > docela pekne fungovat = upravit soucasny tracer plugin, a to tak, ze > nebude trasovat z bitmapy, ale veme vektor/body. > > => zdroj zi zobrazim jako podklad, a pokud klipnu "do budovy", tak ji to > bafne a vlozi do aktivniho layeru. Melo by to samo mit funkci "merge" => > pokud chci slucovat, melo by jit nastavit zda poloha bude stavajici nebo > ze zdroje + to drapne vsechny stavajici tagy + to samo prida IDcko ze > zdroje a omarkuje pokud je poloha z OSM (aby se to v pripade zmeny ve > zdroji nemenilo). Tohle by melo fungovat tak, ze klipnu (vyberu) dva > objekty stejnyho typu a on je automaticky podle danych pravidel slouci. > > Zjistovani rozdilu = vemu objekty danyho typu v danym boxu a podivam se, > zda mam v OSM vsechny objekty danyho typu s danym ID. Ty co tam nejsou > vyrenderuju jako rozdil. > Dale u tech co tam jsou overim, zda maji stejne souradnice (a pripadne > dalsi parametry) jako ve zdroji (pokud ne = rozdil), pripadne zda sou > oznaceny (= v RUIAN je blbost). > Pokud to bude v podobe podkladu (trebas vrstva toho WMS generovanyho z > RUIAN), tak se da velmi snadno a rychle najit kde co chybi. Melo by to > mit nejakou moznost zpetne prohlasit ze v RUIAN je blbost, a takovej > objekt by se neresil, dokud nebude v RUIAN zmenen (pripadne by to mohla > byt dalsi vrstva). > > Ad adresni body - me osobne se nelibi, protoze jak uz sem psal vejs, > pokud ma budova definovany vchody, da se navigovat ke vchodu i z jiny > ulice nez te, kde ma adresu. Pokud je tam bod, tak kazda navigace povede > do ulice, kam ta adresa patri. Dovedu si to predstavit prave pro > oznaceni mist, kde z nejakyho duvodu budova neni, neni tam digitalini > km, ... protoze tam budovy neni moc jak vykreslit. > > V takovym pripade bych si asi doved predstavit, ze (v ramci upraveneho > pluginu) vyberu trebas nejaky box a prohlasim ze do nej chci vlozit > vsechny adresni body ze zdroje. S matchovanim to asi bude vselijaky, neb > sem svyho casu podobny veci delal, uspesnost asi nepreleze 80 - 85%. Ale > opet, lze renederovat nejaky rozdil, a postupne se to da dokupy. Hlavne > musi byt nekde videt co kde chybi. > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > Dobrý nápad, jenže pokud budu chtít zmapovat budovy v celém městě/vesnici, > kde zatím vůbec žádné nejsou, bude to stále ještě hodně pracné. Nebylo by > pro tyto případy lepší provést tento import podobně jako import UIR-ZSJ? > Pomocí skriptu by se vytvořil .osm soubor obsahující budovy z RÚIAN z daného > katastru. Otevřel by se v JOSM jako nová vrstva. Tato vrstva by se porovnala > s jinými zdroji a nesrovnalosti by se ručně opravily. Soubor by se uložil a > dalším skriptem (který by doplnil source=ruian apod.) poslal do databáze > OSM. > O programování toho ale moc nevím, takže možná navrhuju něco, co není > prakticky proveditelné. > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Dne 3. srpna 2012 1:07 Martin Kokeš <shr3k na typo3-hosting.com> napsal(a): > > S tou sedmiprvkovou transformací je to samozřejmě přesnější. Jde o > to, jestli byla při > importu UIR-ADR použita... :-)

> podle přesnosti (WGS84/ERTS89->S-JTSK) 2D:

> severozápad - základní sedmiprvková transformace

> klíče; nepoužívá se

> transformačního klíče

> klíč pro ČR/SR

> článek

> mailing > list

> Ooops, myšleno sedmikoeficientová (prostě těch 7 toWGS čísel), občas se mi to plete.

> Druhy transformací >> podle přesnosti (WGS84/ERTS89->S-JTSK) 2D: > > * 100-110 metrů na >> severozápad - základní sedmiprvková transformace > bez transformačního >> klíče; nepoužívá se > * < 1 metr - základní navíc s parametry >> transformačního klíče > "towgs"; viz níže globální transformační >> klíč pro ČR/SR > * < 0,1 metr - pomocí gridu (ČR); zvláštní >> článek

> Postup - rozdělit podle katastrů, velké katastry klidně ještě na pár > částí a ty pak postupně ručně importovat je určitě lepší, než hromadný > import.

> Když budou data někde k dispozici + stránka na wiki, za pár > měsíců uživatelé naimportují své okolí a pak se ukáže, co zbývá a > uvidí se, co s tím zbytkem.

>> Postup - rozdělit podle katastrů, velké katastry klidně ještě na pár >> částí a ty pak postupně ručně importovat je určitě lepší, než hromadný >> import. > *** napred rucne a pak import - zda se mi to jako komplikace pro > cloveka pracujiciho s importem navic. Uz tak dost je to slozite a > nevidim tam prinos toho jednotlivce. Uz z koordinace UIR-ADR je zrejme > ze samotna domluva je slozita: > http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR > > >> Když budou data někde k dispozici + stránka na wiki, za pár >> měsíců uživatelé naimportují své okolí a pak se ukáže, co zbývá a >> uvidí se, co s tím zbytkem. > *** kolik si z tech 13 000 k.u. beres? ;) > Uzivatelske zpracovani UIR-ADR bylo po okresech a dosud neni kompletni... > http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR > > ha > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Dne 1.8.2012 10:32, Petr Kadlec napsal(a): > > 2012/7/31 LM_1 <flukas.robot+osm na gmail.com>: > >> Rozumím tomu, proč bych jako řidič chtěl vědět, kudy vede oficiální > >> objízdná trasa, ale co vím tak žádná navigace tuto možnost > >> nepodporuje. > > V Německu mají takové ty trvalé předpřipravené objízdné trasy, kde > > beru, že asi dává smysl je mít v mapě nějak reprezentované. A vskutku: > > http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Bedarfsumleitung > > > > Ale nejsem si jist, jestli dává nějaký velký smysl mapovat běžné ad > > hoc objížďky, ani se nedivím navigacím, že takovou potřebu nemají. > > Tohle uz se tu taky tusim nekdy resilo. OSM je navrhovana na trvale > platne mapovani, aktualne nema zadnou "vrstvu" s docasnymi daty, coz by > prave podobny veci pokryvalo. > Chtelo by to podobnou vrstvu nad temi daty, ktera by nebyla beznou > soucasti dat, a kazdy zaznm by tam mel nejak omezenou platnost (od:do), > a po skonceni platnosti se sam vyhodil. > > Silnici lze sice zavrit, ale stejne si to sosne jen minimum navigaci, > specielne pokud je to opravdu jen kratkodoby (14dnu ...). Kdyby

> existovala da docasna vrstva, tak jelikoz bude mit radove min dat, daj > se aktualizace sosat i pres nase uzasne FUPy (a navic by se do toho daly > ladovat nejspis i data o nehodach ...).

> Dne 29.7.2012 10:16, Martin Kokeš napsal(a): > > Já jsem pro hromadný import, případně následně pro vytvoření robota na údržbu. Minimálně u adresních bodů. > > > > MK > > A dopadne to jako potoky, ktery nejsou spraveny doted.

> On Thu 2012-08-02 13:41:03, jzvc wrote: >> Dne 29.7.2012 10:16, Martin Kokeš napsal(a): >>> Já jsem pro hromadný import, případně následně pro vytvoření robota na údržbu. Minimálně u adresních bodů. >>> >>> MK >> A dopadne to jako potoky, ktery nejsou spraveny doted. > Mozna je to nepopularni nazor, ale od importu potoku se stala osm *o > hodne* pouzitelnejsi. > > Skript ktery najde krizici-se vodni toky by nemel byt problem... > Pavel

>> A dopadne to jako potoky, ktery nejsou spraveny doted. > > Mozna je to nepopularni nazor, ale od importu potoku se stala osm *o > hodne* pouzitelnejsi.

>> Postup - rozdělit podle katastrů, velké katastry klidně ještě na pár >> částí a ty pak postupně ručně importovat je určitě lepší, než hromadný >> import. > *** napred rucne a pak import - zda se mi to jako komplikace pro > cloveka pracujiciho s importem navic. Uz tak dost je to slozite a > nevidim tam prinos toho jednotlivce. Uz z koordinace UIR-ADR je zrejme > ze samotna domluva je slozita: > http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR > > >> Když budou data někde k dispozici + stránka na wiki, za pár >> měsíců uživatelé naimportují své okolí a pak se ukáže, co zbývá a >> uvidí se, co s tím zbytkem. > *** kolik si z tech 13 000 k.u. beres? ;) > Uzivatelske zpracovani UIR-ADR bylo po okresech a dosud neni kompletni... > http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR

> > ha > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Dne 3.8.2012 10:41, hanoj napsal(a): >>> Postup - rozdělit podle katastrů, velké katastry klidně ještě na pár >>> částí a ty pak postupně ručně importovat je určitě lepší, než hromadný >>> import. >> *** napred rucne a pak import - zda se mi to jako komplikace pro >> cloveka pracujiciho s importem navic. Uz tak dost je to slozite a >> nevidim tam prinos toho jednotlivce. Uz z koordinace UIR-ADR je zrejme >> ze samotna domluva je slozita: >> http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR >> >> >>> Když budou data někde k dispozici + stránka na wiki, za pár >>> měsíců uživatelé naimportují své okolí a pak se ukáže, co zbývá a >>> uvidí se, co s tím zbytkem. >> *** kolik si z tech 13 000 k.u. beres? ;) >> Uzivatelske zpracovani UIR-ADR bylo po okresech a dosud neni kompletni... >> http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR > > Problem = nevizualnost. Ja taky nebudu zkoumat 100x nejakou stranku na > wiki, a sacovat X strankovej seznam ... na to se kazdej vybodne. Je > treba, aby to bylo videt na mape => uzemi kde je hotovo, uzemi kde neni, > uzemi ktery je treba kontrolovat ... to se samo netyce jen tohoto, ale > veskerych importu. Pokud by byla k dispozici mapka, kde budou prubezne > mizet zpracovana uzemi, tak to kazdej jednim mrknutim zkoukne.