[Talk-cz] Import adres z katastralni mapy
Jan Bilak
jan.bilak.osm na gmail.com
Sobota Únor 13 00:05:07 UTC 2010
Ty body, které nemají rozpoznané popisky, jsou myslím příliš u kraje.
Tedy nyní tam mám nějaký tvrdý limit podle vzdálenosti bodu od kraje
(tuším 120px od pravého okraje, a cca 20 od horního). Na ploše, kde to
má rozpoznávat, je třeba se dohodnout. Pokud máš nějaký případ, který
není takto blízko kraje, tak mi prosím pošli dlaždici. Přidám tamk
takovým bodům zatím popisek [out-of-box] do csv souboru.
A ocením i zaslání dlaždice, kde bod nebyl nalezen vůbec.
Honza
2010/2/13 Jan Bilak <jan.bilak.osm na gmail.com>:
> Jinak ... když si povolíš logování, tak se loguje i grafická
> reprezentace toho textu, takže tam uvidíš, co a jak to rozpoznává.
>
> Honza
>
>
> 2010/2/13 Jan Bilak <jan.bilak.osm na gmail.com>:
>> Ahoj,
>> ten copyright je vlevo nahoře, ale pak i na souřadnici cca [530,510] px.
>>
>> Ta detekce bodů ... toho jsem si nevšiml. Jak to kontroluješ?
>>
>> Check ... to značí opravdu i nepatrný překryv. Pokud si to není jisté,
>> tak je tam znak otazník a v hranatých závorkách seznam možností. Ještě
>> tam dám jednu kontrolu a mělo byt o být myslím 100% spolehlivé, když
>> tam nebude žádný červený bod chybět (tedy je třeba použít možnost a)
>> nebo b) vypořádání se s copyrightem).
>>
>> Ořez před detekcí nedělám ... detekce si sama řídí, kdy skončit.
>>
>> Check by nemělo být nic, co by bylo třeba ručně kontrolovat - až se
>> vyřeší ten copyright a přidám tam tu jednu drobnou kontrolu. Těch
>> možností, kdy se tam objeví otazník (není si to jisté) je myslím
>> minimum. Zatím se mi to nestalo.
>>
>> Honza
>>
>>
>> 2010/2/13 Petr Dlouhý <petr.dlouhy na email.cz>:
>>> 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
>>>
>>
>
Další informace o konferenci talk-cz