[Talk-cz] Import adres z katastralni mapy

Sobota Únor 13 00:02:58 UTC 2010

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