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