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....@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.dlo...@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....@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.dlo...@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 <u...@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@openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz@openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> -- >> Petr Dlouhý >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz -- Petr Dlouhý _______________________________________________ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
