Re: [Talk-cz] stav UHUL ortofoto
Spíše jen něco jako klasický webserver. TileCache mi přijde pro tento účel příliš složitá věc, která řeší generování v případě, že dlaždice není v cache apod. Dlaždice zřejmě budou samostatné jpg (příp. png/gif) soubory v nějaké adresářové struktuře, aby jich nebylo mnoho v jednom adresáři. A jediné, co je potřeba, tak je umožnění přístupu k nim přes HTTP protokol. Šlo by ty dlaždice ve formě nějakého archivu někam veřejně nahrát a dát se odkaz? Honza Dne 10. února 2014 23:48 Pavel Machek pa...@ucw.cz napsal(a): On Mon 2014-02-10 22:39:52, Lukas Kohout wrote: On 10.2.2014 21:39, Pavel Machek wrote: Jak rikam, mam lokalni kopii. Ani neni tak velka (1.6GB). Pak mam taky notebooka a ADSL, coz znamena, ze se mi asi neche pustit tileserver doma. Na druhou stranu, nekdo tu trema ma pocitac na silny lince s 1.6GB mista? Pavel Ahoj, co by tileserver obnášel? Jde jen o distribuci vygenerovaných dlaždic, nebo ty se generují on-demand skriptem z databáze? Jen distribuce vygenerovanych dlazdic, zda se ze je to tohle: http://tilecache.org/ . Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Aplikace TerrainGIS pro Android
Ahoj, můžeš, prosím, uvést praktické výhody oproti Vespucci OSM Editoru: https://play.google.com/store/apps/details?id=de.blau.android Honza Dne 16. září 2013 21:43 Vojtěch Kalčík vo...@kalcik.cz napsal(a): Ahoj, jako diplomku jsem dělal open source program TerrainGIS pro mapování v terénu pro Android. Dnes jsem ho zveřejnil na Google Play. http://vojta.kalcik.cz/doku.php?id=programy:terraingis https://play.google.com/store/apps/details?id=cz.kalcik.vojta.terraingis Styl používání programu je spíše bližší klasickým GISům. Do programu je možné importovat a exportovat vrstvy v formátu Shapefile. Vnitřně jsou geodata uložená ve SpatiaLite databázi. Jako podkladová mapa se používají dlaždice z OSM, které se kešují pro off-line použití. Aplikace vyžaduje Android 4.x V Josm je možné otevírat Shapefile pomocí pluginu opendata. Není úplně vhodné použít data z Shapefile přímo, protože v Shapefile se nedá uložit topologie objektů. Shapefile je možné v Josm převést do GPX vrstvy. Aplikace by se dala dál rozvíjet, ale ještě nevím jestli o ní bude zájem. Vojtěch Kalčík ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nemehlo
Možná tam maluje nějaký historický stav. Nějaký Palouš v obci bydlel, vyhořel tam i nějaký mlýn... (http://www.dbranna.cz/hiszaj.htm). Honza Dne 7. dubna 2013 2:18 LM_1 flukas.robot+...@gmail.com napsal(a): Mnohokrát se probíralo, že spousta uživatelů - nováčků neví, že opravdu upravují skutečnou mapu a bez zlých záměrů se chovají jako na pískovišti... LM_1 Dne 7. dubna 2013 2:13 Michal Tauchman michal.tauch...@gmail.com napsal(a): Lukas Kohout luko@... writes: Souhlasím. Také se mi tu objevil jeden takový aktivní blbec, který v krátkém čase vygeneroval obrovské množství nových cest, ploch a bodů. Mlátil to do editoru, jak mu to přišlo pod ruku, cesty a plochy náhodně přes sebe, různé cestičky nenapojené na existující silnice, nové cesty by nejradši v celé mapě namaloval jedním tahem se všemi důsledky z toho plynoucími (např. u slepé cesty se jednoduše vrátil bez přerušení kreslení). Keepright předtím poměrně čistý po něm hrál všemi barvami. Při kontaktu z něj vypadlo, že OSM objevil a do editace se pustil, aniž by si přečetl jakoukoli nápovědu. Občas to není o tom, že to ti lidé dělají naschvál, ale jednoduše nezvládnou nadšení z možnosti přímo editovat mapu v kombinaci s obrovskou škálou možností a voleb, které v editoru mají k dispozici. LuKo On 6.4.2013 21:21, LM_1 wrote: Předně bych ho zkusil kontaktovat. Třeba ani neví co dělá... Lukáš Matějka (LM_1) Já to dokážu pochopit, nejsem ras, ale proč tam kreslí nějakou vodní plochu, která nejspíš neexistuje? Opravdu mi to nejde do hlavy. Nepochopení křížení apod. dokážu pochopit, ale tohle? Jak říkám, neznám tu v okolí každý metr, ale na jakýchkoli ortofoto mapách vidím, že tam žádná voda není, ani nevím, proč by tam někdo dělal skutečný rybník, podle mne by to ani nešlo. Ani netuším, co by to mohlo být jiného. No asi ho zkusím kontaktovat, nic mi jinak nezbývá, ale moc se do toho neženu. Nerad někoho kárám, samotnému mi to nedělá dobře, ale když není zbytí... ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] rúian bot - první výsledky testů
Ahoj, jak ten bot rychlý? Aneb za jak dlouho by zpracoval (pokusně) celou ČR - tedy vygeneroval log? Můžeš udělat histogram vzdáleností spárovaných bodů? Honza Dne 6. srpna 2012 4:54 Mirek Dlask dlas...@gmail.com napsal(a): Je otázka, zda nejsou v RÚIAN adresní body domů bez č.p. , asi tam budou adresní body rozestavěných domů. Ty v OSM předpokládám nejsou. Nebo by se asi zobrazovaly tečky bez čísel!? Buď zkusit zmenšit boxík na nějaké garáže, nebo průmysl bez č.p. , nebo SELECT adresních bodů bez čísel popisných a zároveň evidenčních, jsou-li ... 150 je fakt nějak moc Mirek Dne 5. srpna 2012 23:30 Miroslav Šulc fordf...@fordfrog.com napsal(a): tak jsem dodělal bota do stádia, že načte body z osm api a z rúian db, pokusí se je spárovat a vygeneruje nějaké statistiky. pokud se někdo chce podívat do kódu, tak je k dispozici na https://github.com/fordfrog/ruian2osm co se týče načítání bodů z api, tak jsem to omezil na nody, které mají tag addr:housenumber a tag addr:country=CZ (doufám, že adresní body v čr mají aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak). pro testy jsem použil BOX(14.63 50.55,14.68 50.58). pro párování bodů jsem nastavil maximální povolenou vzdálenost na 0.005, nicméně největší vzdálenost mezi shodnými body je 0,0009538 (RÚIAN: POINT(14.6562825 50.5617608) CZ, Doksy, Hálkova 890 OSM: POINT(14.6553375 50.5616313) CZ, null, Hálkova 890, http://maps.fordfrog.com/?zoom=18lat=50.56166lon=14.65557layers=0B0FTF). u tohohle bodu je zajímavé, že údaj v kú je jiný než údaj v rúian (je to vidět z kú vrstvy, u nás ale zatím neproběhla digitalizace). co se týče propojování, tak úspěšnost byla následující: Total matched nodes: 1 136 Total unmatched nodes - RÚIAN: 150, OSM: 15 z toho mj vyplývá, že pokud jsem nikde neudělal chybu, tak v dané oblasti je oproti rúian navíc 15 adresních bodů a 150 jich chybí (což je opravdu dost na tak malé území, aspoň podle mě). k párování ještě poznámka. to že se body sprárovaly ještě neznamená, že osm obsahuje kompletní adresy. jak jsem psal jinde, u nás kompletně chybí addr:city, součástí adresy není ani addr:postcode. párování probíhá v několika cyklech, nejdříve podle celé adresy, nespárované body se pak porovnávají podle ulice a čísla, a to co zbyde se nakonec porovná pouze podle čísla. ve všech případech se ještě zohledňuje vzdálenost bodů. pro programátory podrobnější info tady: https://github.com/fordfrog/ruian2osm/blob/next_release/src/main/java/com/fordfrog/ruian2osm/AddressNodesMatcher.java tady je ještě údaj o průměrné vzdálenosti propojených bodů: Average matched node distance: 0,046 v příloze posílám (snad proleze zip) kompletní log z bota. uvítal bych, pokud by se někdo na ten log podíval, jestli tam nenajde ještě něco zajímavého (nějaké zjevné chyby, na co si dát pozor apod.). stejně tak, pokud budete někdo chtít, abych pustil bota (samozřejmě pouze v testovacím režimu) na nějaké vaší oblíbené oblasti, tak mi pošlete bounding box a já vám pošlu log z bota. 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
Re: [Talk-cz] import budov
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 l...@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@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
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
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] tagování silnic - praxe a wiki se liší
O konvencích tagování toho moc nevím, ale co na to jít od jinud? Tedy dávat silnicím tagy, které mají jasný význam. Tedy např. tag, který bude říkat třídu silnice, tag, který bude říkat počet pruhů apod. Takové ty neurčité tagy, podle který ale třeba renderer kreslí mapy, by pak bylo možné hromadně automaticky nastavovat podle toho, jak se ukáže za vhodné. Tedy něco jako když má x pruhů a y. třídy, tak dostane tag Tato pravidla by pak stačilo udržovat na jednom místě (na rozdíl od hlavy každého mappera), snadno by je bylo možné udržovat konzistentní (opravovat na základě tagů s jasnou informací), při změně pravidel by stačilo pravidla jednou změnit a spustit skript... Tento systém by se mi líbil obecně všude v OSM. Zaznamenávání tagů, které nesou zcela jasnou informaci. A následné odvozování tagů, které nenesou zcela jasnou informaci, ale jsou nutné kvůli kompatibilitě (se světem, se softwarem apod.). Honza Dne 21. července 2012 1:08 Jakub j...@kub.cz napsal(a): Chtěl bych se zeptat jestli proběhla (předpokládám že ano) nějaká diskuze ohledně tagování silnic první třídy. Pokud ne, tak bych jí rád otevřel. Na http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/roads_tagging se píše, že to zda se silnice 1. třídy taguje jako trunk nebo primary je určeno tím, zda má silnice 2 nebo 4 pruhy. Začal jsem tagovat podle této informace, ale velmi rychle mi začalo připadat, že to není dobrý nápad. Neodpovídá tomu vůbec praxe, která taguje jako trunk (podle toho co jsem viděl) jen rychlostní komunikace - pokud by se dodrželo to co je ve wiki, bude potřeba udělat změny na mnoha místech, například Praha by byla plná trunků. IMHO to není ani pěkné v Mapniku (ale to není hlacní argument) ani praktické. Ztrácíme tím vizuální informaci - rozdíl mezi silnicemi 1. třídy a dálnicí či rychlostní komunikací. Prosím vaše názory, rád bych to když procházím silnice ČR měl možnost zároveň upravovat. Můj návrh: silnice první třídy mapovat jako primary nehledě na počet pruhů. Jakub ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] (skoro) funkční rúian wms vrstvy
Tohle je podle mě vlastnost JOSM, takto se mi to chovalo vždy u všech zdrojů. Honza Dne 19. července 2012 20:09 Miroslav Šulc fordf...@fordfrog.com napsal(a): jinak jsem zjistil, že pokud si přiblížím mapu a až pak si načtu tu wms vrstvu, tak se mi načte detailnější. bohužel ale při zoomování se podklad neaktualizuje. netušíte někdo, kde by mohl být problém? ff ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Pěkná kupka práce
Obkreslovat by podle mě bylo licenčně špatně. Ale používat to pro informaci o tom, co je třeba v mapě doplnit, podle mě licenčně špatně není. Vlastní kreslení by pak muselo probíhat podle jiného zdroje. Honza Dne 18. července 2012 18:43 Jan Breuer jan.bre...@jaybee.cz napsal(a): Taky bych to uvítal, ale nebude to licenčně špatně obkreslovat podle něčeho, co bylo právě kvůli licenci vyřazeno? Honza Dne 18. července 2012 18:19 Zdeněk Pražák zpra...@seznam.cz napsal(a): lze uvedenou mapu dostat nějak jako podkladovou vrstvu do JOSM Pražák Dne 18. července 2012 4:56 Jakub j...@kub.cz napsal(a): Tak koukám, že máme o zábavu postaráno. Republika je plná rozkouskovaných cest :-) ... Takže (zkušení omluví trivialitu sdělení) pokud máte pár dní čas, tak doporučuju zasednout ke strojům. K přehledu o tom, co bylo smazáno (čistě technicky spíše v historii editování skryto dobře poslouží mapa http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php?zoom=8lat=49.70961lon=14.42081layers=B00F 1. najděte si místo kde to znáte, nebo chcete opravovat a zazoomujte 2. klikněte na + v pravém hodním roku a zvolte BADMAP - tady je vidět co všechno bylo smazáno 3. dokreslete to jako kdybyste to malovali poprvé, tj. podle vašich znalostí, tras nebo leteckých snímků. Když už budete v tom, dopoučuju se na oblast podívat na http://keepright.ipax.at/report_map.php?lat=49.87008lon=14.05625zoom=8layers=B0Tch=0%2C30%2C40%2C50%2C60%2C70%2C90%2C100%2C110%2C120%2C130%2C150%2C160%2C170%2C180%2C191%2C192%2C193%2C194%2C195%2C196%2C197%2C198%2C201%2C202%2C203%2C204%2C205%2C206%2C207%2C208%2C210%2C220%2C231%2C232%2C270%2C281%2C282%2C283%2C284%2C291%2C292%2C293%2C311%2C312%2C313%2C350%2C370%2C380%2C411%2C412%2C413show_ign=1show_tmpign=1 kde najdete i další chyby, které tam byly ještě před promazáváním. Pokud i tyto na konci vaší remapovací mise úspěšně vyřešíte, bude mapa lepší než dřív. Tak do toho Jakub ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Praha bude brzy děravá :-(
Ahoj, to mě také zaráží. V takovém případě by snad mělo smysl použít poslední licenčně použitelnou verzi, případně selektivně odstranit licenčně problematické tagy apod. Honza Dne 16.7.2012 18:04 Jakub Sykora kub...@kbx.cz napsal(a): Docela me zarazi, ze tam dojde ke smazani veci, ktere jsem mapoval v zacatcich OSM jen proto, ze to nekdo, kdo s licenci nesouhlasi lehce opravil nebo k tomu pridal nazev... Ach jo... Dne 16.7.2012 17:42, Jakub Těšínský napsal(a): Tak jsem si zazoomoval na Prahu abych viděl, co nám relicencovací bot v nejbližší době smázne a veselý pohled to není. Koukněte na http://harrywood.dev.**openstreetmap.org/license-** change/botprocessing.php?zoom=**12lat=50.05582lon=14.44004** layers=00BFTTFFhttp://harrywood.dev.openstreetmap.org/license-change/botprocessing.php?zoom=12lat=50.05582lon=14.44004layers=00BFTTFF Pokud máte zrovna čas je nejspíš posledních pár hodin některé te věci třeba z leteckých snímků opravit. Jakub __**_ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-czhttp://lists.openstreetmap.org/listinfo/talk-cz __**_ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-czhttp://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] RUIAN - veřejný dálkový přístup
Zdravím, nemohu si pomoci, ale souhlasím s hanojem a jsem přesvědčen, tak dlaždicování je správná cesta. Marushka je opravdu strašně pomalá - generování výřezu 10 sekund není nic výjimečného - naštěstí s ní nepracuji. Ono tedy nahlížení do katastru je také velmi pomalé (4 až 5 sekund běžně) - dokonce dříve to bývalo rychlejší. Každý den se aktualizuje grafika v cca 700 katastrálních územích, takže data jsou docela živá a nějaké vyrábění dlaždic (navíc průběžně - mapové služby mají zpoždění pouze v řádu hodin proti produkčnímu systému) by bylo vysoce problematické Dlaždice se aktualizují pouze při změně (dané dlaždice). Tedy při změně dat se zjistí jejich rozdíl (pokud není možné jej zjistit přímo) a zneplatní se zasažené dlaždice, které se průběžně s menší prioritou generují. S větší prioritou se generují dlaždice, které si někdo vyžádal a nejsou již vygenerované. Nevěřím, že každý den změní relativně velké množství dlaždic. Mapy jsou ve velkých zoomech a dlaždice tak pokrývá poměrně malé území. Pro informaci - současné reálné špičky v zatížení WMS jsou kolem 5000 požadavků za minutu. Čím více požadavků, tím více je to ve prospěch dlaždic. Generování výřezu mapky z dat trvá dle pozorování hodně dlouho. Pokud je tím myšleno dlaždicování na straně klienta, tak o tom jsme se také bavili. Tam je ale problém s prvky, které řeže hrana dlaždice (popisy definičních bodů atd.) - na dlaždici s bodem pak je kus popisu a na sousední dlaždici není nic (protože tam není ten bod, ke kterému se doplňuje popis). Zrovna na ikatastr.cz to jde pěkně demonstrovat. Tohle má celkem jednoduché řešení - pro každý takový prvek je třeba zjistit ohraničující obdélník a ten zanést do prostorového indexu, ze kterého se pak zjišťuje, které objekty zasahují do daného výřezu (dlaždice). Ale tento problém musíte stejně řešit již nyní, kdy generujete výřez na přání. Honza ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Data RUIAN - výměnný formát
Ahoj,
transformaci souřadnic mám rozchozenou v .NETu pomocí knihovny PROJ.4
(http://trac.osgeo.org/proj/) s gridem
(http://grass.fsv.cvut.cz/gwiki/S-JTSK-Grid). Tedy alespoň v tom
doufám, že to počítá správně. Ověřoval jsem na příkladu, který je
uveden na té stránce GRIDu - ten to spočítalo přesně. Bez použití
GRIDu byly výsledky trošku jiné.
Spíše je otázka, co s tím dál, protože zatím ještě není dohodnuto,
jaký je ideální výsledný stav (zda adresní body nebo tagy na budovách,
jaké tagy, jak nakládat se starými daty apod.) a jaký postup importu
tedy zvolit.
Honza
Dne 30. června 2012 13:11 Martin Kokeš sh...@typo3-hosting.com napsal(a):
Čistě matematická transformace dosahuje značné nepřesnosti v závislosti na
lokalitě až 70 metrů.
http://grass.fsv.cvut.cz/gwiki/Chyba_při_transformaci_z_WGS84_do_S-JTSK
Převod GML se dělá pomocí ogr2ogr, případně lze GDAL knihovnu začlenit do
Céčkového programu nebo do Python skriptu bez problémů pomocí API:
http://gdal.org/gdal_tutorial.html
MK
- Original Message -
From: Pavel Machek [mailto:pa...@ucw.cz]
To:
OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org]
Sent: Sat,
30 Jun 2012 12:45:23 +0200
Subject: Re: [Talk-cz] Data RUIAN - výměnný
formát
On Sat 2012-06-23 04:45:21, Jan Bilak wrote:
Díky. Nevíte o nějakých
knihovnách (.NET, Java, JavaScript, C, C++,
...) pro transformaci pomocí
toho S-JTSK gridu? Nebo, pokud nejsou
přímo knihovny, ve kterých
opensource programech s vhodnou licencí by
tato transformace šla
najít?
Ja tu mam:
gdalwarp -s_srs +proj=krovak +a=6377397.155
+rf=299.1528128 +no_defs
+towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56
-t_srs
+proj=latlong +a=6378137 +rf=298.257223563
+no_defs
+towgs84=0.000,0.000,0.000
/data/gis/READ-ONLY/cechy.tif
/tmp/delme.tiff
a pak pascalovej zdrojak:
{
Copyright 2005 Zdenek Hrdina, distribute under GPLv2
}
procedure
jtsk_wgs( X,Y,Hel:double; var B,L,H:double);
{Vypocet zemepisnych souradnic
v systemu WGS-84 z rovinnych souradnic
S-JTSK a elipsoidicke
vysky}
procedure transformace_BLH(var B,L,H: double);
{Transformace
zemepisnych souradnic z JTSK do WGS}
var
lat,lon,alt,x1,y1,z1,x2,y2,z2:double;
... Poslu nebo by mel jit
vygooglit.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky,
pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Talk-cz
mailing
list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)
Ahoj, Trochu sem se prohrab temi samply, a me by se libilo nevyrabet adresni body ale priradit adresy budovam, neb ta vazba v tech datech je. Bod bych vyrobil jen tam, kde budova neni (a je tam definovana adresa). Co se tyce ulic, tam to asi s jejich presnosti nebude zadna slava - predpokladam, ze kazdej kdo obkresloval rucne to udelal podrobnejsi. Ale lepsi nez dratem do oka. Adresní bod a budova ... to mě napadlo také (a někde se to v OSM i používá), ale vidím v tom trochu problémy. Zaprvé budova může mít více vchodů/adres. Jak by se jmenovaly tagy? addr:housenumber1, addr:housenumber2, addr:housenumber3 apod.? Nebo by se dělila budova na části? Ale jak? Nikdo nebude zkoumat vnitřní strukturu budovy - typicky ji vidíš zvenku a pár vchodů dovnitř. Občas se je zřejmé, ale nemusí být vždy. Zadruhé adresní bod (pokud je vhodně umístěn) říká i polohu vchodu. Např. budova stojí mezi dvěma ulicemi a takto by nebylo zřejmé, odkud je vlastně vchod. Zatřetí je otázka, zda je vhodné štěpit jeden druh informace do různých zápisů (někdy adresní bod, někde vlastnost budovy). Nicméně informace u budovy může být také užitečná. Teoreticky lze najít všechny adresní body, které leží uvnitř polygonu budovy. Jak je rychlé/pracné, to záleží na tom, jak se data oindexují apod. Jak je to pracné v existujících nástrojích, to nevím. Předpokládám, že dotaz na objekty ležící v daném obdélníku je jeden z nejčastějších dotazů a data jsou tedy vhodně oindexována (r-tree, quad-tree nebo tak něco). Tohle je pekny, ale uvital bych SVG. obi:VlajkaTextList tvoří tři vodorovné pruhy, žlutý, modrý oboustranně zubatý a žluto-černě polcený, v poměru 1:2:1. Modrý má nahoře i dole po čtyřech zubech a pěti mezerách, vysokých jednu osminu šířky listu. V modrém pruhu žlutý kráčející lev s červenou zbrojí držící v předních tlapách bílou rybu hlavou nahoru a hřbetem k žerdi. Poměr šířky k délce listu je 2:3./obi:VlajkaText obi:ZnakTextV modrém štítě se zlatou cimbuřovou hlavou zlatý kráčející lev s červenou zbrojí držící v předních tlapách stříbrnou rybu, pod ním zlato-černě polcený štítek./obi:ZnakText Tohle tam není jen textově, ale i ve formě obrázků. Pravda - bitmap, nikoli vektorů. Ono asi ani všechno vektory nejde dobře vyjádřit nebo nejsou data ve vektorech dostupná. Přeci jen tohle vznikalo v době, kdy se ještě malovalo štětcem na papír apod. Podle me naopak nejvetsi kandidat na vyhozeni je prave is_in, protoze je to nestrukturovana hromada cehosi. Navic v soucasnosti drtiva vetsina aplikaci spravne najde ze adresa lezi uvnitr boundary XYZ. Souhlas, je to nestrukturovaná hromada, ovšem to cosi nese užitečnou informaci. Jak už jsem psal, někdy jedno katastrální uzemí obsahuje více částí obce, každá část má vlastní číslování domů. Tedy v hranicích jednoho KÚ se čísla opakují. Nestrukturovaná data se mě také nelíbí. Ale existuje strukturovaná verze is_in, jak píšou na té stránce http://wiki.openstreetmap.org/wiki/Key:is_in (is_in:city, is_in:country, ...). Dál navrhuji seskupit adresy jedné ulice do relace, která ponese addr:street a is_in, aby se předešlo duplikaci. Adresní body by v tom případě měly jen addr:housenumber, addr:streetnumber a addr:conscriptionnumber. Otázkou je, jak by taková relace měla vypadat[2]. Toto je neprohledatelny, zadny stavajici nastroj s necim takovym nepocita, tudiz tu adresu nikdo nenajde. Jako bonus je to obtizne editovatelny. Nominatim používá relaci associatedStreet. http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview#Building_Indexing Editace jsou samozřejmě obtížnější, nicméně mě stále láká strukturovanost této relace. Na druhou stranu, software na import asi psát nebudu, a kdyby ano, nemořil bych se s generováním relací. Takže to tu nechme jako dobrý nápad. Po stránce software na import bych tom neviděl velký problém (software na import průběžně připravuji). Větší starost mi dělá to, že vlastně nevím, co mám přesně udělat. Tedy jak má vypadat výsledek, co udělat se starými daty, podle čeho matchovat stará a nová data apod. Nemám dobrý přehled o významu všech tagů a vůbec konvencích a doporučení OSM a studovat WIKI se mi opravdu nechce (zabralo by mi to spoustu času). Proto bych rád, kdyby z diskuse vzešly nějaké závěry a mohl jsem to podle nich implementovat. Honza ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)
Ahoj, díky za rozbor, ale myslel jsem to tak, jaký zápis chceme v OSM ideálně mít. Tedy v jakém formátu připravovat import z RUIAN, jaké tagy tam dát pro nové adresní body, jaké tagy doplnit ke stávajícím, jaké existující tagy případně smazat nebo změnit (ostatní předpokládám zachovat). Tedy aby to všude jednotné (+ u některých bodů nějaké specifické tagy). Jak se má složit obsah tagu is_in (pokud tam má být), protože to je složenina různých údajů. Honza Dne 26. června 2012 13:58 Libor Pechacek lpecha...@gmx.com napsal(a): Ahoj, Z mojí zkušenosti se formát adresního bodu liší podle použitého nástroje. Jsou tři (polo)automatické způsoby importu, a nakonec pak ruční zadání. On Tue 26-06-12 04:14:04, Jan Bilak wrote: jak vypadá ideální zápis adresního bodu v OSM XML? Koukal jsem se do snapshotu OSM dat ČR a zápisy nemají jednotný formát. Např.: node id=296674495 lat=48.9631350 lon=14.5119948 version=2 changeset=1965423 user=Radomír Černoch uid=51295 timestamp=2009-07-28T14:56:31Z tag k=addr:conscriptionnumber v=2030 / tag k=addr:housenumber v=2030/1 / tag k=addr:postcode v=37006 / tag k=addr:street v=U pramene / tag k=addr:streetnumber v=1 / tag k=source:addr v=uir_adr / tag k=uir_adr:ADRESA_KOD v=23398671 / /node Tohle je podle mě výsledek UIR-ADR importu. http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Adresn.C3.AD_body_-_MPSV.28UIR-ADR.29 node id=1496603658 lat=48.8736400 lon=14.6758775 version=1 changeset=9784174 user=Petr1868 uid=72020 timestamp=2011-11-09T19:54:47Z tag k=addr:conscriptionnumber v=13 / tag k=addr:country v=CZ / tag k=addr:housenumber v=13 / tag k=is_in v=Třebeč, Borovany, Jihočeský kraj, CZ / tag k=source:addr v=mvcr:adresa / tag k=source:loc v=cuzk:km / /node Tento záznam vytváří nástroje napsané Lukášem Kábrtem. http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR Pokud jsou v obci ulice, je přítomen i tag addr:street. node id=33705330 lat=49.7021197 lon=17.0731786 version=12 changeset=5435557 user=NE2 uid=207745 timestamp=2010-08-08T17:43:41Z tag k=addr:city v=Litovel / tag k=addr:conscriptionnumber v=678 / tag k=addr:country v=CZ / tag k=addr:housenumber v=678/1 / tag k=addr:postcode v=78401 / tag k=addr:street v=Mlýnská / tag k=addr:streetnumber v=1 / tag k=is_in v=Litovel, Olomoucký kraj, CZ / tag k=name v=Penzion U starého mlýna / tag k=source:addr v=mvcr:adresa / tag k=tourism v=hotel / tag k=url v=http://ustarehomlyna.cz; / /node Tohle je podle mě CzechAddress plugin pro JOSM napsaný Radomírem Černochem. http://wiki.openstreetmap.org/wiki/CS:JOSM/Plugins/CzechAddress Name a URL tagy byly zřejmě přidány ručně. node id=283050015 lat=50.1039117 lon=14.5115490 version=2 changeset=1984279 user=Radomír Černoch uid=51295 timestamp=2009-07-30T12:44:24Z tag k=addr:housenumber v=?/66 / tag k=addr:streetnumber v=66 / tag k=created_by v=Potlatch 0.10b / /node Tenhle byl asi vyroben ručně v Potlatchi, JOSM vytváří podobné. Chybí v nich is_in. Jak se vlastně jednoznačně/algoritmicky určí, co je a co není adresní bod? Všechny mají addr:housenumber, čehož bych se držel. Je vidět, že některé adresní body obsahují i doplňkové informace, které bude třeba zachovat. Tedy nějaké globální mazání a import adresních bodů nebude možný. Bude třeba matchovat staré a nové a podle toho se nějak zachovat. Rozhodně. A aby to nebylo jednoduché, různé zdroje mají různou přesnost. Polohově nejpřesnější jsou ruční editace, pak je import pomocí nástrojů Lukáše K., nejméně přesný je UIR-ADR. Co se týče doplňkových informací, informaci o ulici, čísle orientačním a hierarchii sídel obsahují body vytvořené ručně s pomocí CzechAddress a poloautomaticky nástroji Lukáše K. Informace o čísle, ulici a sídle pochází z databáze adres MVČR, umístění adresního bodu je pak výsledkem tvůrčí práce. V případech, kdy je na jednom katastrálním území více částí obcí, mohou někdy být tyto informace nesprávně. Záleží totiž, jak pečlivě byl import proveden. Libor ___ 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] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)
Ahoj, koukám, že tu budou i různé rozdíly mezi adresami z registru a z OSM, i když v OSM mají v tagu uveden kód adresy registru (tedy mělo by se jednat o stejnou adresu a asi import z UIR-ADR): Pár rozdílů z Prahy (pokud jsem neudělal chybu): http://jabi.aspone.cz/osm/temp/praha-rozdily.pdf Narážím konkrétně na rozdíly v číslech domu, nikoli v poloze. Poznámka: levá část je z registru, pravá část z OSM, 0 = neuvedeno, vzdálenost brát s velkou rezervou, celkově je výstup odporný... Otázka je, co je správně. Řešit to ručně? Bude toho mnohem více (i z Prahy). A jak to vůbec řešit? Honza ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import budov
Ahoj, s importem adresních bodů získaných z teček na mapě bych se teď moc nezatěžoval, protože v brzké době se doufám podaří provést import z RUIAN, což být měl být kvalitnější zdroj (viz probíhající diskuse o RUIAN) - tedy úplný, denně aktualizovaný, přesnější, s menším rizikem chyby, lehčeji zpracovatelný, ... Zrovna adresní body myslím budou to nejjednodušší, co z RUIAN půjde naimportovat. Honza Dne 25. června 2012 13:50 Libor Pechacek lpecha...@gmx.com napsal(a): Ahoj, Postup importu adresních bodů je dobře popsán na již zmíněné wiki [1]. Až se Ti podaří rozchodit software, zapiš se na wiki jako importér a pusť se do toho. Při importu je většina práce řešení chyb při importu. Jde o to, že v jednom katastrálním území je někdy více částí obcí. V tomto případě se v souboru *-fixme.osm objeví duplicitní adresy a je třeba relaci popisující hranice karastrálního území rozdělit na části a tyto části zapojit do hierarchie adres editací *.map souboru. Malá ukázka je v adresy-priklad.zip [2]. Dál pak může být potřeba posunout hranice KÚ, v mapě jsou někdy nepřesně, nebo je třeba přiřadit části obcí katastrálním územím, když se nepodařilo Lukášovi vytvořit tato spojení algoritmicky. Hodně štěstí, pozor na oblasti kde už adresní body jsou a ozvi se kdybys potřeboval pomoc. Libor [1] http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR [2] http://osm.kabrt.cz/home/adresy-priklad.zip?attredirects=0d=1 On Thu 21-06-12 22:11:45, xkomc...@centrum.cz wrote: Aha, tak to jsem nevěděl, myslel jsem, že se importují adresy i rovnou s nakreslenými budovami :-( V tom případě bych rád poprosil, zda-li by nebyl odkaz na návod jak importovat alespoň ty adresy a jak vytvořit obrysy budov. Díky, xkomczax __ Od: jzvc j...@tpfree.net Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 21.06.2012 19:40 Předmět: Re: [Talk-cz] Import budov On nekdo nejak importuje budovy? Pokud se pamatuju, mluvilo se tu o importu adresnich bodu, coz je ponekud neco jineho - a ten odkaz odpovida prave adresam. Osobne to teda delam jinak, za pomoci czech address pluginu, neb mam overeno, ze adresni body jsou dost casto naprosto mimo, pripadne chybi uplne, takze by to stejne byla dvoji prace. Vetsinou postupuju tak, ze pouziju tracer a na nakreslenou budovu rovnou pridam i adresu. V kazdym pripade, importem do mapy asi nic nezkazis - kazdej by si mel predem overit jestli tam uz data nejsou, jen to udelej pod nejakym extra uctem, aby se vedelo, ze jde o import. Kazdopadne by to pomalu chtelo nejakej tool, kterej by umel najit budovy, ktere maji uvnitr cervenou tecku, ale jsou bez adresy (a idealne to zobrazit jako podklad do JOSM a spol), pripadne najit adresy, ktere nejsou v mape ... protoze posledni dobou uz narazim i na starsi oblasti, kde je zmapovano, ale mezi tim tam jsou nove budovy ... ktere se v OSM objevi jen, pokud na to nahodou nekdo narazi. Dne 21.6.2012 19:23, xkomc...@centrum.cz napsal(a): Zdravím, chtěl jsem se zeptat jak je to s importem budov z katastru nemovitostí. U okresu Prostějov je napsána poznámka probíhá, ale žádný pokrok osobně nepozoruji. Napsal jsem proto před časem uživateli Dave, který je u Prostějova napsán, ale od začátku března nepřišla odpověď, z čehož usuzuji, že import bude muset proběhnout jinak. Mám tedy o import požádat někoho zkušenějšího nebo se mám do něj pustit svépomocí? A mimochodem, když jsem našel na serveru http://osm.kabrt.cz/ soubor Prostějov.zip, ve kterém jsou i zbývající vesnice v .map formátu, znamená to že jsou již importovány a stačí jej pouze nějak nahrát na server? Pokud ano, jak to mohu provést? Díky, xkomczax ___ 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 -- ___ 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] Data RUIAN - výměnný formát
Ahoj, jak vypadá ideální zápis adresního bodu v OSM XML? Koukal jsem se do snapshotu OSM dat ČR a zápisy nemají jednotný formát. Např.: node id=296674495 lat=48.9631350 lon=14.5119948 version=2 changeset=1965423 user=Radomír Černoch uid=51295 timestamp=2009-07-28T14:56:31Z tag k=addr:conscriptionnumber v=2030 / tag k=addr:housenumber v=2030/1 / tag k=addr:postcode v=37006 / tag k=addr:street v=U pramene / tag k=addr:streetnumber v=1 / tag k=source:addr v=uir_adr / tag k=uir_adr:ADRESA_KOD v=23398671 / /node node id=1496603658 lat=48.8736400 lon=14.6758775 version=1 changeset=9784174 user=Petr1868 uid=72020 timestamp=2011-11-09T19:54:47Z tag k=addr:conscriptionnumber v=13 / tag k=addr:country v=CZ / tag k=addr:housenumber v=13 / tag k=is_in v=Třebeč, Borovany, Jihočeský kraj, CZ / tag k=source:addr v=mvcr:adresa / tag k=source:loc v=cuzk:km / /node node id=33705330 lat=49.7021197 lon=17.0731786 version=12 changeset=5435557 user=NE2 uid=207745 timestamp=2010-08-08T17:43:41Z tag k=addr:city v=Litovel / tag k=addr:conscriptionnumber v=678 / tag k=addr:country v=CZ / tag k=addr:housenumber v=678/1 / tag k=addr:postcode v=78401 / tag k=addr:street v=Mlýnská / tag k=addr:streetnumber v=1 / tag k=is_in v=Litovel, Olomoucký kraj, CZ / tag k=name v=Penzion U starého mlýna / tag k=source:addr v=mvcr:adresa / tag k=tourism v=hotel / tag k=url v=http://ustarehomlyna.cz; / /node node id=283050015 lat=50.1039117 lon=14.5115490 version=2 changeset=1984279 user=Radomír Černoch uid=51295 timestamp=2009-07-30T12:44:24Z tag k=addr:housenumber v=?/66 / tag k=addr:streetnumber v=66 / tag k=created_by v=Potlatch 0.10b / /node Jak se vlastně jednoznačně/algoritmicky určí, co je a co není adresní bod? Je vidět, že některé adresní body obsahují i doplňkové informace, které bude třeba zachovat. Tedy nějaké globální mazání a import adresních bodů nebude možný. Bude třeba matchovat staré a nové a podle toho se nějak zachovat. Honza Dne 25. června 2012 12:16 jzvc j...@tpfree.net napsal(a): Dne 25.6.2012 0:35, hanoj napsal(a): (nebo jsou data nesprávná - např. jiný tvar obrys budovy). *** No katastr, uznává tuším styk budovy se zemí jako reprezentující a vzhledem k tomu že to dosud od něj obkreslujem asi by to chtělo uznat za standard. Tak to pozor, km sice pouzivam jako jeden z primarnich zdroju, ale vzdycky minimalne kontroluju, jestli tam ta budova +- opravdu stoji. A pripadu kdy v km budova je, ale fyzicky tam neni po budove ani pamatky (= ani ruiny), pripadne naopak, budova si na miste vesele stoji, zato po ni ani pamatky neni v km (a to vcetne toho, ze budova ma i vlastni cp) nejsou zadnou vyjimkou, narazim na takove pri kazde editaci mapy. Zrovna tento tyden sem odmazaval zborene budovy, ktere v km vesele stale jsou (a to jsou zborene uz minimalne par let). = 1) zadny zbesily import a rozhodne ne zadne mazani v OSM. 2) optimalne vygenerovani nejake kolizni mapy (wms/tms server) aby sla dat na podkres editoru. 3) IMo by bodnul nastroj, kterej by byl schopnej nejak slinkovat existujici budovy - rekneme s nejakym rozpalem hranic +- 1m? a ohranicene plochy +- 10%? Cisla by samo chtelo vyhodnotit na zaklade uspesnosti = pokud zbude nejaky nepatrny % budov, ty se daj poresit rucne. Pokud se budova vejde to tohodle rozpalu (IMO vsechny vyrobeny tracerem), tak se da prohlasit, ze to je ona, priradit ji prislusny ID a posunout jeji hranice tak, aby to sedelo presne na km. Co se aktualizaci tyce - pokud dojde ke zmene v km a neni zadna zmena na strane osm, tak asi neni co resit - aktualizace v osm. Pokud ke zmene dojde opacne, tak dost pochybuju ze nekdo zmeni neco v km. Pokud je zmena oboustrana, tak asi leda tak, ze nekdo koukne do osm a bud prohlasi, ze se to ma syncnou s km nebo prohlasi, ze data sou spravne v osm (a nejakym marknutim objektu ho vyradi ze synchronizace). obsahovat více upřesňujících tagů. Je tedy možné (pravděpodobné), že některá data budou lepší v OSM než v datech registru. Uliční čáry musí nějak rozumně na sebe navazovat... *** Opravdu se jedná o uliční čáry, nebude to jen popisek? Já jsem v ukazkach nic nenašel Které konrétní údaje z registru se budou do OSM importovat? *AdresniMisto (addr=*) *Stavebni objekt (building=*) *Ulice (name=*) Jak se vypořádat se starými daty? *** Mno nebal bych se smazat a nahrat novou geometrii budov (pro source=cuzk:km) a ponechat pripadne tagy navic. Dost digitalizaci je neduslednych co do geometrie tvaru (krizeni,
Re: [Talk-cz] Data RUIAN - výměnný formát
Ahoj, díky, transformace souřadnic vypadá v pohodě (testovacím příkladem to prošlo). Teď je otázka, jakou celkovou strategii importu a následných aktualizací zvolit. Zveřejněná data registru neobsahují některé informace o celé ČR, ale jen o částech, ve kterých je digitalizovaný katastr. Dále nevím, do jaké míry katastr odpovídá realitě, ale tipuji, že určitě budou budovy, které v katastru nejsou a opačně (nebo jsou data nesprávná - např. jiný tvar obrys budovy). Data mohu obsahovat více upřesňujících tagů. Je tedy možné (pravděpodobné), že některá data budou lepší v OSM než v datech registru. Uliční čáry musí nějak rozumně na sebe navazovat... Na druhou stranu registr má jistě celkově velkou míru konzistence a úplnosti, bude se průběžně rozšiřovat území, kde jsou dostupné všechny informace a bude se průběžně aktualizovat, ... Které konrétní údaje z registru se budou do OSM importovat? Jak se vypořádat se starými daty? Za ideální cílový stav bych považovat navázání dat na registr kvůli aktualizacím, ale s možnost provádění všech typů změn, pokud registr někde nebude správný, úplný nebo bude k dispozici více informací, než které registr obsahuje. Celkově jde o poměrně mnoho dat (v XML to má necelých 30 GB, i přes ukecanost XML je toho opravdu hodně), takže jakékoli větší ruční zásahy do importu budou časově náročné. Máte nějakou představu, nápady, ...? Honza Dne 23. června 2012 7:39 Martin Kokeš sh...@typo3-hosting.com napsal(a): Ahoj, viz http://grass.fsv.cvut.cz/gwiki/S-JTSK-Grid, cokoliv co používá GDAL/PROJ4. MK - Original Message - From: Jan Bilak [mailto:jan.bilak@gmail.com] To: OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org] Sent: Sat, 23 Jun 2012 04:45:21 +0200 Subject: Re: [Talk-cz] Data RUIAN - výměnný formát Díky. Nevíte o nějakých knihovnách (.NET, Java, JavaScript, C, C++, ...) pro transformaci pomocí toho S-JTSK gridu? Nebo, pokud nejsou přímo knihovny, ve kterých opensource programech s vhodnou licencí by tato transformace šla najít? Honza Dne 22. června 2012 22:12 Martin Kokeš sh...@typo3-hosting.com napsal(a): Jelikož se všude používá nativně Křovák, je nutná zpřesněná transformace pomocí S-JTSK gridu. MK ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Data RUIAN - výměnný formát
Zdravím, díky za info, ještě mám dotazy. Budou průběžně vydávané změnové soubory (popis formátu jsem tam viděl) nebo jen kompletní snapshoty? S jak častou aktualizací dat se počítá (jednou denně, ...)? Honza Dne 24.6.2012 17:26 Jiří Veselý j@seznam.cz napsal(a): Zdravím všechny, s webovými službami se zatím nepočítá, výjimkou bude WS pro ověření adresy. Jinak pokud jde o pokrytí území, tak katastrální data jsou ve výměnném formátu na cca 2/3 katastrálních území (DKM + KMD). Definiční čáry ulic a další prvky jsou v RUIAN přes celou republiku. J. Veselý Dne 22.6.2012 22:12, Martin Kokeš napsal(a): Ano, jde o RÚIAN, veřejný registr bez licence, dle 111/2009 Sb.. Generovaná data jsou už teď ke stažení. Rozhraní VDP ještě není, bude až od 1.7., nevím jak to bude se SOAPem, možná podobně, jako funguje u WSDP ke KN. Více info by asi dal p. Veselý. Využitelné jsou samozřejmě uliční čáry, polygony budov, adresní body, takže je čas udělat tracerům pápá (to platí pro zastavěné území). V souvislosti s WFS službou nad tématem INSPIRE parcely je možné získávat parcely i mimo zastavěné území, buď jako předgenerované soubory, nebo přímo přes WFS dotaz (možná by se ulevilo ZP a jeho tabletu při obkreslování zemědělské půdy ;-)...). Jelikož se všude používá nativně Křovák, je nutná zpřesněná transformace pomocí S-JTSK gridu. MK - Original Message - From: Jan Bilak [mailto:jan.bilak.osm@gmail.**com jan.bilak@gmail.com] To: OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.**org talk-cz@openstreetmap.org] Sent: Fri, 22 Jun 2012 20:53:02 +0200 Subject: Re: [Talk-cz] Data RUIAN - výměnný formát Ahoj, předem se omlouvám, pokud budu psát nesmysly - moc o tom nevím. Chápu to správně tak, že data budou licenčně použitelné pro OSM, budou obsahovat např. adresní body, obrysy budov, ulice apod., vše zdarma ve formě veřejné dostupné aplikace na bázi XML/SOAP? A nyní data ještě dostupná nejsou, ale budou od příštího měsíce. Data nejsou kompletní, ale zahrnutí jen ty části ČR, které mají digitalizovaný katastr nemovitostí (cca půlka, ale výhledově bude růst). Data budou průběžně aktualizována a budou dostupná ve dvou formátech: a) aktuální stav b) změnové soubory Pokud je to tak je, tak by bylo vhodné celý proces importu maximálně zautomatizovat tak, aby se dala provádět pravidelně aktualizace dat (třeba 1x denně nebo týdně ... to je už detail). Kromě vlastního převedení dat bude třeba řešit kolize s daty, které pochází z jiných zdrojů (např. ručně kreslené). Rád bych se na takové automatizaci podílel, protože v tom vidím značný přínos. S pozdravem Honza __**_ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-czhttp://lists.openstreetmap.org/listinfo/talk-cz __**_ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-czhttp://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Data RUIAN - výměnný formát
Tak si odpovídám sám. Snapshoty budou zveřejňovány jednou za měsíc, změnové soubory budou generovány jednou za den. Oboje patrně bude veřejně dostupné ke stažení (jaká bude dostupná historie změnových souborů, to jsem nenašel). To je rozumné a mělo by to umožnit pravidelnou aktualizaci dat v OSM. Honza Dne 24. června 2012 17:55 Jan Bilak jan.bilak@gmail.com napsal(a): Zdravím, díky za info, ještě mám dotazy. Budou průběžně vydávané změnové soubory (popis formátu jsem tam viděl) nebo jen kompletní snapshoty? S jak častou aktualizací dat se počítá (jednou denně, ...)? Honza Dne 24.6.2012 17:26 Jiří Veselý j@seznam.cz napsal(a): Zdravím všechny, s webovými službami se zatím nepočítá, výjimkou bude WS pro ověření adresy. Jinak pokud jde o pokrytí území, tak katastrální data jsou ve výměnném formátu na cca 2/3 katastrálních území (DKM + KMD). Definiční čáry ulic a další prvky jsou v RUIAN přes celou republiku. J. Veselý Dne 22.6.2012 22:12, Martin Kokeš napsal(a): Ano, jde o RÚIAN, veřejný registr bez licence, dle 111/2009 Sb.. Generovaná data jsou už teď ke stažení. Rozhraní VDP ještě není, bude až od 1.7., nevím jak to bude se SOAPem, možná podobně, jako funguje u WSDP ke KN. Více info by asi dal p. Veselý. Využitelné jsou samozřejmě uliční čáry, polygony budov, adresní body, takže je čas udělat tracerům pápá (to platí pro zastavěné území). V souvislosti s WFS službou nad tématem INSPIRE parcely je možné získávat parcely i mimo zastavěné území, buď jako předgenerované soubory, nebo přímo přes WFS dotaz (možná by se ulevilo ZP a jeho tabletu při obkreslování zemědělské půdy ;-)...). Jelikož se všude používá nativně Křovák, je nutná zpřesněná transformace pomocí S-JTSK gridu. MK - Original Message - From: Jan Bilak [mailto:jan.bilak@gmail.com] To: OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org] Sent: Fri, 22 Jun 2012 20:53:02 +0200 Subject: Re: [Talk-cz] Data RUIAN - výměnný formát Ahoj, předem se omlouvám, pokud budu psát nesmysly - moc o tom nevím. Chápu to správně tak, že data budou licenčně použitelné pro OSM, budou obsahovat např. adresní body, obrysy budov, ulice apod., vše zdarma ve formě veřejné dostupné aplikace na bázi XML/SOAP? A nyní data ještě dostupná nejsou, ale budou od příštího měsíce. Data nejsou kompletní, ale zahrnutí jen ty části ČR, které mají digitalizovaný katastr nemovitostí (cca půlka, ale výhledově bude růst). Data budou průběžně aktualizována a budou dostupná ve dvou formátech: a) aktuální stav b) změnové soubory Pokud je to tak je, tak by bylo vhodné celý proces importu maximálně zautomatizovat tak, aby se dala provádět pravidelně aktualizace dat (třeba 1x denně nebo týdně ... to je už detail). Kromě vlastního převedení dat bude třeba řešit kolize s daty, které pochází z jiných zdrojů (např. ručně kreslené). Rád bych se na takové automatizaci podílel, protože v tom vidím značný přínos. S pozdravem Honza ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Data RUIAN - výměnný formát
Ahoj, předem se omlouvám, pokud budu psát nesmysly - moc o tom nevím. Chápu to správně tak, že data budou licenčně použitelné pro OSM, budou obsahovat např. adresní body, obrysy budov, ulice apod., vše zdarma ve formě veřejné dostupné aplikace na bázi XML/SOAP? A nyní data ještě dostupná nejsou, ale budou od příštího měsíce. Data nejsou kompletní, ale zahrnutí jen ty části ČR, které mají digitalizovaný katastr nemovitostí (cca půlka, ale výhledově bude růst). Data budou průběžně aktualizována a budou dostupná ve dvou formátech: a) aktuální stav b) změnové soubory Pokud je to tak je, tak by bylo vhodné celý proces importu maximálně zautomatizovat tak, aby se dala provádět pravidelně aktualizace dat (třeba 1x denně nebo týdně ... to je už detail). Kromě vlastního převedení dat bude třeba řešit kolize s daty, které pochází z jiných zdrojů (např. ručně kreslené). Rád bych se na takové automatizaci podílel, protože v tom vidím značný přínos. S pozdravem Honza Dne 22. června 2012 18:37 Martin Kokeš sh...@typo3-hosting.com napsal(a): Já jsem si udělal pár jednoduchých XSL a přechroustal to pomocí XMLStarletu dvěma kroky (první odstraní ty namespacy a druhý je pak transformace do daného typu vrstvy) do docela importovatelného GML, které jde poslat do QGISu nebo transformovat přes ogr2ogr. Jde třeba hranice ku, hranice obce (nic moc), hranice parcel, hranice budov, budovy jako body, adresni místa jako body... s většinou atributů. Chce se toho někdo ujmout a vylepšit to na nějaký udělátor pro import? Asi by šlo i udělat XSL přímo do OSM formátu, ale Merkaartor zvládne GML levou zadní. MK - Original Message - From: hanoj [mailto:eha...@gmail.com] To: OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org] Sent: Fri, 22 Jun 2012 13:48:11 +0200 Subject: Re: [Talk-cz] Data RUIAN - výměnný formát Ahoj, Po spuštění Veřejného dálkového přístupu k RUIAN budou data dostupná přes tuto aplikaci. Vyborna zprava! Par otazek... * Proc se uziva EPSG:2065, kdyz na data se bezne uziva ESRI:102067? * Je nejaky osvedceny prohlizec, ktery umi data zobrazit krome Snowflake s registraci? In specie OSM - Chapu to tak ze pro OSM jsou pro plne automaticky import pouzitelne vrstvy na uzemi ktera uz ma DKM (v dubnu 2012 55% CR): *AdresniMisto (addr=*) *Stavebni objekt (building=*) *Ulice (name=*) Na uzemi bez DKM je jen Adresni Misto. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Data RUIAN - výměnný formát
Díky. Nevíte o nějakých knihovnách (.NET, Java, JavaScript, C, C++, ...) pro transformaci pomocí toho S-JTSK gridu? Nebo, pokud nejsou přímo knihovny, ve kterých opensource programech s vhodnou licencí by tato transformace šla najít? Honza Dne 22. června 2012 22:12 Martin Kokeš sh...@typo3-hosting.com napsal(a): Jelikož se všude používá nativně Křovák, je nutná zpřesněná transformace pomocí S-JTSK gridu. MK ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] OSM ortofoto
Zdravím, rád bych se na to podíval a případně to nějak zpracoval. Nic neslibuji - nevím, jak to vypadá. A i kdybych to viděl, tak nevím, jak mi to půjde zpracovat. Nicméně rád bych to zkusil. Honza Dne 2. února 2012 14:34 Jakub Sykora kub...@kbx.cz napsal(a): Kolik je to asi tak dat? Mame nejake servery na ktere bychom mohli neco umistit... K Dne 2.2.2012 14:32, Pavel Machek napsal(a): On Tue 2011-12-20 22:35:12, Jan Bilak wrote: Zdravím. Problém vidím v bodě 3. Třeba máš lepší zdroje, spoustu kamarádů pilotů, ale nějak moc nevěřím tomu, že by se toho podařilo dostatek nashromáždit. Přitom, aby to mělo rozumnou kvalitu, tak by to muselo Na disku mam celou CR, cernobilou a starsi ale ve slusny kvalite, redistribuovatelnou. (WMS CENIA). Otazka je jen kde. Najdou se dobrovolnici na zpracovani? Pavel ___ 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] OSM Inspector a stav přijetí licence
Zdravím, mám několik dotazů: 1) Změna licence má nějaké klady a nějaké zápory. Mezi zápory jistě patří ztráta dat z OSM map. To je celkem podstatný zápor. Otázka tedy zní, jaké jsou ty konkrétní podstatné klady, které mají převážit zápory? 2) Změnou licence nedojde ze ztrátě dat obecně, ale ke ztrátě z OSM. Pokud to dobře chápu, tak ve FOSM (což je vzniklá odnož s původní licencí) bude fungovat dále. Má tato odnož k dispozici prostředky, aby mohla reálně fungovat? 3) Pokud někdo bude po rozdělení na OSM a FOSM příspívat do OSM, může tyto změny přebírat FOSM (po stránce licence)? 4) Pokud někdo bude po rozdělení na OSM a FOSM příspívat do FORM, může tyto změny přebírat OSM (po stránce licence)? Chápu, že u bodu 3 a 4 bude technický problém s návaznostmi na stávající data, která nebudou v obou projektech stejná. 5) Jaké praktické důsledky změna licence má? Co někdo dříve mohl a nově nemůže a naopak? Myslím, že už jsem se jednou na to ptal, ale nedostal jasnou odpověď (z čehož jsem usoudil, že to asi není moc jasné nebo o tom spousta lidí neví). 6) V čem bude OSM lepší než FOSM? FOSM bude obsahovat více dat, protože žádná neztratí, ne? Honza Dne 25. ledna 2012 19:23 Petr Morávek [Xificurk] xific...@gmail.com napsal(a): jzvc wrote: Jenze v principu ma pravdu, protoze kvuli tyhle kravine bude znicena prace spousty lidi Ale houby! Práce spousty lidí nebude zničena proto, že se mění licence, ale proto, že pavel momentálně zaujal postoj - chci zničit co nejvíc dat OSM, aby lidi přešli na FOSM. Ono, když se podíváte na statistiky, tak nebýt rozhodnutí pavla a jkjk, tak ztráta dat je prakticky nulová... Ale mají na to rozhodnutí právo, a zbytek komunity se holt bude muset nějak se vzniklou situací vypořádat. Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] hlášení chybného zobrazení katastrální mapy
Zdravím,
omlouvám, že se nyní projektu nevěnuji (nedostatek času). VerticalSkip
tuším bylo kvůli odříznutí nějakého copyrightu, který by dělal při
rozpoznávání problémy v případě, že by někdo kliknul na místo, kde se
zrovna nacházel. Nevím, zda se tam pořád nebo už tam není. Pokud tam
je, že tak to s VerticalSkip=1 bude dělat problémy. Stejně tak větší
dlaždice nemělo příliš smysl dělat, protože pak už tam přibyl další
copyright.
S pozdravem
Honza
2011/11/28 jzvc j...@tpfree.net:
Dne 28.11.2011 15:44, Petr Schonmann napsal(a):
Dne 28.11.2011 10:50, Zdeněk Pražák napsal(a):
Dá se někam nahlásit chybné zobrazení katastrální mapy na cuzk.cz -
zobrazuje se duplicitně digitální mapa i původní rastrová mapa
například v katastrálním území Trusnov
Pražák
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
Mám nastaveno
wms:http://wms.cuzk.cz/wms.asp?FORMAT=image/pngtransparent=TRUEVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=DEF_BUDOVY,dalsi_p_mapy_i,hranice_parcel_i,obrazy_parcel_i,parcelni_cisla_iSRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}
A abych si ještě postěžoval já :) Stejné vrstvy jsem nastavil i do
traceru - jsou to jen digitalizované mapy. V Josm stejnou wms url,
přesto dostávám výsledný polygon z traceru kousek posunutý. Je to bug ?
Neni to bug, je to dany historickym nastavenim v konfiguraci.
jde o toto: downloader verticalSkip=0 tileSize=0.001 resolution=1600
verticalSkip bylo puvodne (od autora) nastaveno na 560, kdyz sem tam
nastavil 0, tak to sedi temer dokonale (a lehce sem zvednul rozliseni na
dvojnasobek zmensenim titlesize, ale to uz spis kvuli ruznym pidi domeckum)
http://tinypic.com/view.php?pic=3160x0gs=5
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Oauth strasi?
Zdravím, situaci ohledně změny licence jsem nesledoval a i když nemám žádný podstatný podíl na editacích v OSM, rád bych si udělal obrázek o tom, o co jde, a nějak se rozhodnul. Můžete mi prosím někdo stručně vysvětlit, v čem jsou zásadní rozdíly mezi licencemi? Jaký je hlavní důvod změny licence? Jaké jsou naopak negativa nové licence, že někteří nesouhlasí (podle té tabulky s licencí nesouhlasí i druhý nejčastější přispěvovatel pavel, který je pořád velmi aktivní). Jakým způsobem je třeba vyjádřit souhlas/nesouhlas a do kdy? Věřím, že tyto informace stručně a jasně shrnuté pomohou i dalším. Díky Honza Dne 21. června 2011 15:36 MP singular...@gmail.com napsal(a): To že vznikne CC-BY-SA fork je skoro jisté, teď už jen doufat, že ten fork bude jen jeden, nebo že pokud jich bude víc, tak ty ostatní rychle vychcípou a zbyde jen jeden (plus někteří lidi chtěli i PD fork, takže je možné, že vznikne ještě jeden fork, kde ale bude asi jen minimum dat) Pokud v ČR zmizí 20 až 25 procent dat (což je aktuální odhad dle té stránky), tak bych tipoval, že lidi nejspíš utečou k cc-by-sa forku, v jiných zemích to může dopadnout jinak (pokud bude dopad mazání minimální, můžou tam lidi zůstat). Úplný rozpad asi nebude, ale tipuju, že se přispěvatelé rozdělí na tři skupiny, jedna co zůstane na ODBl a pokusí se napravit chaos vzniklý smazáním čtvrtiny dat (tipuju to na většinu lesů a vodstva plus asi celkem dost silnic a dalších věcí - může to být méně než čtvrtina pokud se některé podaří přesvědčit aby odbl akceptovali, ale i více, pokud se ukáže že některé importy jsou s novou licencí nekompatibilní a pak by musela data pryč ať už dotyčný souhlasil s odbl nebo ne) a ta se nejspíš časem bude spíše zmenšovat (asi je těžké dávat dohromady mapu, kde po celé republice různé náhodné kousky chybí). Druhá se přesune na cc-by-sa fork, kde budou data všechny (ale je to fork, ne každý o něm ví atd ...). Třetí odejde a přestane mapovat. Tipuju, že žádná z prvních dvou nebude větší než polovina současných uživatelů. Martin On Tue, 21 Jun 2011 14:21:21 +0200, Jakub Sykora wrote: Ja pockam, jak se to vyvine. Kazdopadne pokud to zpusobi rozpad tohoto projektu, bude me to hodne mrzet - adl jsem do toho dost sveho casu a energie, ktera by vysla dost nazmar. A vkladat znovu energii do neceho co bude zase zacinat od piky, to opravdu ne... K Dne 21.6.2011 14:05, Michal Grézl napsal(a): 2011/6/21 Jakub Sykorakub...@kbx.cz: Abych pravdu rekl, tak jsem tohle moc nesledoval i kdyz jsem vedel, ze to dopadne jako pru.er, ale faze 4 me trochu desi a jeste vic po ni faze 5. Pokud bude clovek pro kompletni dataset muset mergovat finalccby.osm a novou odbl databazi, tak to bude pekne na vite co... Tech dat, ktere z DB vypadnou, nebude malo - vizte [1] K [1] http://odbl.de/czech_republic.html Pokud ty data opravdu smazou, coz udelaji, a nikdo je neda zpet, tak se bude muset zustat u forku, nebot zadne mergeovani pravdepodobne nebude mozne. Nehlede na to ze budeme mozna muset vymazat veskera importovana data, u kterych puvodni vlastnik nebude souhlasit s novou licenci. Pro zacatek http://fosm.org/ ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Oauth strasi?
Díky. Ale ještě z toho shrnutí nerozumím, jak to tedy podle nové licence bude v tom modelovém případě: Pokud někdo vaše data používá pro mapu s několika vrstvami v knize, co všechno má být pod CC-BY-SA? Jen vrstva OpenStreetMap a její úpravy? Celá mapa včetně nesouvisejících vrstev a značek? Celá kniha? Tohoto se patrně týká odstavec: Podle nové licence může mapu uvolnit pod jakoukoli licencí chce, pokud uvolní všechny doplňky a vylepšení, které k našim datům přidal. Hlavním důvodem pro tuto změnu je, že mapy lze nyní vytvářet pomocí vrstev z nekompatibilních zdrojů dat. Těmi doplňky se myslí např. software, který použil k vytvoření mapy z dat, data jiných vrstev? Tedy nyní lze vzít OSM data, vytvořit z jich libovolným způsobem mapu (např. pomocí nějakého software, který není volný), dokreslit si na ni nějaké další informace (např. trasu nějakého závodu), které neuvolním ... a tohle po změně licence již nepůjde (tedy s novými daty, které nejsou licencovány i starou licencí)? Tedy změna licence přidává omezení na využití dat? Honza Dne 21. června 2011 16:39 Petr Kadlec petr.kad...@gmail.com napsal(a): Ahoj Můžete mi prosím někdo stručně vysvětlit, v čem jsou zásadní rozdíly mezi licencemi? Věřím, že tyto informace stručně a jasně shrnuté pomohou i dalším. [...] Volne prekladam z [1]: Nechci nějak moc provádět samopropagaci, ale... http://wiki.openstreetmap.org/wiki/Cz:ODbL/We_Are_Changing_The_License :-) -- Petr Kadlec / Mormegil ___ 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] Oauth strasi?
Řekněme, že by se opravdu někdo našel a data začal prodávat. Kdo by je ale koupil, kdy je může získat zdarma přímo z OSM? Jistě - někdo by se najít mohl, ale nevidím v tom žádné podstatné riziko. Obdobně vydělávat lze např. i prodejem GPL software, ale kdo GPL software kupoval, když jej může mít zdarma? Také by mohl data nějak vylepšit a prodat vylepšená data. Ale to je velmi podobný případ. Kdo by koupil takto vylepšená data za větší cenu než je cena tohoto vylepšení? Mohl by si totiž vzít zdarma data z OSM a vylepšit si je stejně. Honza Dne 21. června 2011 17:43 Jakub Sykora kub...@kbx.cz napsal(a): Přirozenou nevýhodou demokracie je, že těm, kdo to s ní myslí poctivě, nesmírně svazuje ruce, zatímco těm, kteří ji neberou vážně, umožňuje téměř vše. (V. Havel) Jinymi slovy - cela tahle habadura se dela vlastne jen proto, ze by v budoucnu (nebo soucasnosti) mohl nekdo vytezovat OSM a prodavat to jako svoji praci. Xfree a Xorg - celkem hezke prirovnani - akorat u Xek neni ten vyvoj tak strasne rychly jako u OSM... Navic ne mala skupina lidi podporila zmenu na ODBL (skoro 50% vsech) Bohuzel OSM pro me neni jen ta databaze ale i vsechno kolem - servery, sluzby - a to neni malo. Neumim si v tuhle chvili predstavit zivotaschopny fork. K Dne 21.6.2011 17:08, Stanislav Brabec napsal(a): Jakub Sykora píše v Út 21. 06. 2011 v 16:20 +0200: - to znamena, ze hodni hosi legalne nemuzou vlastne data pouzivat a zli hosi je muzou beztak vyuzivat jak chteji Takže chápu-li to dobře, tak proto, aby zlí hoši nemohli kopírovat mou práci, tak hodní hoši čtvrtinu mé práce zničí. S novou licencí jsem souhlasil. Souhlasil jsem s tím, aby mé příspěvky byly public domain. Ale hrubě nesouhlasím s tím, aby se mé příspěvky mazaly z jakéhokoliv vnitřně politického důvodu. Pokud to provedou, projektu OpenStreetMap předpovídám budoucnost XFree86. Ten projekt také dodnes existuje a vydává své verze, ale téměř všichni uživatelé utekli po vnucené změně licence k forku - k Xorg. ___ 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 adresních bodů - Nekonzistenc e cuzk:km a mvcr:adresa
Ahoj, souhlasím. Hranice mají tu výhodu, že je lze dobře vykreslovat na mapě. Z stromového/svazového (dále budu psát jen o stromu, i když možná by šlo obecně o svaz kvůli městským částem a částem obcí apod.) by se pro vykreslení musela hranice vždy počítat - jinak si nedovedu představit nějaké rozumné vykreslení na mapě (barvení budov apod. není myslím dobrý nápad). Stromovou strukturu poskytuje v rozumné podobě UIR-ADR. Tato DB se i průběžně aktualizuje a je tedy vhodné si udržovat na ni vazby. A to ideálně před ty kódy, které jsou v této DB. Nevím, kdo je vymyslel (asi jsou to nějaké číselníky statistického úřadu), ale hojně se používají (např. katastr, ARES apod.). A tyto kódy bych tedy navrhoval doplnit ke všem objektům (krajům, obcím, částem obce, budovám, ...), kde to bude možné. Usnadní se tak mimo jiné i možnost automatické aktualizace OSM podle UIR-ADR. Když budou data jak ve formě hranice, tak ve formě stromu/svazu, tak to znamená duplicity v datech a spoustu problémů při změnách. Otázka je, zda ty změny jsou tady tak časté, aby mělo smysl na tím uvažovat. Ideální by podle mne bylo, mít jako primární jeden způsob uchování vztahů mezi objekty pro každou dvojici typů objektů. Tedy např. stanovit, že vztahy mezi objekty (budovami) a částmi obce bude primárně ve formě stromu a hranice částí obcí se budou dopočítávat. Na dopočítávání by se udělala nějaká utilitka. Dopočítávání až při kreslení ... nevím, zda je reálné, ale obecně nějaké dopočítávané cache informace v OSM obecně nepovažuji za špatné - jen je třeba s nimi tak zacházet. Hierarchie UIR-ADR je znázorněna tady a stejná hierarchie by neškodila v OSM: http://forms.mpsv.cz/uir/prohlizec/prohlizec.html S těmi SVJčky máš asi pravdu - koukal jsem namátkově na několik SVJ. Získat automaticky polohu dalších vchodů (čísel popisných) si nedovedu moc představit - tedy nevím, z čeho. Ale zjistit čísla popisná, která tvoří jednu budovu v katastru, není takový problém - a to právě z katastru nemovitostí. Otázka ale je, jak je to licencí těchto dat. Pokud by to šlo legálně využít, tak nějaká data mohu dodat (mám toho tady poměrně hodně předzpracovaného). Honza Dne 30. září 2010 15:27 Ondrej Zajicek santi...@crfreenet.org napsal(a): On Thu, Sep 30, 2010 at 12:53:56PM +0200, jzvc wrote: A jinak jo, v is_in muze byt cela hierarchie. Pavel Jak bylo receno, je to z historickych duvodu, ale u nove vkladanych dat bych to tam necpal, postrada to smysl. Ony se casem aplikace naucej pouzivat hranice a pak bude mozny to odstranit. Je otazka, zda ma kvuli takovym vecem smysl pouzivat hranice, zda by nebylo mnohem lepsi mit nekde zvlast hierarchicka data ve forme stromu nebo svazu, ktere by aplikace pouzivaly pro urceni nadrazenych celku. Reseni vyuzivajici geometrickou hranici ma nevyhody jednak kvuli nekonzistenci dat (napr. zmineny problem s objekty blizko hranice, kde je nekonzistence mezi hranici v OSM a u uradu. Opravit tag urcujici nadrazeny celek je jednoduche, ale opravit hranici (bez vhodneho zdroje dat slouziciho jako podklad) je vyrazne komplikovanejsi. Krom toho reseni skrz hranice nemusi byt v nekterych pripadech vubec mozne - AFAIK casti obce (v ramci obce) nejsou vymezene hranicema, ale ciste formalnim rozdelenim objektu (budov), aby platila jedinecnost cisla popisneho/evidencniho v ramci casti obce. V nekterych obcich (co jsem si vsiml v KN) treba budovy s cislem popisnym jsou rozdelene na casti obce podle toho kde lezi, ale skoro vsechny budovy s cislem evidencnim jsou prirazene k 'hlavni' casti obce. Druhy problem je, ze jak addr:city, tak ani is_in (v soucasne podobe ziskane importem adres) neni v nekterych pripadech dostatecny. is_in (generovany importem adres z CUZK a KN) obsahuje cast obce, obec a kraj, jenze jmena obci jsou unikatni jen v ramci okresu a i v ramci kraju existuje par set kolizi. Mam napsany programek na validaci importovanych adres v OSM, ale na tomhle selhava. Mozna by bylo dobre zavest nejaky cesky specificky atribut udavajici kod casti obce unikatni v CZ (treba ten pouzivany v registru CUZK, nebo nektery jiny oficialni) a udavat ho u adresnich bodu v CZ. To by dost usnadnilo validaci a pripadne pozdejsi automaticke udrzovani konzistence s daty CUZK ci automaticke upravy osatnich tagu adres na zaklade dat z CUZK. Jinak jeste je tu jeden nesouvisejici problem s importama adres z CUZK a KN. Vypada to, ze kdyz se druzstevni domy konvertovaly na SVJ, tak v KN je pro ne jen jeden adresni bod (s jednim c.p.), prestoze realne jde o vic c.p. . Tohle generuje znacnou cast nenalezenych adres z CUZK. Je otazka, zda by slo tohle nejak (polo)automaticky opravit. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) To err is human -- to blame it on a computer is even more so. -BEGIN PGP
Re: [Talk-cz] Import adresních bodů - Nekonzistenc e cuzk:km a mvcr:adresa
Ahoj, Jak už jsem napsal dvakrát, tak si myslím, že název obce je součástí adresy, a měl by bít součástí adresního bodu. Jednak kvůli problémům s přesností hranic obce, jednak kvůli rozdílům v úředních databázích, ale především kvůli tomu, že z dat není jasné, který nadřazený celek má vlastně na té adrese být a u částí obce v datech vůbec není. Jak se to vezme. Pokud bychom se chtěli vyhnout duplicitám, tak v adrese patrně stačí: - část obce - číslo domovní - ulice (náměstí, ..., obecně UVP) - číslo orientační Každá část obce pak jednoznačně patří do nějaké obce. Obec patří do okresy atp. Přesně podle toho schematu: http://forms.mpsv.cz/uir/prohlizec/prohlizec.html Obec pak lze zjistit přes část obce. A pokud bychom duplicity považovali z nějakého důvodu užitečné, tak by bylo dobré jasně prohlásit takové údaje za duplicity (jakési sekundární vyjádření informací, které jsou primárně vyjádřené nějak jinak), a které se budou aktualizovat automaticky podle primárního vyjádření informací a tak bude zaručena konzistence dat a snadnost aktualizací. Doplňovat tam celý strom mi ale přijde trochu zbytečné. Mít v OSM informace o všech objektech, které jsou v UIR-ADR mi přijde poměrně užitečné. Nakonec OSM chápu jako takovou DB, do které se importují všechna užitečná geo data, která jsou licenčně dostupná. A když tam budou ty objekty, tak by tam měly být i jejich vzájemné vztahy. Zda ten vztah bude primárně vyjádřen hranicí nebo atributem patří_do, to je už je věc jiná a zde by podle mne mělo záležet na tom, jak je daný vztah primárně definovaný (např. nějakým zákonem, opatřením ČSÚ apod.). Sekundárně může být vyjádřen i jinak, ale sekundární vyjádření lze již doplňovat automaticky z primárního vyjádření. Takový postup podle mne usnadní aktualizace. Honza 2010/9/30 Petr Dlouhý petr.dlo...@email.cz: Ahoj, mám pocit, že Nominatim si ten strom bez problému generuje z dat, takže pro většinu běžných použití to bohatě stačí. Napojení na úřední databáze pomocí čísel je samozřejmě víc než vhodné udělat v každém případě. Jak už jsem napsal dvakrát, tak si myslím, že název obce je součástí adresy, a měl by bít součástí adresního bodu. Jednak kvůli problémům s přesností hranic obce, jednak kvůli rozdílům v úředních databázích, ale především kvůli tomu, že z dat není jasné, který nadřazený celek má vlastně na té adrese být a u částí obce v datech vůbec není. Doplňovat tam celý strom mi ale přijde trochu zbytečné. On Thu, 30 Sep 2010 16:16:59 +0200, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, souhlasím. Hranice mají tu výhodu, že je lze dobře vykreslovat na mapě. Z stromového/svazového (dále budu psát jen o stromu, i když možná by šlo obecně o svaz kvůli městským částem a částem obcí apod.) by se pro vykreslení musela hranice vždy počítat - jinak si nedovedu představit nějaké rozumné vykreslení na mapě (barvení budov apod. není myslím dobrý nápad). Stromovou strukturu poskytuje v rozumné podobě UIR-ADR. Tato DB se i průběžně aktualizuje a je tedy vhodné si udržovat na ni vazby. A to ideálně před ty kódy, které jsou v této DB. Nevím, kdo je vymyslel (asi jsou to nějaké číselníky statistického úřadu), ale hojně se používají (např. katastr, ARES apod.). A tyto kódy bych tedy navrhoval doplnit ke všem objektům (krajům, obcím, částem obce, budovám, ...), kde to bude možné. Usnadní se tak mimo jiné i možnost automatické aktualizace OSM podle UIR-ADR. Když budou data jak ve formě hranice, tak ve formě stromu/svazu, tak to znamená duplicity v datech a spoustu problémů při změnách. Otázka je, zda ty změny jsou tady tak časté, aby mělo smysl na tím uvažovat. Ideální by podle mne bylo, mít jako primární jeden způsob uchování vztahů mezi objekty pro každou dvojici typů objektů. Tedy např. stanovit, že vztahy mezi objekty (budovami) a částmi obce bude primárně ve formě stromu a hranice částí obcí se budou dopočítávat. Na dopočítávání by se udělala nějaká utilitka. Dopočítávání až při kreslení ... nevím, zda je reálné, ale obecně nějaké dopočítávané cache informace v OSM obecně nepovažuji za špatné - jen je třeba s nimi tak zacházet. Hierarchie UIR-ADR je znázorněna tady a stejná hierarchie by neškodila v OSM: http://forms.mpsv.cz/uir/prohlizec/prohlizec.html S těmi SVJčky máš asi pravdu - koukal jsem namátkově na několik SVJ. Získat automaticky polohu dalších vchodů (čísel popisných) si nedovedu moc představit - tedy nevím, z čeho. Ale zjistit čísla popisná, která tvoří jednu budovu v katastru, není takový problém - a to právě z katastru nemovitostí. Otázka ale je, jak je to licencí těchto dat. Pokud by to šlo legálně využít, tak nějaká data mohu dodat (mám toho tady poměrně hodně předzpracovaného). Honza Dne 30. září 2010 15:27 Ondrej Zajicek santi...@crfreenet.org napsal(a): On Thu, Sep 30, 2010 at 12:53:56PM +0200, jzvc wrote: A jinak jo, v is_in muze byt cela hierarchie. Pavel Jak bylo receno, je to z historickych duvodu, ale u nove vkladanych
Re: [Talk-cz] Import adresních bodů - Nekonzistenc e cuzk:km a mvcr:adresa
Problem je, ze toto neni adresa. Ve vetsine obci, ktere maji i sve casti, je urcujici adresa ulice + cp + obec + psc. Z psc se da (pokud je spravne) urcit cast obce. Cast obce (tu oficialni) spousta lidi ani nezna. Klidne muzu uvest konkretni priklad, v Teplicich je cast Trnovany a cast Sanov, ale existuje prostor, kteremu se odjakziva rika Sanov II, presto, ze oficielne je soucasti mestske casti Trnovany. Vetsina lidi ale vubec netusi ze bydli v Trnovanech, protoze za ty je oznacovana starsi zastavba, nikoli sidliste na kopci. Dobře, ale co tím chceš říct? Co je to adresa? Všechny informace o daném místě? Minimální množství údajů, které identifikuje dané místo? Nevím a o pojmy stejně nejde. Je jasné, že pro danou adresu musí jít lehce zjistit všechno, co je možné - část obce, obec, okres, kraj, psč, stát, ... prostě všechno. Ale neznamená to automaticky, že ty všechny informace musí být u daného adresního nodu. Obdobné je to třeba v relačních (typicky SQL) databázích, které se typicky navrhují ve 3. normální formě, která víceméně kromě jiného volně řečeno říká, že jedna informace tam má být zanesena pouze jednou. Ústupky z normální formy se typicky dělají pouze z výkonostních důvodů. A i v SQL databázích jsou nástroje pro výkonostní optimalizaci bez narušení normální formy - např. materializované pohledy. Tedy jde vlastně u uchování duplicitních dat v nějakém tvaru, který je výhodný pro rychlou práci, a který se automaticky aktualizuje podle primárních údajů v tabulkách. A obdobně bych si dovedl představit, že automat bude doplňovat např. obec k adresnímu místu a to tak, že se podívá na adresní místo, do jaké části obce patří. A pak na danou část obce, do jaké obce tato část obce patří. A co s případy, kde si lidé myslí něco jiného než je oficiální rozdělení? Nevím. Buď to ignorovat - proč zanášet do OSM nepravdivé informace? Nebo to tam zapsat jako nějaký jiný tag typu nezanedbatelná skupina lidí si myslí, že tohle je ..., i když to není pravda, což pak může nějaká aplikace využít pro nějaké hledání. Honza 2010/9/30 jzvc j...@tpfree.fdns.net: Problem je, ze toto neni adresa. Ve vetsine obci, ktere maji i sve casti, je urcujici adresa ulice + cp + obec + psc. Z psc se da (pokud je spravne) urcit cast obce. Cast obce (tu oficialni) spousta lidi ani nezna. Klidne muzu uvest konkretni priklad, v Teplicich je cast Trnovany a cast Sanov, ale existuje prostor, kteremu se odjakziva rika Sanov II, presto, ze oficielne je soucasti mestske casti Trnovany. Vetsina lidi ale vubec netusi ze bydli v Trnovanech, protoze za ty je oznacovana starsi zastavba, nikoli sidliste na kopci. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] tema bakalarky
Ahoj, myslím, že by se těch témat našlo o dost více, ale jde spíše o to, co by tě bavilo dělat (nemyslím konkrétně, to bys pak téma nehledala), ale druh práce (hromadné zpracování dat, algoritmické úlohy, desktopové aplikace, klientskou část webové aplikace, serverové aplikace, propojování existujících služeb, teoreticky zaměřená práce, ...). Honza 2010/9/20 Anna Kratochvílová kratocha...@seznam.cz: Díky za rychlou odpověď, ještě se na to podívám podrobněji a případně prodiskutuji s vyučujícím. Kdybych se pro něco takového rozhodla, určitě se ozvu. Anna Kratochvílová Původní zpráva Od: Radek Bartoň black...@post.cz Předmět: Re: [Talk-cz] tema bakalarky Datum: 20.9.2010 21:58:36 Ahoj, Ahoj. v současnosti hledám téma bakalářské práce (studuji Geoinformatiku na ČVUTu), tak mne napadlo, jestli byste mi někdo nenavrhnul něco souvisejícího s OSM. S OSM jsem se setkala jen okrajově, ale projekt mne zaujal. Přiznám se, že nejsem žádný rozený programátor, ale programování se nevyhýbám, jen preferuji Python. S databázemi mám také nějaké zkušenosti. Pokuď vás napadne něco užitečného, co bych byla schopná napsat (v rozsahu bakalářky), napište prosím. Díky Anna Kratochvílová Co se týče projektu OpenTrackMap, tak zde by se našlo spousta dílčích problémů k implementaci: * Výpočet výškového profilu cesty, podobně jako u http://tchor.fi.muni.cz:8080/ * Výpočet délky/času trasy. * Integrace s routovacími službami jako je http://openrouteservice.org/ nebo implementace vlastní specializované pro účely pěší turistiky. * Integrace se službami poskytujícími georeferencované data jako je např. Panoramio, Flickr, 360 Cities, OpenStretView, OpenStreetPhoto, GeoRSS, atp. * Nedávno zmiňovaná podpora uploadu georeferencovaných obrázků rozcestníků. * Uživatelsky editovatelné osobní mapy (podobně jako u Google Maps). * Samotné definování Mapnik stylu s turisticky zajímavými POI, který mám v plánu, ale ještě jsem se k tomu nedostal. * atd, atd, vše by se ale asi implementovalo většinou v JavaScriptu. Dalším možným tématem by mohla být služba (Python+PgSQL) zobrazující přehledněji změny dat OpenStreetMap v daném bounding boxu, podobně jako záložka Historie v na http://openstreetmap.org, ale místo dotazu typu: Vyber všechny seznamy změn, v nichž je element v bounding boxu XY. by zobrazovala dotazy typu: Vyber všechny změněné elementy v bounding boxu XY. Snad je můj popis daných problému alespoň částečně srozumitelný. Kdyby ne, vysvětlím podrobněji. S pozdravem, Radek Bartoň. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] OSM tracer fix
Ahoj, máš nějakou konkrétní potřebu tam začlenit nějakou GPL knihovnu, pro kterou není alternativa pod jinou vhodnou licencí? Honza Dne 16. září 2010 8:01 Pavel Machek pa...@ucw.cz napsal(a): On Wed 2010-09-08 22:54:21, Jan Bilak wrote: Ahoj, v licencích se moc neorientuji. Představoval bych si to tak, že program lze bez omezení použít pro přípravu dat do projektu OpenStreetMap. Program lze bez omezení šířit a měnit s tím, že bude zachována a přiložena tato licence. Program ale nelze použít pro přípravu dat, které by byly komerčně využity, aniž by před tímto využitím byly uploadovány do projektu OpenStreetMap pod licencí, kterou OSM vyžaduje. Prosim prosim, dejte tam proste GPL. Pak pujdou pridavat do traceru casti jinych (BSD, GPL) svobodnych programu, a pujde to hostovat ve streetmapi SVNce, kam to patri... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ 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] OSM tracer fix
Ještě mne napadnul codeplex.com ... který poskytuje dobré zázemí a pro .NET projekty je jak dělaný. Licence jsem tam tuším viděl všelijaké, ale třeba se pletu. Honza Dne 9. září 2010 19:37 jan.bilak@gmail.com jan.bilak@gmail.com napsal(a): Ahoj, pokud to opravdu není žádný problém, tak by to bylo fajn. Jinak jsem našel třeba unfuddle.com. Akorát jsou tam jen dva účty, takže by se muselo řešit pod společným účtem. Ale to při předpokládané četnosti změn mi nepřijde jako příliš neomezující. Stejně je otázka, jak by účty vznikaly u tebe. Asi jen ručně - tedy další práce s tím, že? Honza - Reply message - Od: Aleš Janda Datum: čt, 9. 9, 2010 19:25 Předmět: [Talk-cz] OSM tracer fix Komu: OpenStreetMap Czech Republic Ahoj, 2) hodí se to někam jinam - má někdo nějaký server kde by mohl být svn nebo jiný (git?) repozitář? Vzhledem k tomu, že nejde o svobodný sotware, tak github, sourceforge a podobné využít nepůjdou. Zřídit SVN nebo GIT server není problém, můžu udělat u mě (tam co teď běží izometrická mapa apod.). Kdyžtak mi napište. Aleš Janda Dne 9.9.2010 01:50, MP napsal/a: On 2010-09-08, Jan Bilak wrote: Hmmm, tak pokud je jediný problém to, že k tomu nemohu napsat, že je to svobodný software, tak to nevidím jako problém. Šlo mne o podporu U svobodných licencí je jen omezení co člověk může dělat se zdrojáky a progamem ohledně distribuce, ne už ohledně používání programu. Stímhle omezením už to technicky nepatří mezi svobodný software (což ale pro účely použití v OSM vůbec nevadí :). projektu OSM a ne o to, aby program např. používala nějaká firma pro přípravu map, které pak bude prodávat. Vzhledem k tomu, že výstup z traceru pořád potřebuje celkem dost ruční práce, tak mi takovéhle použití přijde nepravděpodobné. K něčemu takovému by to museli jednak dost vylepšit, jednak tam přidat další části, jako třeba něco co určí kde začít trasovat. A pak by měli jen budovy - myslím si, že ty snadněji získají odjinud. Tak s tímhle to asi nepůjde dát do SVN openstreetmap, nevím jestli tam jdou cpát věci co nejsou svobodný software. Vidím to asi tak na 2 alternativy - 1) zdrojáky, binárky a případná vylepšení budou kolovat mailinglistem jako dosud. 2) hodí se to někam jinam - má někdo nějaký server kde by mohl být svn nebo jiný (git?) repozitář? Vzhledem k tomu, že nejde o svobodný sotware, tak github, sourceforge a podobné využít nepůjdou. Martin ___ 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] OSM tracer fix
Tak codeplex.com patrně umožnuje jen některé licence. Ale ještě jsem našel xp-dev.com ... nabízí 200 MB pro dva privátní projekty nebo neomezeně veřejných, neomezený počet uživatelů, SVN. Akorát patrně se zálohování to není žádná sláva, ale to se u free dá celkem pochopit a stejně to bude mít několik lidí (včetně mne) u sebe. Když mi vyjde čas, večer to tam založím. Honza 2010/9/9 Jan Bilak jan.bilak@gmail.com: Ještě mne napadnul codeplex.com ... který poskytuje dobré zázemí a pro .NET projekty je jak dělaný. Licence jsem tam tuším viděl všelijaké, ale třeba se pletu. Honza Dne 9. září 2010 19:37 jan.bilak@gmail.com jan.bilak@gmail.com napsal(a): Ahoj, pokud to opravdu není žádný problém, tak by to bylo fajn. Jinak jsem našel třeba unfuddle.com. Akorát jsou tam jen dva účty, takže by se muselo řešit pod společným účtem. Ale to při předpokládané četnosti změn mi nepřijde jako příliš neomezující. Stejně je otázka, jak by účty vznikaly u tebe. Asi jen ručně - tedy další práce s tím, že? Honza - Reply message - Od: Aleš Janda Datum: čt, 9. 9, 2010 19:25 Předmět: [Talk-cz] OSM tracer fix Komu: OpenStreetMap Czech Republic Ahoj, 2) hodí se to někam jinam - má někdo nějaký server kde by mohl být svn nebo jiný (git?) repozitář? Vzhledem k tomu, že nejde o svobodný sotware, tak github, sourceforge a podobné využít nepůjdou. Zřídit SVN nebo GIT server není problém, můžu udělat u mě (tam co teď běží izometrická mapa apod.). Kdyžtak mi napište. Aleš Janda Dne 9.9.2010 01:50, MP napsal/a: On 2010-09-08, Jan Bilak wrote: Hmmm, tak pokud je jediný problém to, že k tomu nemohu napsat, že je to svobodný software, tak to nevidím jako problém. Šlo mne o podporu U svobodných licencí je jen omezení co člověk může dělat se zdrojáky a progamem ohledně distribuce, ne už ohledně používání programu. Stímhle omezením už to technicky nepatří mezi svobodný software (což ale pro účely použití v OSM vůbec nevadí :). projektu OSM a ne o to, aby program např. používala nějaká firma pro přípravu map, které pak bude prodávat. Vzhledem k tomu, že výstup z traceru pořád potřebuje celkem dost ruční práce, tak mi takovéhle použití přijde nepravděpodobné. K něčemu takovému by to museli jednak dost vylepšit, jednak tam přidat další části, jako třeba něco co určí kde začít trasovat. A pak by měli jen budovy - myslím si, že ty snadněji získají odjinud. Tak s tímhle to asi nepůjde dát do SVN openstreetmap, nevím jestli tam jdou cpát věci co nejsou svobodný software. Vidím to asi tak na 2 alternativy - 1) zdrojáky, binárky a případná vylepšení budou kolovat mailinglistem jako dosud. 2) hodí se to někam jinam - má někdo nějaký server kde by mohl být svn nebo jiný (git?) repozitář? Vzhledem k tomu, že nejde o svobodný sotware, tak github, sourceforge a podobné využít nepůjdou. Martin ___ 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] OSM tracer fix
Ahoj, v licencích se moc neorientuji. Představoval bych si to tak, že program lze bez omezení použít pro přípravu dat do projektu OpenStreetMap. Program lze bez omezení šířit a měnit s tím, že bude zachována a přiložena tato licence. Program ale nelze použít pro přípravu dat, které by byly komerčně využity, aniž by před tímto využitím byly uploadovány do projektu OpenStreetMap pod licencí, kterou OSM vyžaduje. Aneb když připravíš data pro OSM, tak neaplikuj žádná omezení a klidně data použij i komerčně. Pokud program použiješ, ale o výsledná data se nepodělíš vprojektu OSM, tak data nesmíš komerčně použít (tím se vyřeší to, že třeba data z nějakého důvodu zahodíš nebo předáš někomu jinému pro dopracování, než se uploadnou do OSM). Pokud v tom vidíte nějaký problém, řekněte. Třeba je to blbost. Honza Dne 8. září 2010 22:33 MP singular...@gmail.com napsal(a): On 2010-09-07, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, díky za úpravy. Na SVNko OSM to samozřejmě klidně dejte - bude to nejlepší. Jen pak prosím sem do maillistu napište na to odkaz, kde se to dá najít. No tak momentálně zdrojáky neobsahují žádnou licenci, takže pro publikování někde v SVNku OSM by chtělo minimálně vymyslet pod jakou licencí to tam dát (GPL2? GPL3? BSD? Jiná? ) no a potom by se to už asi mohlo nechat aby se to nějak vyvíjelo - zatím jsem pro to napsal jeden patch, kde je možné specifikovat adresář pro cache, aby to neplnilo adresář s binárkou cachovanými daty, takže ten bych tam pak mohl přidat :) Mohl bych to tam pak hodit (musel bych k tomu dopsat min. nějakékrátké readme a info o autorivi, licenci, k čemu ten program je a tak ...)... asi bych to tam dal do http://svn.openstreetmap.org/applications/utils/ a tam bych vytvořil adresář tracer-server Martin Honza 2010/9/7 hanoj eha...@gmail.com: binarka http://openstreetmap.cz/tracer/tracer7patched.tar.gz *** supr funguje to, na CZ:wiki pluginu jsem pridal odkaz. diky hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] OSM tracer fix
Hmmm, tak pokud je jediný problém to, že k tomu nemohu napsat, že je to svobodný software, tak to nevidím jako problém. Šlo mne o podporu projektu OSM a ne o to, aby program např. používala nějaká firma pro přípravu map, které pak bude prodávat. Honza Dne 8. září 2010 23:09 Aleš Janda openstreet...@kyblsoft.cz napsal(a): Ahoj, tak přesně takovouhle licenci jsem chtěl taky pro svůj program, jenže pak se stává nesvobodným, viz http://www.abclinuxu.cz/poradna/programovani/show/297980 Nakonec jsem to vyřešil GPLv3. Aleš Janda Dne 8.9.2010 22:54, Jan Bilak napsal/a: Ahoj, v licencích se moc neorientuji. Představoval bych si to tak, že program lze bez omezení použít pro přípravu dat do projektu OpenStreetMap. Program lze bez omezení šířit a měnit s tím, že bude zachována a přiložena tato licence. Program ale nelze použít pro přípravu dat, které by byly komerčně využity, aniž by před tímto využitím byly uploadovány do projektu OpenStreetMap pod licencí, kterou OSM vyžaduje. Aneb když připravíš data pro OSM, tak neaplikuj žádná omezení a klidně data použij i komerčně. Pokud program použiješ, ale o výsledná data se nepodělíš vprojektu OSM, tak data nesmíš komerčně použít (tím se vyřeší to, že třeba data z nějakého důvodu zahodíš nebo předáš někomu jinému pro dopracování, než se uploadnou do OSM). Pokud v tom vidíte nějaký problém, řekněte. Třeba je to blbost. Honza Dne 8. září 2010 22:33 MPsingular...@gmail.com napsal(a): On 2010-09-07, Jan Bilakjan.bilak@gmail.com wrote: Ahoj, díky za úpravy. Na SVNko OSM to samozřejmě klidně dejte - bude to nejlepší. Jen pak prosím sem do maillistu napište na to odkaz, kde se to dá najít. No tak momentálně zdrojáky neobsahují žádnou licenci, takže pro publikování někde v SVNku OSM by chtělo minimálně vymyslet pod jakou licencí to tam dát (GPL2? GPL3? BSD? Jiná? ) no a potom by se to už asi mohlo nechat aby se to nějak vyvíjelo - zatím jsem pro to napsal jeden patch, kde je možné specifikovat adresář pro cache, aby to neplnilo adresář s binárkou cachovanými daty, takže ten bych tam pak mohl přidat :) Mohl bych to tam pak hodit (musel bych k tomu dopsat min. nějakékrátké readme a info o autorivi, licenci, k čemu ten program je a tak ...)... asi bych to tam dal do http://svn.openstreetmap.org/applications/utils/ a tam bych vytvořil adresář tracer-server Martin Honza 2010/9/7 hanojeha...@gmail.com: binarka http://openstreetmap.cz/tracer/tracer7patched.tar.gz *** supr funguje to, na CZ:wiki pluginu jsem pridal odkaz. diky hanoj ___ Talk-cz mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list talk...@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 ___ 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] OSM tracer fix
Ahoj, díky za úpravy. Na SVNko OSM to samozřejmě klidně dejte - bude to nejlepší. Jen pak prosím sem do maillistu napište na to odkaz, kde se to dá najít. Honza 2010/9/7 hanoj eha...@gmail.com: binarka http://openstreetmap.cz/tracer/tracer7patched.tar.gz *** supr funguje to, na CZ:wiki pluginu jsem pridal odkaz. diky hanoj ___ 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 adres okresu Benešov
Ahoj. Stiskni START. Zvol položku Spustit a napiš: cmd.exe a stiskni ENTER napiš CD C:\Users\Zdeněk Pražák\osmosis (vcetne uvozozovek) a stiskni ENTER. Nyní se ti zobrazí: C:\Users\Zdeněk Pražák\osmosis napiš osmosis.bat a stiskni ENTER. Ale co to bude dělat, to nevím. Osmosis jsem nikdy nepoužil. Honza 2010/9/7 Zdeněk Pražák zpra...@seznam.cz: asi jsem nějak natvrdlý ale nejsde mi to. osmosis jsem rozbalil do adresáře c:\Users\Zdeněk Pražák\osmosis Spustím cmd.exe nastavím adresář c:\Users\Zdeněk Pražák\osmosis a napíši c:\Users\Zdeněk Pražák\osmosis\osmosis.bat a napíše mi že osmosis.bat není názvem vnitřního ani vnějšího příkazu, spustitelného programu nebo dávkového souboru totéž mi píše i když nastavím adresář c:\Users\Zdeněk Pražák\osmosis\bin\osmosis.bat Původní zpráva Od: Michal Grézl michal.gr...@openstreetmap.cz Předmět: Re: [Talk-cz] Import adres okresu Benešov Datum: 07.9.2010 20:35:04 2010/9/7 Zdeněk Pražák zpra...@seznam.cz: no ale jak ho mám spustit, když na něj poklepu, otevře se okno a hned zase zmizí a ani si nemohu přečíst co je v něm napsáno, cudl start pak spustit napsat cmd.exe odentrovat napsat cd adresar_ve_kerem_je_osmosis.bat osmosis.bat nebo pokud se to musi pustit s tim bin tak cd adrresar_kde_je_bin a pak bin\osmosis.bat jinak receno pustit ho v prikazovem radku -- Michal Grézl http://openstreetmap.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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] OSM tracer fix
Ahoj, z důvodu nedostatku času jsem se k tomu pořádně nedostal. Tady jsou zdrojáky, kde jsem to nahrubo připravil, ale netestoval jsem to a ani nezjišťoval, jaká je vlastně nová adresu wms serveru či co jiného se změnilo. Doufám, že se najde někdo, kdo to dotáhne. Kdyby tam něco chybělo, dejte vědět ... snad jsem nevzal nějakou starou verzi ... dělal jsem to dost na rychlo. http://jabi.aspone.cz/osm/TraceServerBeta7-src.zip Honza 2010/9/6 Zdeněk Pražák zpra...@seznam.cz: Dne 2. 9. 2010 Jan Bilak napsal: Ahoj, urcite ... jen, co se k tomu dostanu (asi pred vikend). Honza Dne 1. září 2010 10:54 hanoj ehanoj na gmail.com napsal(a): Ahoj Honzo, dnes doslo ke zmene nastaveni KM na WMS CUZK. Bylo by mozno upravit tracer na novy stav pripadne rovnou nechat moznost si nastavit zdrojovy server v konfiguraku? diky hanoj Mohu se zeptat, jaký je stav aktualizace traceru Děkuji, Pražák ___ 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] OSM tracer fix
Ahoj, urcite ... jen, co se k tomu dostanu (asi pred vikend). Honza Dne 1. září 2010 10:54 hanoj eha...@gmail.com napsal(a): Ahoj Honzo, dnes doslo ke zmene nastaveni KM na WMS CUZK. Bylo by mozno upravit tracer na novy stav pripadne rovnou nechat moznost si nastavit zdrojovy server v konfiguraku? diky hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] nefunkční tracer
Zdravím, zkoušel jsem tracer se starým JOSM 2561 na jedné oblasti a trasoval v pohodě - stahované mapy vypadaly obdobně jako dříve. Za jakých podmínek to nefunguje? Záleží na oblasti nebo na něčem jiném? Honza 2010/7/14 hanoj eha...@gmail.com: IMHO Tracer ma WMS nastaveno URL natvrdo. Problem na prvni pohled je ze, mapa KN je jineho charakteru, nema spojite linie, resp. je ma tensi a jsou mezi nimi obcas diry. tady bych si dovolil to trochu bránit :-) DKM momentálně vzniká z vektorových dat, takže by tam díry být neměly. Pokud ano, prosím o ukázku. Možná mohou být problémy s hranicemi parcel pro měřítko nad 1:3000 nebo s vnitřní kresbou - tam je použita 1 px linie a ta v obecném směru nemůže být spojitá. *** viz http://osm.templ.net/wms-josm.png podle HTTP req: http://wms.cuzk.cz/wms.asp?service=WMSVERSION=1.Zdravím,1.1REQUEST=GetMapSRS=EPSG:4326LAYERS=kn-i,prehledky,def_budovyFORMAT=image/pngtransparent=TRUE; Primlouval bych se za snizeni barevne hloubky smerem k puvodnim 4 bitum. Mozna je JOSM spatne napsan pro operaci s tak barevnymi rastry, ale pro cernobilou mapu nejsou prave barvy(true color) potreba. Já u výstupu z WMS vidím barevnou hloubku 8-bit. 32-bit hloubka byla před časem (doufám :-) opravena *** Ano, neco jsem prehledl, na wms-new.asp je 32, ale na wms.asp je 8. PS: jeste by se mi libilo mit v KM vrstvu, ktera by mi rikala jaka data vidim (DKM, KM-D, SK...), jak jsou stara vuci ISKN a jaka je obecna kvalita geodat. I v současné době jsou poskytovány jednotlivé vrstvy podle původu dat (DKM, analog, KM-D, PK, geometráky). To ostatní je spíž záležitostí metadat. *** Vypinat a zapinat si vrstvy a zjistovat ktera ze se mi to natahuje je ponekud neprakticke. *** Pocet uzivatelu, kteri jsou schopni a maji odbornou erudici zkoumat metadata z ISKN se limitne blizi nule, resp poctu geodetu, kteri tusi, co tam zadavaji. Presto informacni vrstva obsahujici text: tady je platna mapa typu SK, tady delame digitalizaci a bude hotova za rok, tady je empiricka presnost radech 1 dm, tady se porad dokresluje na folie... ma svuj vyznam. Obecně teď u nového způsobu aktualizace vektorů platí, že publikovaná data mají maximálně jednodenní zpoždění za stavem katastru (běžně spíš v řádu hodin). *** Rastry jsou v KM take a dlouho jeste budou. zdravi hanoj ___ 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] Izometrická 3D mapa z OSM
Ahoj, dostal jsem typ na reseni renderovani strech... Knihovna: http://www.cgal.org/Manual/3.2/doc_html/cgal_manual/Straight_skeleton_2/Chapter_main.html Popis algoritmu: http://web.natur.cuni.cz/~bayertom/Adk/adk7.pdf Honza 2010/3/28 hanoj eha...@gmail.com: Podle pravidel fotbalu má hřiště nějakou danou velikost - http://en.wikipedia.org/wiki/Association_football_pitch, takže pokud je to příliš velké, tak je možné, že někdo otagoval pomocí sport=soccer i okolní tribuny, zázemí a tak (a pokud moc malé, tak jde nejspíš o trénínkové hřiště pro dorost nebo tak něco :) *** tak zrovna rozmer fotbalového hriste je hodne plovouci, (chapu ze UEFA to ma fix), ale UEFA hrist je asi par v republice. Navic existuji okolni odstupove zony, na ktere se podle souteze az tak nedba. A také je škoda, že při importu z UHUL se nezachovala informace o druhu lesa. Možná by to šlo nějak doplnit - brát existující polygony z UHULu jeden po druhém, zjišťovat typ lesa (coniferous/deciduous, případně mixed - a u těch mixed pak případně zvážit, jestli by se ten les nedal rozetnout na listnaté a jehličnaté části), na polygon se plácne patřičný tag a jede se dál :) *** to sice asi ano, ale problem je doslo ke slouceni prostorovych a druhovych(habrina, dubohabrina, smrcina, ...) polygonu jen do prostorovych polygonu. ha hanoj ___ 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] Izometrická 3D mapa z OSM
A tady je ještě Java applet, který to názorně a interaktivně ukazuje: http://www.sable.mcgill.ca/~dbelan2/roofs/roofs.html Honza 2010/3/28 Jan Bilak jan.bilak@gmail.com: Ahoj, dostal jsem typ na reseni renderovani strech... Knihovna: http://www.cgal.org/Manual/3.2/doc_html/cgal_manual/Straight_skeleton_2/Chapter_main.html Popis algoritmu: http://web.natur.cuni.cz/~bayertom/Adk/adk7.pdf Honza 2010/3/28 hanoj eha...@gmail.com: Podle pravidel fotbalu má hřiště nějakou danou velikost - http://en.wikipedia.org/wiki/Association_football_pitch, takže pokud je to příliš velké, tak je možné, že někdo otagoval pomocí sport=soccer i okolní tribuny, zázemí a tak (a pokud moc malé, tak jde nejspíš o trénínkové hřiště pro dorost nebo tak něco :) *** tak zrovna rozmer fotbalového hriste je hodne plovouci, (chapu ze UEFA to ma fix), ale UEFA hrist je asi par v republice. Navic existuji okolni odstupove zony, na ktere se podle souteze az tak nedba. A také je škoda, že při importu z UHUL se nezachovala informace o druhu lesa. Možná by to šlo nějak doplnit - brát existující polygony z UHULu jeden po druhém, zjišťovat typ lesa (coniferous/deciduous, případně mixed - a u těch mixed pak případně zvážit, jestli by se ten les nedal rozetnout na listnaté a jehličnaté části), na polygon se plácne patřičný tag a jede se dál :) *** to sice asi ano, ale problem je doslo ke slouceni prostorovych a druhovych(habrina, dubohabrina, smrcina, ...) polygonu jen do prostorovych polygonu. ha hanoj ___ 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] Tracer - nastavení
Zdroják SmallHoleRemover filtru vypadá takto:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Osm.Kn.Trace.Server.Trace.Interfaces;
namespace SmallHoleRemover
{
[BitmapFilter(SmallHoleRemover)]
public class SmallHoleRemover : IBitmapFilter
{
const byte BACKGROUND = 0;
const byte PEN = 1;
const byte TEMP = 2;
#region IBitmapFilter Members
public byte[][] Filter(byte[][] bitmap)
{
int h = bitmap.Length;
int w = bitmap[0].Length;
for (int y = 1; y h - 1; y++)
{
for (int x = 1; x w - 1; x++)
{
if ((bitmap[y][x] == PEN)
(bitmap[y][x - 1] != BACKGROUND || bitmap[y][x
+ 1] != BACKGROUND ||
bitmap[y - 1][x] != BACKGROUND || bitmap[y +
1][x] != BACKGROUND))
bitmap[y][x] = TEMP;
}
}
for (int y = 1; y h - 1; y++)
{
for (int x = 1; x w - 1; x++)
{
if (bitmap[y][x] == TEMP)
bitmap[y][x] = PEN;
}
}
return bitmap;
}
#endregion
#region IConfigurable Members
public void Init(IDictionarystring, string confValues)
{
}
#endregion
}
}
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer - nastavení
Ahoj,
to se divím, že funguje o dost lépe, protože tam prakticky žádné změny
v tomto směru nejsou. Změny se týkají možnosti nastavení a pluginů
(filtrů). Pravda je, že jeden ukázkový primitivní filtr
SmallHoleRemover, jehož zdroják jsem zde posílal, zaceluje malé díry a
tak může někde přinést lepší výsledky (někde zase horší, pokud jsou
čáry už tak dost tlusté).
Ten plugin nemá žádné nastavení. Když se koukneš do toho zdrojáku (je
velmi krátký a zřejmý), tak zjistíš, že natvrdo obarvuje bílé body,
které na jedné ze 4 základních stran sousedí s černým pixelem. Stačí
tuto podmínku upravit nebo filtr udělat konfigurovatelný... a může se
to chovat jinak. Nebo prostě udělat jiný filtr ... tvorba filtru je
jednoduchá věc, stačí referencovat jednu Class Library a implementovat
jednoduché rozlišení. Výsledné DLL dát do adresáře plugins a přidat
filtr v konfiguráku na vhodné místo
Případně hrubou silou lze v konfiguráku aplikovat stejný filtr třeba
2x za sebou. Tím se také zacelí trochu větší díry (ale není to moc
pěkné řešení).
bitmapFilters
filter name=SmallHoleRemover /
filter name=SmallHoleRemover /
/bitmapFilters
Honza
2010/3/1 Petr Dlouhý petr.dlo...@email.cz:
Ahoj,
zkoušel jsem tu novou verzi, která opravdu funguje zase o dost lépe.
Zdá se ale, že to na tenkých čarách stále moc nefunguje - většinou to
stejně projde nějakou mezerou.
Dá se někde nastavit, jak velkou mezeru to zacelí?
On Mon, 01 Mar 2010 13:32:21 +0100, Jan Bilak jan.bilak@gmail.com
wrote:
Zdroják SmallHoleRemover filtru vypadá takto:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Osm.Kn.Trace.Server.Trace.Interfaces;
namespace SmallHoleRemover
{
[BitmapFilter(SmallHoleRemover)]
public class SmallHoleRemover : IBitmapFilter
{
const byte BACKGROUND = 0;
const byte PEN = 1;
const byte TEMP = 2;
#region IBitmapFilter Members
public byte[][] Filter(byte[][] bitmap)
{
int h = bitmap.Length;
int w = bitmap[0].Length;
for (int y = 1; y h - 1; y++)
{
for (int x = 1; x w - 1; x++)
{
if ((bitmap[y][x] == PEN)
(bitmap[y][x - 1] != BACKGROUND || bitmap[y][x
+ 1] != BACKGROUND ||
bitmap[y - 1][x] != BACKGROUND || bitmap[y +
1][x] != BACKGROUND))
bitmap[y][x] = TEMP;
}
}
for (int y = 1; y h - 1; y++)
{
for (int x = 1; x w - 1; x++)
{
if (bitmap[y][x] == TEMP)
bitmap[y][x] = PEN;
}
}
return bitmap;
}
#endregion
#region IConfigurable Members
public void Init(IDictionarystring, string confValues)
{
}
#endregion
}
}
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouhý
___
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] Tracer - nastavení
Ahoj.
SmallHoleRemover je spíše ukázkový filtr, než filtr, který by to
opravdu dobře řešil. V rámci úpravy traceserveru tak, aby byl
konfigovatelný, jsem se rozhodl vytvořit dva typy filtrů. Jeden typ
umí pozměnit černobílou bitmapu (a tedy např. lze pomocí takového typu
filtru zacelovat díry). Druhý typ filtru pak slouží k redukci
(případně i přidání) bodů na obrysu trasovaného domu.
Filtrů druhého typu existuje v programu několik a tvoří to podstatnou
část traceserveru. Na vstupu je množina bodů tvořící vnější obrys
oblasti vyplnění floodfillem. Pak tato množina projde sadou filtrů a
výsledek posledního filtru je už vlastně konečný výsledek (jen se
přepočtou souřadnice apod.). Přitom typy filtrů, jejich pořadí a
nastavení je výsledek nějakých pokusů zejména na jednom typy mapového
podkladu. Věřím, že lze zde dosáhnout i lepších výsledků - zejména v
jiných oblastech mapy, než kde jsem to zkoušel.
Filtr prvního typu ale žádný neexistoval a SmallHoleRemover je vlastně
takový ukázkový filtr (zacelí opravdu jen malé díry a tak jeho
praktický použití je dosti omezené, ale zase to názorná ukázka, jak
takový filtr vytvořit).
Konfigurací pak lze ovlivnit, které filtry se použijí, v jakém pořadí
a s jakým nastavením filtru (pokud filtr nějaké nastavení podporuje).
Nyní si tedy každý (.NET programátor) může vytvářet vlastní filtry a
konfiguraci podle oblasti, kterou trasuje nebo osobních preferencí.
Shrnuto: Tato verze si nekladla za cíl lepší rozpoznávání nebo opravu
nějakých chyb. Cílem bylo zavedení konfigurovatelnosti, kterou ocení
třeba někteří vývojáři nebo pokročilejší uživatelé.
Honza
2010/3/1 Petr Dlouhý petr.dlo...@email.cz:
Ahoj,
tím funguje lépe jsem myslel v jiných směrech - například často správně
ignoruje nesouvisející čáry zasahující do trasovaného objektu.
Myslel jsem, že SmallHoleRemover má problém tenkých čar řešit.
Mimochodem: v Traceru jsou stále některé otravné chyby z dřívějška - občas
trasovaná oblast vůbec neobsahuje bod, na který jsem kliknul; někdy
vystřelují body z objektu daleko za jeho hranici; občas hlásí
IndexOutOfRangeException.
On Mon, 01 Mar 2010 18:13:33 +0100, Jan Bilak jan.bilak@gmail.com
wrote:
Ahoj,
to se divím, že funguje o dost lépe, protože tam prakticky žádné změny
v tomto směru nejsou. Změny se týkají možnosti nastavení a pluginů
(filtrů). Pravda je, že jeden ukázkový primitivní filtr
SmallHoleRemover, jehož zdroják jsem zde posílal, zaceluje malé díry a
tak může někde přinést lepší výsledky (někde zase horší, pokud jsou
čáry už tak dost tlusté).
Ten plugin nemá žádné nastavení. Když se koukneš do toho zdrojáku (je
velmi krátký a zřejmý), tak zjistíš, že natvrdo obarvuje bílé body,
které na jedné ze 4 základních stran sousedí s černým pixelem. Stačí
tuto podmínku upravit nebo filtr udělat konfigurovatelný... a může se
to chovat jinak. Nebo prostě udělat jiný filtr ... tvorba filtru je
jednoduchá věc, stačí referencovat jednu Class Library a implementovat
jednoduché rozlišení. Výsledné DLL dát do adresáře plugins a přidat
filtr v konfiguráku na vhodné místo
Případně hrubou silou lze v konfiguráku aplikovat stejný filtr třeba
2x za sebou. Tím se také zacelí trochu větší díry (ale není to moc
pěkné řešení).
bitmapFilters
filter name=SmallHoleRemover /
filter name=SmallHoleRemover /
/bitmapFilters
Honza
2010/3/1 Petr Dlouhý petr.dlo...@email.cz:
Ahoj,
zkoušel jsem tu novou verzi, která opravdu funguje zase o dost lépe.
Zdá se ale, že to na tenkých čarách stále moc nefunguje - většinou to
stejně projde nějakou mezerou.
Dá se někde nastavit, jak velkou mezeru to zacelí?
On Mon, 01 Mar 2010 13:32:21 +0100, Jan Bilak jan.bilak@gmail.com
wrote:
Zdroják SmallHoleRemover filtru vypadá takto:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Osm.Kn.Trace.Server.Trace.Interfaces;
namespace SmallHoleRemover
{
[BitmapFilter(SmallHoleRemover)]
public class SmallHoleRemover : IBitmapFilter
{
const byte BACKGROUND = 0;
const byte PEN = 1;
const byte TEMP = 2;
#region IBitmapFilter Members
public byte[][] Filter(byte[][] bitmap)
{
int h = bitmap.Length;
int w = bitmap[0].Length;
for (int y = 1; y h - 1; y++)
{
for (int x = 1; x w - 1; x++)
{
if ((bitmap[y][x] == PEN)
(bitmap[y][x - 1] != BACKGROUND || bitmap[y][x
+ 1] != BACKGROUND ||
bitmap[y - 1][x] != BACKGROUND || bitmap[y +
1][x] != BACKGROUND))
bitmap[y][x] = TEMP;
}
}
for (int y = 1; y h - 1; y++)
{
for (int x = 1; x w - 1; x++)
{
if (bitmap[y][x] == TEMP)
bitmap[y][x] = PEN
Re: [Talk-cz] Tracer - nastavení
Ahoj, omlouvám se za chyby ... opravenou verzi jsem dal na stejné místo. Honza 2010/2/28 Jan Bilak jan.bilak@gmail.com: Ahoj, díky za reakci ... zítra (nebo možná ještě teď večer) se kouknu, v čem je problém. Mimochodem zkoušíš to na Windows nebo pod Monem? Honza Dne 28. února 2010 2:21 MP singular...@gmail.com napsal(a): On 27/02/2010, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, přidal jsem podporu nějakého nastavení TraceServeru: http://jabi.aspone.cz/osm/TraceServerBeta5.zip Tak jsem to zkusil a nefunguje to, hází to jakousi exception kvůli nenalezenému filtru: filter name=SmallHoleRemover / Pokud tuhle řádku v defaultním konfiguráku nezakomentuju, hází mi to tuhle chybu: $ mono Osm.Kn.Trace.Server.exe EXPERIMENTALNI VERZE (2) Plugin dir is /m/e/p/josm/tracer/plugins. Plugin SmallHoleRemover.dll loaded. Unhandled Exception: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary. at System.Collections.Generic.Dictionary`2[System.String,System.Type].get_Item (System.String key) [0x0] at Osm.Kn.Trace.Server.Wms.BitmapFilterManager.AddFilter (System.String name, IDictionary`2 parameters) [0x0] at Osm.Kn.Trace.Server.Config.LoadBitmapFilters () [0x0] at Osm.Kn.Trace.Server.Server.Start () [0x0] at Osm.Kn.Trace.Server.Program.Main (System.String[] args) [0x0] Bez téhle řádky to sice jde spustit, ale pak to hází tuhle chybu: - trace/simple/50.10415000432744;14.36878225455269 http://wms.cuzk.cz/wms.asp?service=WMSVERSION=1.1.1REQUEST=GetMapSRS=EPSG:4326FORMAT=image/pn gLAYERS=knBBOX=14.3660,50.1040,14.3680,50.1067WIDTH=1600HEIGHT=2160 System.NullReferenceException: Object reference not set to an instance of an object at Osm.Kn.Trace.Server.Config.get_Treshold () [0x0] at Osm.Kn.Trace.Server.Wms.TileDownloader.Download (Osm.Kn.Trace.Server.Wms.Tile tile) [0x0 ] at Osm.Kn.Trace.Server.Wms.TileDownloader.Get (Osm.Kn.Trace.Server.Wms.Tile tile) [0x0] at Osm.Kn.Trace.Server.Server.CreateBitmap (Osm.Kn.Trace.Server.Wms.Tile[,] tiles, Int32 resolution) [0x0] at Osm.Kn.Trace.Server.Server.TraceCommand (PointGeo point, IExporter exporter) [0x0] at Osm.Kn.Trace.Server.Server.webServer_GetContent (System.Object sender, Osm.Kn.Trace.Server.WebServer.GetDataEventArgs e) [0x0] ... takže ta nová verze vlastně nefunguje Martin ___ 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] Tracer - nastavení
Ahoj, přidal jsem podporu nějakého nastavení TraceServeru: http://jabi.aspone.cz/osm/TraceServerBeta5.zip Zároveň podporuje pluginy pro předzpracování bitmapy i filtraci bodů (asi nejproblematičtější část trasování). Konfigurační soubor je ve formátu XML a definuje dvě pipelines (bitmapFilters a pointSetFilters). Tyto lze skládat z vestavených filtrů a pluginů. Pluginy ve formě tříd v Class Library musí referencovat Osm.Kn.Trace.Server.Interfaces.dll a implementovat jednoduché rozhraní IBitmapFilter nebo IPointSetFilter. Schema: http://jabi.aspone.cz/osm/PluginInterface.png Zároveň je třeba třídě přiřadit atribut BitmapFilterAttribut nebo PointSetFilterAttribute a kontruktoru přiřadit jméno, které se pak používá pro označení pluignu v konfiguračním souboru. Filtry mohou mít parametry, které lze nastavovat v konf. souboru. Jeden filtr může být v pipeline vícekrát (třeba i s různým nastavením). Hotové Class Libraries (jedna knihovna může obsahovat více filtrů) je třeba umístit do složky plugins, která leží ve složce, ve které je Osm.Kn.Trace.Server.exe a Osm.Kn.Trace.Server.Interfaces.dll. Pro pochopení, co který filtr dělá, doporučuji všechny následující filtry v pipeline zakomentovat a zkusit v JOSM, co z toho bude lézt. Při změně bitmapFilters je vhodné smazat cache soubory. Při změně pointSetFilters to není třeba. I bez tvorby nových pluignů je možné trasování ovlivňovat změnou pipeline (ubírám filtrů, změnou pořadí, přidávám filtrů, změnou parametrů, ...). Pomocí pluginů je možné část nebo celou pipeline nahradit. Honza Příklad konfiguráku: ?xml version=1.0 encoding=utf-8 ? config bitmapFilters !-- Zacelí drobné díry v čarách tím, že očerní všechny bílé body, které sousedí alespoň v jednom ze 4 základních směrech s černým bodem. -- filter name=SmallHoleRemover / /bitmapFilters pointSetFilters !-- Najde body, ve kterých se křivka láme pomocí metodu obdobnou jako při hledání extrémů funkce pomocí derivace. Ostatní body vynechá. -- filter name=FindExtrems !-- Vzdálenost bodu, od kterého se počítají vzdálenosti bodů křivky, od objektu. -- param name=dist value=1 / !-- Počet směrů, do kterých se výše zmíněný bod umisťuje. -- param name=stepCount value=27 / /filter !-- Najde body A, B, C, kde |AB| a |BC| je větěí než minDistance a zároveň vzdálenost AC od B je menší než minDistance. V takovýchto případech vynechá B. -- filter name=SimplifyPolyline param name=minDistance value=15 / param name=maxDistance value=4 / /filter !-- Najde body A, B, C, kde |AB| a |BC| je větěí než minDistance a zároveň vzdálenost AC od B je menší než minDistance. V takovýchto případech vynechá B. -- filter name=SimplifyPolyline param name=minDistance value=3 / param name=maxDistance value=1.3 / /filter !-- Najde A, B, C, D takové, že - |AB| je větší než minOuterDist, - |CD| je větší než minOuterDist, - |BC| je menší než maxInnerDist, - úhel přímek AB a CD je větší než minAngle A pak BC vyhodí a nahradí průsečíkem AB a CD. Tedy vlastně eliminuje kulaté rohy. -- filter name=FindVertexis param name=maxInnerDist value=15 / param name=minOuterDist value=5 / param name=minAngle value=30 / !-- Neprovádět, pokud je bod ke smazání dále než tolerance od přímky AB i CD. -- param name=tolerance value=3 / !-- Neprovádět, pokud je průsečík AB a CD dále než tolerance od bodu B nebo C. -- param name=tolerance2 value=20 / /filter !-- Najde po sobě jdoucí body A, B, C, vzdálenost AC od B je menší než tolerance. V takovýchto případech vynechá B. ??? -- filter name=FilterPointGroups param name=tolerance value=2 / /filter !-- Najde body vynechané, které jsou dále než maxDistance od upraveného polygonu. A vrátí je zpět.-- filter name=AddMissingPoints param name=maxDistance value=4 / /filter !-- Pokusí se polygon nafouknout tak, aby segmenty polygonu byly ve středu čáry. -- filter name=LineWidthCorrection /filter !-- Najde body A, B, C, kde |AB| a |BC| je větěí než minDistance a zároveň vzdálenost AC od B je menší než minDistance. V takovýchto případech vynechá B. -- filter name=SimplifyPolyline param name=minDistance value=5 / param name=maxDistance value=1.3 / /filter !-- Najde body A, B, C, kde |AB| a |BC| je větěí než minDistance a zároveň vzdálenost AC od B je menší než minDistance. V takovýchto případech vynechá B. -- filter name=SimplifyPolyline param name=minDistance value=15 / param name=maxDistance value=2 / /filter /pointSetFilters webServer !-- TCP port, na kterém server poslouchá. -- endPoint port=5050 / /webServer wms !-- Okolí bodu kliknutí ve stupních lon/lat, které se stahuje. Stáhne se tedy minimálně čtverec (2*size) x (2*size). -- surroundingToDownload size=0.001 /
Re: [Talk-cz] Tracer - nastavení
Ahoj, díky za reakci ... zítra (nebo možná ještě teď večer) se kouknu, v čem je problém. Mimochodem zkoušíš to na Windows nebo pod Monem? Honza Dne 28. února 2010 2:21 MP singular...@gmail.com napsal(a): On 27/02/2010, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, přidal jsem podporu nějakého nastavení TraceServeru: http://jabi.aspone.cz/osm/TraceServerBeta5.zip Tak jsem to zkusil a nefunguje to, hází to jakousi exception kvůli nenalezenému filtru: filter name=SmallHoleRemover / Pokud tuhle řádku v defaultním konfiguráku nezakomentuju, hází mi to tuhle chybu: $ mono Osm.Kn.Trace.Server.exe EXPERIMENTALNI VERZE (2) Plugin dir is /m/e/p/josm/tracer/plugins. Plugin SmallHoleRemover.dll loaded. Unhandled Exception: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary. at System.Collections.Generic.Dictionary`2[System.String,System.Type].get_Item (System.String key) [0x0] at Osm.Kn.Trace.Server.Wms.BitmapFilterManager.AddFilter (System.String name, IDictionary`2 parameters) [0x0] at Osm.Kn.Trace.Server.Config.LoadBitmapFilters () [0x0] at Osm.Kn.Trace.Server.Server.Start () [0x0] at Osm.Kn.Trace.Server.Program.Main (System.String[] args) [0x0] Bez téhle řádky to sice jde spustit, ale pak to hází tuhle chybu: - trace/simple/50.10415000432744;14.36878225455269 http://wms.cuzk.cz/wms.asp?service=WMSVERSION=1.1.1REQUEST=GetMapSRS=EPSG:4326FORMAT=image/pn gLAYERS=knBBOX=14.3660,50.1040,14.3680,50.1067WIDTH=1600HEIGHT=2160 System.NullReferenceException: Object reference not set to an instance of an object at Osm.Kn.Trace.Server.Config.get_Treshold () [0x0] at Osm.Kn.Trace.Server.Wms.TileDownloader.Download (Osm.Kn.Trace.Server.Wms.Tile tile) [0x0 ] at Osm.Kn.Trace.Server.Wms.TileDownloader.Get (Osm.Kn.Trace.Server.Wms.Tile tile) [0x0] at Osm.Kn.Trace.Server.Server.CreateBitmap (Osm.Kn.Trace.Server.Wms.Tile[,] tiles, Int32 resolution) [0x0] at Osm.Kn.Trace.Server.Server.TraceCommand (PointGeo point, IExporter exporter) [0x0] at Osm.Kn.Trace.Server.Server.webServer_GetContent (System.Object sender, Osm.Kn.Trace.Server.WebServer.GetDataEventArgs e) [0x0] ... takže ta nová verze vlastně nefunguje Martin ___ 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] Izometrická 3D mapa z OSM
Ahoj, tohle by opravdu obecně nefungovalo ... i u obdélníku by to bylo divné. Ale mohlo by to jít jinak... nebo nějak obdobně. Rozhodně je to relativně snadno algoritmicky řešitelné i u nekonvexních a nepravoúhlých polygonů. Honza Dne 24. února 2010 22:37 Aleš Janda openstreet...@kyblsoft.cz napsal(a): Ahoj, To by to řešilo, ovšem tím se problém jen trochu převede - neumím z obecného polygonu udělat menší polygon :-) Aspoň mě nenapadá žádný způsob jak to udělat. Celkem jednoduse vemes tu strechu, zmensis ji (je to 2D plocha, operace zmenseni je celkem trivialni, kdyztak hledej 2D transformace), zmensenou plochu pak posunes vejskove, rekneme +2m a vzajemne odpovidajici body spojis. Jak to bude vypadat by se muselo testnout. Samozrejme by to vzhledem k poctu budov sezralo asi dost vykonu. Tohle by zřejmě nefungovalo ;-) Teda fungovalo, ale jen pro nevykousnuté budovy. Kdyby ta budova byla např. do L, tak by se vrchní část posunula do středu. Nebo dokonce kdyby ta budova byla s dírou uvnitř, tak by ta střecha nešla nad středem konkrétních budov po obvodu, ale byla by šouplá směrem k vnitřnímu vykousnutí. Kdyz sme u toho, mozna by nebylo od veci stvorit aplikaci pro boinc, pak by potize s vykonem zmizly :D. Něco takového už připravuju, minimálně to používám pro vlastní účely. Je to klient, který si říká o práci a nahrává na server. Používám to doma i v práci. Chce to ale ještě doladit - sám nedokáže aktualizovat vstupní data, neošetřuje to moc chybových stavů, funguje to jen pod Linuxem, no a ještě to často měním :-) Ale až to dám do nějakého použitelnějšího stavu, určitě to nabídnu. Minimálně aby se to i mně lépe používalo. Aleš Janda ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz attachment: Konstukce-navrh.PNG___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Dibavod konfliktni data
Sice nevím, o co jde, ale podle pořadí mailů a rozsahů to vypadá na: 11 - 20 ... Jan Dudík 21 - 30 ... Zdeněk Pražák 31 - 35 ... Jiří Parkan Honza 2010/2/24 Martin Kupec ma...@jkopava.cz: On Wed, Feb 24, 2010 at 08:56:25PM +0100, Zdeněk Pražák wrote: Beru tedy 11 - 20 Koukam ze o to 11 se popralo spousta lidi :-) Ja pockam az se dohodnete a pak si taky vezmu kus. Martin Kupec ___ 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] Izometrická 3D mapa z OSM
Nebo ty body BCDE můžeš hledat i přímo jako průsečíky třech ploch: B = průsečík ploch přiléhajících k s1, s2, s3 C = průsečík ploch přiléhajících k s1, s3, s4 D = průsečík ploch přiléhajících k s1, s4, s5 E = průsečík ploch přiléhajících k s1, s5, s6 Celkově jde pořád prakticky jen o analytickou geometrii - tedy nějaké průsečíky rovin, přímek apod. Nemyslím, že by vlastní výpočet (ať může vypadat složitě) nějak zvlášť zvyšoval výpočetní náročnost. Přecijen na budovu to budou odhadem stovky elementárních operací s floaty a těch budov zase tak moc není. Jak se to projeví na větším množství ploch (trojúhelníků) k rendrování, to je otázka. Přecijen pixelů výsledného obrázku je řádově více. Ale myslím, že to stojí zato. A případně lze řešit pomalost distribuovaným výpočtem. Honza 2010/2/25 Jan Bilak jan.bilak@gmail.com: Ahoj, tohle by opravdu obecně nefungovalo ... i u obdélníku by to bylo divné. Ale mohlo by to jít jinak... nebo nějak obdobně. Rozhodně je to relativně snadno algoritmicky řešitelné i u nekonvexních a nepravoúhlých polygonů. Honza Dne 24. února 2010 22:37 Aleš Janda openstreet...@kyblsoft.cz napsal(a): Ahoj, To by to řešilo, ovšem tím se problém jen trochu převede - neumím z obecného polygonu udělat menší polygon :-) Aspoň mě nenapadá žádný způsob jak to udělat. Celkem jednoduse vemes tu strechu, zmensis ji (je to 2D plocha, operace zmenseni je celkem trivialni, kdyztak hledej 2D transformace), zmensenou plochu pak posunes vejskove, rekneme +2m a vzajemne odpovidajici body spojis. Jak to bude vypadat by se muselo testnout. Samozrejme by to vzhledem k poctu budov sezralo asi dost vykonu. Tohle by zřejmě nefungovalo ;-) Teda fungovalo, ale jen pro nevykousnuté budovy. Kdyby ta budova byla např. do L, tak by se vrchní část posunula do středu. Nebo dokonce kdyby ta budova byla s dírou uvnitř, tak by ta střecha nešla nad středem konkrétních budov po obvodu, ale byla by šouplá směrem k vnitřnímu vykousnutí. Kdyz sme u toho, mozna by nebylo od veci stvorit aplikaci pro boinc, pak by potize s vykonem zmizly :D. Něco takového už připravuju, minimálně to používám pro vlastní účely. Je to klient, který si říká o práci a nahrává na server. Používám to doma i v práci. Chce to ale ještě doladit - sám nedokáže aktualizovat vstupní data, neošetřuje to moc chybových stavů, funguje to jen pod Linuxem, no a ještě to často měním :-) Ale až to dám do nějakého použitelnějšího stavu, určitě to nabídnu. Minimálně aby se to i mně lépe používalo. Aleš Janda ___ 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 DIBAVOD
Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne? Honza Dne 23. února 2010 21:44 Tomas Kolda ko...@web2net.cz napsal(a): A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? Tomas Jan Dudík napsal(a): Jo, to je možný část 91 mi spadla chvilku po začátku imortu, myslel jsem ,že se stačilo přenést jen pár kousků a zatím to vypadá na skoro celý díl :-(... JD Dne 23. února 2010 20:41 MP singular...@gmail.com napsal(a): Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s validatorem to jde rychle a vcelku automaticky...), takze nektere rybniky tam jsou uz jen jednou. Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky dibavod (byt kazdy rybnik je tam jen dvakrat). pavel ma 13700 duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich bylo asi 32000) Takze duplicity od Medulove by taky asi chtely vyresit... Martin On 22/02/2010, Pavel Machek pa...@ucw.cz wrote: Hi! It seems that I created duplicate data when importing DIBAVOD; I assumed that if connection died before closing transaction, no data would be uploaded, and it seems it is not so :-(. Edits in question are: #3938287 February 21, 2010 20:50 dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938219 February 21, 2010 21:37 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938181 February 21, 2010 21:30 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938082 February 21, 2010 21:23 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) ...they should be duplicates (if not, the biggest one should be left). Now, there are big fat warnings about revert scripts and I'd prefer not to mess up the database even more. What is the best way to proceed? Sorry for the mess, Pavel Pokud jsem se díval na několik rybníků, tak všechny byly nahrány 4x. Například Trubární rybník - cesta č. 50937312 je nahrán ještě jako cesta č. 50932852, 50935613 a 50934642 Praák Původní zpráva Od: Pavel Machek pa...@ucw.cz Předmět: Re: [Talk-cz] Import DIBAVOD Datum: 22.2.2010 08:03:14 Ahoj! Namátkou jsem zjistil, že Pavel nahrál omylem část č. 41 celkem čtyřikrát. Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to znovu. Opravdu je duplicita v datech? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list talk...@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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import DIBAVOD
Ted jsem to asi uplne nepochopil. V JSOM lze nejak nastavit, jestli pouzije API metodu diff upload, aby nahral vsechno v jednom changesetu a transakci nebo to delal nejak jinak? Osobne bych cekal, ze ten alternativni postup je pro ten webovy editor a JOSM bude pouzivat vzdy diff upload. Tedy vse pekne v transakci a jednom changesetu. Tedy, pokud se to vejde do toho limitu poctu zmen. Honza 2010/2/23 Tomas Kolda ko...@web2net.cz: Tak jsem to asi vykoukal. Ja jsem si 0.6 jeste necetl, coz je mozna skoda. Naposledy jsem delal lesy a to byla verze 0.5. Ty soubory co jsem posilal se totiz dali udelat velmi rychle pomoci toho diff upload. Mozna JOSMu vadilo, ze v xml bylo osm version='0.5'. Netusim. JOSM to dela po jednom nodu v changesetu a nakonec po jedne line. To je samozrejmne 1 requestu a to trva tu hodinu. Pak je tam napsano: To avoid stale open changesets a mechanism is implemented to automatically close changesets upon one of the following three conditions: More than 50.000 edits on a single changeset See more specific limits The changeset has been open for more than 24 hours There have been no changes/API calls related to a changeset in 1 hour (i.e. idle timeout) Coz vysvetluje proc data zustaly. Ja to pochopil, ze je changeset jen kvuli lepsi identifikaci pro reverty ne jako transakce. Na transakci je pouzit ten diff upload. No aspon vime jak se to asi ma priste delat. Tomas jzvc napsal(a): Dne 23.2.2010 21:55, Jan Bilak napsal(a): Ja vychazel z tohoto: Diff upload: POST /api/0.6/changeset/#id/upload With this API call files in the OsmChange format can be uploaded to the server. This is guaranteed to be running in a transaction. So either all the changes are applied or none. To upload an OSC file it has to conform to the OsmChange specification with the addition of a changeset and a version attribute for each element, except when you are creating an element where the version is not required as the server sets that for you. [http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6] Honza Otazka je, jestli vam to nezbuchlo ve finalni fazi, kdyz uz transakce byla uzavrena = melo by to by duplicitni komplet a teoreticky by melo jit revertnout komplet jeden changeset (pokud ho nekdo mezi tim nezmenil). Dalsi varianta, ktera me napada (spekulace) ze kdyz changeset je otevreny dyl nez X (hodina ???) tak ho OSM uzavre automaticky. Nektere typy chyb by tomu nasvedcovaly. BTW: Osobne trochu nechapu co trva na uploadu 1MB dat na 8Mbit lince cca 20 - 30 minut. Tech +- 10k zaznamu se da nacpat do databaze behem vterin. 2010/2/23 Tomas Kolda ko...@web2net.cz: No asi to tak neni, protoze by pak nevznikly ty duplikaty. Jak presne jste postupovali, kdyz vam to spadlo? At vysledujeme jak se spravne pri uploadech chovat... Tomas Jan Bilak napsal(a): Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne? Honza Dne 23. února 2010 21:44 Tomas Kolda ko...@web2net.cz napsal(a): A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? Tomas Jan Dudík napsal(a): Jo, to je možný část 91 mi spadla chvilku po začátku imortu, myslel jsem ,že se stačilo přenést jen pár kousků a zatím to vypadá na skoro celý díl :-(... JD Dne 23. února 2010 20:41 MP singular...@gmail.com napsal(a): Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s validatorem to jde rychle a vcelku automaticky...), takze nektere rybniky tam jsou uz jen jednou. Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky dibavod (byt kazdy rybnik je tam jen dvakrat). pavel ma 13700 duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich bylo asi 32000) Takze duplicity od Medulove by taky asi chtely vyresit... Martin On 22/02/2010, Pavel Machek pa...@ucw.cz wrote: Hi! It seems that I created duplicate data when importing DIBAVOD; I assumed that if connection died before closing transaction, no data would be uploaded, and it seems it is not so :-(. Edits in question are: #3938287 February 21, 2010 20:50 dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938219February 21, 2010 21:37 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938181February 21, 2010 21:30 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938082February 21, 2010 21:23 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) ...they should be duplicates
Re: [Talk-cz] Import adres z katastralni mapy
Ahoj, odkaz na zdrojáky jsem do této konference už zasílal (na betu 3) - o pár příspěvků výše jej najdeš. Beta 4 upravovala jen drobnosti. Ještě zdrojáky trochu upravím (po formální stránce - refaktoring, komentáře, ...) ... a pak, když vymyslíte vhodné místo na SVN, tak tam nahraju. Obecně si ale myslím, že je vhodné dělat tyto utility jako class library (v případě .NETu) s nějakým rozumným interfacem, aby je bylo možné začlěňovat do celku. Tedy místo dlouhého postupu, co spouštět v jakém pořadí, tak pak mít utilitku s příjemným rozhraním (ať již konzolovým nebo GUI), která tohle všechno zařídí. A přitom jednotlivé části řešené jako vyměnitelné a nahraditelné jinou implementací. Jinak mám velké pochybnosti o tom, že se budou dostatečně často data aktualizovat. Už to nebude mít takový ten wow efekt, kdy na mapách přibude mnoho dat a tak se do toho nikomu nebude moc chtít, když to bude složité. Honza 2010/2/17 Petr Dlouhý petr.dlo...@email.cz: Princip práce Honzova programu se dá jednoduše poznat z logových souborů. Zdrojáky by asi bylo nejlepší nahrát na http://svn.openstreetmap.org/applications/utils/, abychom se s nimi při příštím importu zase setkali, a aby se jimi mohli inspirovat i ostatní. Původní zpráva Od: Lukas Kabrt lu...@kabrt.cz Předmět: Re: [Talk-cz] Import adres z katastralni mapy Datum: 17.2.2010 15:38:57 BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program pracuje. -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz Petr Dlouhý petr.dlo...@email.cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Než to nějak upravím ... tak zatím ještě přikládám beta4 zdrojáky pro zájemce: http://jabi.aspone.cz/osm/FindAddressPoints-beta4-src.zip Honza 2010/2/17 Jan Bilak jan.bilak@gmail.com: A mimochodem nejde o můj program ... je to upravený ten tvůj. Honza 2010/2/17 Jan Bilak jan.bilak@gmail.com: Ahoj, odkaz na zdrojáky jsem do této konference už zasílal (na betu 3) - o pár příspěvků výše jej najdeš. Beta 4 upravovala jen drobnosti. Ještě zdrojáky trochu upravím (po formální stránce - refaktoring, komentáře, ...) ... a pak, když vymyslíte vhodné místo na SVN, tak tam nahraju. Obecně si ale myslím, že je vhodné dělat tyto utility jako class library (v případě .NETu) s nějakým rozumným interfacem, aby je bylo možné začlěňovat do celku. Tedy místo dlouhého postupu, co spouštět v jakém pořadí, tak pak mít utilitku s příjemným rozhraním (ať již konzolovým nebo GUI), která tohle všechno zařídí. A přitom jednotlivé části řešené jako vyměnitelné a nahraditelné jinou implementací. Jinak mám velké pochybnosti o tom, že se budou dostatečně často data aktualizovat. Už to nebude mít takový ten wow efekt, kdy na mapách přibude mnoho dat a tak se do toho nikomu nebude moc chtít, když to bude složité. Honza 2010/2/17 Petr Dlouhý petr.dlo...@email.cz: Princip práce Honzova programu se dá jednoduše poznat z logových souborů. Zdrojáky by asi bylo nejlepší nahrát na http://svn.openstreetmap.org/applications/utils/, abychom se s nimi při příštím importu zase setkali, a aby se jimi mohli inspirovat i ostatní. Původní zpráva Od: Lukas Kabrt lu...@kabrt.cz Předmět: Re: [Talk-cz] Import adres z katastralni mapy Datum: 17.2.2010 15:38:57 BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program pracuje. -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz Petr Dlouhý petr.dlo...@email.cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Izometrická 3D mapa z OSM
Zdravím, je to moc pěkné. Dovedu si živě představit, že třeba orientační mapka typu jak se dostat do ... by byla tímto způsobem provedená a vypadala velmi efektně. Měřítko ... v izometrickém pohledu prostě bude mapka zkreslená, s tím nic nenaděláš. Když to nějak roztáhneš, tak už to není izometrické zobrazení, ale něco nereálného, divného, ... Kombinovat 2D pohled shora a izometrický pohled (jako různé vrstvy) nedává smysl. Různé vrstvy použít lze, ale všechny musí být zobrazené stejně - tedy např. v izometrii. Vylepšení ... napadá mne vyrendrování nějaké oblasti mapy na přání (tedy se zvoleným úhlem pohledu). A také nějaká konfigurace způsobu vykreslení (výška budov, barvy, tlouštky čar apod.). Když si bude moci každý nastavit vlastní zobrazení, tak se myslím brzy najde nějaké obecně hezčí než toto. Honza Dne 17. února 2010 19:48 Aleš Janda openstreet...@kyblsoft.cz napsal(a): Zdravím, trošku jsem si hrál a udělal jsem izometrickou 3D mapu z OSM dat. Něco jsem dal na web, je to na http://osm.kyblsoft.cz/3dmapa/ Napřed jak to pracuje a potom na co se chci zeptat :-) Udělal jsem si program v C++, který načte .osm soubor a ty objekty, které zná, převede do nějaké 3D podoby. Výstup programu je ve formátu POV, čili formát pro POV-Ray, což je renderer 3D modelů. Takže ten výsek mapky, co vidíte na uvedeném odkaze, je proveden několika cykly osmosis = můj osm2pov = povray = rozsekat na dlaždice = web :-) A teď co se chci zeptat: 1) co tomu říkáte? :-) 2) narazil jsem na problém s měřítkem. Jak je totiž mapa v izometrickém pohledu, tak je trochu nakloněná. Tím dojde ke smrštění osy Y - to co vede od severu k jihu se zdá menší než od východu k západu. Zatím moc nevím, jak to vyřešit, napadají mě dva způsoby, na tom odkazu jsou použity oba: - roztažení obrázku na výšku tak, aby to bylo správně vysoké. To ale vypadá divně (většina mapy) - v ose Y bude mít mapa poloviční velikost (to jsem použil v pásu od Kralup do Neratovic) - vypadá to mnohem lépe, ale je to nekompatibilní se zbytkem OSM - je problém s přepínáním vrstev, permalinkem, různé navazování s jinými mapami atd. Chci se zeptat, jestli nevíte o nějakém standardním způsobu, jak řešit netypické měřítko. Jinak ta mapa je jen v oblasti od Kralup do Prahy, ladil jsem ji za pochodu, některé dlaždice jsou chybné (nenavazují, špatná šířka silnicí...), hromadu toho ještě nevykresluje nebo chybně (atribut layer). V pruhu Kralupy-Neratovice jsem dal záměrně to smrštění v ose Y (vypadá to líp, pochopitelně nenavazuje se zbytkem mapy). 3) máte nějaké nápady na vylepšení? Díky. Aleš Janda ___ 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] Izometrická 3D mapa z OSM
Ahoj, jak píšeš o stylovém souboru ... tak ten asi bude obsahovat prakticky všechno. Jaká data se vezmou a jakým způsobem se vykreslí. Takže to je ideální forma parametrizace vykreslování. Co se týká výšky budov, tak samozřejmě vhodně otagované budovy jsou ideální. Ale nedělám si iluze, že někdo bude hromadně přeměřovat budovy (možná na několika málo zajímavých místech). Žádný zdroj dat, který by obsahoval výšku budov v ČR, nejspíše neexistuje. Takže podstatná bude nějaká defaultní výška. A defautní výšku bude vhodné zvolit jinou na vesnici a jinou třeba na sídlišti plného paneláků. Tlouštky čar možná nemá velký smysl měnit, to byl jen příklad. Ukáže čas, co bude třeba. Pokud budeš dělat nějaké zohlednění výšky terénu, tak bych to dělal vypínatelné. V některých případech (orientační mapka) to bude spíše na obtíž. Je jasné, že je zatím brzy. Honza Dne 17. února 2010 21:11 Aleš Janda openstreet...@kyblsoft.cz napsal(a): Ahoj, díky za názor. Jak to myslíš s tím způsobem vykreslení? Resp. co by se mělo všechno měnit? Počítám s tím, že výška budov se bude brát z tagů http://wiki.openstreetmap.org/wiki/Proposed_features/Building_attributes minimálně typ střechy a výška, popř. počet pater. Pak je jen otázka, jestli to v těch datech bude... Tloušťky čar... no, možná, ale v defaultu by to mělo být alespoň přijatelně pěkné. Mimochodem, ten převodní program asi později uvolním (pod nějakou volnou licencí) a stylový soubor bude patrně jeho externí částí. Takže každý si bude moci vyrenderovat co chce. Ale zatím je to příliš v raném stádiu. Aleš Janda On 17.2.2010 20:52, Jan Bilak napsal/a: Zdravím, je to moc pěkné. Dovedu si živě představit, že třeba orientační mapka typu jak se dostat do ... by byla tímto způsobem provedená a vypadala velmi efektně. Měřítko ... v izometrickém pohledu prostě bude mapka zkreslená, s tím nic nenaděláš. Když to nějak roztáhneš, tak už to není izometrické zobrazení, ale něco nereálného, divného, ... Kombinovat 2D pohled shora a izometrický pohled (jako různé vrstvy) nedává smysl. Různé vrstvy použít lze, ale všechny musí být zobrazené stejně - tedy např. v izometrii. Vylepšení ... napadá mne vyrendrování nějaké oblasti mapy na přání (tedy se zvoleným úhlem pohledu). A také nějaká konfigurace způsobu vykreslení (výška budov, barvy, tlouštky čar apod.). Když si bude moci každý nastavit vlastní zobrazení, tak se myslím brzy najde nějaké obecně hezčí než toto. Honza Dne 17. února 2010 19:48 Aleš Jandaopenstreet...@kyblsoft.cz napsal(a): Zdravím, trošku jsem si hrál a udělal jsem izometrickou 3D mapu z OSM dat. Něco jsem dal na web, je to na http://osm.kyblsoft.cz/3dmapa/ Napřed jak to pracuje a potom na co se chci zeptat :-) Udělal jsem si program v C++, který načte .osm soubor a ty objekty, které zná, převede do nějaké 3D podoby. Výstup programu je ve formátu POV, čili formát pro POV-Ray, což je renderer 3D modelů. Takže ten výsek mapky, co vidíte na uvedeném odkaze, je proveden několika cykly osmosis = můj osm2pov = povray = rozsekat na dlaždice = web :-) A teď co se chci zeptat: 1) co tomu říkáte? :-) 2) narazil jsem na problém s měřítkem. Jak je totiž mapa v izometrickém pohledu, tak je trochu nakloněná. Tím dojde ke smrštění osy Y - to co vede od severu k jihu se zdá menší než od východu k západu. Zatím moc nevím, jak to vyřešit, napadají mě dva způsoby, na tom odkazu jsou použity oba: - roztažení obrázku na výšku tak, aby to bylo správně vysoké. To ale vypadá divně (většina mapy) - v ose Y bude mít mapa poloviční velikost (to jsem použil v pásu od Kralup do Neratovic) - vypadá to mnohem lépe, ale je to nekompatibilní se zbytkem OSM - je problém s přepínáním vrstev, permalinkem, různé navazování s jinými mapami atd. Chci se zeptat, jestli nevíte o nějakém standardním způsobu, jak řešit netypické měřítko. Jinak ta mapa je jen v oblasti od Kralup do Prahy, ladil jsem ji za pochodu, některé dlaždice jsou chybné (nenavazují, špatná šířka silnicí...), hromadu toho ještě nevykresluje nebo chybně (atribut layer). V pruhu Kralupy-Neratovice jsem dal záměrně to smrštění v ose Y (vypadá to líp, pochopitelně nenavazuje se zbytkem mapy). 3) máte nějaké nápady na vylepšení? Díky. Aleš Janda ___ 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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map
Ahoj, kdyz nepouzivam zadnou fotomapu, tak pouzivam kn neinvertovanou a s citelnosti nemam problem. Invertovana je citelna take, ale tohle mi vyhovuje vice (asi otazka zvyku). To vse s defaultnim barevnych schematem. S jinym barevnych schematek bude citelnost uplne jina. Idealni by bylo z WMS ziskavat seznam dostupnych vrstev a jinych nastaveni a toto poskytnout formou dialogu. Ale nemuzu rict, ze by to nejak chybelo. Honza 2010/2/14 hanoj eha...@gmail.com: ten seznam předvoleb pro WMS plugin je na [1], ale taky si nejsem jist, že dobrý nápad tam dávat tu inverzní barvu. Sice jsem to nezkoušel, ale řekl bych, že to bude špatně vidět nad Yahoo/UHUL ortofotomapou. Na druhou stranu opravdu není dobře, že to v defaultu není vidět. Možná by bylo lepší změnit defaultní pozadí, já používám šedivou. Kdyz si udelam tabulky citelnosti kombinovanych vrstev: vrstva; samotna; s uhul; s cenia; kn; ne; horsi; ano; kn-i; ano; ano; ano; mate jine prakticke zkusenosti? hanoj ___ 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 adres z katastralni mapy
Ahoj, mas k tomu jeste nejake zasadni postrehy (co je treba upravit)? Tedy krome toho, ze ti to zacne plnit pamet, protoze to se mi nepodarilo nasimulovat a ani nemam zadny napad, cim by to mohlo byt. Honza 2010/2/13 Jan Bilak jan.bilak@gmail.com: Tady jsou výsledná *.csv a logy z tvých dat Prahy: http://www.flyshare.cz/stahni/46207/praha.zip Zpracovával jsem to po 5 částech - jsou očíslovány stejně *.csv a logy (stejná čísla patří k sobě). Honza 2010/2/13 Jan Bilak jan.bilak@gmail.com: Projel jsem všechny dlaždice, které jsi mi poslal. Na problém jsem nenarazil. Možné je to specifické chování Mona - já to dělám pod .NETem (třeba vím, že pod Monem mi aplikace vždycky padala, když jsem přistupoval ke konzoli z více vláken, zato .NET to automaticky synchronizoval apod.). Nevím - těžko se ladí něco, co se mi neprojevuje. Zdrojáky jsou tady: http://jabi.aspone.cz/osm/FindAddressPoints-beta3-src.zip Pokud by se problém nepodařilo odstranit, tak je možné to dělat pod Windows. Zase tak dlouho to myslím netrvá, aby byla třeba dělat akce na způsob s...@home. Honza 2010/2/13 Jan Bilak jan.bilak@gmail.com: Dal jsem tam novou verzi beta3 (na stejné místo). Má navíc parametr -gc, kterým lze zařídit zavolání Garbace Collectoru po zpracování každé dlaždice. Tím se výrazně sníží paměťové nároky, ale za cenu nějakého snížení rychlosti. Zkus to prosím. Mne to ve Windows žere bez -gc spičkově tak 650 MB, s -gc tak 250 MB. To při použití dvou vláken. Jinak jsem zatím po zpracování dalších dlaždic z Prahy problém nenarazil. Honza 2010/2/13 Petr Dlouhý petr.dlo...@email.cz: Ahoj, je tam stále ten problém s pamětí. Když jsem zkoušel adresář pz1, tak to po nějaké době začne náhle konzumovat velké množství paměti (zabere mi to cca 1,7 GB paměti + 0,5 GB swapu). Není to způsobené programem samotným (dlouhou dobu se paměť téměř nezabírá), ale ani jednotlivou dlaždicí (během finále se stále ještě dlaždice mění). On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) - oprava padání. Honza -- Petr Dlouhý ___ 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] Tracer na rozpoznání budov z katastr . map
Ahoj, popravdě mne zatím nenapadá nějaký vhodný algoritmus, který by na to šel aplikovat. Ani jsem moc neprocházel katastrální mapu, takže nevím, jak na jiných místech vypadá. Pro slučky bych si dovedl představit něco, co bude detekovat dvě čáry, které se skoro dotýkají, jsou téměř rovnoběžné a mezi nimi je řada jiných divných úseků (obkroužující služku). Celé toto by se pak nahradilo jednou čarou. U floodfillu by sice šlo nějak detekovat, že jsem v díře ... na dvou různých stranách je nějaký černý pixel, ale aby to bylo trochu rozumné, tak by to chtělo domyslet konkrétní řešení. Můžeš poslat nějakou souřadnici, kde je typická ukázka těchto tenkých čar? Ještě dodělávám ten OCRovač, pak bych na to kouknul. Ale jak říkám, zatím nemám konkrétní nápad... Honza 2010/2/13 Petr Dlouhý petr.dlo...@email.cz: Ahoj, v Praze, například, už začínají docházet nezmapovaná KÚ, která jsou kreslená tlustými čarami. Zbylá území jsou kreslená čárami tenkými a na těch se Tracer moc nechytá, takže to dá výrazně víc práce. Nešlo by upravit Tracer server pro tenké čáry? Hlavní problémy jsou dva - slučky a díry v čarách. Slučky asi budou tvrdší oříšek, a asi jsou zatím důležitější věci na práci (například import adresních bodů). Díry by ale možná šly vyřešit jednodušeji. Nešlo by udělat, aby šlo nastavit, jak moc velkou dírou ten flood-fill proleze? V tlustých čarách je naopak problém s tím, že u některých garáží to občas neproleze kolem nápisu vedle kterého je úzká díra. On Sun, 07 Feb 2010 20:33:57 +0100, Petr Dlouhý petr.dlo...@email.cz wrote: Ono to funguje na tlustých čarách bez problému. Na některých místech je ale KM kreslená tenkými čarami, a v nich jsou občas i díry - proto to natrasuje ten pozemek okolo. Možná by stálo za to udělat nějakou speciální verzi pro tenké čáry (ale nevím jestli je to otázka úpravy konstant nebo by to dalo spoustu práce). To s tím, že to občas skončí tak, že místo kliknutí není v té budově je ale určitě chyba. -- Petr Dlouhý ___ 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 adres z katastralni mapy
Ahoj. Dal jsem tam betu 3 ... http://jabi.aspone.cz/osm/OcrBeta3.zip Pridava drive zminovanou podminku, ktera umoznuje detekovat, zda jde o jednoznacne rozpoznani nebo je treba rucni kontrola. Dale meni stavy rozpoznani: [CHECK] ... je treba rucni kontrola [OVERLAP] ... byl tam prekryv, ale melo by to byt jednoznacne (spise pro debug ucely a overeni programu) Doslo i ke zmene parametru programu: Command line options are: -tiles [..] (*) Path to downloaded tiles -output [..](*) Output filename -log [..] Log filename -allLog all -overlapLog overlap -threads [..] Thread count (*) Required. Defaultni logovani pri uvedeni souboru logu je takove, ze se loguji jen CHECK body. Lze zapnout i overlap body nebo vsechny. Na Monu je asi problem s vicevlaknovym provozem (asi je treba jeste navic neco zamykat nebo tak neco), tak pribyl argument pro urceni poctu vlaken. Pri problemech nastavte na hodnotu 1. A dale cernou barvu povazuji za cervenou. Pokud s tim budou problemy, lze zvolit variantu s orezem a vetsim prekryvem nebo dynamicke stahovani zazoomovane oblasti (pracnejsi). Honza 2010/2/13 Petr Dlouhý petr.dlo...@email.cz: Jedno upozornění - ta data jsem stahoval na třikrát, a potom to sesypal do jednoho adresáře (v domnění, že se překrývající dlaždice požerou, což se ale nestalo protože nejsou zaokrouhlovány stejně). V adresáři jsou tedy v překrývajících oblastech shodné dlaždice akorát s posunem. Pokud bys chtěl jednotlivé dlaždice rozdělit do původních adresářů, tak na [1] jsou seznamy souborů z jednotlivých původních adresářů. [1] http://www.flyshare.cz/stahni/46192/pz.tar.gz On Sat, 13 Feb 2010 02:07:28 +0100, Petr Dlouhý petr.dlo...@email.cz wrote: Posílám testovací data (měl by to být celý okres Praha-západ) na [2]. -- Petr Dlouhý ___ 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] Tracer na rozpoznání budov z katastr . map
Tam jsou čáry souvislé (tedy až na výjimku, kde jsou křivě slepené dvě mapy, které vůbec nepasují k sobě a to je tak ošklivá věc, že si nedovedu představit její automatické řešení - je to častý případ?). Honza 2010/2/13 Petr Dlouhý petr.dlo...@email.cz: Například tady: http://www.openstreetmap.org/?lat=50.03166lon=14.49917zoom=17 ale jestli jinak v Praze stačí stáhnout nějakou oblast, ve které domy chybí, a většinou se trefíš. On Sat, 13 Feb 2010 16:31:49 +0100, Jan Bilak jan.bilak@gmail.com wrote: Můžeš poslat nějakou souřadnici, kde je typická ukázka těchto tenkých čar? -- Petr Dlouhý ___ 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 adres z katastralni mapy
Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) - oprava padání. Honza 2010/2/13 Jan Bilak jan.bilak@gmail.com: Ahoj. Dal jsem tam betu 3 ... http://jabi.aspone.cz/osm/OcrBeta3.zip Pridava drive zminovanou podminku, ktera umoznuje detekovat, zda jde o jednoznacne rozpoznani nebo je treba rucni kontrola. Dale meni stavy rozpoznani: [CHECK] ... je treba rucni kontrola [OVERLAP] ... byl tam prekryv, ale melo by to byt jednoznacne (spise pro debug ucely a overeni programu) Doslo i ke zmene parametru programu: Command line options are: -tiles [..] (*) Path to downloaded tiles -output [..] (*) Output filename -log [..] Log filename -all Log all -overlap Log overlap -threads [..] Thread count (*) Required. Defaultni logovani pri uvedeni souboru logu je takove, ze se loguji jen CHECK body. Lze zapnout i overlap body nebo vsechny. Na Monu je asi problem s vicevlaknovym provozem (asi je treba jeste navic neco zamykat nebo tak neco), tak pribyl argument pro urceni poctu vlaken. Pri problemech nastavte na hodnotu 1. A dale cernou barvu povazuji za cervenou. Pokud s tim budou problemy, lze zvolit variantu s orezem a vetsim prekryvem nebo dynamicke stahovani zazoomovane oblasti (pracnejsi). Honza 2010/2/13 Petr Dlouhý petr.dlo...@email.cz: Jedno upozornění - ta data jsem stahoval na třikrát, a potom to sesypal do jednoho adresáře (v domnění, že se překrývající dlaždice požerou, což se ale nestalo protože nejsou zaokrouhlovány stejně). V adresáři jsou tedy v překrývajících oblastech shodné dlaždice akorát s posunem. Pokud bys chtěl jednotlivé dlaždice rozdělit do původních adresářů, tak na [1] jsou seznamy souborů z jednotlivých původních adresářů. [1] http://www.flyshare.cz/stahni/46192/pz.tar.gz On Sat, 13 Feb 2010 02:07:28 +0100, Petr Dlouhý petr.dlo...@email.cz wrote: Posílám testovací data (měl by to být celý okres Praha-západ) na [2]. -- Petr Dlouhý ___ 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 adres z katastralni mapy
Ahoj, mne se stalo něco podobného, když jsem tam nechal v adresáři PNGčko, které jsem generoval z původních PNG tak, že jsem tam doplňoval modré tečky (kvůli hledání toho chybějícího bodu, který nakonec nechyběl). Ale to mi spíše začalo strašně rychle plnit log. Právě to zkouším na těch tvých datech Prahy ... ještě nejsem u konce. Pravda je, že mám 4 GB RAM, takže 2,3 GB by mi systém možná přežil, kdyby odswapoval všechno ostatní zkusím sledovat paměť. Lukáš tam volal explicitně Garbage Collector tuším po zpracování každé dlaždice, zkusím to tam případně vrátit - třeba pro to měl dobrý důvod (já to odstranil jako zbytečně zdržující). Jinak výsledky jsou podle mne velmi pěkné ... asi 9 bodů k ruční kontrole z cca 3000 dlaždic a nějakých 5 bodů. A to je v Praze, kde jsou překryvy častější než na venkově. Honza 2010/2/13 Petr Dlouhý petr.dlo...@email.cz: Ahoj, je tam stále ten problém s pamětí. Když jsem zkoušel adresář pz1, tak to po nějaké době začne náhle konzumovat velké množství paměti (zabere mi to cca 1,7 GB paměti + 0,5 GB swapu). Není to způsobené programem samotným (dlouhou dobu se paměť téměř nezabírá), ale ani jednotlivou dlaždicí (během finále se stále ještě dlaždice mění). On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) - oprava padání. Honza -- Petr Dlouhý ___ 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 adres z katastralni mapy
Dal jsem tam novou verzi beta3 (na stejné místo). Má navíc parametr -gc, kterým lze zařídit zavolání Garbace Collectoru po zpracování každé dlaždice. Tím se výrazně sníží paměťové nároky, ale za cenu nějakého snížení rychlosti. Zkus to prosím. Mne to ve Windows žere bez -gc spičkově tak 650 MB, s -gc tak 250 MB. To při použití dvou vláken. Jinak jsem zatím po zpracování dalších dlaždic z Prahy problém nenarazil. Honza 2010/2/13 Petr Dlouhý petr.dlo...@email.cz: Ahoj, je tam stále ten problém s pamětí. Když jsem zkoušel adresář pz1, tak to po nějaké době začne náhle konzumovat velké množství paměti (zabere mi to cca 1,7 GB paměti + 0,5 GB swapu). Není to způsobené programem samotným (dlouhou dobu se paměť téměř nezabírá), ale ani jednotlivou dlaždicí (během finále se stále ještě dlaždice mění). On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) - oprava padání. Honza -- Petr Dlouhý ___ 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 adres z katastralni mapy
Projel jsem všechny dlaždice, které jsi mi poslal. Na problém jsem nenarazil. Možné je to specifické chování Mona - já to dělám pod .NETem (třeba vím, že pod Monem mi aplikace vždycky padala, když jsem přistupoval ke konzoli z více vláken, zato .NET to automaticky synchronizoval apod.). Nevím - těžko se ladí něco, co se mi neprojevuje. Zdrojáky jsou tady: http://jabi.aspone.cz/osm/FindAddressPoints-beta3-src.zip Pokud by se problém nepodařilo odstranit, tak je možné to dělat pod Windows. Zase tak dlouho to myslím netrvá, aby byla třeba dělat akce na způsob s...@home. Honza 2010/2/13 Jan Bilak jan.bilak@gmail.com: Dal jsem tam novou verzi beta3 (na stejné místo). Má navíc parametr -gc, kterým lze zařídit zavolání Garbace Collectoru po zpracování každé dlaždice. Tím se výrazně sníží paměťové nároky, ale za cenu nějakého snížení rychlosti. Zkus to prosím. Mne to ve Windows žere bez -gc spičkově tak 650 MB, s -gc tak 250 MB. To při použití dvou vláken. Jinak jsem zatím po zpracování dalších dlaždic z Prahy problém nenarazil. Honza 2010/2/13 Petr Dlouhý petr.dlo...@email.cz: Ahoj, je tam stále ten problém s pamětí. Když jsem zkoušel adresář pz1, tak to po nějaké době začne náhle konzumovat velké množství paměti (zabere mi to cca 1,7 GB paměti + 0,5 GB swapu). Není to způsobené programem samotným (dlouhou dobu se paměť téměř nezabírá), ale ani jednotlivou dlaždicí (během finále se stále ještě dlaždice mění). On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) - oprava padání. Honza -- Petr Dlouhý ___ 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 adres z katastralni mapy
Tady jsou výsledná *.csv a logy z tvých dat Prahy: http://www.flyshare.cz/stahni/46207/praha.zip Zpracovával jsem to po 5 částech - jsou očíslovány stejně *.csv a logy (stejná čísla patří k sobě). Honza 2010/2/13 Jan Bilak jan.bilak@gmail.com: Projel jsem všechny dlaždice, které jsi mi poslal. Na problém jsem nenarazil. Možné je to specifické chování Mona - já to dělám pod .NETem (třeba vím, že pod Monem mi aplikace vždycky padala, když jsem přistupoval ke konzoli z více vláken, zato .NET to automaticky synchronizoval apod.). Nevím - těžko se ladí něco, co se mi neprojevuje. Zdrojáky jsou tady: http://jabi.aspone.cz/osm/FindAddressPoints-beta3-src.zip Pokud by se problém nepodařilo odstranit, tak je možné to dělat pod Windows. Zase tak dlouho to myslím netrvá, aby byla třeba dělat akce na způsob s...@home. Honza 2010/2/13 Jan Bilak jan.bilak@gmail.com: Dal jsem tam novou verzi beta3 (na stejné místo). Má navíc parametr -gc, kterým lze zařídit zavolání Garbace Collectoru po zpracování každé dlaždice. Tím se výrazně sníží paměťové nároky, ale za cenu nějakého snížení rychlosti. Zkus to prosím. Mne to ve Windows žere bez -gc spičkově tak 650 MB, s -gc tak 250 MB. To při použití dvou vláken. Jinak jsem zatím po zpracování dalších dlaždic z Prahy problém nenarazil. Honza 2010/2/13 Petr Dlouhý petr.dlo...@email.cz: Ahoj, je tam stále ten problém s pamětí. Když jsem zkoušel adresář pz1, tak to po nějaké době začne náhle konzumovat velké množství paměti (zabere mi to cca 1,7 GB paměti + 0,5 GB swapu). Není to způsobené programem samotným (dlouhou dobu se paměť téměř nezabírá), ale ani jednotlivou dlaždicí (během finále se stále ještě dlaždice mění). On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) - oprava padání. Honza -- Petr Dlouhý ___ 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 adres z katastralni mapy
Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude výrazně lepší než byla (to už je myslím teď). Ale stoprocentní samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A také jim to bude zatěžovat servery, když se to přežene s rychlostí stahování (mnoho vláken apod.). Honza 2010/2/12 Petr Dlouhý petr.dlo...@email.cz: Kvůli překryvům - čísla se s rozlišením zmenšují. Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících se číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím zabralo počítání. Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc cenu, protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat příliš mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení může nastat spíš tím, že je nutné zpracovat větší množství obrazové informace. On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým rozlišením ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho detekovat oblasti, které obsahují adresní body. A jen tyto úseky stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit množství stahovaných dat. Přijde mi, že nejpomalejší bude právě stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas prodloužil. Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, které byste mohli někam hodit zazipované, abych to nemusel stahovat z WMS pro testování? Honza 2010/2/12 Petr Dlouhý petr.dlo...@email.cz: Ahoj, zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, tak by možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší detekci u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším zoomem, tak to bude další plus). On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, pokusná implementace je velmi rychlá a měla by být i spolehlivá. Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas zpracování jednoho adresního bodu je 17 ms. To vše v jednom vlákně a tedy to zatěžuje jen jedno jádro procesoru. Zítra to snad dodělám do použitelného stavu. Honza 2010/2/11 Petr Dlouhý petr.dlo...@email.cz: Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat pouze ta evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je tam ta dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že by to nešlo uříznout o trochu níž. Problém je, že už jsme to udělali špatně, takže by to bylo dobré napravit bez toho, abychom museli všechno předělávat. On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec u...@penguin.cz wrote: Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat uříznutou dvojku? Pokud to ovšem nezvýší riziko chyby jinde. -- Petr Dlouhý ___ 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 -- Petr Dlouhý ___ 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 -- Petr Dlouhý ___ 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 adres z katastralni mapy
K vyzkoušení: http://jabi.aspone.cz/osm/OcrBeta1.zip Má to stejné ovládání jako původní tile-processor, ale navíc možnost logování: FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv -log log.txt -all -log log.txt ... pokud se toto uvede, tak program bude logovat nerozpoznané body nebo ty, které byly narušené překryvem. Pokud se uvede navíc -all, tak se budou logovat všechny body. Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je to také textový soubor, který když zobrazíte fontem s pevnou šířkou, tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při spuštění v aktuálním adresáři. Honza 2010/2/12 Jan Bilak jan.bilak@gmail.com: Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude výrazně lepší než byla (to už je myslím teď). Ale stoprocentní samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A také jim to bude zatěžovat servery, když se to přežene s rychlostí stahování (mnoho vláken apod.). Honza 2010/2/12 Petr Dlouhý petr.dlo...@email.cz: Kvůli překryvům - čísla se s rozlišením zmenšují. Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících se číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím zabralo počítání. Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc cenu, protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat příliš mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení může nastat spíš tím, že je nutné zpracovat větší množství obrazové informace. On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým rozlišením ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho detekovat oblasti, které obsahují adresní body. A jen tyto úseky stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit množství stahovaných dat. Přijde mi, že nejpomalejší bude právě stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas prodloužil. Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, které byste mohli někam hodit zazipované, abych to nemusel stahovat z WMS pro testování? Honza 2010/2/12 Petr Dlouhý petr.dlo...@email.cz: Ahoj, zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, tak by možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší detekci u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším zoomem, tak to bude další plus). On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, pokusná implementace je velmi rychlá a měla by být i spolehlivá. Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas zpracování jednoho adresního bodu je 17 ms. To vše v jednom vlákně a tedy to zatěžuje jen jedno jádro procesoru. Zítra to snad dodělám do použitelného stavu. Honza 2010/2/11 Petr Dlouhý petr.dlo...@email.cz: Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat pouze ta evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je tam ta dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že by to nešlo uříznout o trochu níž. Problém je, že už jsme to udělali špatně, takže by to bylo dobré napravit bez toho, abychom museli všechno předělávat. On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec u...@penguin.cz wrote: Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat uříznutou dvojku? Pokud to ovšem nezvýší riziko chyby jinde. -- Petr Dlouhý ___ 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 -- Petr Dlouhý ___ 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 -- Petr Dlouhý ___ 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] Tracer na rozpoznání budov z katastr ální mapy
Pokud vím, tak v současné době nikoli. Ani nevím, jak by to vlastně mělo dělat. Zda vytvořit jeden obrys přes všechny části nebo více obrysů a přes to relaci? A jak to pak tagovat? Honza 2010/2/12 Zdeněk Pražák zpra...@seznam.cz: Nainstaloval jsem si tracer a chtěl bych se zeptat, zda se v případě, kdy má budova například několik přístavků v katastrální mapě oddělených od budovyslabší čarou, ale nalézajících se na jednom pozemku, dá tracer přinutit k tomu, aby tyto přístavky otagoval spolu s budovou jako jeden objekt. Pražák ___ 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 adres z katastralni mapy
Doplnil jsem tam chybějící číslici 4. Honza 2010/2/12 Jan Bilak jan.bilak@gmail.com: K vyzkoušení: http://jabi.aspone.cz/osm/OcrBeta1.zip Má to stejné ovládání jako původní tile-processor, ale navíc možnost logování: FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv -log log.txt -all -log log.txt ... pokud se toto uvede, tak program bude logovat nerozpoznané body nebo ty, které byly narušené překryvem. Pokud se uvede navíc -all, tak se budou logovat všechny body. Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je to také textový soubor, který když zobrazíte fontem s pevnou šířkou, tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při spuštění v aktuálním adresáři. Honza 2010/2/12 Jan Bilak jan.bilak@gmail.com: Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude výrazně lepší než byla (to už je myslím teď). Ale stoprocentní samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A také jim to bude zatěžovat servery, když se to přežene s rychlostí stahování (mnoho vláken apod.). Honza 2010/2/12 Petr Dlouhý petr.dlo...@email.cz: Kvůli překryvům - čísla se s rozlišením zmenšují. Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících se číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím zabralo počítání. Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc cenu, protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat příliš mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení může nastat spíš tím, že je nutné zpracovat větší množství obrazové informace. On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým rozlišením ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho detekovat oblasti, které obsahují adresní body. A jen tyto úseky stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit množství stahovaných dat. Přijde mi, že nejpomalejší bude právě stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas prodloužil. Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, které byste mohli někam hodit zazipované, abych to nemusel stahovat z WMS pro testování? Honza 2010/2/12 Petr Dlouhý petr.dlo...@email.cz: Ahoj, zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, tak by možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší detekci u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším zoomem, tak to bude další plus). On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, pokusná implementace je velmi rychlá a měla by být i spolehlivá. Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas zpracování jednoho adresního bodu je 17 ms. To vše v jednom vlákně a tedy to zatěžuje jen jedno jádro procesoru. Zítra to snad dodělám do použitelného stavu. Honza 2010/2/11 Petr Dlouhý petr.dlo...@email.cz: Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat pouze ta evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je tam ta dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že by to nešlo uříznout o trochu níž. Problém je, že už jsme to udělali špatně, takže by to bylo dobré napravit bez toho, abychom museli všechno předělávat. On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec u...@penguin.cz wrote: Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat uříznutou dvojku? Pokud to ovšem nezvýší riziko chyby jinde. -- Petr Dlouhý ___ 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 -- Petr Dlouhý ___ 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 -- Petr Dlouhý ___ 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 adres z katastralni mapy
Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy. Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne. Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze červenou barvu. Jsou 3 možnosti jak to řešit: a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z těch částí mapy, které copyright není. Výhody: Nejlepší výsledky. Nevýhody: Nutnost stahovat více dat z WMS. b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody: Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale nemusí to znamenat nic, i když se to trefí. c) Provádět ruční kontrolu všech popisků s překryvem (těch může být hodně). Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít postřehnutelně horší výsledky. Honza 2010/2/12 Jan Bilak jan.bilak@gmail.com: Doplnil jsem tam chybějící číslici 4. Honza 2010/2/12 Jan Bilak jan.bilak@gmail.com: K vyzkoušení: http://jabi.aspone.cz/osm/OcrBeta1.zip Má to stejné ovládání jako původní tile-processor, ale navíc možnost logování: FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv -log log.txt -all -log log.txt ... pokud se toto uvede, tak program bude logovat nerozpoznané body nebo ty, které byly narušené překryvem. Pokud se uvede navíc -all, tak se budou logovat všechny body. Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je to také textový soubor, který když zobrazíte fontem s pevnou šířkou, tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při spuštění v aktuálním adresáři. Honza 2010/2/12 Jan Bilak jan.bilak@gmail.com: Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude výrazně lepší než byla (to už je myslím teď). Ale stoprocentní samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A také jim to bude zatěžovat servery, když se to přežene s rychlostí stahování (mnoho vláken apod.). Honza 2010/2/12 Petr Dlouhý petr.dlo...@email.cz: Kvůli překryvům - čísla se s rozlišením zmenšují. Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících se číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím zabralo počítání. Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc cenu, protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat příliš mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení může nastat spíš tím, že je nutné zpracovat větší množství obrazové informace. On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým rozlišením ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho detekovat oblasti, které obsahují adresní body. A jen tyto úseky stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit množství stahovaných dat. Přijde mi, že nejpomalejší bude právě stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas prodloužil. Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, které byste mohli někam hodit zazipované, abych to nemusel stahovat z WMS pro testování? Honza 2010/2/12 Petr Dlouhý petr.dlo...@email.cz: Ahoj, zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, tak by možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší detekci u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším zoomem, tak to bude další plus). On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, pokusná implementace je velmi rychlá a měla by být i spolehlivá. Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas zpracování jednoho adresního bodu je 17 ms. To vše v jednom vlákně a tedy to zatěžuje jen jedno jádro procesoru. Zítra to snad dodělám do použitelného stavu. Honza 2010/2/11 Petr Dlouhý petr.dlo...@email.cz: Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat pouze ta evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je tam ta dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že by to nešlo uříznout o trochu níž. Problém je, že už jsme to udělali špatně, takže by to bylo dobré napravit bez toho, abychom museli všechno předělávat. On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec u...@penguin.cz wrote: Aha, tak to jsme si nerozuměli. Nejde naučit
Re: [Talk-cz] Import adres z katastralni mapy
Ahoj, ten copyright je vlevo nahoře, ale pak i na souřadnici cca [530,510] px. Ta detekce bodů ... toho jsem si nevšiml. Jak to kontroluješ? Check ... to značí opravdu i nepatrný překryv. Pokud si to není jisté, tak je tam znak otazník a v hranatých závorkách seznam možností. Ještě tam dám jednu kontrolu a mělo byt o být myslím 100% spolehlivé, když tam nebude žádný červený bod chybět (tedy je třeba použít možnost a) nebo b) vypořádání se s copyrightem). Ořez před detekcí nedělám ... detekce si sama řídí, kdy skončit. Check by nemělo být nic, co by bylo třeba ručně kontrolovat - až se vyřeší ten copyright a přidám tam tu jednu drobnou kontrolu. Těch možností, kdy se tam objeví otazník (není si to jisté) je myslím minimum. Zatím se mi to nestalo. Honza 2010/2/13 Petr Dlouhý petr.dlo...@email.cz: Ahoj, ten copyright je jen úplně nahoře na každé dlaždici, nebo se pletu? Pokud tomu tak je, tak bych volil možnost a), protože je to minimum z velikosti dlaždice, a ty se už stejně stahují s přesahem (kvůli tomu, že se čísla kreslí jen na dlaždici s tečkou). Jinak jsem se koukal na ten skript, a zdá se to velice dobré. Myslím, že by stálo za to to přepočítat, vzhledem k tomu, že je to tak 20x rychlejší, tak to asi nebude problém udělat na jednou počítači. Chyby vidím následující: -Některé adresní body nejsou vůbec detekovány, a u některých je prázdný text (přestože jsou daleko od všeho). -Často se objevuje [CHECK] i u bodů, které byly detekovány správně. Pokud je to v případech, kdy se čísla už skutečně překrývají, tak OK. Jenom se ptám, jestli není možné zvolit agresivnější ořez před detekcí (pozor na jiné posunutí č.e. vs č.p.). -V případech, kdy se objeví [CHECK], tak by asi skript měl stáhnout číslo ve vyšším rozlišení a detekovat to. On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak jan.bilak@gmail.com wrote: Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy. Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne. Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze červenou barvu. Jsou 3 možnosti jak to řešit: a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z těch částí mapy, které copyright není. Výhody: Nejlepší výsledky. Nevýhody: Nutnost stahovat více dat z WMS. b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody: Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale nemusí to znamenat nic, i když se to trefí. c) Provádět ruční kontrolu všech popisků s překryvem (těch může být hodně). Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít postřehnutelně horší výsledky. Honza 2010/2/12 Jan Bilak jan.bilak@gmail.com: Doplnil jsem tam chybějící číslici 4. Honza 2010/2/12 Jan Bilak jan.bilak@gmail.com: K vyzkoušení: http://jabi.aspone.cz/osm/OcrBeta1.zip Má to stejné ovládání jako původní tile-processor, ale navíc možnost logování: FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv -log log.txt -all -log log.txt ... pokud se toto uvede, tak program bude logovat nerozpoznané body nebo ty, které byly narušené překryvem. Pokud se uvede navíc -all, tak se budou logovat všechny body. Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je to také textový soubor, který když zobrazíte fontem s pevnou šířkou, tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při spuštění v aktuálním adresáři. Honza 2010/2/12 Jan Bilak jan.bilak@gmail.com: Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude výrazně lepší než byla (to už je myslím teď). Ale stoprocentní samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A také jim to bude zatěžovat servery, když se to přežene s rychlostí stahování (mnoho vláken apod.). Honza 2010/2/12 Petr Dlouhý petr.dlo...@email.cz: Kvůli překryvům - čísla se s rozlišením zmenšují. Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících se číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím zabralo počítání. Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc cenu, protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat příliš mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení může nastat spíš tím, že je nutné zpracovat větší množství obrazové informace. On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ahoj
Re: [Talk-cz] Import adres z katastralni mapy
Jinak ... když si povolíš logování, tak se loguje i grafická reprezentace toho textu, takže tam uvidíš, co a jak to rozpoznává. Honza 2010/2/13 Jan Bilak jan.bilak@gmail.com: Ahoj, ten copyright je vlevo nahoře, ale pak i na souřadnici cca [530,510] px. Ta detekce bodů ... toho jsem si nevšiml. Jak to kontroluješ? Check ... to značí opravdu i nepatrný překryv. Pokud si to není jisté, tak je tam znak otazník a v hranatých závorkách seznam možností. Ještě tam dám jednu kontrolu a mělo byt o být myslím 100% spolehlivé, když tam nebude žádný červený bod chybět (tedy je třeba použít možnost a) nebo b) vypořádání se s copyrightem). Ořez před detekcí nedělám ... detekce si sama řídí, kdy skončit. Check by nemělo být nic, co by bylo třeba ručně kontrolovat - až se vyřeší ten copyright a přidám tam tu jednu drobnou kontrolu. Těch možností, kdy se tam objeví otazník (není si to jisté) je myslím minimum. Zatím se mi to nestalo. Honza 2010/2/13 Petr Dlouhý petr.dlo...@email.cz: Ahoj, ten copyright je jen úplně nahoře na každé dlaždici, nebo se pletu? Pokud tomu tak je, tak bych volil možnost a), protože je to minimum z velikosti dlaždice, a ty se už stejně stahují s přesahem (kvůli tomu, že se čísla kreslí jen na dlaždici s tečkou). Jinak jsem se koukal na ten skript, a zdá se to velice dobré. Myslím, že by stálo za to to přepočítat, vzhledem k tomu, že je to tak 20x rychlejší, tak to asi nebude problém udělat na jednou počítači. Chyby vidím následující: -Některé adresní body nejsou vůbec detekovány, a u některých je prázdný text (přestože jsou daleko od všeho). -Často se objevuje [CHECK] i u bodů, které byly detekovány správně. Pokud je to v případech, kdy se čísla už skutečně překrývají, tak OK. Jenom se ptám, jestli není možné zvolit agresivnější ořez před detekcí (pozor na jiné posunutí č.e. vs č.p.). -V případech, kdy se objeví [CHECK], tak by asi skript měl stáhnout číslo ve vyšším rozlišení a detekovat to. On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak jan.bilak@gmail.com wrote: Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy. Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne. Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze červenou barvu. Jsou 3 možnosti jak to řešit: a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z těch částí mapy, které copyright není. Výhody: Nejlepší výsledky. Nevýhody: Nutnost stahovat více dat z WMS. b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody: Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale nemusí to znamenat nic, i když se to trefí. c) Provádět ruční kontrolu všech popisků s překryvem (těch může být hodně). Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít postřehnutelně horší výsledky. Honza 2010/2/12 Jan Bilak jan.bilak@gmail.com: Doplnil jsem tam chybějící číslici 4. Honza 2010/2/12 Jan Bilak jan.bilak@gmail.com: K vyzkoušení: http://jabi.aspone.cz/osm/OcrBeta1.zip Má to stejné ovládání jako původní tile-processor, ale navíc možnost logování: FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv -log log.txt -all -log log.txt ... pokud se toto uvede, tak program bude logovat nerozpoznané body nebo ty, které byly narušené překryvem. Pokud se uvede navíc -all, tak se budou logovat všechny body. Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je to také textový soubor, který když zobrazíte fontem s pevnou šířkou, tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při spuštění v aktuálním adresáři. Honza 2010/2/12 Jan Bilak jan.bilak@gmail.com: Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude výrazně lepší než byla (to už je myslím teď). Ale stoprocentní samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A také jim to bude zatěžovat servery, když se to přežene s rychlostí stahování (mnoho vláken apod.). Honza 2010/2/12 Petr Dlouhý petr.dlo...@email.cz: Kvůli překryvům - čísla se s rozlišením zmenšují. Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících se číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím zabralo počítání. Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc cenu, protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat příliš mnoho datového objemu. To samé platí pro
Re: [Talk-cz] Import adres z katastralni mapy
Ořez by mohl být nižší, ale já to každý sloupec reprezentuji 16-bitovým číslem (16 řádek) a pak s tím dělám různé bitové operace. Takže 15 by se mi nehodilo... Tyhle nápady jsou dobré, ale nejsou třeba. Algoritmus totiž funguje tak, že se snaží najít napřed přesnou shodu. A pokud přesná shoda není, tak najít všechny možnosti, které tam mohou být. Pokud je více možností, co by tam mohlo být, tak to do textu přidá ?. Pokud jedna možnost, tak ji to bere jako správnou. A pokud žádá možnost, tak to končí. Check je jen indikace toho, že tam nebyla přesná shoda. Otazník je indikace toho, že to bylo mnohoznačné. Zatím tam tedy chybí jedna kontrola, která teoreticky může způsobit chybu bez otázníku (jen s checkem). Ale to opravím a pravděpodobnost takové chyby je velmi malá. Testovací data by se mi hodila, pokud máš kam dát nějaký archiv (klidně na nějaký free one-file hosting typu rapidshare - ale účet tam nikde nemám, tak aby to bylo reálné stáhnout zdarma). Honza 2010/2/13 Petr Dlouhý petr.dlo...@email.cz: Ahoj, teprv teď jsem si všiml toho krásného logu. Ořez by mohl být o 1 pixel nižší a o něco užší (nevím ale kolikaciferná je nejdelší adresa). Další nápady na snížení množství [CHECK] jsou: Pokud adresa začíná na bez č.p./č.e. tak není nutné dávat [CHECK], ale stačí oříznout zbytek řetězce (tím se vyřadí tak polovina případů). Pokud je tam navíc pouze pár bodů nižších než číslice/písmeno, nemohou ji tvořit, a tudíž není nutné dávat [CHECK], protože se tam nemohl připlést nějaký další adresný bod, který by musel začínat na č nebo b. Pro vypořádání s copyrightem existuje ještě možnost d) - pokud si skript není jist výsledkem, tak si stáhne zazoomované číslo, takže mu muže být copyright jedno. Spolehlivé to není hlavně v místech, kde je několik adres v jednom shluku (poměrně blízko sebe). Kontroluju to tak, že si vygeneruju adresní body pomocí Merge skriptu a otevřu to v JOSM. PS. Jestli pořád sháníš testovací data, můžu ti poslat celou prahu-západ, myslel jsem, že už jsem jí smazal, ale není tomu tak. Původní zpráva Od: Petr Dlouhý petr.dlo...@email.cz Předmět: Re: [Talk-cz] Import adres z katastralni mapy Datum: 13.2.2010 00:29:16 Ahoj, ten copyright je jen úplně nahoře na každé dlaždici, nebo se pletu? Pokud tomu tak je, tak bych volil možnost a), protože je to minimum z velikosti dlaždice, a ty se už stejně stahují s přesahem (kvůli tomu, že se čísla kreslí jen na dlaždici s tečkou). Jinak jsem se koukal na ten skript, a zdá se to velice dobré. Myslím, že by stálo za to to přepočítat, vzhledem k tomu, že je to tak 20x rychlejší, tak to asi nebude problém udělat na jednou počítači. Chyby vidím následující: -Některé adresní body nejsou vůbec detekovány, a u některých je prázdný text (přestože jsou daleko od všeho). -Často se objevuje [CHECK] i u bodů, které byly detekovány správně. Pokud je to v případech, kdy se čísla už skutečně překrývají, tak OK. Jenom se ptám, jestli není možné zvolit agresivnější ořez před detekcí (pozor na jiné posunutí č.e. vs č.p.). -V případech, kdy se objeví [CHECK], tak by asi skript měl stáhnout číslo ve vyšším rozlišení a detekovat to. On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak jan.bilak@gmail.com wrote: Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy. Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne. Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze červenou barvu. Jsou 3 možnosti jak to řešit: a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z těch částí mapy, které copyright není. Výhody: Nejlepší výsledky. Nevýhody: Nutnost stahovat více dat z WMS. b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody: Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale nemusí to znamenat nic, i když se to trefí. c) Provádět ruční kontrolu všech popisků s překryvem (těch může být hodně). Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít postřehnutelně horší výsledky. Honza 2010/2/12 Jan Bilak jan.bilak@gmail.com: Doplnil jsem tam chybějící číslici 4. Honza 2010/2/12 Jan Bilak jan.bilak@gmail.com: K vyzkoušení: http://jabi.aspone.cz/osm/OcrBeta1.zip Má to stejné ovládání jako původní tile-processor, ale navíc možnost logování: FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv -log log.txt -all -log log.txt ... pokud se toto uvede, tak program bude logovat nerozpoznané body nebo ty, které byly narušené překryvem. Pokud se uvede navíc -all, tak se budou logovat všechny body. Soubor charDef.txt obsahuje
Re: [Talk-cz] Import adres z katastralni mapy
Dal jsem tam betu 2 ... http://jabi.aspone.cz/osm/OcrBeta2.zip Je vícevláknová, trochu přepracovaný výpis do konzole (časový odhad do konce apod.). + zapisuje do csv souboru info o tom, že bod je moc blízko kraje dlaždice. Honza 2010/2/13 Jan Bilak jan.bilak@gmail.com: Ořez by mohl být nižší, ale já to každý sloupec reprezentuji 16-bitovým číslem (16 řádek) a pak s tím dělám různé bitové operace. Takže 15 by se mi nehodilo... Tyhle nápady jsou dobré, ale nejsou třeba. Algoritmus totiž funguje tak, že se snaží najít napřed přesnou shodu. A pokud přesná shoda není, tak najít všechny možnosti, které tam mohou být. Pokud je více možností, co by tam mohlo být, tak to do textu přidá ?. Pokud jedna možnost, tak ji to bere jako správnou. A pokud žádá možnost, tak to končí. Check je jen indikace toho, že tam nebyla přesná shoda. Otazník je indikace toho, že to bylo mnohoznačné. Zatím tam tedy chybí jedna kontrola, která teoreticky může způsobit chybu bez otázníku (jen s checkem). Ale to opravím a pravděpodobnost takové chyby je velmi malá. Testovací data by se mi hodila, pokud máš kam dát nějaký archiv (klidně na nějaký free one-file hosting typu rapidshare - ale účet tam nikde nemám, tak aby to bylo reálné stáhnout zdarma). Honza 2010/2/13 Petr Dlouhý petr.dlo...@email.cz: Ahoj, teprv teď jsem si všiml toho krásného logu. Ořez by mohl být o 1 pixel nižší a o něco užší (nevím ale kolikaciferná je nejdelší adresa). Další nápady na snížení množství [CHECK] jsou: Pokud adresa začíná na bez č.p./č.e. tak není nutné dávat [CHECK], ale stačí oříznout zbytek řetězce (tím se vyřadí tak polovina případů). Pokud je tam navíc pouze pár bodů nižších než číslice/písmeno, nemohou ji tvořit, a tudíž není nutné dávat [CHECK], protože se tam nemohl připlést nějaký další adresný bod, který by musel začínat na č nebo b. Pro vypořádání s copyrightem existuje ještě možnost d) - pokud si skript není jist výsledkem, tak si stáhne zazoomované číslo, takže mu muže být copyright jedno. Spolehlivé to není hlavně v místech, kde je několik adres v jednom shluku (poměrně blízko sebe). Kontroluju to tak, že si vygeneruju adresní body pomocí Merge skriptu a otevřu to v JOSM. PS. Jestli pořád sháníš testovací data, můžu ti poslat celou prahu-západ, myslel jsem, že už jsem jí smazal, ale není tomu tak. Původní zpráva Od: Petr Dlouhý petr.dlo...@email.cz Předmět: Re: [Talk-cz] Import adres z katastralni mapy Datum: 13.2.2010 00:29:16 Ahoj, ten copyright je jen úplně nahoře na každé dlaždici, nebo se pletu? Pokud tomu tak je, tak bych volil možnost a), protože je to minimum z velikosti dlaždice, a ty se už stejně stahují s přesahem (kvůli tomu, že se čísla kreslí jen na dlaždici s tečkou). Jinak jsem se koukal na ten skript, a zdá se to velice dobré. Myslím, že by stálo za to to přepočítat, vzhledem k tomu, že je to tak 20x rychlejší, tak to asi nebude problém udělat na jednou počítači. Chyby vidím následující: -Některé adresní body nejsou vůbec detekovány, a u některých je prázdný text (přestože jsou daleko od všeho). -Často se objevuje [CHECK] i u bodů, které byly detekovány správně. Pokud je to v případech, kdy se čísla už skutečně překrývají, tak OK. Jenom se ptám, jestli není možné zvolit agresivnější ořez před detekcí (pozor na jiné posunutí č.e. vs č.p.). -V případech, kdy se objeví [CHECK], tak by asi skript měl stáhnout číslo ve vyšším rozlišení a detekovat to. On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak jan.bilak@gmail.com wrote: Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy. Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne. Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze červenou barvu. Jsou 3 možnosti jak to řešit: a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z těch částí mapy, které copyright není. Výhody: Nejlepší výsledky. Nevýhody: Nutnost stahovat více dat z WMS. b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody: Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale nemusí to znamenat nic, i když se to trefí. c) Provádět ruční kontrolu všech popisků s překryvem (těch může být hodně). Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít postřehnutelně horší výsledky. Honza 2010/2/12 Jan Bilak jan.bilak@gmail.com: Doplnil jsem tam chybějící číslici 4. Honza 2010/2/12 Jan Bilak jan.bilak@gmail.com: K vyzkoušení: http://jabi.aspone.cz/osm/OcrBeta1.zip Má to stejné ovládání jako původní tile-processor, ale navíc možnost logování: FindAddressPoints.exe
Re: [Talk-cz] Import adres z katastralni mapy
Ano, to prodloužení o něco bude řešit ta kontrola (už je celkem jedno, zda prodloužení čísla nebo popisu bez č.p./č.e.. Tedy alespoň jsem o tom přesvědčen. Do vypořádání se s copyrightem a přidání té kontroly to není zcela spolehlivé. Může to jak zkrátit číslo, tak prodloužit - teoreticky i možná změnit. Díky za příklad i data. Honza 2010/2/13 Petr Dlouhý petr.dlo...@email.cz: Aha, tak to jsem předtím nepochopil. V tom případě se ale u některých bez č.p./č.e. detekují nějaké mezery nebo jiný bordel za nimi a možná jsem viděl i případ, kdy se nějaké číslo prodloužilo o číslice, které tam neměly být (pokusím se to najít). Dlaždice je na [1], je tam víc takových bodů, co se nedetekovali. Testovací data se pokusím nahrát, je toho kolem 200MB. [1] http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png On Sat, 13 Feb 2010 01:10:29 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ořez by mohl být nižší, ale já to každý sloupec reprezentuji 16-bitovým číslem (16 řádek) a pak s tím dělám různé bitové operace. Takže 15 by se mi nehodilo... Tyhle nápady jsou dobré, ale nejsou třeba. Algoritmus totiž funguje tak, že se snaží najít napřed přesnou shodu. A pokud přesná shoda není, tak najít všechny možnosti, které tam mohou být. Pokud je více možností, co by tam mohlo být, tak to do textu přidá ?. Pokud jedna možnost, tak ji to bere jako správnou. A pokud žádá možnost, tak to končí. Check je jen indikace toho, že tam nebyla přesná shoda. Otazník je indikace toho, že to bylo mnohoznačné. Zatím tam tedy chybí jedna kontrola, která teoreticky může způsobit chybu bez otázníku (jen s checkem). Ale to opravím a pravděpodobnost takové chyby je velmi malá. Testovací data by se mi hodila, pokud máš kam dát nějaký archiv (klidně na nějaký free one-file hosting typu rapidshare - ale účet tam nikde nemám, tak aby to bylo reálné stáhnout zdarma). Honza -- Petr Dlouhý ___ 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 adres z katastralni mapy
Zkoušel jsem tu dlaždici http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png a nenašel jsem žádný bod, který by to nedetekovalo. Nechal jsem si udělat modrou tečku do původní bitmapy na každý detekovaný bod ... a ruční kontrolou byly všechny omodřené a žádný červený nezbyl. Prosím o jeden případ bodu (číslo popisné, souřadnici v pixelech nebo tak něco), který se ti nedetekoval. Do csv mi to napsalo 186 řádek. Tedy to našlo 186 bodů. Tobě také? Honza 2010/2/13 Petr Dlouhý petr.dlo...@email.cz: Aha, tak to jsem předtím nepochopil. V tom případě se ale u některých bez č.p./č.e. detekují nějaké mezery nebo jiný bordel za nimi a možná jsem viděl i případ, kdy se nějaké číslo prodloužilo o číslice, které tam neměly být (pokusím se to najít). Dlaždice je na [1], je tam víc takových bodů, co se nedetekovali. Testovací data se pokusím nahrát, je toho kolem 200MB. [1] http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png On Sat, 13 Feb 2010 01:10:29 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ořez by mohl být nižší, ale já to každý sloupec reprezentuji 16-bitovým číslem (16 řádek) a pak s tím dělám různé bitové operace. Takže 15 by se mi nehodilo... Tyhle nápady jsou dobré, ale nejsou třeba. Algoritmus totiž funguje tak, že se snaží najít napřed přesnou shodu. A pokud přesná shoda není, tak najít všechny možnosti, které tam mohou být. Pokud je více možností, co by tam mohlo být, tak to do textu přidá ?. Pokud jedna možnost, tak ji to bere jako správnou. A pokud žádá možnost, tak to končí. Check je jen indikace toho, že tam nebyla přesná shoda. Otazník je indikace toho, že to bylo mnohoznačné. Zatím tam tedy chybí jedna kontrola, která teoreticky může způsobit chybu bez otázníku (jen s checkem). Ale to opravím a pravděpodobnost takové chyby je velmi malá. Testovací data by se mi hodila, pokud máš kam dát nějaký archiv (klidně na nějaký free one-file hosting typu rapidshare - ale účet tam nikde nemám, tak aby to bylo reálné stáhnout zdarma). Honza -- Petr Dlouhý ___ 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 adres z katastralni mapy
OK, nic se nestalo. Hlavně, že se to vyjasnilo. Honza 2010/2/13 Petr Dlouhý petr.dlo...@email.cz: Omlouvám se. To není chyba - Merge nevygeneruje pro bez č.p./č.e. žádný bod, takže je všechno v pořádku. Původní zpráva Od: Petr Dlouhý petr.dlo...@email.cz Předmět: Re: [Talk-cz] Import adres z katastralni mapy Datum: 13.2.2010 03:02:22 Ahoj, 186 souhlasí, ty chybějící body jsou vždy bez č.p./č.e.. Chybí například bod pod č.p. 1 a 121 na souřadnicích 50,13254; 14,33821. On Sat, 13 Feb 2010 01:58:07 +0100, Jan Bilak jan.bilak@gmail.com wrote: ___ 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 adres z katastralni mapy
Ahoj, jasně ... to je dobrá otázka. Ale ono by to neznamelalo to celé předělat. Prakticky by to bylo spíše rozšíření stávajícího. Jen místo zavolání externího OCR by se zavolalo jednoúčelové interní OCR. Honza 2010/2/11 Petr Dlouhý petr.dlo...@email.cz: Ahoj, to by možná fungovalo líp, ale je otázka, jestli to stojí za tu práci, když už mám funkční program. Ty změny se samozřejmě časem budou muset udělat, takže by to určitě nebyla zbytečná práce. Zajímavý by byl taky nějaký obecný diff plugin pro JOSM. On Thu, 11 Feb 2010 18:29:27 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, ještě jsem si říkal, že možná nebylo špatné rozpoznávání dělat na základě podobnosti vzoru jednotlivých číslic. Když je to psané jedním fontem, jednou velikostí, vždy stejně natočené a bez nějakých kazů vzniklým skenováním, tak by tato metoda musela být vysoce spolehlivá. Dokonce podle pozorování jsou znaky zarovnané na celé pixely (ale mohu se plést - koukal jsem na to jen letmo). Výhoda je v tom, že je to metoda prakticky zcela spolehlivá. Pokud text něco překrývá, tak to odhalí (neshoduje se s žádným vzorem číslice/písmena). Pokud se naopak znak shoduje se vzorem, tak je prakticky jisté, že jde o tento znak. Teoreticky by nějaký jiný objekt mohl udělat např. z písmene I písmeno T, ale aby to zcela přesně odpovídalo vzoru, to je podle mne menší pravděpodobnost, než vyhrát první cenu v nějaké loterii. Algoritmus rozpoznávání by přitom byl myslím velmi jednoduše naprogramovatelný, rychlý a nepotřeboval by nějaké externí OCRy. To se sice může zdát jako zbytečnost, ale mělo by to význam při aktualizacích. Tedy nyní se celý import pojal jako jednorázový import. Ale data se budou měnit a nebylo by od věci, kdyby se periodicky našly změny, doplnila nová čísla domů apod. Zkusím to ověřit na příkladu. Honza 2010/2/11 Petr Dlouhý petr.dlo...@email.cz: Ahoj, začal jsem s imortem adresních bodů v Praze-západ, ale zjistil jsem jeden celkem zásadní problém. Zdá se, že evidenční čísla jsou o něco blíž k tečce než ta popisná - důsledkem je to, že pokud je v čísle číslice 2, tak se občas stane, že jí to rozezná jako 7. Těch případů je tolik, že dělat to ručně pro celou ČR by byla nepředstavitelná práce (nehledě na to, že by se to špatně přiřadilo) - bylo by tedy dobré vyřešit to nějak automaticky. Otázka je jak problém vyřešit. Asi nejlepší bude znovu rozpoznat ty evidenční čísla, ve kterých je 7 - byl by to tedy stejný problém jako jsem už navrhoval s čísly, která nebyla rozpoznána vůbec. Máš na to Lukáši skript, nebo ho mám vyrobit? On Wed, 10 Feb 2010 01:48:34 +0100, Petr Dlouhý petr.dlo...@email.cz wrote: Ahoj, tak na Kubajzově stroji je (po kratší odstávce) už taky vše spočítané a uploadované. On Tue, 02 Feb 2010 22:52:06 +0100, Martin Kupec ma...@jkopava.cz wrote: Tak jsem uploadoval na server vysledky, odkaz je na wiki ([1]). Nevim jak je to se zpracovanim zbylych tilu, ale kdyz mi nekdo neco uvolni, tak to klidne jeste spocitam :-). Zjistil jsem ze ten stoj co jsem na to zneuzil se nejak moc zbytecne flaka... [1] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR/Prubeh_Zpracovani Martin Kupec ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- Petr Dlouhý ___ 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 -- Petr Dlouhý ___ 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 adres z katastralni mapy
Ahoj, pokusná implementace je velmi rychlá a měla by být i spolehlivá. Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas zpracování jednoho adresního bodu je 17 ms. To vše v jednom vlákně a tedy to zatěžuje jen jedno jádro procesoru. Zítra to snad dodělám do použitelného stavu. Honza 2010/2/11 Petr Dlouhý petr.dlo...@email.cz: Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat pouze ta evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je tam ta dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že by to nešlo uříznout o trochu níž. Problém je, že už jsme to udělali špatně, takže by to bylo dobré napravit bez toho, abychom museli všechno předělávat. On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec u...@penguin.cz wrote: Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat uříznutou dvojku? Pokud to ovšem nezvýší riziko chyby jinde. -- Petr Dlouhý ___ 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] Tracer na rozpoznání budov z katastr . map
Ahoj, zkoušel jsem použít algoritmus pro ztenčování od Jiřího Parkana (díky za něj). Rychlost je velmi dobrá. Problém je, že je poněkud agresivní a pokud k čáře přiléhá něco tlustšího, tak to dělá ošklivé věci. V příloze je trochu extrémní ukázka, ale dělá to často obdobnou věc i u klasické čáry. A myslím, že nejde o chybu tohoto algoritmu, ale je to obecná věc. Asi u většiny algoritmů by to vyhnulo obrys jen někam do poloviny (těžiště), ale i to je špatné. Honza Dne 8. února 2010 22:19 MP singular...@gmail.com napsal(a): Taky se mi zda, ze tracer ma problemy s nekterymi vetsimi budovami, treba od tehle vytrasuje jen roh: trace/simple/50.08182736797727;14.513559241177791 a nektere nevytrasuje vubec Neni tam nejaky limit na maximalni velikost budovy? Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz attachment: agresivita.PNG___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map
Ahoj, ten tracker se snažil to čáru posouvat na střed čáry (tedy nejprve obtáhnul vnitřní hranu, pak zkoušel detekovat tlouštky čar a čáru posouvat). Ale moc mu to nešlo. Mám rozpracovanou úpravu, která to myslím trochu zlepší. Chybu to občas udělá, ale je to myslím lepší. Zazněl tady nápad - nedělat detekci tlouštky čar, ale linie ztenčit ještě v bitmapě. To by mohlo přinést lepší výsledky. Obávám se, že za cenu zpomalení trasování, ale výpočetního výkonu je obecně dostatek - jen by se to muselo patrně předzpracovávat. Zkoušel jsem nějakou morfologickou operaci provádět nad polem bytů (pixelů) cca 4000 x 4000 velkým v .NETu (unsafe) ... a trvalo to celkem dlouho (malé jednotky sekund). A jak jsem pochopil, takových operací by se tam musely dělat desítky. Ale jistě by se daly dělat různé optimalizace - není třeba takto upravovat celou ohromnou bitmapu, ale jen její část, kde je dům + malé okolí. Dalo by se to celé udělat unmanaged (v Cčku) apod. Ten dialog ... myslím, že by se s tím dalo dělat něco i relativně snadno. Také jej nemám rád. Tedy hlavně v případech, kdy se nenačítají další dlaždice mapky z webu a tedy trasování netrvá moc dlouho. Asi by stačila změna kurzoru na hodinky. Honza Dne 6. února 2010 18:07 Aleš Janda openstreet...@kyblsoft.cz napsal(a): Ahoj, teda musím říci - ten Váš Tracker je super. Jednoznačně. Díky moc za něj. To je plugin užitečností určitě srovnatelný s czechaddress, a možná ještě užitečnější. I když to lze těžko srovnávat. Měl bych k němu jen dvě malé připomínky: 1) Tracker neobtahuje domy ve středu čar, ale vyrobí je na vnitřní straně čáry. To má dva neblahé důsledky - dům je tak pravděpodobně zakreslen menší než ve skutečnosti a také pak moc nevychází navazování domů. Když stojí dva domy nalepené k sobě, různých velikostí, tak vyrobím jeden a obtáhne se vnitřní strana toho prvního. Pak udělám druhý, ten si všimne, že blízko leží nějaký dům, tak ho přetáhne k sobě do vnitřní strany - a nevyjde to, tam, kde jsou na katastru čáry kolmé, jsou křivé, protože je rozdíl právě o tloušťku čáry. Škoda toho 2) V okamžiku trackování se objeví modální dialog Stopování Je pěkné, že mi program říká, že něco dělá, ale po chvíli to ruší. V okamžiku stopování nemůžu dělat vůbec nic (posouvat mapou atd.), navíc ten dialog vyjede uprostřed obrazovky (často tam, kde jsem kliknul) - je to takové nepěkné. Ideální by byl nemodální dialog někde po straně - abych ho viděl, ale nerušil. Nevím, jak je technicky náročné to v JOSM udělat. Každopádně ale díky moc, i tak je Tracker velkým přínosem do OSM a vynikajícím počinem. Aleš Janda ___ 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] Tracer na rozpoznání budov z katastr . map
Ahoj, ano - se změnou balíku nemám problém. Jde mi to jak zkompilovat, tak spustit. Nakonec když se koukneš na jiné pluginy, tak většina z nich je v balíku org.openstreetmap.josm.plugins.[neco]. Osobně si musím zase lokálně předělávat build skript, protože mi nefunguje získávání verze z revize SVN. Ale nevadí - udělal jsem si skriptík, který to dělá automaticky, takže o tom už skoro ani nevím. Je to tak patrně správně, tak jsem to tak v SVN nechal. A ten úhel ... těžko říct, zda je užitečný nebo ne. Chtěl jsem, aby když se snaží to nacpat do nové úsečku existující bod, tak aby tím nevzniklo něco moc zalomeného. Nemám vypozorované, co se chová lépe. A možná ani žádní univerzální řešení není a něco se bude chovat lépe v oblastech, kde jsou domy obdélníkové (paneláky apod.) a něco zase někde na venkově nebo kde jsou domu různě kulaté... Jinak jsem zkoušel upravovat ten server a při pokusech mi to dělalo strašné věci při napojování, jak jsi zvýšil tu toleranci. Když jsem ji 3x zmenšil (na 0.05), tak se mi to chová mnohem lépe. Honza 2010/2/6 Petr Dlouhý petr.dlo...@email.cz: Ahoj, přidělal jsem funkci, že při stisknutém alt to nepřidává tag building. Měl bych ale dva dotazy: Po předělání balíku se mi nedaří plugin spustit - musím si to lokálně předělávat zpátky. Daří se ti spustit? Nenašel jsem, co by mohlo být nastavené špatně. Proč je tam ta kontrola na úhel při spojování, a proč je navíc jen u jednoho typu spojování? Zkoušel jsem jí dat pryč a připadá mi, že se to chová stále rozumně. Když tam ale je, tak to občas nespojí něco, co by spojit mohlo. On Sat, 06 Feb 2010 18:25:00 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, ten tracker se snažil to čáru posouvat na střed čáry (tedy nejprve obtáhnul vnitřní hranu, pak zkoušel detekovat tlouštky čar a čáru posouvat). Ale moc mu to nešlo. Mám rozpracovanou úpravu, která to myslím trochu zlepší. Chybu to občas udělá, ale je to myslím lepší. Zazněl tady nápad - nedělat detekci tlouštky čar, ale linie ztenčit ještě v bitmapě. To by mohlo přinést lepší výsledky. Obávám se, že za cenu zpomalení trasování, ale výpočetního výkonu je obecně dostatek - jen by se to muselo patrně předzpracovávat. Zkoušel jsem nějakou morfologickou operaci provádět nad polem bytů (pixelů) cca 4000 x 4000 velkým v .NETu (unsafe) ... a trvalo to celkem dlouho (malé jednotky sekund). A jak jsem pochopil, takových operací by se tam musely dělat desítky. Ale jistě by se daly dělat různé optimalizace - není třeba takto upravovat celou ohromnou bitmapu, ale jen její část, kde je dům + malé okolí. Dalo by se to celé udělat unmanaged (v Cčku) apod. Ten dialog ... myslím, že by se s tím dalo dělat něco i relativně snadno. Také jej nemám rád. Tedy hlavně v případech, kdy se nenačítají další dlaždice mapky z webu a tedy trasování netrvá moc dlouho. Asi by stačila změna kurzoru na hodinky. Honza Dne 6. února 2010 18:07 Aleš Janda openstreet...@kyblsoft.cz napsal(a): Ahoj, teda musím říci - ten Váš Tracker je super. Jednoznačně. Díky moc za něj. To je plugin užitečností určitě srovnatelný s czechaddress, a možná ještě užitečnější. I když to lze těžko srovnávat. Měl bych k němu jen dvě malé připomínky: 1) Tracker neobtahuje domy ve středu čar, ale vyrobí je na vnitřní straně čáry. To má dva neblahé důsledky - dům je tak pravděpodobně zakreslen menší než ve skutečnosti a také pak moc nevychází navazování domů. Když stojí dva domy nalepené k sobě, různých velikostí, tak vyrobím jeden a obtáhne se vnitřní strana toho prvního. Pak udělám druhý, ten si všimne, že blízko leží nějaký dům, tak ho přetáhne k sobě do vnitřní strany - a nevyjde to, tam, kde jsou na katastru čáry kolmé, jsou křivé, protože je rozdíl právě o tloušťku čáry. Škoda toho 2) V okamžiku trackování se objeví modální dialog Stopování Je pěkné, že mi program říká, že něco dělá, ale po chvíli to ruší. V okamžiku stopování nemůžu dělat vůbec nic (posouvat mapou atd.), navíc ten dialog vyjede uprostřed obrazovky (často tam, kde jsem kliknul) - je to takové nepěkné. Ideální by byl nemodální dialog někde po straně - abych ho viděl, ale nerušil. Nevím, jak je technicky náročné to v JOSM udělat. Každopádně ale díky moc, i tak je Tracker velkým přínosem do OSM a vynikajícím počinem. Aleš Janda ___ 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 -- Petr Dlouhý ___ 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] Tracer na rozpoznání budov z katastr . map
Experimentální verze TraceServeru - jen pro toho, kdo to chce vyzkoušet: http://jabi.aspone.cz/www/osm/TraceServerBeta3.zip (nenahrazuje betu 2 - tohle občas padá apod.) Honza 2010/2/6 Jan Bilak jan.bilak@gmail.com: Ahoj, ano - se změnou balíku nemám problém. Jde mi to jak zkompilovat, tak spustit. Nakonec když se koukneš na jiné pluginy, tak většina z nich je v balíku org.openstreetmap.josm.plugins.[neco]. Osobně si musím zase lokálně předělávat build skript, protože mi nefunguje získávání verze z revize SVN. Ale nevadí - udělal jsem si skriptík, který to dělá automaticky, takže o tom už skoro ani nevím. Je to tak patrně správně, tak jsem to tak v SVN nechal. A ten úhel ... těžko říct, zda je užitečný nebo ne. Chtěl jsem, aby když se snaží to nacpat do nové úsečku existující bod, tak aby tím nevzniklo něco moc zalomeného. Nemám vypozorované, co se chová lépe. A možná ani žádní univerzální řešení není a něco se bude chovat lépe v oblastech, kde jsou domy obdélníkové (paneláky apod.) a něco zase někde na venkově nebo kde jsou domu různě kulaté... Jinak jsem zkoušel upravovat ten server a při pokusech mi to dělalo strašné věci při napojování, jak jsi zvýšil tu toleranci. Když jsem ji 3x zmenšil (na 0.05), tak se mi to chová mnohem lépe. Honza 2010/2/6 Petr Dlouhý petr.dlo...@email.cz: Ahoj, přidělal jsem funkci, že při stisknutém alt to nepřidává tag building. Měl bych ale dva dotazy: Po předělání balíku se mi nedaří plugin spustit - musím si to lokálně předělávat zpátky. Daří se ti spustit? Nenašel jsem, co by mohlo být nastavené špatně. Proč je tam ta kontrola na úhel při spojování, a proč je navíc jen u jednoho typu spojování? Zkoušel jsem jí dat pryč a připadá mi, že se to chová stále rozumně. Když tam ale je, tak to občas nespojí něco, co by spojit mohlo. On Sat, 06 Feb 2010 18:25:00 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, ten tracker se snažil to čáru posouvat na střed čáry (tedy nejprve obtáhnul vnitřní hranu, pak zkoušel detekovat tlouštky čar a čáru posouvat). Ale moc mu to nešlo. Mám rozpracovanou úpravu, která to myslím trochu zlepší. Chybu to občas udělá, ale je to myslím lepší. Zazněl tady nápad - nedělat detekci tlouštky čar, ale linie ztenčit ještě v bitmapě. To by mohlo přinést lepší výsledky. Obávám se, že za cenu zpomalení trasování, ale výpočetního výkonu je obecně dostatek - jen by se to muselo patrně předzpracovávat. Zkoušel jsem nějakou morfologickou operaci provádět nad polem bytů (pixelů) cca 4000 x 4000 velkým v .NETu (unsafe) ... a trvalo to celkem dlouho (malé jednotky sekund). A jak jsem pochopil, takových operací by se tam musely dělat desítky. Ale jistě by se daly dělat různé optimalizace - není třeba takto upravovat celou ohromnou bitmapu, ale jen její část, kde je dům + malé okolí. Dalo by se to celé udělat unmanaged (v Cčku) apod. Ten dialog ... myslím, že by se s tím dalo dělat něco i relativně snadno. Také jej nemám rád. Tedy hlavně v případech, kdy se nenačítají další dlaždice mapky z webu a tedy trasování netrvá moc dlouho. Asi by stačila změna kurzoru na hodinky. Honza Dne 6. února 2010 18:07 Aleš Janda openstreet...@kyblsoft.cz napsal(a): Ahoj, teda musím říci - ten Váš Tracker je super. Jednoznačně. Díky moc za něj. To je plugin užitečností určitě srovnatelný s czechaddress, a možná ještě užitečnější. I když to lze těžko srovnávat. Měl bych k němu jen dvě malé připomínky: 1) Tracker neobtahuje domy ve středu čar, ale vyrobí je na vnitřní straně čáry. To má dva neblahé důsledky - dům je tak pravděpodobně zakreslen menší než ve skutečnosti a také pak moc nevychází navazování domů. Když stojí dva domy nalepené k sobě, různých velikostí, tak vyrobím jeden a obtáhne se vnitřní strana toho prvního. Pak udělám druhý, ten si všimne, že blízko leží nějaký dům, tak ho přetáhne k sobě do vnitřní strany - a nevyjde to, tam, kde jsou na katastru čáry kolmé, jsou křivé, protože je rozdíl právě o tloušťku čáry. Škoda toho 2) V okamžiku trackování se objeví modální dialog Stopování Je pěkné, že mi program říká, že něco dělá, ale po chvíli to ruší. V okamžiku stopování nemůžu dělat vůbec nic (posouvat mapou atd.), navíc ten dialog vyjede uprostřed obrazovky (často tam, kde jsem kliknul) - je to takové nepěkné. Ideální by byl nemodální dialog někde po straně - abych ho viděl, ale nerušil. Nevím, jak je technicky náročné to v JOSM udělat. Každopádně ale díky moc, i tak je Tracker velkým přínosem do OSM a vynikajícím počinem. Aleš Janda ___ 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 -- Petr Dlouhý ___ Talk-cz mailing list Talk-cz@openstreetmap.org http
Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map
Ahoj. Oprava adresy: http://jabi.aspone.cz/osm/TraceServerBeta3.zip Honza 2010/2/6 Petr Dlouhý petr.dlo...@email.cz: Ahoj, ta beta 3 nějak nejde stáhnout. Oni v tom byly chyby (asi ještě jsou), takže se to v některých případech nespojovalo - proto jsem asi tu citlivost příliš nadhodnotil. Budu se snažit to dál sledovat. On Sat, 06 Feb 2010 19:21:13 +0100, Jan Bilak jan.bilak@gmail.com wrote: Experimentální verze TraceServeru - jen pro toho, kdo to chce vyzkoušet: http://jabi.aspone.cz/www/osm/TraceServerBeta3.zip (nenahrazuje betu 2 - tohle občas padá apod.) Honza 2010/2/6 Jan Bilak jan.bilak@gmail.com: Ahoj, ano - se změnou balíku nemám problém. Jde mi to jak zkompilovat, tak spustit. Nakonec když se koukneš na jiné pluginy, tak většina z nich je v balíku org.openstreetmap.josm.plugins.[neco]. Osobně si musím zase lokálně předělávat build skript, protože mi nefunguje získávání verze z revize SVN. Ale nevadí - udělal jsem si skriptík, který to dělá automaticky, takže o tom už skoro ani nevím. Je to tak patrně správně, tak jsem to tak v SVN nechal. A ten úhel ... těžko říct, zda je užitečný nebo ne. Chtěl jsem, aby když se snaží to nacpat do nové úsečku existující bod, tak aby tím nevzniklo něco moc zalomeného. Nemám vypozorované, co se chová lépe. A možná ani žádní univerzální řešení není a něco se bude chovat lépe v oblastech, kde jsou domy obdélníkové (paneláky apod.) a něco zase někde na venkově nebo kde jsou domu různě kulaté... Jinak jsem zkoušel upravovat ten server a při pokusech mi to dělalo strašné věci při napojování, jak jsi zvýšil tu toleranci. Když jsem ji 3x zmenšil (na 0.05), tak se mi to chová mnohem lépe. Honza 2010/2/6 Petr Dlouhý petr.dlo...@email.cz: Ahoj, přidělal jsem funkci, že při stisknutém alt to nepřidává tag building. Měl bych ale dva dotazy: Po předělání balíku se mi nedaří plugin spustit - musím si to lokálně předělávat zpátky. Daří se ti spustit? Nenašel jsem, co by mohlo být nastavené špatně. Proč je tam ta kontrola na úhel při spojování, a proč je navíc jen u jednoho typu spojování? Zkoušel jsem jí dat pryč a připadá mi, že se to chová stále rozumně. Když tam ale je, tak to občas nespojí něco, co by spojit mohlo. On Sat, 06 Feb 2010 18:25:00 +0100, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, ten tracker se snažil to čáru posouvat na střed čáry (tedy nejprve obtáhnul vnitřní hranu, pak zkoušel detekovat tlouštky čar a čáru posouvat). Ale moc mu to nešlo. Mám rozpracovanou úpravu, která to myslím trochu zlepší. Chybu to občas udělá, ale je to myslím lepší. Zazněl tady nápad - nedělat detekci tlouštky čar, ale linie ztenčit ještě v bitmapě. To by mohlo přinést lepší výsledky. Obávám se, že za cenu zpomalení trasování, ale výpočetního výkonu je obecně dostatek - jen by se to muselo patrně předzpracovávat. Zkoušel jsem nějakou morfologickou operaci provádět nad polem bytů (pixelů) cca 4000 x 4000 velkým v .NETu (unsafe) ... a trvalo to celkem dlouho (malé jednotky sekund). A jak jsem pochopil, takových operací by se tam musely dělat desítky. Ale jistě by se daly dělat různé optimalizace - není třeba takto upravovat celou ohromnou bitmapu, ale jen její část, kde je dům + malé okolí. Dalo by se to celé udělat unmanaged (v Cčku) apod. Ten dialog ... myslím, že by se s tím dalo dělat něco i relativně snadno. Také jej nemám rád. Tedy hlavně v případech, kdy se nenačítají další dlaždice mapky z webu a tedy trasování netrvá moc dlouho. Asi by stačila změna kurzoru na hodinky. Honza Dne 6. února 2010 18:07 Aleš Janda openstreet...@kyblsoft.cz napsal(a): Ahoj, teda musím říci - ten Váš Tracker je super. Jednoznačně. Díky moc za něj. To je plugin užitečností určitě srovnatelný s czechaddress, a možná ještě užitečnější. I když to lze těžko srovnávat. Měl bych k němu jen dvě malé připomínky: 1) Tracker neobtahuje domy ve středu čar, ale vyrobí je na vnitřní straně čáry. To má dva neblahé důsledky - dům je tak pravděpodobně zakreslen menší než ve skutečnosti a také pak moc nevychází navazování domů. Když stojí dva domy nalepené k sobě, různých velikostí, tak vyrobím jeden a obtáhne se vnitřní strana toho prvního. Pak udělám druhý, ten si všimne, že blízko leží nějaký dům, tak ho přetáhne k sobě do vnitřní strany - a nevyjde to, tam, kde jsou na katastru čáry kolmé, jsou křivé, protože je rozdíl právě o tloušťku čáry. Škoda toho 2) V okamžiku trackování se objeví modální dialog Stopování Je pěkné, že mi program říká, že něco dělá, ale po chvíli to ruší. V okamžiku stopování nemůžu dělat vůbec nic (posouvat mapou atd.), navíc ten dialog vyjede uprostřed obrazovky (často tam, kde jsem kliknul) - je to takové nepěkné. Ideální by byl nemodální dialog někde po straně - abych ho viděl, ale nerušil. Nevím, jak je technicky náročné to v JOSM udělat. Každopádně ale díky moc, i tak je Tracker velkým přínosem do OSM a vynikajícím počinem. Aleš Janda
Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map
Ahoj, díky. Zrovna dělám na úpravách, které se trochu překrývají ... snažil jsem se to rozhodit do tříd a metod, okomentovat a vůbec trochu zkulturnit, napojovat jen na budovy, ... No nevadí. Zkusím to mergnout nebu ručně přenést užitečné neduplicitní změny. Ohledně dostání pluginu na ofic. seznam ... myslím, že se musí někam commitovat i binárky. Ale je to jen tušení. Honza 2010/2/4 Petr Dlouhý petr.dlo...@email.cz: Ahoj, na SVN jsem commitnul další úpravy pluginu: Snažil jsem se ho udělat kompatibilní s nástroji ortogonalizace (q) a spojit překrývající plochy (shift-j). Poslední nakreslený dům tedy zůstane ve výběru, a při zmáčknutí shift se k výběru přidá. Další změna je možnost vypnout spojování budov pomocí ctrl. Plugin nyní také spojuje pouze domy, a dalších objektů by si neměl všímat. Také jsem mírně zvýšil toleranci pro spojování (alespoň dokud nebude tracer strkat body opravdu na středy čar). S použítím ortogonalizace je stále trochu problém - tracer krátičké úseky často neudělá dostatečně kolmé. Nevím, jak ale dostat plugin na oficiální seznam, který používá JOSM pro automatické stahování pluginů - měl by se tam přidat automaticky, což se zatím nestalo. Měnil jsem build.xml, ale nevím, jestli to pomohlo. Původní zpráva Od: Petr Dlouhý petr.dlo...@email.cz Předmět: Re: [Talk-cz] Tracer na rozpoznání budov z katastr. map Datum: 02.2.2010 18:29:51 Ahoj, v příloze posílám první drobnou opravu - změnu pluginu z nástroje na editační mód. Tato změna odstraňuje mnoho problémů, které předchozí chování způsobovalo. Ikony si neposlal, takže jsem musel použít náhradní. Původní zpráva Od: Jan Bilak jan.bilak@gmail.com Předmět: Re: [Talk-cz] Tracer na rozpoznání budov z katastr. map Datum: 02.2.2010 16:33:31 Ahoj, jj, ohledně spojování ... máme na to stejný názor. Ohledně zhoršení výsledku trasování kvůli detekci tloušťky čáry ... něco na tom bude, také se mi to nelíbí. Zkusím nastínit zjednodušeně algoritmus, jak to funguje (tedy jak jsem zamýšlel, třeba je tam chyba): a) napřed se floodfillem vyplní souvislá plocha, na kterou uživatel kliknul b) najde se vnější hranice - množina bodů c) najdou se tam významné/zlomové body d) zjednoduší se a naopak doplní chybějící body (sada různých postupů) A tady vylezl myslím celkem dobrý výsledek, ale na vnitřní straně čáry. A nyní nově ... pro každou úsečku polygonu se vynese kolmice v 1/10, 2/10, ..., 9/10 a najde tloušťka čáry na obě strany v místě kolmice. Vezme se ta nejmenší tloušťka a podle toho se čára posune. Body se tam nepřidávají, jen posouvají. Proč nejmenší? Protože na mapě typicky je nějaká čára navíc, která zvětšuje tloušťku čáry. Ale většinou v žádném místě kus čáry nechybí. Možná ale lepší bude medián nebo dolní kvartil. K ladění je tam i řada konstant. Zvláště u krátkých úseků je detekce tloušťky čáry celkem problematická. Jak na to lépe? Nějaké nápady? Mohu tam mít nějakou chybu, mohu zkusit nějaké průměrování, mohu zkusit tloušťku čáry u krátkých čar odvozovat od těch delších... Nějaké prokládání přímky body moc nepadá v úvahu, protože těžko poznat, které body patří právě dané čáře - na vnější stranu čáry navazují další čáry. Moc jsem se tím zatím nezabýval, protože jsem si hrál s tím pluginem. Škoda, že čára po celé obvodu nemá v mnoha případech stejnou tloušťku - bylo by to značně jednodušší. Zdrojáky: http://jabi.aspone.cz/osm/TracerPluginBeta2-src.zip http://jabi.aspone.cz/osm/TracerServerBeta2-src.zip Zdrojáky toho pluginu jsou dost hrozné ... a potřebují větší refaktorizaci. U toho serveru je to lepší, ale také by to řadu úprav potřebovalo (včetně rozdělení do metod apod.). Takže to berte jako předzveřejnění pro silné povahy :) Honza 2010/2/2 Petr Dlouhý petr.dlo...@email.cz: Ahoj, díky za 2. betu, mám k ní pár poznámek: Už je to výrazně použitelnější, ale stále to má poměrně významné nedostatky: Spojování budov opravdu spojuje i s nesouvisejícími objekty (typicky adresní body), jak jsem se bál (někdy naopak zase nespojuje sousedící domy). Já vidím dvě možná řešení tohoto problému: Buď stávající funkcionalitu ještě vylepšit - přidat možnost vypnutí (zapnutí) spojování při zmáčknuté klávese Ctrl, a omezení spojování pouze na domy. Druhá možnost je udělat nástroj, který spojí vybrané objekty. První možnost má výhodu, že spojování probíhá automaticky; druhá možnost je zase univerzálnější a mohla by být časem přidána přímo do JOSM. Taky mi přijde, že se po přidání trasování na střed čáry trochu zhoršil výsledek (občas se tam přidají zbytečné body, nebo se v rozích udělají nesmysly). Trasování navíc často neumisťuje body na středy čar. Taky jsem zkoušel trasovat již dříve zakreslený kostel sv. Antonína
Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map
Mimochodem ... proč jsi plugin přestím přendal z balíku package org.openstreetmap.josm.plugins.tracer do balíku tracer? A je otázka, zda má smysl se snažit tam ten plugin dostat ... když stejně samostatně nefunguje (bez Trace Serveru). Takže automatický instalace pluginu je sice pěkná věc, ale stejně to samo fungovat zatím nebude. Honza 2010/2/4 Jan Bilak jan.bilak@gmail.com: Ahoj, díky. Zrovna dělám na úpravách, které se trochu překrývají ... snažil jsem se to rozhodit do tříd a metod, okomentovat a vůbec trochu zkulturnit, napojovat jen na budovy, ... No nevadí. Zkusím to mergnout nebu ručně přenést užitečné neduplicitní změny. Ohledně dostání pluginu na ofic. seznam ... myslím, že se musí někam commitovat i binárky. Ale je to jen tušení. Honza 2010/2/4 Petr Dlouhý petr.dlo...@email.cz: Ahoj, na SVN jsem commitnul další úpravy pluginu: Snažil jsem se ho udělat kompatibilní s nástroji ortogonalizace (q) a spojit překrývající plochy (shift-j). Poslední nakreslený dům tedy zůstane ve výběru, a při zmáčknutí shift se k výběru přidá. Další změna je možnost vypnout spojování budov pomocí ctrl. Plugin nyní také spojuje pouze domy, a dalších objektů by si neměl všímat. Také jsem mírně zvýšil toleranci pro spojování (alespoň dokud nebude tracer strkat body opravdu na středy čar). S použítím ortogonalizace je stále trochu problém - tracer krátičké úseky často neudělá dostatečně kolmé. Nevím, jak ale dostat plugin na oficiální seznam, který používá JOSM pro automatické stahování pluginů - měl by se tam přidat automaticky, což se zatím nestalo. Měnil jsem build.xml, ale nevím, jestli to pomohlo. Původní zpráva Od: Petr Dlouhý petr.dlo...@email.cz Předmět: Re: [Talk-cz] Tracer na rozpoznání budov z katastr. map Datum: 02.2.2010 18:29:51 Ahoj, v příloze posílám první drobnou opravu - změnu pluginu z nástroje na editační mód. Tato změna odstraňuje mnoho problémů, které předchozí chování způsobovalo. Ikony si neposlal, takže jsem musel použít náhradní. Původní zpráva Od: Jan Bilak jan.bilak@gmail.com Předmět: Re: [Talk-cz] Tracer na rozpoznání budov z katastr. map Datum: 02.2.2010 16:33:31 Ahoj, jj, ohledně spojování ... máme na to stejný názor. Ohledně zhoršení výsledku trasování kvůli detekci tloušťky čáry ... něco na tom bude, také se mi to nelíbí. Zkusím nastínit zjednodušeně algoritmus, jak to funguje (tedy jak jsem zamýšlel, třeba je tam chyba): a) napřed se floodfillem vyplní souvislá plocha, na kterou uživatel kliknul b) najde se vnější hranice - množina bodů c) najdou se tam významné/zlomové body d) zjednoduší se a naopak doplní chybějící body (sada různých postupů) A tady vylezl myslím celkem dobrý výsledek, ale na vnitřní straně čáry. A nyní nově ... pro každou úsečku polygonu se vynese kolmice v 1/10, 2/10, ..., 9/10 a najde tloušťka čáry na obě strany v místě kolmice. Vezme se ta nejmenší tloušťka a podle toho se čára posune. Body se tam nepřidávají, jen posouvají. Proč nejmenší? Protože na mapě typicky je nějaká čára navíc, která zvětšuje tloušťku čáry. Ale většinou v žádném místě kus čáry nechybí. Možná ale lepší bude medián nebo dolní kvartil. K ladění je tam i řada konstant. Zvláště u krátkých úseků je detekce tloušťky čáry celkem problematická. Jak na to lépe? Nějaké nápady? Mohu tam mít nějakou chybu, mohu zkusit nějaké průměrování, mohu zkusit tloušťku čáry u krátkých čar odvozovat od těch delších... Nějaké prokládání přímky body moc nepadá v úvahu, protože těžko poznat, které body patří právě dané čáře - na vnější stranu čáry navazují další čáry. Moc jsem se tím zatím nezabýval, protože jsem si hrál s tím pluginem. Škoda, že čára po celé obvodu nemá v mnoha případech stejnou tloušťku - bylo by to značně jednodušší. Zdrojáky: http://jabi.aspone.cz/osm/TracerPluginBeta2-src.zip http://jabi.aspone.cz/osm/TracerServerBeta2-src.zip Zdrojáky toho pluginu jsou dost hrozné ... a potřebují větší refaktorizaci. U toho serveru je to lepší, ale také by to řadu úprav potřebovalo (včetně rozdělení do metod apod.). Takže to berte jako předzveřejnění pro silné povahy :) Honza 2010/2/2 Petr Dlouhý petr.dlo...@email.cz: Ahoj, díky za 2. betu, mám k ní pár poznámek: Už je to výrazně použitelnější, ale stále to má poměrně významné nedostatky: Spojování budov opravdu spojuje i s nesouvisejícími objekty (typicky adresní body), jak jsem se bál (někdy naopak zase nespojuje sousedící domy). Já vidím dvě možná řešení tohoto problému: Buď stávající funkcionalitu ještě vylepšit - přidat možnost vypnutí (zapnutí) spojování při zmáčknuté klávese Ctrl, a omezení spojování pouze na domy. Druhá možnost je udělat nástroj, který spojí vybrané objekty. První možnost má výhodu, že spojování
Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map
Ještě koukám na jednu věc ... upravil jsi TracerPlugin.java tak, že jsi tam přidal parametr PluginInformation info. S tímto mi to nechce chodit pod otestovanou verzí JOSM (2561). Asi tam tohle přidali až později. Nevím, zda by to třeba zkouslo dva kontruktory nebo zda je třeba udržovat více verzí pluginu. Obecně netuším, jak s verzemi funguje - tedy vůči jaké revizi zdrojáků JOSM se má plugin kompilovat. Stáhnul jsem nějakou z počátku prosince, ale tak odhadem, protože nevím, jakou přesnou revizi použít. Honza 2010/2/4 Jan Bilak jan.bilak@gmail.com: Díky, jak jednoduché :) Honza 2010/2/4 Petr Dlouhý petr.dlo...@email.cz: Stačí spustit JOSM z konzoly, a hlášky tam vybíhaj. Původní zpráva Od: Jan Bilak jan.bilak@gmail.com Předmět: Re: [Talk-cz] Tracer na rozpoznání budov z katastr. map Datum: 04.2.2010 17:35:49 Nene, nebylo to moc práce. Dělám na tom jen chilku a prolínalo se to jen málo. Ještě mám takový praktický dotaz (Javu moc neznám) ... koukal jsem, že tam používáš: System.out.println(...) Jak zapínáš ladící konzolu nebo jak to ladíš? Já jsem to dělal krkolomnou cestou přes posílání si ladících hlášek do Trace Serveru... Ale nějaká ladíci konzola by byla fajn. Ale netuším, jak ji zapnout. Honza 2010/2/4 Petr Dlouhý petr.dlo...@email.cz: Za duplicitní úpravy se omlouvám, snad to nebylo moc zbytečné práce. Měl jsem pocit, že se to tak dělalo dřív a už to neplatí (viz [1]). Každopádně jsem nahrál binárku na [2], tak uvidíme. [1] http://svn.openstreetmap.org/applications/editors/josm/plugins/build.xml [2] http://svn.openstreetmap.org/applications/editors/josm/dist/ Petr Dlouhý Původní zpráva Od: Jan Bilak jan.bilak@gmail.com Předmět: Re: [Talk-cz] Tracer na rozpoznání budov z katastr. map Datum: 04.2.2010 17:18:46 Ohledně dostání pluginu na ofic. seznam ... myslím, že se musí někam commitovat i binárky. Ale je to jen tušení. Honza ___ 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 Petr Dlouhý petr.dlo...@email.cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map
Ahoj. Je to tak. Ve Windows je vyžadován .NET Framework (tuším verze 2.0+, 3.5 stačí určitě). Je celkem pravděpodobné, že .NET Framework už v počítači máš, pokud máš Windows. Ve Vistách a Windows 7 je přímo (tedy ve Vistách ve verzi 3.0). V XPčkách není, ale vyžaduje jej hodně programů a tedy se pravděpodobně nainstaloval s něčím jiným. Pokud jej nemáš, tak jej stáhneš téměř všude na netu... např. z: http://www.microsoft.com/downloads/details.aspx?familyid=25FD-AE52-4E35-B531-508D977D32A6displaylang=cs Honza 2010/2/4 Petr Dlouhý petr.dlo...@email.cz: Tak už je plugin v oficiálním seznamu. Stačí tedy Tracer nainstalovat jako jakýkoliv jiný plugin. Pro jeho provoz je ale nutné spustit server - dá se stáhnout z [1] (jestli není novější verze), ve Windows asi stačí poklepat na .exe soubor, v Linuxu je nutné nainstalovat Mono (z balíčků) a spustit: mono Osm.Kn.Trace.Server.exe [1] http://jabi.aspone.cz/osm/TraceServerBeta2.zip On Thu, 04 Feb 2010 21:29:39 +0100, Jan Dudík jan.du...@gmail.com wrote: Ahoj, když už to tak krásně funguje, dal by někdo návod pro běžného uživatele JOSM, jak do něj tento plugin dostat? slova jako zkompilovat nebo binárka jsou pro běžného uživatele nesrozumitelná, naopak slova jako nakopírovat, přidat řádek, editovat soubor či kliknout na tlačítko jsou naopak vítána JD -- Petr Dlouhý ___ 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] Tracer na rozpoznání budov z katastr . map
Spřežky se tuším nazývají ty čáry, které naznačují vztah dvou ploch, které jsou oddělené čarou. Tedy je to taková čára ve tvaru písmene s, která vede z jedné plochy do druhé. Honza 2010/2/4 Petr Dlouhý petr.dlo...@email.cz: O integraci serveru už jsme psali, ale jsou podstatnější věci. Nevím, co myslíš spřežkami, ale pokud to je skosený roh přiléhající na rovnou čáru, tak to je způsobené problémy v implementaci trasování na středy čar. První verze serveru byla možná lepší, ale zase zdvojuje některé body, takže je nepoužitelná. Myslím, že zjednodušování se používá, a připadá mi, že je nastavené víceméně správně. Řekl bych, že zkosování je ale problém, který by bylo dobré pokud možno potlačit - pak nefunguje správně ortogonalizace. Na kód serveru jsem se zatím ale nedíval, takže toho moc nevím. On Thu, 04 Feb 2010 21:45:50 +0100, Petr Schönmann pschonm...@gmail.com wrote: Zlepseni pro vyvojare: Neslo by udelat, ze by si plugin server vyvolal sam (stahnul a spustil), pripadne spustil v pozadi ? Dale jsem si vsimnul, ze pri trasovani objektu vadi spřežky, udělá se okolo nich nevzhledná obklička. Mozna by se na tak jemné ways dal použít příkaz simplify way, ale ten občas pravoúhlé objekty zkosí, ale víceméně poslouží, pokud to bude jeden nod na objekt šoupnutý bokem a eliminuje spousty nežádoucího bordelu. -- Petr Dlouhý ___ 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] Tracer na rozpoznání budov z katastr . map
Díky za nápady, úpravu ... a omlouvám se za chybu v URL a chybějící ikonky ... tyhle tvoje jsou ale myslím hezčí. Správně je: http://jabi.aspone.cz/osm/TraceServerBeta2-src.zip (tedy bez r) Honza 2010/2/2 Petr Dlouhý petr.dlo...@email.cz: Ještě jsem zapoměl - zdrojáky od serveru se nedají stáhnout. Původní zpráva Od: Jan Bilak jan.bilak@gmail.com Předmět: Re: [Talk-cz] Tracer na rozpoznání budov z katastr. map Datum: 02.2.2010 16:33:31 Ahoj, jj, ohledně spojování ... máme na to stejný názor. Ohledně zhoršení výsledku trasování kvůli detekci tloušťky čáry ... něco na tom bude, také se mi to nelíbí. Zkusím nastínit zjednodušeně algoritmus, jak to funguje (tedy jak jsem zamýšlel, třeba je tam chyba): a) napřed se floodfillem vyplní souvislá plocha, na kterou uživatel kliknul b) najde se vnější hranice - množina bodů c) najdou se tam významné/zlomové body d) zjednoduší se a naopak doplní chybějící body (sada různých postupů) A tady vylezl myslím celkem dobrý výsledek, ale na vnitřní straně čáry. A nyní nově ... pro každou úsečku polygonu se vynese kolmice v 1/10, 2/10, ..., 9/10 a najde tloušťka čáry na obě strany v místě kolmice. Vezme se ta nejmenší tloušťka a podle toho se čára posune. Body se tam nepřidávají, jen posouvají. Proč nejmenší? Protože na mapě typicky je nějaká čára navíc, která zvětšuje tloušťku čáry. Ale většinou v žádném místě kus čáry nechybí. Možná ale lepší bude medián nebo dolní kvartil. K ladění je tam i řada konstant. Zvláště u krátkých úseků je detekce tloušťky čáry celkem problematická. Jak na to lépe? Nějaké nápady? Mohu tam mít nějakou chybu, mohu zkusit nějaké průměrování, mohu zkusit tloušťku čáry u krátkých čar odvozovat od těch delších... Nějaké prokládání přímky body moc nepadá v úvahu, protože těžko poznat, které body patří právě dané čáře - na vnější stranu čáry navazují další čáry. Moc jsem se tím zatím nezabýval, protože jsem si hrál s tím pluginem. Škoda, že čára po celé obvodu nemá v mnoha případech stejnou tloušťku - bylo by to značně jednodušší. Zdrojáky: http://jabi.aspone.cz/osm/TracerPluginBeta2-src.zip http://jabi.aspone.cz/osm/TracerServerBeta2-src.zip Zdrojáky toho pluginu jsou dost hrozné ... a potřebují větší refaktorizaci. U toho serveru je to lepší, ale také by to řadu úprav potřebovalo (včetně rozdělení do metod apod.). Takže to berte jako předzveřejnění pro silné povahy :) Honza 2010/2/2 Petr Dlouhý petr.dlo...@email.cz: Ahoj, díky za 2. betu, mám k ní pár poznámek: Už je to výrazně použitelnější, ale stále to má poměrně významné nedostatky: Spojování budov opravdu spojuje i s nesouvisejícími objekty (typicky adresní body), jak jsem se bál (někdy naopak zase nespojuje sousedící domy). Já vidím dvě možná řešení tohoto problému: Buď stávající funkcionalitu ještě vylepšit - přidat možnost vypnutí (zapnutí) spojování při zmáčknuté klávese Ctrl, a omezení spojování pouze na domy. Druhá možnost je udělat nástroj, který spojí vybrané objekty. První možnost má výhodu, že spojování probíhá automaticky; druhá možnost je zase univerzálnější a mohla by být časem přidána přímo do JOSM. Taky mi přijde, že se po přidání trasování na střed čáry trochu zhoršil výsledek (občas se tam přidají zbytečné body, nebo se v rozích udělají nesmysly). Trasování navíc často neumisťuje body na středy čar. Taky jsem zkoušel trasovat již dříve zakreslený kostel sv. Antonína (http://osm.org/go/0J0wCrtWh--), a moc dobře to nedopadlo - asi je na tak složitý objekt zjednodušení přílišné. Další problém je, že stále nefunguje správně přepínání nástrojů. Občas se mi také stane, že se dokončí trasování, ale výsledek se už neobjeví. Několikrát se mi stalo, že se nějaká z okolních ulic prodloužila na jeden z bodů nově trasovaného domu. Původní zpráva Od: Jan Bilak jan.bilak@gmail.com Předmět: Re: [Talk-cz] Tracer na rozpoznání budov z katastr. map Datum: 02.2.2010 02:59:12 Ahoj, ke slučování ... můžeš zkusit betu 2: http://jabi.aspone.cz/osm/TraceServerBeta2.zip (nejsou tam asi optimálně nastavené konstanty ... jak vzdálené body ještě napojovat apod.) Možná se to heslo v opensource prosazuje, ale já si nemyslím, že je dobré commitovat neupravený kód (i v samotném JOSM chybí na řadě míst alespoň základní komentáře apod. ... což dost znesnadňuje práci s ním). A druhá věc je, že plugin + trasovací server je poměrně specificky dělaný na české katastrální mapy. Pravděpodobně by z toho něco šlo použít i na pro trasování jiných obdobných map, ale není to navržené jako univerzální věc. A tak očekávám zájem o dodělání tohoto pouze ze strany českých vývojářů ... tedy této komunity a nikdo zde ani nenaznačil, že by měl o zdrojáky osobní zájem, že by uvažoval nad spoluprácí. Naplsal jsem si o přístup na SVN, tak
Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map
Před chvilkou mi dorazil přístup do SVN, tak jsem Java plug-in commitnul. Kam s tou .NETí částí, to je otázka... Do nějakého podadresáře pluginu? Ale ten server je nezávislý a tedy třeba jej někdo použije i v jiném softu (Merkaartoru apod.) ... takže logicky by se moc nepatřil. A také není v Javě. Honza 2010/2/2 Jan Bilak jan.bilak@gmail.com: Díky za nápady, úpravu ... a omlouvám se za chybu v URL a chybějící ikonky ... tyhle tvoje jsou ale myslím hezčí. Správně je: http://jabi.aspone.cz/osm/TraceServerBeta2-src.zip (tedy bez r) Honza 2010/2/2 Petr Dlouhý petr.dlo...@email.cz: Ještě jsem zapoměl - zdrojáky od serveru se nedají stáhnout. Původní zpráva Od: Jan Bilak jan.bilak@gmail.com Předmět: Re: [Talk-cz] Tracer na rozpoznání budov z katastr. map Datum: 02.2.2010 16:33:31 Ahoj, jj, ohledně spojování ... máme na to stejný názor. Ohledně zhoršení výsledku trasování kvůli detekci tloušťky čáry ... něco na tom bude, také se mi to nelíbí. Zkusím nastínit zjednodušeně algoritmus, jak to funguje (tedy jak jsem zamýšlel, třeba je tam chyba): a) napřed se floodfillem vyplní souvislá plocha, na kterou uživatel kliknul b) najde se vnější hranice - množina bodů c) najdou se tam významné/zlomové body d) zjednoduší se a naopak doplní chybějící body (sada různých postupů) A tady vylezl myslím celkem dobrý výsledek, ale na vnitřní straně čáry. A nyní nově ... pro každou úsečku polygonu se vynese kolmice v 1/10, 2/10, ..., 9/10 a najde tloušťka čáry na obě strany v místě kolmice. Vezme se ta nejmenší tloušťka a podle toho se čára posune. Body se tam nepřidávají, jen posouvají. Proč nejmenší? Protože na mapě typicky je nějaká čára navíc, která zvětšuje tloušťku čáry. Ale většinou v žádném místě kus čáry nechybí. Možná ale lepší bude medián nebo dolní kvartil. K ladění je tam i řada konstant. Zvláště u krátkých úseků je detekce tloušťky čáry celkem problematická. Jak na to lépe? Nějaké nápady? Mohu tam mít nějakou chybu, mohu zkusit nějaké průměrování, mohu zkusit tloušťku čáry u krátkých čar odvozovat od těch delších... Nějaké prokládání přímky body moc nepadá v úvahu, protože těžko poznat, které body patří právě dané čáře - na vnější stranu čáry navazují další čáry. Moc jsem se tím zatím nezabýval, protože jsem si hrál s tím pluginem. Škoda, že čára po celé obvodu nemá v mnoha případech stejnou tloušťku - bylo by to značně jednodušší. Zdrojáky: http://jabi.aspone.cz/osm/TracerPluginBeta2-src.zip http://jabi.aspone.cz/osm/TracerServerBeta2-src.zip Zdrojáky toho pluginu jsou dost hrozné ... a potřebují větší refaktorizaci. U toho serveru je to lepší, ale také by to řadu úprav potřebovalo (včetně rozdělení do metod apod.). Takže to berte jako předzveřejnění pro silné povahy :) Honza 2010/2/2 Petr Dlouhý petr.dlo...@email.cz: Ahoj, díky za 2. betu, mám k ní pár poznámek: Už je to výrazně použitelnější, ale stále to má poměrně významné nedostatky: Spojování budov opravdu spojuje i s nesouvisejícími objekty (typicky adresní body), jak jsem se bál (někdy naopak zase nespojuje sousedící domy). Já vidím dvě možná řešení tohoto problému: Buď stávající funkcionalitu ještě vylepšit - přidat možnost vypnutí (zapnutí) spojování při zmáčknuté klávese Ctrl, a omezení spojování pouze na domy. Druhá možnost je udělat nástroj, který spojí vybrané objekty. První možnost má výhodu, že spojování probíhá automaticky; druhá možnost je zase univerzálnější a mohla by být časem přidána přímo do JOSM. Taky mi přijde, že se po přidání trasování na střed čáry trochu zhoršil výsledek (občas se tam přidají zbytečné body, nebo se v rozích udělají nesmysly). Trasování navíc často neumisťuje body na středy čar. Taky jsem zkoušel trasovat již dříve zakreslený kostel sv. Antonína (http://osm.org/go/0J0wCrtWh--), a moc dobře to nedopadlo - asi je na tak složitý objekt zjednodušení přílišné. Další problém je, že stále nefunguje správně přepínání nástrojů. Občas se mi také stane, že se dokončí trasování, ale výsledek se už neobjeví. Několikrát se mi stalo, že se nějaká z okolních ulic prodloužila na jeden z bodů nově trasovaného domu. Původní zpráva Od: Jan Bilak jan.bilak@gmail.com Předmět: Re: [Talk-cz] Tracer na rozpoznání budov z katastr. map Datum: 02.2.2010 02:59:12 Ahoj, ke slučování ... můžeš zkusit betu 2: http://jabi.aspone.cz/osm/TraceServerBeta2.zip (nejsou tam asi optimálně nastavené konstanty ... jak vzdálené body ještě napojovat apod.) Možná se to heslo v opensource prosazuje, ale já si nemyslím, že je dobré commitovat neupravený kód (i v samotném JOSM chybí na řadě míst alespoň základní komentáře apod. ... což dost znesnadňuje práci s ním). A druhá věc je, že plugin + trasovací server je poměrně specificky dělaný na české katastrální
Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map
Ahoj, ke slučování ... můžeš zkusit betu 2: http://jabi.aspone.cz/osm/TraceServerBeta2.zip (nejsou tam asi optimálně nastavené konstanty ... jak vzdálené body ještě napojovat apod.) Možná se to heslo v opensource prosazuje, ale já si nemyslím, že je dobré commitovat neupravený kód (i v samotném JOSM chybí na řadě míst alespoň základní komentáře apod. ... což dost znesnadňuje práci s ním). A druhá věc je, že plugin + trasovací server je poměrně specificky dělaný na české katastrální mapy. Pravděpodobně by z toho něco šlo použít i na pro trasování jiných obdobných map, ale není to navržené jako univerzální věc. A tak očekávám zájem o dodělání tohoto pouze ze strany českých vývojářů ... tedy této komunity a nikdo zde ani nenaznačil, že by měl o zdrojáky osobní zájem, že by uvažoval nad spoluprácí. Naplsal jsem si o přístup na SVN, tak uvidím... Honza 2010/2/1 Petr Dlouhý petr.dlo...@email.cz: V opensource se prosazuje heslo Commit Early, Commit Often. Já bych se snažil dodržet pouze základní formální požadavky (moc jich není) a co nejdříve to nahrál. Pokud vím, tak navíc příliš formálních požadavků na pluginy neexistuje, něco je možné najít na [1]; licenci by asi bylo dobré uvést, ale ostatní věci můžeš ty nebo někdo jiný dodělat časem. Komentování nebo čištění kódu taky můžeš udělat časem. Získat přístup, pokud vím, není příliš těžké - já jsem napsal na Tom Hughes t...@compton.nu. Nevím, jakým způsobem to děláš, ale nejsem si jist, jestli nemůže být slučování bodů a hran trochu na obtíž (aby se neslučovalo i to, co by nemělo). Já osobně bych si to spíš představoval jako nástroj - uživatel vybere jednotlivé objekty a nechá je spojit. Možná ale tvoje verze funguje dobře, neměl jsem ji možnost vyzkoušet. [1] http://svn.openstreetmap.org/applications/editors/josm/plugins/00_README On Mon, 01 Feb 2010 04:28:58 +0100, Jan Bilak jan.bilak@gmail.com wrote: Na commitnutí do ofic. SVN by to potřebovalo: a) formálně doladit (po stránkách struktury adresářů, build skriptů, informace o licenci, ...) b) získat přístup do SVN c) zpřehlednit ... okomentovat, trochu refaktorizovat, ... Přičemž c) mám určitě v plánu. O b) jsem se nezajímal, takže nevím, jak to chodí. A do a) se mi moc nechce (studovat, jak to má být). -- Petr Dlouhý ___ 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] Tracer na rozpoznání budov z katastr . map
Ahoj. implementování/opraveno mám: a) tagování b) duplicitní bod cesty c) detekci tlouštky čáry a snaha o umístění bodů na její střed d) hledání a slučování bodů e) eliminaci copyright popisků v mapě, které pak způsobovaly nesmyslné body a hrany Pracuji na hledání a slučování hran (way). Tedy reálně spíše na zkoumání zdrojáků JOSM, protože algoritmicky nejde o nic složitého. Jen to tam nějak začlenit. Popis pluginu, spouštění a viditelnost serveru považuji zatím za relativně nepodstatnou (aneb jsou důležitější věci, ale pokud se chce někdo do těchto věcí pustit, proč ne). Přepínání módů jsem zatím nezačal řešit, ale to myslím půjde. Na commitnutí do ofic. SVN by to potřebovalo: a) formálně doladit (po stránkách struktury adresářů, build skriptů, informace o licenci, ...) b) získat přístup do SVN c) zpřehlednit ... okomentovat, trochu refaktorizovat, ... Přičemž c) mám určitě v plánu. O b) jsem se nezajímal, takže nevím, jak to chodí. A do a) se mi moc nechce (studovat, jak to má být). A pak je spousta dalších věcí ... třeba široké možnosti konfigurace (je tam takových konstant, které lze vyladit pro lepší funkčnost...). Co se týká JOSM/Merkaartora, tak trasovací server je nezávislý a lze jej teoreticky používat z čehokoli - třeba i z toho flashového editoru, pokud by ten server někdo někde rozjel. Integraci do Merkaartora dělat určitě nebudu - to nechám na případné jiné lidi, kteří se jím zabývají - využít trasovací server není problém. Integraci do JOSM bych také nejraději nedělal a zabýval jsem se jen trasovacím serverem. Zda bude nějaké vlastní GUI v .NETu, to nevím. Myslím, že to bude velmi záležet na tom, jak se mi bude líbit implementace JOSM. Celkově mám rád pro takové programy .NET či Javu než C++ a vidím v nich větší perspektivnost. Jen pro určité části, které jsou výkonostně kritické, pak nějakou nativní implementaci. A věřím tomu, že pokud se použijí vhodné alogoritmy a datové struktury, tak pak rychlost je jen o málo pomalejší než u nativních aplikací. V praxi pak často i větší, protože je snažší tam dělat algoritmicky lepší a složitější věci. Honza 2010/1/31 Petr Dlouhý petr.dlo...@email.cz: Běžně mi sežere přes půlku paměti (500 MB), možná ale nechávám Javě příliš mnoho prostoru a on ji pak nemá tendenci uvolňovat (což je problém Javy). Nejnovější build používám často. Pomalost mi vadí především při běžných editačních úkolech - přidávání/posouvání bodů, přídávání tagů, posouvání/zoomování mapy. Při těchto činnostech zdržuje téměř každá prodleva, by bylo ideální, kdyby to bylo úplně plynulé. Nepoužívám úplně nejnovější počítač. Díky za tip se server módem, vyzkouším. Zkusím to trochu pozorovat, a když přijdu na něco, co vadí nejvíc, tak to zkusím nahlásit. On Sun, 31 Jan 2010 08:33:03 +0100, Jiri Klement jiri.klem...@gmail.com wrote: Ja myslim, ze pametova narocnost JOSM uz neni tak hrozna, na praci s 60MB osm potrebuje 100MB heap (+ nejaky overhead jvm). A dalsi pametove optimalizace mam v planu. Co se tyce rychlosti, tak je treba poustet javu s dostatkem pameti (parameter -Xmx) a v server modu. Server mod znamena, ze se pouzije vice optimalizaci, takze JOSM se bude o neco dele spoustet, ale o to rychleji potom pobezi. Velikost pameti je dulezita, nove verze javy maji (imho nestastnou) vlastnost, ze pred tim nez vyhodi OutOfMemory, tak budou se hodne dlouho snazit pamet uvolnit. Takze pokud JOSM jede na hrane (a defaultni velikosti heapu na Windows je 64MB, coz je na hrane), tak se zbytecne zpomali. A pokud presto mate nejaky usecase, kde je JOSM prilis pomaly, tak si stezujte na tracku. 2010/1/31 Petr Dlouhý petr.dlo...@email.cz: Je fakt, že pomalost JOSM a jeho paměťová náročnost mi také vadí. Nemožnost tvořit body může být způsobená buď tím, že jsi nepochopil, že JOSM má různé editační módy (přidávání, editace, zvětšování). Pokud to si opravdu myslíš, že je to chyba JOSM, a že to ostatní nevidí protože jsou na to zvyklí, tak můžeš nahlásit chybu. Jinak je většina funkcionality toho Traceru v tom samostatném serveru, takže by nebyl problém udělat plugin do Merkaartoru, kdyby pluginy podporoval. On Sun, 31 Jan 2010 00:51:59 +0100, Frettie fret...@gmail.com wrote: No, dal jsem znova šanci JOSM a stále bych byl pro nějakou jinou možnost. Je pár problémů, je to Javový (a to v tom píšu bakalářku) a dsně pomalý a hlavně neohrabaný. Sem tam se tak jako stane (neznámo proč) že nemůžu tvořit body, až odklikávám sebevíc a to je prostě věc, která u programu, kterej bych někdy měl použít být nemůže. To vidím jen já, jak je to nešikovnej program? Zlatej Merkaartor, uvítal bych tak i možnost klikat v nějakém okně samostatně. Jo a mimochodem, je to jen u mě, nebo víc lidem u v. 2561 nefunguje czechadress? J. 2010/1/29 Jan Bilak jan.bilak@gmail.com: Zdravím pánové, prosím o vyzkoušení první betaverze traceru budov z katastrálních map. http://jabi.aspone.cz/osm/TraceServerBeta1.zip Archiv obsahuje dva soubory. 1
Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map
Zdravím pánové, prosím o vyzkoušení první betaverze traceru budov z katastrálních map. http://jabi.aspone.cz/osm/TraceServerBeta1.zip Archiv obsahuje dva soubory. 1) Osm.Kn.Trace.Server.exe 2) tracer.jar První z nich je trasovací server, který je třeba mít spuštěný v průběhu trasování. Poslouchá na portu 5050 a zatím není nijak konfigurovatený. Prostě jej spustíte a až jej nebudete potřebovat, tak jej zavřete. To je vše. Doporučuji jej dát do prázdného adresáře, proto si k sobě ukládá dočasné soubory (stažené a předzpracované výseky katastrální mapy). Druhý soubor je plugin do JOSM (založený na LakeWalkeru). Ten zkopírujete do adresáře s pluginy JOSM (ve Vistě např. c:\Users\[userName]\AppData\Roaming\JOSM\plugins). Funguje s verzí 2561 JOSM. Aktivujete jej v nastavení. Přibude nástroj Tracer (klávesová zkratka T). Po aktivaci nástroje můžete klikat na mapu a mělo by to trasovat. Opětovným zvolením nástroje (nebo T) by se měl zase deaktivovat. Uvítám připomínky, ale nevím, kdy je stihnu realizovat. Nějaký další vývojář by se hodil... Kdo se hlásí dobrovolně? :) BTW: Jak to má tagovat ty budovy? Honza 2010/1/28 Frettie fret...@gmail.com: To si právě nemyslím, to, že je složitý, pro mě jako začátečníka v mapování (no dobře, mám za sebou práci v ArcGISu a Topolu) to bylo fajn, bylo snadné se napojit, snadné si nakonfigurovat to, co jsem potřeboval. JOSM odpuzuje bohužel už tím, jak vypadá a taky tím, že je tuším v Javě. Možná jsi měl jen smůlu na špatný kus, mě se lehce škubne, jen při velkém počtu bodů a linek (a to nemám zdaleka oslnivý hardware). Ale API nemá (zatím). 2010/1/28 Jan Bilak jan.bilak@gmail.com: Na Merkaator jsem zběžně koukal a nějak mne zatím nepřesvědčil. A to ani možnostmi (to jsem ani moc nečekal), ani rychlostí (to jsem čekal, protože je psaný v C++/qt a to je hodně výkonná platforma - třeba při tažení nové cesty se to vyloženě škube a to podle mne značí spíše na použití špatných algoritmů a datových struktur). A nakonec ani jednoduchostí ... na první pohled. Ale možná je to tím, že na JOSM jsem přeci jen koukal delší dobu. Tu jednoduchost jsem myslel hlavně pro lidi, kteří se chtěl OSM zúčastnit tak nějak rekreačně - dodělat si tam nějaké okolí svého domu, nic neimportovat, neprogramovat, ... Ale možnost volby je dobrá věc - nechť každý používá to, co mu vyhovuje. Honza -- Forwarded message -- From: Frettie fret...@gmail.com Date: 2010/1/27 Subject: Re: [Talk-cz] Tracer na rozpoznání budov z katastr. map To: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Právě, ono takovej merkaartor je super věc, JOSM je jak složitý, tak prostě ovladatelný. :/ Ale asi by mě to donutilo přejít, to zas jo. 2010/1/27 Jan Bilak jan.bilak@gmail.com: Ahoj, uvažoval jsem podobně ... zatím tedy o JOSM a API pro pluginy moc nevím. A v Javě jsem něco naposledy před x lety (nějaké drobnosti tedy i později, ale mnohem větší zkušenosti mám s .NETem). Přepsat jádro algoritmu do Javy by asi takový problém nebyl (tedy tu část, která vezme 2D pole bytů (byte = pixel) a souřadnici kliknutí a vrátí seřazený seznam souřadnic vrcholů polygonu obrysu budovy). Horší pro mne bude se stahováním a cachování bitmap, jejich spojováním pro účely trace, převáděním na pole bytů (kvůli rychlosti ... v .NETu na to používám unmanaged kód). Tedy takovými věcmi, kde jsou třeba znalosti nejen jazyka Java, ale i různých knihoven. A otázka je, jak to bude rychlé v čisté Javě. Spíše jsem uvažoval i nad přepisem toho jádra do nativního C či C++. Včera jsem na ten plugin lake-walker zběžně koukal, inspirovat by se z toho jistě dalo. Zda by z toho šlo využít všechno a jen doplnit algoritmus rozpoznávání, to je otázka. Jinak jsem ještě uvažoval na tím, že by rozpoznávání mohla dělat externí aplikace, se kterou by plugin komunikovat třeba TCP ... tedy plugin JOSM by zavolat uživatel kliknul na souřadnici x, y a externí aplikace by vrátila ok, výsledný polygon je x1, y1, x2, y2, x3, y3, Bylo by to jistě méně pohodlné, ale to jádro by nemuselo být v Javě. Ten směr z externí aplikace do JOSM je dokonce myslím už v JOSM naimplementovaný v podobě RemoteControl: [http://wiki.openstreetmap.org/wiki/JOSM/Plugins/RemoteControl] Algoritmus jsem ještě trochu vylepšil oproti tomu v ukázce. Jinak integrace do JOSM by měla výhodu v tom, že by nebylo třeba do té aplikace dělat všechno ostatní GIS věci (tedy takový klon JOSM). Nevýhoda by asi byla v tom, že JOSM je pro začátečníky složitý a výsledný program by nebyl tak jednoduchý, jak může být (tedy něco takového, co by si člověk s Windows stáhnul, nainstaloval a klikal na budovy, aniž by musel něco nastavovat, zkoumat ovládání, ...). Aneb práce ještě není zdaleka u konce ... algoritmus trasování je jen jedna část. Honza 2010/1/27 Pavel Zbytovský m...@zby.cz: Ahoj, jůů, tak tohle je velmi dobrá práce! Něco podobného mi hodně chybělo, tak jsem uvažoval nad tvorbou vlastního
Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map
Jinak, kdyby někdo měl problémy, tak můžete ověřit, zda funguje trasovací server ... využívá klasický HTTP protokol, takže stačí otevřít internetový prohlížeč a napsat např.: http://localhost:5050/trace/simple/50.037973499148485;14.50494914227297 Výsledek by měl být ve stylu seznamu souřadnic bodů budovy, např.: 50.038111;14.505007|50.037951;14.505044|50.037932;14.504851|50.037962;14.504843|50.037966;14.504868|50.038064;14.504848|50.038061;14.504823|50.038094;14.504813|50.038111;14.505007 Případně lze použít formát OSM: http://localhost:5050/trace/osm/50.037973499148485;14.50494914227297 (to vrátí XML se stejnými daty) Naopak, pokud kliknete v JOSM na nějaký bod nástrojem Tracer, tak v okénku serveru uvidíte, co tam přišlo za požadavek... Honza 2010/1/29 Jan Bilak jan.bilak@gmail.com: Zdravím pánové, prosím o vyzkoušení první betaverze traceru budov z katastrálních map. http://jabi.aspone.cz/osm/TraceServerBeta1.zip Archiv obsahuje dva soubory. 1) Osm.Kn.Trace.Server.exe 2) tracer.jar První z nich je trasovací server, který je třeba mít spuštěný v průběhu trasování. Poslouchá na portu 5050 a zatím není nijak konfigurovatený. Prostě jej spustíte a až jej nebudete potřebovat, tak jej zavřete. To je vše. Doporučuji jej dát do prázdného adresáře, proto si k sobě ukládá dočasné soubory (stažené a předzpracované výseky katastrální mapy). Druhý soubor je plugin do JOSM (založený na LakeWalkeru). Ten zkopírujete do adresáře s pluginy JOSM (ve Vistě např. c:\Users\[userName]\AppData\Roaming\JOSM\plugins). Funguje s verzí 2561 JOSM. Aktivujete jej v nastavení. Přibude nástroj Tracer (klávesová zkratka T). Po aktivaci nástroje můžete klikat na mapu a mělo by to trasovat. Opětovným zvolením nástroje (nebo T) by se měl zase deaktivovat. Uvítám připomínky, ale nevím, kdy je stihnu realizovat. Nějaký další vývojář by se hodil... Kdo se hlásí dobrovolně? :) BTW: Jak to má tagovat ty budovy? Honza 2010/1/28 Frettie fret...@gmail.com: To si právě nemyslím, to, že je složitý, pro mě jako začátečníka v mapování (no dobře, mám za sebou práci v ArcGISu a Topolu) to bylo fajn, bylo snadné se napojit, snadné si nakonfigurovat to, co jsem potřeboval. JOSM odpuzuje bohužel už tím, jak vypadá a taky tím, že je tuším v Javě. Možná jsi měl jen smůlu na špatný kus, mě se lehce škubne, jen při velkém počtu bodů a linek (a to nemám zdaleka oslnivý hardware). Ale API nemá (zatím). 2010/1/28 Jan Bilak jan.bilak@gmail.com: Na Merkaator jsem zběžně koukal a nějak mne zatím nepřesvědčil. A to ani možnostmi (to jsem ani moc nečekal), ani rychlostí (to jsem čekal, protože je psaný v C++/qt a to je hodně výkonná platforma - třeba při tažení nové cesty se to vyloženě škube a to podle mne značí spíše na použití špatných algoritmů a datových struktur). A nakonec ani jednoduchostí ... na první pohled. Ale možná je to tím, že na JOSM jsem přeci jen koukal delší dobu. Tu jednoduchost jsem myslel hlavně pro lidi, kteří se chtěl OSM zúčastnit tak nějak rekreačně - dodělat si tam nějaké okolí svého domu, nic neimportovat, neprogramovat, ... Ale možnost volby je dobrá věc - nechť každý používá to, co mu vyhovuje. Honza -- Forwarded message -- From: Frettie fret...@gmail.com Date: 2010/1/27 Subject: Re: [Talk-cz] Tracer na rozpoznání budov z katastr. map To: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Právě, ono takovej merkaartor je super věc, JOSM je jak složitý, tak prostě ovladatelný. :/ Ale asi by mě to donutilo přejít, to zas jo. 2010/1/27 Jan Bilak jan.bilak@gmail.com: Ahoj, uvažoval jsem podobně ... zatím tedy o JOSM a API pro pluginy moc nevím. A v Javě jsem něco naposledy před x lety (nějaké drobnosti tedy i později, ale mnohem větší zkušenosti mám s .NETem). Přepsat jádro algoritmu do Javy by asi takový problém nebyl (tedy tu část, která vezme 2D pole bytů (byte = pixel) a souřadnici kliknutí a vrátí seřazený seznam souřadnic vrcholů polygonu obrysu budovy). Horší pro mne bude se stahováním a cachování bitmap, jejich spojováním pro účely trace, převáděním na pole bytů (kvůli rychlosti ... v .NETu na to používám unmanaged kód). Tedy takovými věcmi, kde jsou třeba znalosti nejen jazyka Java, ale i různých knihoven. A otázka je, jak to bude rychlé v čisté Javě. Spíše jsem uvažoval i nad přepisem toho jádra do nativního C či C++. Včera jsem na ten plugin lake-walker zběžně koukal, inspirovat by se z toho jistě dalo. Zda by z toho šlo využít všechno a jen doplnit algoritmus rozpoznávání, to je otázka. Jinak jsem ještě uvažoval na tím, že by rozpoznávání mohla dělat externí aplikace, se kterou by plugin komunikovat třeba TCP ... tedy plugin JOSM by zavolat uživatel kliknul na souřadnici x, y a externí aplikace by vrátila ok, výsledný polygon je x1, y1, x2, y2, x3, y3, Bylo by to jistě méně pohodlné, ale to jádro by nemuselo být v Javě. Ten směr z externí aplikace do JOSM je dokonce myslím už v JOSM
