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
