[Talk-cz] Import adres z katastralni mapy

Pátek Únor 12 23:44:56 UTC 2010

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.osm na 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.dlouhy na 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.osm na 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.osm na gmail.com>:
>>>> Doplnil jsem tam chybějící číslici 4.
>>>>
>>>> Honza
>>>>
>>>> 2010/2/12 Jan Bilak <jan.bilak.osm na 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.osm na 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.dlouhy na 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.osm na 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.dlouhy na 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.osm na 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.dlouhy na 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
>>>>>>>>>>> <utx na 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 na openstreetmap.org
>>>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Talk-cz mailing list
>>>>>>>>>> Talk-cz na openstreetmap.org
>>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Petr Dlouhý
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Talk-cz mailing list
>>>>>>>>> Talk-cz na openstreetmap.org
>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Talk-cz mailing list
>>>>>>>> Talk-cz na openstreetmap.org
>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Petr Dlouhý
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Talk-cz mailing list
>>>>>>> Talk-cz na openstreetmap.org
>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz na openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>> --
>> Petr Dlouhý
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz na openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>