[Talk-cz] Import adres z katastralni mapy

Sobota Únor 13 00:13:59 UTC 2010

Dal jsem tam betu 2 ... http://jabi.aspone.cz/osm/OcrBeta2.zip

Je vícevláknová, trochu přepracovaný výpis do konzole (časový odhad do
konce apod.).
+ zapisuje do csv souboru info o tom, že bod je moc blízko kraje dlaždice.

Honza

2010/2/13 Jan Bilak <jan.bilak.osm na gmail.com>:
> 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ý <petr.dlouhy na email.cz>:
>> 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ý <petr.dlouhy na email.cz>
>>> 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 <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
>>>
>>>
>>>
>>
>> Petr Dlouhý
>> petr.dlouhy na email.cz
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz na openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>