Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map
Dne 5.2.2010 14:14, Petr Dlouhý napsal(a): Nevím, jak by se to přesně mělo nastavovat. Nejjednodušší možnost vidím takovou, že by se se zmáčknutým altem nepřidal tag building=yes, a šlo by objekt otagovat ručně (případně pomocí ctrl-shift-v). Jsou nějaké lepší návrhy? Konfigurace pluginu by byla lepsi, pripadne otevrit aktualne pridelovane tagy v pravym sloupci s moznosti pridat/odebrat. Ostatne by bylo celkem fajn, kdyby slo neco podobneho primo v JOSM pro prave kreslene objekty = aby se vsemu co nakreslim pridelila sada nadefinovanych tagu. Slučování sousedních objektů už v JOSM je - shift-j (možná ale až v latest), pokud navíc klikneš na první oblast, podržíš shift a klikneš na druhou, tak zůstanou obě ve výběru, takže jde rovnou spustit slučování. Řekl bych, že detekce vnitřních polygonů by opravdu způsobila víc práce než užitku. V JOSM ale chybí nástroj na jednoduché vytváření děravých polygonů, takže kdyby ho někdo vytvořil, tak by se mohla ušetřit práce. Nemyslis multipoly (plugin) ? Vyberes mnozinu polygonu a jednim klikem vytvori relaci s tim, ze je spravne oznaci vnejsi/vnitrni. On Fri, 05 Feb 2010 13:59:12 +0100, Jan Dudík jan.du...@gmail.com wrote: Jako tip do budoucna - možnost nastavení, že trasovaný objekt není nutně budova, ale třeba rybník, nebo cokoliv jiného. A samozřejmě, kdyby šly slučovat sousedící plochy... a detekce vnitřních polygonů by asi byla příliš chybová, než aby to stálo za aplikaci, že? ___ 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, nyní jde použít trasování s altem + ctrl-shift-v. Řešení přidávání na úrovni pluginu by byla zbytečná práce, chtělo by to udělat na úrovni JOSM. On Fri, 12 Feb 2010 12:25:26 +0100, jzvc j...@tpfree.fdns.net wrote: Konfigurace pluginu by byla lepsi, pripadne otevrit aktualne pridelovane tagy v pravym sloupci s moznosti pridat/odebrat. Ostatne by bylo celkem fajn, kdyby slo neco podobneho primo v JOSM pro prave kreslene objekty = aby se vsemu co nakreslim pridelila sada nadefinovanych tagu. -- Petr Dlouhý ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
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
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
[Talk-cz] Tracer na rozpoznání budov z katastr ální mapy
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
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 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, 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ší
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
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 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,
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
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. 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. On Sat, 13 Feb 2010 00:28:20 +0100, Petr Dlouhý petr.dlo...@email.cz wrote: -Č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 -- Petr Dlouhý ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
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
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
Ahoj, našel jsem případ, kdy se slila dvě čísla dohromady (testováno v betě 1) - je to na dlaždici [1], číslo 2341. Nevidím důvod, proč by se vlastně měly ta čísla prodlužovat nebo zkracovat o další číslice - pokud se tam připlete další adresní bod ve stejném místě, mělo by se tam připlést i č nebo b, takže by se neměl při Merge vůbec přiřadit - jde to opravit ručně (a stačí tedy minimalizovat počet případů na únosnou mez). Zkracovat by se snad nemělo to číslo nikdy (pokud skončíme včas před pravým okrajem), pokud tam bude velký zmatek, tak se ve výsledku může objevit nanejvýš ?. Změnit snad také ne. Posílám testovací data (měl by to být celý okres Praha-západ) na [2]. Zkoušel jsem betu 2, ale má problém s pamětí - když to generuju na velké oblasti, tak po nějaké době spadne na zaplnění paměti. Beta 1 byla v pořádku. [1] http://www.flyshare.cz/stahni/46190/14.2327_50.0796_14.2377_50.0846-budovy.png [2] http://www.flyshare.cz/stahni/46188/pz.tar.bz2 On Sat, 13 Feb 2010 01:32:41 +0100, Jan Bilak jan.bilak@gmail.com wrote: 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 -- Petr Dlouhý ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
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: 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 -- Petr Dlouhý ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
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
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
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
