Re: [Talk-cz] Please, consider ... CC-BY-SA compatible - Was: Pěkná kupka práce
On Wednesday 25 July 2012 13:55:02 Václav Řehák wrote: Naprosto souhlasím se vším uvedeným v tvém mailu. Vedena (možná) dobrými úmysly provedla OSMF přelicencování hodně špatným způsobem a ukázala, že se nezajímá o názor komunity. To považuju za vážné zjištění. Řešením by mohl být FOSM fork, ale nejsem si jistý, zda je to životaschopný projekt, proto se skřípěním zubů pokračuji v editacích hlavní db a čekám, jak to celé dopadne. Zdravím všechny, vzhledem k tomu, že můj názor byl na tomto listu přijatý vcelku pozitivně/bez vyslovení výhrad, tak jsem zase po měsících zkusil jestli někdo z OSMF odpoví na příspěvek do legal-talk. http://lists.openstreetmap.org/pipermail/legal-talk/2012-July/007173.html Zároveň zítra odjíždím na dovolenou, takže se případně na diskuzi na legal-talk občas podívejte a vyjádřete svůj názor. S přáním příjemného prožití léta, Pavel Píša ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Please, consider ... CC-BY-SA compatible - Was: Pěkná kupka práce
Dne 27. července 2012 8:38 Pavel Pisa ppisa4li...@pikron.com napsal(a): On Wednesday 25 July 2012 13:55:02 Václav Řehák wrote: Naprosto souhlasím se vším uvedeným v tvém mailu. Vedena (možná) dobrými úmysly provedla OSMF přelicencování hodně špatným způsobem a ukázala, že se nezajímá o názor komunity. To považuju za vážné zjištění. Řešením by mohl být FOSM fork, ale nejsem si jistý, zda je to životaschopný projekt, proto se skřípěním zubů pokračuji v editacích hlavní db a čekám, jak to celé dopadne. Zdravím všechny, vzhledem k tomu, že můj názor byl na tomto listu přijatý vcelku pozitivně/bez vyslovení výhrad, tak jsem zase po měsících zkusil jestli někdo z OSMF odpoví na příspěvek do legal-talk. http://lists.openstreetmap.org/pipermail/legal-talk/2012-July/007173.html Zároveň zítra odjíždím na dovolenou, takže se případně na diskuzi na legal-talk občas podívejte a vyjádřete svůj názor. *** No ja premyslim, jak jinak slo prelicencovat a nez neprelicencovavat (coz prosazoval Pavel Machek). Pro mne je ODbL vyrazny prinos jiz ted. *** Dualni licencovani je hezke v teorii, ale praxi ukazal licencni BOT, nebot jednu licenci je pro vysledek treba zvolit. *** Krome ODbL a Public Domain neznam zadne geograficko/databazove licence toho typu jako maji tradici ve FOSS GNU GPL, MIT, Apache. *** Obavy z obohacovani na ukor komunity moc nerozumim, protoze licence ODbL umoznuje komercni pristup. *** Komunikace s OSMF mohla byt lepsi to snad ano, ale realna predstava komunikace set tisicu uzivatelu mi unika, rad se necham informovat o zkusenostech odjinud. *** Jeste mi neni zcela zrejmy problem CT, muze nekdo vysvetlit? PS: Zmena licence trva uz vice nez 2 roky, skoro polovinu trvani projektu ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] import budov
já jsem nad tím ješte( vc(era pr(emýšlel, a dospe(l jsem k tomuhle: * aplikace by me(la umožn(ovat nejen jednorázový import, ale i následné aktualizace podle zme(n v rúian * evidence prováde(ní importu* by me(la být souc(ástí aplikace tak, aby se na ní nezapomínalo, souc(asne( by me(la být co nejjednodušší * z aplikace by me(lo být zr(ejmé, co už je hotové a co ješte( ne, pr(ípadne( kde jsou ne(jaké zme(ny v rúian * aplikace by me(la fungovat naprosto samostatne(, bez nutnosti ne(jaké obsluhy takhle ne(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 pr(ípadne( 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 ne(jakým zme(nám + možnost filtrování (okres, stav importu, název kú) - v pr(ípade( budov by aplikace zobrazovala jen kú, kde je definovaný obrys alespon( jedné budovy * v aplikaci by se evidovalo, kdo a kdy jaký soubor naimportoval do osm + poznámky k importu * aplikace by umožn(ovala sledovat zme(ny v rúian (tj. pokud ne(kdo stáhne a naimportuje ne(jaké budovy do osm, tak info zanese do aplikace, aplikace pak bude ve(de(t, že k danému datu jsou budovy naimportované a umožní pr(íšte( vyexportovat pouze rozdíl mezi posledním naimportovaným stavem a souc(asným stavem v rúian) a exportovat pouze zme(ny (vc(etne( informace o odstrane(ných objektech) * z aplikace také bude zr(ejmé, kdo zrovna na c(em de(lá * aplikace by mohla také zobrazovat historii importu* (tj. kdo, kdy a co), kdo má co rozde(lané a jak dlouho, kolik toho zbývá naimportovat apod. pr(emýšlel jsem o tom, jak por(ešit, aby nebylo nutné se do aplikace registrovat a souc(asne( zajistit urc(itou míru autorizace pr(i zadávání informací o provedení importu a napadlo me( následující: 1) když si budu chtít stáhnout data z urc(itého kú, tak si to kú vyhledám, zadám svu*j mail a jestli chci komplet soubor nebo rozdílový soubor a aplikace mi soubor pošle na mail, vc(etne( 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ár(, já tam zadám poznámky k importu a odešlu 4) systém si informace spáruje s pr(edchozím exportem a bude ve(de(t, že až po urc(ité datum jsou budovy naimportované, takže bude moct jednoduše sledovat rozdíly máte k tomu ne(kdo ne(jaké pr(ipomínky nebo podne(ty? pak mám ješte( jeden technický dotaz. tušíte ne(kdo, jak pr(evést data z postgis geometry do osm formátu? s body pr(edpokládám problém nebude, ale netuším, jak s polygony. rúian se neomezuje jen na c(áry, takže tam asi bude nutné provést ne(jakou konverzi. ideální by byla ne(jaká knihovna, která vezme postgis geometry a ude(lá z ní osm xml. zkoušel jsem ne(co vygooglovat, ale asi jsem zadával špatná klíc(ová slova. ff Dne 26.7.2012 08:50, Zdene(k Pražák napsal(a): 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 fordf...@fordfrog.com mailto:fordf...@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 fordf...@fordfrog.com mailto:fordf...@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
Re: [Talk-cz] import budov
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. července 2012 13:05 Miroslav Šulc fordf...@fordfrog.com napsal(a): 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 fordf...@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 fordf...@fordfrog.com Předmět: Re: [Talk-cz] rúian mapy -
Re: [Talk-cz] import budov
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 smime.p7s Description: Elektronicky podpis S/MIME ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Please, consider ... CC-BY-SA compatible - Was: Pěkná kupka práce
Komunikace s OSMF mohla byt lepsi to snad ano, ale realna predstava komunikace set tisicu uzivatelu mi unika, rad se necham informovat o zkusenostech odjinud. PS: Zmena licence trva uz vice nez 2 roky, skoro polovinu trvani projektu Ahoj! Dovolím si reagovat, protože zkušenost odjinud mám, byť ne se statisíci autorů :-) Konkrétně se jedná o Simutrans, hru ve stylu Transport Tycoonu (strategie / simulátor dopravy). Původně probíhal vývoj jako freeware pod vedením BDFL, rozdělený na engine a různé varianty grafiky/krajiny. Po asi sedmi letech BDFL odpadl a došlo víceméně ke generační výměně celého týmu pro program. Jak to probíhalo tam, to netuším, ale skončilo to jako open source. Podobný vývoj nastal i u jedné z verzí grafiky a náhle to byla moje starost. Jako víceméně jediný zásadní cíl jsem si stanovil přejít na model open source i pro sadu grafiky. Období, kdy jsme identifikovali co je čí dílo, trvalo asi půl roku - informace o autorství byly v původním modelu správy nejednotné, nekompletní a tak vůbec. Pak došlo na shánění autorů, což bylo taky veselé - maily, telefony, účty tak všude různě, korespondence s adminy různých míst jestli mohou předat zprávu účtu xyz atd. Nakonec to dopadlo tak, že se podařilo sehnat souhlas pro většinu infrastruktury, ale ne pro průmysl... Kromě toho vyletěla spousta obsahu, který nebyl kritický z hlediska funkce. Problém grafiky pro průmysl se ale řešil další skoro tři roky. Autorství bylo celkově roztříštěné mezi desítky lidí, ale někteří z nich měli na svědomí klidně i čtvrtinu celkových dat, na ty se čekalo jak na smilování. Takže tu byla i jakási obdoba masových importů odmítači. Mezitím běžela paralelně distribuce verze s původními objekty a bez nich, po čase se vyměnila hlavní verze na tu skoro-free, takže uživatelé (míněno hráči) kafrali že jim chybí toto a tamto a proč že to muselo pryč a že jsme banda blbů atd. Shrnutí... Většinu času zabralo čekání a náhrada kritických částí, které nikdo moc neuměl. Ve srovnání s OSM šlo o nesrovnatelně menší komunitu, takže se povedlo dohledat většinu opravdu důležitých lidí. Zkušenost je ale velmi podobná, myslím že se v tom popisu snadno najdete :-D Vláďa PS: Pro ultra-zájemce odkazy na diskuse... http://forum.simutrans.com/index.php?topic=320.0 http://forum.simutrans.com/index.php?topic=388.0 http://forum.simutrans.com/index.php?topic=472.0 http://forum.simutrans.com/index.php?topic=1442.0 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] import budov
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 fordf...@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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] import budov
Jan Bilak wrote: 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. V OSM se používají v podstatě dva formáty: 1) osm: XML soubor s jednotlivými prvky. 2) osc (osmChange): XML soubor obsahující změny dat (obsah changesetu), v podstatě se jedná o seznam prvků delete, modify, create, kde každý z nich obsahuje změněné prvky. Jestli existuje nějaký rozumný prohlížeč tohoto formátu netuším. (více viz wiki) Už nějakou dobu vyvíjím pythoní knihovnu [1] pro práci s OSM daty, mj. jsem používal pro import sídel z UIR-ZSJ. Tam jsem taky používal metodu, která diffne dva osm souboru a vytvoří z nich osc vhodný k uploadu (proto byl postup - otevři vygenerovaný osm soubor, uprav dle chuti, ulož, spusť skript pro upload). 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. Pokud se shodneme, že budem adresní body skutečně do OSM dávat jako jednotlivé body (ale mám pocit, že tahle otázka se ještě definitivně nerozřešila), tak by se asi dala zrecyklovat značná část logiky z importu UIR-ZSJ. Troufám si tvrdit, že v takovém připadě by se dala synchronizace OSM a RUIAN prakticky úplně zautomatizovat. Ale teď se odhodlávám podívat se na to, v jaké formě obsahuje RUIAN hranice a jestli by se nedala nějak zautomatizovat jejich aktualizace v OSM (co jsem koukal, tak na některých místech se změnilo docela dost). Zdraví, Petr Morávek aka Xificurk [1] https://github.com/xificurk/osmapis signature.asc Description: OpenPGP digital signature ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] import budov
Jeden námět k prozkoumání: Aplikace pro koordinaci úloh v OSM - OSM Tasking manager. https://github.com/pgiraud/OSMTM Praktické nasazení je možné vidět v humanitárním týmu OSM: http://tasks.hotosm.org/ A nebo pro koordinaci remapování po licenčním botovi: http://rebuild.poole.ch/ Na první pohled vypadá aplikace použitelně minimálně na koordinaci činností a řeší některé problémy: - není potřeba registrace, použije se přihlašování z OSM - úlohy jsou vidět na mapě - integrované vazby na JOSM a Potlatch - vyřešené rezervace úloh jednotlivými uživateli včetně automatického uvolnění při nečinnosti Pokud se chcete někdo pustit do vývoje nějaké poloautomatické importovací aplikace, mohl by to být použitelný základ. TT ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] import budov
Určitě jsem rád že směřujeme k ručnímu importu s výraznou pomocí nějakých nástrojů typu toho co teď připravil Mirek (doufám že si to dobře pamatuju). Jakub On 27.7.2012 14:18, Jan Bilak wrote: 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 Šulcfordf...@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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] import budov
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 fordf...@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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz smime.p7s Description: Elektronicky podpis S/MIME ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
