[Talk-cz] Import adres z katastralni mapy

Jan Bilak jan.bilak.osm na gmail.com
Pátek Únor 12 21:05:40 UTC 2010


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
>>>>
>>>
>>
>




Další informace o konferenci talk-cz