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 <[email protected]>: > 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ý <[email protected]>: >> 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ý <[email protected]> >>> 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 <[email protected]> >>> 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 <[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 >>> >>> >>> -- >>> Petr Dlouhý >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> [email protected] >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> >> >> Petr Dlouhý >> [email protected] >> >> _______________________________________________ >> 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
