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
