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 <[email protected]>: > Doplnil jsem tam chybějící číslici 4. > > Honza > > 2010/2/12 Jan Bilak <[email protected]>: >> 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 <[email protected]>: >>> 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ý <[email protected]>: >>>> 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 <[email protected]> >>>> 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ý <[email protected]>: >>>>>> 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 <[email protected]> >>>>>> 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ý <[email protected]>: >>>>>>>> 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 <[email protected]> >>>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> [email protected] >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>>> >>>>>> -- >>>>>> Petr Dlouhý >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> [email protected] >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> [email protected] >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> -- >>>> Petr Dlouhý >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> [email protected] >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >> > _______________________________________________ Talk-cz mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-cz
