[Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

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