[Talk-cz] Import adres z katastralni mapy

Pátek Únor 12 23:28:20 UTC 2010

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ý