[Talk-cz] Import adres z katastralni mapy
Jan Bilak
jan.bilak.osm na gmail.com
Sobota Únor 13 00:10:29 UTC 2010
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
>
Další informace o konferenci talk-cz