> [output-filename-prefix]-unmatched.osm - obsahuje body, kterym se nepodarilo > jednoznacne priradit adresu

> zakreslene katastralni uzemi v OSM souboru (pouzil jsem vyrez z > vektorizovne mapy od hanoje [4], kam jsem rucne doplnil relace a nazvy katastralnich uzemi)

> 3) Martin Kupec ted pracuje na dalsi fazi digitalizace, ktera je temer > hotova. Nasledovat bude faze, ktera je zatim jen v me abstraktni > myslence jak z: > * bodu - nesouci atributovou informaci o katastralnim uzemi (k.u.) a > lezici uvnitr k.u., priblizne uprostred > * a linii - nesouci prostorovou informaci o rozhrani k.u. > > *nadelat relace*. (nemaly problemem je, ze linie nejsou vzdy spojite a > obcas jsou prerusene coz vzniklo umistenim loga CUZK, pripadne > nenavaznosti mezi jednotlivymi dlazdicemi)

>        Dalsi faze bude sehnat si od hanoje vektorizovane obrysy >        katastralnich uzemi(nejak bojuju s GRASSem, takze si to nejak >        nejsem schopen udelat sam) a pospojovat je na polygony a pridat >        jim podle polohy nazvy.

> Zdravim, > > kdysi v lete jsem tady psal [1], jak zkousim importovat adresy a obrysy budov z > katastralni mapy CUZK. Protoze jsem nemel prilis casu, tak jsem > program pro import > nedotahnul do konce. Ted jsem se k tomu vratil a do celkem pouzitelne > podoby odelal aspon > import adresnich bodu. > > Rozpoznavani obrysu budov se mi nepodarilo udelat natolik spolehlive, > aby slo nejak > rozumne pouzivat, takze to prozatim odkladam. > > Import jsem vyzkousel na uzemi ORP Broumov [2], jedna se asi o cca 40 > obci / mestskych > casti na 31 katastralnich uzemich - cca 270km2. > > Vysledky jsou nasledujici: > Broumovsko      - 3500 adresnich bodu (nalezena jednoznacna shoda mezi KM > a databazi MVCR) >                - 170 bodu z KM, ke kterym se nepodarilo nalezt zaznam v databazi adres >                - 300 adres, ke kterym se nepodarilo najit bod v KM > > Broumov - 800 >                - 24 >                - 200 > > Mesto Broumov uvadim zvlast, protoze na jednom katastralnim uzemi jsou > 4 mestske casti > takze je potreba najit hranice mestkych casti rucne (napr. podle > ulic). Navic se mi zda, > ze je "neco shnileho" v databazi adres pro Broumov. Nevim, kde by > mohlo byt 200 budov pro > tech 200 adresnich bodu bez polohy. To se pri rucni kontrole snad > prehlednout neda. > > Castou chybou je, ze v KM je uvedeno cislo evidencni a databazi adres > cislo popisne. Na > Broumovsku je to cca 50 pripadu. Pokud se podari zjistt, jaky zdroj je > pravdivy, tak neni > problem tyto chyby napravit. > > Ja jsem uploudoval pouze ty adresni body, pro ktere byla nalezena > jendoznacna shoda. > Jestli uplodovat i ty body, ke ktery se nepodarilo najit adresu v > databazi MVCR (treba s > tagem FIXME) zalezi na dohode. Jaky je na to vas nazor? Stalo by za to > uchovavat nekde i > seznam adres, ke kterym se nepodarilo najit bod v KM?

>Martin Kupec >Dalsi faze bude sehnat si od hanoje vektorizovane obrysy >katastralnich uzemi(nejak bojuju s GRASSem, takze si to nejak >nejsem schopen udelat sam) a pospojovat je na polygony a pridat >jim podle polohy nazvy.

> S mapou od hanoje jsem si dneska hral a vysledek vypada celkem > nadejne, takze mapu s polygony snad budu schopny dodat. Chci to jen > jeste trochu doladit ...

> Tak jsem na wiki [1] vytvoril stranku s informacemi o importu. Zaroven > jsem jsem updatoval program [2], tak aby generoval tagy FIXME pro ty > adresni body, kde prirazeni mezi databazi a mapou neni jednoznacne. > >> Martin Kupec >> Dalsi faze bude sehnat si od hanoje vektorizovane obrysy >> katastralnich uzemi(nejak bojuju s GRASSem, takze si to nejak >> nejsem schopen udelat sam) a pospojovat je na polygony a pridat >> jim podle polohy nazvy. > > S mapou od hanoje jsem si dneska hral a vysledek vypada celkem > nadejne, takze mapu s polygony snad budu schopny dodat. Chci to jen > jeste trochu doladit ... > > [1] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR > [2] http://lkabrt.aspone.cz/osm/cuzk.zip > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Ahoj, > > zkoušel jsem tvůj skript, a narazil jsem na problém s tile-downloaderem. > Pouštím program na Linuxu pod Monem (2.4.2.3), a místo stáhnutých obrázků > je v těch souborech následující text(def_body i kn, zkoušel jsem i příklad > z tvého návodu): > > <?xml version='1.0' encoding="ISO-8859-1" standalone="no" ?> > <!DOCTYPE ServiceExceptionReport SYSTEM > "http://schemas.opengeospatial.net/wms/1.1.1/exception_1_1_1.dtd"> > <ServiceExceptionReport version="1.1.1"> > <ServiceException> > msWMSLoadGetMapParams(): WMS server error. Wrong number of arguments for > BBOX. > </ServiceException> > </ServiceExceptionReport> > > Chci se tedy zeptat, jestli nevíš zdali je problém způsobený Monem, jestli > je to nějaký momentální problém těch serverů, nebo čím to tedy je. > > > On Mon, 18 Jan 2010 01:13:35 +0100, Lukas Kabrt <lukas na kabrt.cz> wrote: > >> Tak jsem na wiki [1] vytvoril stranku s informacemi o importu. Zaroven >> jsem jsem updatoval program [2], tak aby generoval tagy FIXME pro ty >> adresni body, kde prirazeni mezi databazi a mapou neni jednoznacne. >> >>> Martin Kupec >>> Dalsi faze bude sehnat si od hanoje vektorizovane obrysy >>> katastralnich uzemi(nejak bojuju s GRASSem, takze si to nejak >>> nejsem schopen udelat sam) a pospojovat je na polygony a pridat >>> jim podle polohy nazvy. >> >> S mapou od hanoje jsem si dneska hral a vysledek vypada celkem >> nadejne, takze mapu s polygony snad budu schopny dodat. Chci to jen >> jeste trochu doladit ... >> >> [1] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR >> [2] http://lkabrt.aspone.cz/osm/cuzk.zip >> >> _______________________________________________ >> 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 >

> Totéž u mě pod windows, chtěl jsem to zítra zkoumat, ale vidím že to > nebude jen můj problém. > > 2010/1/19 Petr Dlouhý <petr.dlouhy na email.cz>: >> Ahoj, >> >> zkoušel jsem tvůj skript, a narazil jsem na problém s tile-downloaderem. >> Pouštím program na Linuxu pod Monem (2.4.2.3), a místo stáhnutých obrázků >> je v těch souborech následující text(def_body i kn, zkoušel jsem i příklad >> z tvého návodu): >> >> <?xml version='1.0' encoding="ISO-8859-1" standalone="no" ?> >> <!DOCTYPE ServiceExceptionReport SYSTEM >> "http://schemas.opengeospatial.net/wms/1.1.1/exception_1_1_1.dtd"> >> <ServiceExceptionReport version="1.1.1"> >> <ServiceException> >> msWMSLoadGetMapParams(): WMS server error. Wrong number of arguments for >> BBOX. >> </ServiceException> >> </ServiceExceptionReport> >> >> Chci se tedy zeptat, jestli nevíš zdali je problém způsobený Monem, jestli >> je to nějaký momentální problém těch serverů, nebo čím to tedy je. >> >> >> On Mon, 18 Jan 2010 01:13:35 +0100, Lukas Kabrt <lukas na kabrt.cz> wrote: >> >>> Tak jsem na wiki [1] vytvoril stranku s informacemi o importu. Zaroven >>> jsem jsem updatoval program [2], tak aby generoval tagy FIXME pro ty >>> adresni body, kde prirazeni mezi databazi a mapou neni jednoznacne. >>> >>>> Martin Kupec >>>> Dalsi faze bude sehnat si od hanoje vektorizovane obrysy >>>> katastralnich uzemi(nejak bojuju s GRASSem, takze si to nejak >>>> nejsem schopen udelat sam) a pospojovat je na polygony a pridat >>>> jim podle polohy nazvy. >>> >>> S mapou od hanoje jsem si dneska hral a vysledek vypada celkem >>> nadejne, takze mapu s polygony snad budu schopny dodat. Chci to jen >>> jeste trochu doladit ... >>> >>> [1] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR >>> [2] http://lkabrt.aspone.cz/osm/cuzk.zip >>> >>> _______________________________________________ >>> 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 >

> Omlouvam se za problem. Nejak jsem si neuvedomil, ze mam na pocitaci > anglice prostredi a tudiz desetinny oddelovac ".". Program jsem > upravil a ted by mel fungovat spravne, stahovat muzete opet na [1] > [1] http://lkabrt.aspone.cz/osm/cuzk.zip

> Ahoj, > > tak stahování už funguje. Teď je zase problém s tile-processorem. > Program vypíše, že mu chybí ntdll.dll (celý výpis v debug módu je v > příloze) a skončí. Víc informací o chybějících knihovnách je na [1], ale > nevím, kde bych vzal ntdll.dll, resp. kdybych vzal tu windowsovou, tak > by velmi pravděpodobně nefungovala - jediná možnost, kterou vidím je to > zkusit spustit celé pod Wine. > Má někdo nějaké nápady, jak by se to dalo obejít? > > [1] http://www.mono-project.com/DllNotFoundException >

> tak stahování už funguje. Teď je zase problém s tile-processorem. Program > vypíše, že mu chybí ntdll.dll (celý výpis v debug módu je v příloze) a > skončí. Víc informací o chybějících knihovnách je na [1], ale nevím, kde > bych vzal ntdll.dll, resp. kdybych vzal tu windowsovou, tak by velmi > pravděpodobně nefungovala - jediná možnost, kterou vidím je to zkusit > spustit celé pod Wine. > Má někdo nějaké nápady, jak by se to dalo obejít?

> Dneska jsem to zkoušel pod wine. Bohužel nevyřešil, píše to > $ wine tile-processor.exe -tiles data/oblast/ -output data/oblast.csv

> Asi to chce ten .NET Framework 3.5, ale ten je ve Wine označen jako garbage, tak > jsem to zatím dál nezkoušel...

> s Linuxem nemam moc zkusenosti a ani s MONO jsem prilis nepracoval, > ale budu se snazit pomoct. > Pokud jsem ten error spravne rozklicoval, tak se mu nelibi poziti > knihovny AForge. Program jsem upravil tak, aby tuhle knihovnu > nepouzival. Upravena verze je ke stazeni na [1].

> Dneska jsem to zkoušel pod wine. Bohužel nevyřešil, píše to > > $ wine tile-processor.exe -tiles data/oblast/ -output data/oblast.csv > File '/home/ales/.local/share/applications/wine-extension-skp.desktop' > contains > invalid MIME type 'SKP' that is missing a slash > Processing tile: > 16,1050_50,4842_16,1100_50,4892-budovy err:ole:CoInitializeEx > Attempt to change threading model of this apartment from multi-threaded > to > apartment threaded > err:ole:marshal_object couldn't get IPSFactory buffer for interface > {9edde9e7-8dee-47ea-99df-e6faf2ed44bf} > err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, > hres=0x80040155 > err:ole:CoMarshalInterface Failed to marshal the interface > {9edde9e7-8dee-47ea-99df-e6faf2ed44bf}, 80040155 > fixme:ole:CoCreateInstance no instance created for interface > {9edde9e7-8dee-47ea-99df-e6faf2ed44bf} of class > {389ea17b-5078-4cde-b6ef-25c15175c751}, hres is 0x80040155 > > Unhandled Exception: System.Exception: Generic Error [GDI+ status: > GenericError] > at System.Drawing.GDIPlus.CheckStatus (Status status) [0x00000] > at System.Drawing.Image.FromFile (System.String filename, Boolean > useEmbeddedColorManagement) [0x00000] > at System.Drawing.Image.FromFile (System.String filename) [0x00000] > at CUZK.ExtractAddresses.TileAnalyzer.Analyze (System.String > filename) [0x00000] > at CUZK.ExtractAddresses.Program.Main (System.String[] args) [0x00000] > > > Asi to chce ten .NET Framework 3.5, ale ten je ve Wine označen jako > garbage, tak > jsem to zatím dál nezkoušel… > > Aleš Janda > > > On 20.1.2010 13:12, Petr Dlouhý napsal/a: >> Ahoj, >> >> tak stahování už funguje. Teď je zase problém s tile-processorem. >> Program vypíše, že mu chybí ntdll.dll (celý výpis v debug módu je v >> příloze) a skončí. Víc informací o chybějících knihovnách je na [1], ale >> nevím, kde bych vzal ntdll.dll, resp. kdybych vzal tu windowsovou, tak >> by velmi pravděpodobně nefungovala - jediná možnost, kterou vidím je to >> zkusit spustit celé pod Wine. >> Má někdo nějaké nápady, jak by se to dalo obejít? >> >> [1] http://www.mono-project.com/DllNotFoundException >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Tak jsem na wiki [1] vytvoril stranku s informacemi o importu. Zaroven > jsem jsem updatoval program [2], tak aby generoval tagy FIXME pro ty > adresni body, kde prirazeni mezi databazi a mapou neni jednoznacne. > >> Martin Kupec >> Dalsi faze bude sehnat si od hanoje vektorizovane obrysy >> katastralnich uzemi(nejak bojuju s GRASSem, takze si to nejak >> nejsem schopen udelat sam) a pospojovat je na polygony a pridat >> jim podle polohy nazvy. > > S mapou od hanoje jsem si dneska hral a vysledek vypada celkem > nadejne, takze mapu s polygony snad budu schopny dodat. Chci to jen > jeste trochu doladit ... > > [1] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR > [2] http://lkabrt.aspone.cz/osm/cuzk.zip > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Ahoj, > zjistil jsem, že problém je způsoben knihovnou gdiplus. Když to pustíš s > nativním (windowsovým gdiplus), tak to vypisuje spousty errorů, ale zdá > se, že to funguje. > Postup je tedy nakopírovat do složky k tile-processoru knihovnu > gdiplus.dll a spustit: > WINEDLLOVERRIDES="gdiplus=n" wine tile-processor.exe -tiles output > -output > output.csv

>Což ani nevypadá, že by byl problém s Monem. Co má být v souboru >label.txt? Když ten soubor vytvořím a vložím tam nějaké znaky, tak to >začne vypisovat:

>chtěl bych se zeptat, jak tvůj program řeší ořez čísel na okrajích >stažených dlaždic. Ptám se pro jistotu, aby nevznikly zbytečné chyby.

>přes Wine to funguje, ale výsledek není ještě pořád ideální. Spočítaná >poloha jednotlivých bodů totiž nedává úplně smysl - občas je tam NaN, >občas čísla, mimo rozmezí daného BBOX, občas čísla větší než 100000. >Nemůže být zase problém s desetinou tečkou/čárkou?

>V příloze posílám výstup z programu, a zkrácený výpis programu. Wine rád vypisuje >velké množství chyb, takže některých údajů ve výpisu si není třeba všímat.

> Program pracuje tak, ze vezme dlaždici, najde na ní definicni body > budov (cervene tecky) a k nim prislusejici text. Text ulozi do obrazku > "tmp.bmp" a potom ho rozpozna exetnim OCR programem (tesseract.exe). > Ten ulozi rozpoznany text prave do souboru label.txt

>        Muzu se zeptat, zda pouzivate nejak upraveny/nauceny tesseract >        na ceske znaky, nebo to cestinu uspesne neumi?

> Program pracuje tak, ze vezme dlaždici, najde na ní definicni body > budov (cervene tecky) a k nim prislusejici text. Text ulozi do obrazku > "tmp.bmp" a potom ho rozpozna exetnim OCR programem (tesseract.exe). > Ten ulozi rozpoznany text prave do souboru label.txt > Proc program nefunguje, kdyz soubor label.txt pred spustenim > neexistuje je mi zahadou. Podle vystupu "output.csv" co jsi posilal, > tak rozpoznavani evidentne funguje ...

> ------------ Původní zpráva ------------ > Od: Petr Dlouhý <petr.dlouhy na email.cz> > Předmět: Re: [Talk-cz] Import adres z katastralni mapy > Datum: 20.1.2010 23:32:05 > ---------------------------------------- > Tak se to chovalo pod čistým Monem, kde to nefunguje, a to ani s přítomným > label.txt. Vypadá to, že má problém spustit externí aplikaci - mono > používá xdg-open, což je nějaký program na spouštění souborů v uživatelem > preferovaném prohlížeči/editoru (místo toho, aby externí program prostě > spustil). > > Ten program se mi podařilo rozjet pod programem Wine na kterém je > nainstalované Mono, a to jsem ještě musel použít knihovnu gdiplus.dll z > Windows (v tomto případě už nepřítomnost label.txt nehraje roli). Wine je > implementace windowsových knihoven pod Linuxem. Není to ideální řešení > (lepší by bylo aby to fungovalo pod Monem přímo, už jenom kvůli tomu, že > pod Wine je to o něco složitější rozjet), ale pokud by problém zmíněný v > předchozím odstavci nešel jednoduše vyřešit, tak se tím nezabývej, protože > jde pouze o jednoúčelovou utilitu a svůj účel splní i takto. > > > On Wed, 20 Jan 2010 21:37:07 +0100, Lukas Kabrt <lukas na kabrt.cz> wrote: > > > Program pracuje tak, ze vezme dlaždici, najde na ní definicni body > > budov (cervene tecky) a k nim prislusejici text. Text ulozi do obrazku > > "tmp.bmp" a potom ho rozpozna exetnim OCR programem (tesseract.exe). > > Ten ulozi rozpoznany text prave do souboru label.txt > > Proc program nefunguje, kdyz soubor label.txt pred spustenim > > neexistuje je mi zahadou. Podle vystupu "output.csv" co jsi posilal, > > tak rozpoznavani evidentne funguje ... > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

> Moje chyba. Tile-downloader ukladal dlazdice se spatny jmenem (opet > carka / tecka). Oprava opet na [1]. Pokud mas nejake dlazdice stazene, > tak staci carky v nazvech souboru nahradit za tecky.

> Tak jsem trochu zapracoval na mape katastralnich uzemi, aby se k.u. > nemuseli kreslit rucne. > > Vektorizovanou mapu k.u. od hanoje [1] jsem zacistil (slouceni > duplicitnich bodu, odtraneni fragmentu po vektorizaci, pospojovani > prerusenych linii) a vytvoril na ni relace pro jednotliva k.u. > > Mapu jsem dal dohromady s daty co mi poslal Martin Kupec (nazvy > katastralnich uzemi a jejich poloha). Vysledek je ke stazeni tady [2]. > > Trocha statistiky: > CR ma 13027 k.u. > Martin mi poslal data pro 12171 k.u. > Mapa ma definovano 13028 relaci > > Mapa je jenom prozatmni, pri prirazeni se vyskytly nejake chyby (vic > nazvu pro jedno k.u., jedna se ale o jednotky, max. desitky pripadu) > To bych resil az budou hotova data pro vsechy k.u. Stejne tak je v > mape 1 relace navic - pravdepodobne nekde zustal nejaky fragment, ten > se taky objevi, az se priradi vsechny nazvy.

> Pokud jsem ten error spravne rozklicoval, tak se mu nelibi poziti > knihovny AForge. Program jsem upravil tak, aby tuhle knihovnu > nepouzival. Upravena verze je ke stazeni na [1].

> Ahoj, > > povedlo se mi zprovoznit kompilaci pod Monodevelop, takže si už můžu > program upravit sám (chtěl bych tam přidat podporu pro nativní Linuxový > Tesseract, což bude ten hlavní problém proč to nechodí jinak, než pod > Wine). > > Pošli mi prosím tedy aspoň zdrojáky, ve kterých nepoužíváš knihovnu AForge.

> Tak jsem trochu zapracoval na mape katastralnich uzemi, aby se k.u. > nemuseli kreslit rucne. > > Vektorizovanou mapu k.u. od hanoje [1] jsem zacistil (slouceni > duplicitnich bodu, odtraneni fragmentu po vektorizaci, pospojovani > prerusenych linii) a vytvoril na ni relace pro jednotliva k.u. > > Mapu jsem dal dohromady s daty co mi poslal Martin Kupec (nazvy > katastralnich uzemi a jejich poloha). Vysledek je ke stazeni tady [2]. > > Trocha statistiky: > CR ma 13027 k.u. > Martin mi poslal data pro 12171 k.u. > Mapa ma definovano 13028 relaci > > Mapa je jenom prozatmni, pri prirazeni se vyskytly nejake chyby (vic > nazvu pro jedno k.u., jedna se ale o jednotky, max. desitky pripadu) > To bych resil az budou hotova data pro vsechy k.u. Stejne tak je v > mape 1 relace navic - pravdepodobne nekde zustal nejaky fragment, ten > se taky objevi, az se priradi vsechny nazvy. > > Pokud se nekdo pousti do importu adres, tak mu tohle snad usetri trochu casu. > > [1] http://osm.templ.net/kucr.osm.bz2 > [2] http://lkabrt.aspone.cz/osm/kucr.zip

> > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> měl bych k tomu ryze praktický dotaz. Jakým způsobem z téhle mapy > nejsnáze vyříznout oblast která mě zajímá? Při načtení do JOSM se s > takhle velou mapou nedá rozumně pracovat, každou akci provází > minimálně několikaminutové čekání.

> dlazdice se prekryvaji o 5% na kazde strane, takze temer jiste, ze > alespon na jedne dlazdici je text cely. Tile-processor vysledky nijak > nezpracovava, pouze ulozi polohu bodu a jemu prislusejici text. V > dalsim kroku, pri prirazovani adres jednotlivym bodum se nesmyslene > rozpoznany text vyfiltruje.

> Jedna moznost je v JOSM si cast zkopirovat do nove vrstvy a pak > pracovat s ni. Chvili to trva, ale jednou se to da prezit.

> Zkoumal si nějak maximální rozlišení CUZK a optimalizoval naj ně tvůj > program? Jde o to, že čím větší rozlišení zvolíš, tím jsou čísla menší a > tím je také menší riziko překryvu (který způsobuje nejvíc špatně > rozpoznaných čísel).

> Moznosti by bylo nejdrive stahnout mapu v nizsim rozliseni, najit > definicni body budov a pak pro kazdou budovu stahnout detail. Tohle > reseni se mi ale moc nelibi, protoze by bylo nutne stahovat velke > mnozstvi detailu a hodne by to zpomalilo zpracovani. (Vcera jsem > zkousel rozpoznavani na plose cca 20 x 25 km a bylo tam okolo 90000 > budov)

> V kroku 3 (vytvoreni XML souboru, ktery definuje prirazeni mezi > katastralnim uzemim a obci / casti obce z databaze adresnich bodu) > jsem převzal XML z dokumentace. A k tomu se váže první dotaz. Kde > berete tyto informace? A k čemu je to dobré? Upozorňuji, že nejsem > zaměměřič, ale programátor, takže o struktuře území toho moc nevím, i > když jsem k této oblasti trochu přičichnul.

> Moje představa je, že čísla domů jsou jedinečná v části obce (proto > např. v nahlížení do KN říkám obec, část obce, číslo budovy). Proto je > třeba nějak určit část obce, do které dané území patří.

> číselníky částí obcí a jejich vztahy k obcím, okresům, krajům apod. > jsou na Českém Statistikém Úřadě. Ale nevím, zda je lze z licenčních > důvodů použít (ví to někdo?). Ruční vytváření XML pro každé > katastrální území, kterých jsou tisíce(?) je poněkud nepraktické a > hlavně hrozí chyby.

>kterých jsou tisíce(?)

> A pak je třeba udělat merge. Odkud pochází databáze adres? To je > UIR-ADR? Z jakého původního zdroje pocházejí hranice katastrálních > území?

> A co vlastně merge dělá? Moje představa je, že pro každý adresní bod z > toho CSV souboru vygenerovaném v jednom z předchozích kroků najde > katastrální území, jehož hranice je v souboru daném parametrem > territories.

> U druhého parametru nevím. Zkoušel jsem > http://osm.templ.net/kucr.osm.bz2

> http://lkabrt.aspone.cz/osm/kucr.zip.

> Čtvrtý parametr - to je to XML převzaté pro pokus z dokumentace.

> 2) V případě použití http://lkabrt.aspone.cz/osm/kucr.zip program > vytíží jedno jádro procesoru a nic ... tedy nechal jsem to pár desítek > minut (nebo mám čekat déle?). Poslední hláška je, že Loading > territories borders...

> Další věc je, že ten XML soubor z kroku 2 definuje vztahy pomocí > názvů. Ale ty myslím nejsou jednoznačné. Přitom číselníky katastru i > Stat. úřadu používají pro označení obce, části obce, katastr. území > apod. také nějaká číselná IDčka (kupodivu dokonce stejná).

> Rád bych pokračoval vývojem SW pro poloautomatické zpracování, protože > o lepším zdroji informací než je katastrální mapa nevím. Mám představu > nějaké GUI, kde půjdou obkreslovat budovy (s případným automatickým > návrhem), kontrolovat čísla domů apod. Ale napřed bych si rád ujasnil > současnou situaci a zorientoval se v problému.

> Ano je to trochu neprakticke. Asi by to slo castecne automatizovat. > Muj postup je, ze si z databaze [1] vytahnu stukturu oblast - obec - > cast a z mapy nazvy k. u. a rucne prirazuju, vestinou je to jasne > (zatim stejne delam v mistech, ktere jakz takz znam). Prirazeni k.u. - > obec lze nalezt na strankach CUZK [2]. Jak je to s licenci nevim. > Problemy jsou ale s nekterymi castmi obci - na jednom k.u. muze byt > vice casti obce.

> Ahoj, > > pracuji na generátoru .map souboru. Potřeboval bych ale seznam > katastrálních území a jejich čísel, který Martin Kupec získal OCR > přehledek, podle čísel území by to šlo jednoduše spojit. > Kde je možné ten soubor získat? > > On Sat, 23 Jan 2010 20:40:13 +0100, Lukas Kabrt <lukas na kabrt.cz> wrote: > >> Ano je to trochu neprakticke. Asi by to slo castecne automatizovat. >> Muj postup je, ze si z databaze [1] vytahnu stukturu oblast - obec - >> cast a z mapy nazvy k. u. a rucne prirazuju, vestinou je to jasne >> (zatim stejne delam v mistech, ktere jakz takz znam). Prirazeni k.u. - >> obec lze nalezt na strankach CUZK [2]. Jak je to s licenci nevim. >> Problemy jsou ale s nekterymi castmi obci - na jednom k.u. muze byt >> vice casti obce. > >

> Ahoj, udělal jsem si utilitku pro vyjmutí části území ze souboru *.osm > mapy katastrálních území > http://lkabrt.aspone.cz/osm/kucr.zip. > Třeba se také někomu bude hodit (ať již jako binárka nebo zdroják k > zakomentování do celku). > > Upozorňuji, že nejde o nic obecného (i když by to možná zobecnit šlo), > ale je to dělané na míru tomuto souboru. Rychlost nemám s čím > porovnat, na mém stroji to trvá tak 10 sekund. Dělá to všechno v > paměti, takže to zabere pro daný konkrétní soubor asi 260 MB RAM. > Používá to XmlTextReader a XmlTextWriter místo LINQ. > > Zadá se vstupní soubor, výstupní soubor a obdélník (north, west, > south, east). Výsledný soubor obsahuje všechny > nodes, ways a relations, které alespoň jedním nodem zasahují do daného > obdélníku. > > Příklad použití: > ExtractBoundingBox.exe -north 50.50 -west 16.10278129 -south 50.49 > -east 16.123 -input "kucr-jmena.osm" -output kucr-part.osm > > Ke stažení: > http://jabi.aspone.cz/osm/ExtractBoundingBox-bin.rar (binárka pro .NET) > http://jabi.aspone.cz/osm/ExtractBoundingBox-src.rar (zdrojáky v C#) > > Použil jsem k tomu parser parametrů z CUZK.Common.dll, snad autor nebude > proti. > > Honza > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Není to trochu nově vynalezené kolo, když tu mám osmosis? > > [1] > http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004310.html > > On Sun, 24 Jan 2010 02:08:17 +0100, Jan Bilak <jan.bilak.osm na gmail.com> > wrote: > >> Ahoj, udělal jsem si utilitku pro vyjmutí části území ze souboru *.osm >> mapy katastrálních území >> http://lkabrt.aspone.cz/osm/kucr.zip. >> Třeba se také někomu bude hodit (ať již jako binárka nebo zdroják k >> zakomentování do celku). >> >> Upozorňuji, že nejde o nic obecného (i když by to možná zobecnit šlo), >> ale je to dělané na míru tomuto souboru. Rychlost nemám s čím >> porovnat, na mém stroji to trvá tak 10 sekund. Dělá to všechno v >> paměti, takže to zabere pro daný konkrétní soubor asi 260 MB RAM. >> Používá to XmlTextReader a XmlTextWriter místo LINQ. >> >> Zadá se vstupní soubor, výstupní soubor a obdélník (north, west, >> south, east). Výsledný soubor obsahuje všechny >> nodes, ways a relations, které alespoň jedním nodem zasahují do daného >> obdélníku. >> >> Příklad použití: >> ExtractBoundingBox.exe -north 50.50 -west 16.10278129 -south 50.49 >> -east 16.123 -input "kucr-jmena.osm" -output kucr-part.osm >> >> Ke stažení: >> http://jabi.aspone.cz/osm/ExtractBoundingBox-bin.rar (binárka pro .NET) >> http://jabi.aspone.cz/osm/ExtractBoundingBox-src.rar (zdrojáky v C#) >> >> Použil jsem k tomu parser parametrů z CUZK.Common.dll, snad autor nebude >> proti. >> >> Honza >> >> _______________________________________________ >> 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 >

> Asi ano, ale kdyz jsem osmosis zkousel, tak vzdycky spadnul na nejakou > podovnou vyjimku. Pak jsem v rychlosti dospel k zaveru, ze asi ke sve > cinnosti potrebuje nejakou DB (PostreSQL apod.) ... a to se mi > nechtelo instalovat ... ale treba je to spatny zaver. Moc jsem to > nezkoumal. > > Honza > > > 2010/1/24 Petr Dlouhý <petr.dlouhy na email.cz>: >> Není to trochu nově vynalezené kolo, když tu mám osmosis? >> >> [1] >> http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004310.html >> >> On Sun, 24 Jan 2010 02:08:17 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >> wrote: >> >>> Ahoj, udělal jsem si utilitku pro vyjmutí části území ze souboru *.osm >>> mapy katastrálních území >>> http://lkabrt.aspone.cz/osm/kucr.zip. >>> Třeba se také někomu bude hodit (ať již jako binárka nebo zdroják k >>> zakomentování do celku). >>> >>> Upozorňuji, že nejde o nic obecného (i když by to možná zobecnit šlo), >>> ale je to dělané na míru tomuto souboru. Rychlost nemám s čím >>> porovnat, na mém stroji to trvá tak 10 sekund. Dělá to všechno v >>> paměti, takže to zabere pro daný konkrétní soubor asi 260 MB RAM. >>> Používá to XmlTextReader a XmlTextWriter místo LINQ. >>> >>> Zadá se vstupní soubor, výstupní soubor a obdélník (north, west, >>> south, east). Výsledný soubor obsahuje všechny >>> nodes, ways a relations, které alespoň jedním nodem zasahují do daného >>> obdélníku. >>> >>> Příklad použití: >>> ExtractBoundingBox.exe -north 50.50 -west 16.10278129 -south 50.49 >>> -east 16.123 -input "kucr-jmena.osm" -output kucr-part.osm >>> >>> Ke stažení: >>> http://jabi.aspone.cz/osm/ExtractBoundingBox-bin.rar (binárka pro .NET) >>> http://jabi.aspone.cz/osm/ExtractBoundingBox-src.rar (zdrojáky v C#) >>> >>> Použil jsem k tomu parser parametrů z CUZK.Common.dll, snad autor nebude >>> proti. >>> >>> Honza >>> >>> _______________________________________________ >>> 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 >> >

> Asi ano, ale kdyz jsem osmosis zkousel, tak vzdycky spadnul na nejakou > podovnou vyjimku. Pak jsem v rychlosti dospel k zaveru, ze asi ke sve > cinnosti potrebuje nejakou DB (PostreSQL apod.) ... a to se mi > nechtelo instalovat ... ale treba je to spatny zaver. Moc jsem to > nezkoumal. > > Honza >

> A hlavně mým cílem je, aby celý proces byl poměrně jednoduchý ... > integrovaný časem do nějaké GUI, protože i když, jak tady někdo psal, > se to může zdát jako jednorázový proces, tak > > a) je natolik pracný, že je třeba distribuovat mezi více lidí (teď > nemyslím jen adresní body, ale tahání informací z katastrálních map) > b) informace v katastru se mění (aktualizují), takže čím více bude > proces automatický, tím lepší pro pozdější aktualizace > > Přecijen tohle mi přijde snadněji použitelné (i když nechci tvrdit, že > tam to je nějak extra složité - nevím. > > Honza > > > 2010/1/24 Jan Bilak <jan.bilak.osm na gmail.com>: >> Asi ano, ale kdyz jsem osmosis zkousel, tak vzdycky spadnul na nejakou >> podovnou vyjimku. Pak jsem v rychlosti dospel k zaveru, ze asi ke sve >> cinnosti potrebuje nejakou DB (PostreSQL apod.) ... a to se mi >> nechtelo instalovat ... ale treba je to spatny zaver. Moc jsem to >> nezkoumal. >> >> Honza >> >> >> 2010/1/24 Petr Dlouhý <petr.dlouhy na email.cz>: >>> Není to trochu nově vynalezené kolo, když tu mám osmosis? >>> >>> [1] >>> http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004310.html >>> >>> On Sun, 24 Jan 2010 02:08:17 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >>> wrote: >>> >>>> Ahoj, udělal jsem si utilitku pro vyjmutí části území ze souboru *.osm >>>> mapy katastrálních území >>>> http://lkabrt.aspone.cz/osm/kucr.zip. >>>> Třeba se také někomu bude hodit (ať již jako binárka nebo zdroják k >>>> zakomentování do celku). >>>> >>>> Upozorňuji, že nejde o nic obecného (i když by to možná zobecnit šlo), >>>> ale je to dělané na míru tomuto souboru. Rychlost nemám s čím >>>> porovnat, na mém stroji to trvá tak 10 sekund. Dělá to všechno v >>>> paměti, takže to zabere pro daný konkrétní soubor asi 260 MB RAM. >>>> Používá to XmlTextReader a XmlTextWriter místo LINQ. >>>> >>>> Zadá se vstupní soubor, výstupní soubor a obdélník (north, west, >>>> south, east). Výsledný soubor obsahuje všechny >>>> nodes, ways a relations, které alespoň jedním nodem zasahují do daného >>>> obdélníku. >>>> >>>> Příklad použití: >>>> ExtractBoundingBox.exe -north 50.50 -west 16.10278129 -south 50.49 >>>> -east 16.123 -input "kucr-jmena.osm" -output kucr-part.osm >>>> >>>> Ke stažení: >>>> http://jabi.aspone.cz/osm/ExtractBoundingBox-bin.rar (binárka pro >>>> .NET) >>>> http://jabi.aspone.cz/osm/ExtractBoundingBox-src.rar (zdrojáky v C#) >>>> >>>> Použil jsem k tomu parser parametrů z CUZK.Common.dll, snad autor >>>> nebude >>>> proti. >>>> >>>> Honza >>>> >>>> _______________________________________________ >>>> 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

>> V kroku 3 (vytvoreni XML souboru, ktery definuje prirazeni mezi >> katastralnim uzemim a obci / casti obce z databaze adresnich bodu) >> jsem převzal XML z dokumentace. A k tomu se váže první dotaz. Kde >> berete tyto informace? A k čemu je to dobré? Upozorňuji, že nejsem >> zaměměřič, ale programátor, takže o struktuře území toho moc nevím, i >> když jsem k této oblasti trochu přičichnul. > >> Moje představa je, že čísla domů jsou jedinečná v části obce (proto >> např. v nahlížení do KN říkám obec, část obce, číslo budovy). Proto je >> třeba nějak určit část obce, do které dané území patří. > > Presne tak. > >> číselníky částí obcí a jejich vztahy k obcím, okresům, krajům apod. >> jsou na Českém Statistikém Úřadě. Ale nevím, zda je lze z licenčních >> důvodů použít (ví to někdo?). Ruční vytváření XML pro každé >> katastrální území, kterých jsou tisíce(?) je poněkud nepraktické a >> hlavně hrozí chyby. > > Ano je to trochu neprakticke. Asi by to slo castecne automatizovat. > Muj postup je, ze si z databaze [1] vytahnu stukturu oblast - obec - > cast a z mapy nazvy k. u. a rucne prirazuju, vestinou je to jasne > (zatim stejne delam v mistech, ktere jakz takz znam). Prirazeni k.u. - > obec lze nalezt na strankach CUZK [2]. Jak je to s licenci nevim. > Problemy jsou ale s nekterymi castmi obci - na jednom k.u. muze byt > vice casti obce. > >>kterých jsou tisíce(?) > > Presne 13027. > >> A pak je třeba udělat merge. Odkud pochází databáze adres? To je >> UIR-ADR? Z jakého původního zdroje pocházejí hranice katastrálních >> území? > > Adresy pochazeni z webu MVCR [1], hranice k.u. ktere mam na strankach > jsou vektorizovane mapy CUZK - vektorizaci delal hanoj [3], a Martin > Kupec pracuje na OCR nazvu k.u., vysledek na mych strankach jeste neni > hotovy, chybi jeste cca 800 nazvu. > >> A co vlastně merge dělá? Moje představa je, že pro každý adresní bod z >> toho CSV souboru vygenerovaném v jednom z předchozích kroků najde >> katastrální území, jehož hranice je v souboru daném parametrem >> territories. > > Merge vezme CSV soubor se souradnicemi budov a rozpoznanym popiskem, > najde k.u., ve kterem se budova nachazi, podiva se do souboru *.map > jaka obec, mestska cast se na k.u. nachazi a podle toho se budove > pokusi priradit adresu z databaze MVCR. > >> U druhého parametru nevím. Zkoušel jsem >> http://osm.templ.net/kucr.osm.bz2 > > ten urcite fungovat nebude, tam nejsou nazvy k.u. > >> http://lkabrt.aspone.cz/osm/kucr.zip. > > ten muzes pouzit, ale je potreba zkotrolovat, jestli tam je zadany to > k.u. o ktery se zajimas - nazvy jeste nejsou kompletni. > > >> Čtvrtý parametr - to je to XML převzaté pro pokus z dokumentace. > > priklad z dokumentace mozna nebude kompatiblni s mapu z > http://lkabrt.aspone.cz/osm/kucr.zip. Koukam, ze je to jeste z doby, > kdy jsem mapu zkousel malovat jen tak priblizne rucne, jen pro ucely > tohohle programu takze asi nesedi nazvy. > >> 2) V případě použití http://lkabrt.aspone.cz/osm/kucr.zip program >> vytíží jedno jádro procesoru a nic ... tedy nechal jsem to pár desítek >> minut (nebo mám čekat déle?). Poslední hláška je, že Loading >> territories borders... > > Pro parsovani XML pouzivam XML.LINQ, a ten neni delany na zpracovani > tak velkych souboru, proto si ze souboru kucr.zip vyriznu cast se > kterou chci pracovat [4]. S parsovanim XML dokumentu mozna neco > udelam, fakt to neni nejrychlejsi. XML.Linq ma ale tu vyhodu, ze se s > tim hezky pracuje, takze jsem ho pouzil pri vyvoji. > >> Další věc je, že ten XML soubor z kroku 2 definuje vztahy pomocí >> názvů. Ale ty myslím nejsou jednoznačné. Přitom číselníky katastru i >> Stat. úřadu používají pro označení obce, části obce, katastr. území >> apod. také nějaká číselná IDčka (kupodivu dokonce stejná). > > Jmena k.u. jsou jedinecna, stejne tak kombinace oblast-obec-cast z databaze. > > [1] http://aplikace.mvcr.cz/adresa/adresy.zip > [2] http://www.cuzk.cz/Dokument.aspx?PRARESKOD=10&MENUID=10015&AKCE=DOC:10-CISE_KUAP > [3] http://lists.openstreetmap.org/pipermail/talk-cz/2009-June/003204.html > [4] http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004310.html > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Co se týče skriptů, tak myslím, že je třeba se vydat jinou cestou. > Pokud to jde alespoň trochu jednoduše udělat, tak by ten skript měl > dokázat pracovat s celou mapou katastrálních území. Nemůže být problém z > toho souboru vytáhnout pouze ty relace (ty moc nezabírají), a hranice > tahat jen podle potřeby. > Pokud se navíc vytvoří mapovací soubor pro celou ČR, tak to celý proces > výrazně zjednoduší. Pro to není potřeba žádné GUI, manuální práce na > začištění ale asi bude potřeba vždy. > > Co se týče pozdějších manuálních, tak na to existuje Czechaddress plugin > do JOSM. Takže vlastně GUI. > > On Sun, 24 Jan 2010 02:27:55 +0100, Jan Bilak <jan.bilak.osm na gmail.com> > wrote: > >> A hlavně mým cílem je, aby celý proces byl poměrně jednoduchý ... >> integrovaný časem do nějaké GUI, protože i když, jak tady někdo psal, >> se to může zdát jako jednorázový proces, tak >> >> a) je natolik pracný, že je třeba distribuovat mezi více lidí (teď >> nemyslím jen adresní body, ale tahání informací z katastrálních map) >> b) informace v katastru se mění (aktualizují), takže čím více bude >> proces automatický, tím lepší pro pozdější aktualizace >> >> Přecijen tohle mi přijde snadněji použitelné (i když nechci tvrdit, že >> tam to je nějak extra složité - nevím. >> >> Honza >> >> >> 2010/1/24 Jan Bilak <jan.bilak.osm na gmail.com>: >>> Asi ano, ale kdyz jsem osmosis zkousel, tak vzdycky spadnul na nejakou >>> podovnou vyjimku. Pak jsem v rychlosti dospel k zaveru, ze asi ke sve >>> cinnosti potrebuje nejakou DB (PostreSQL apod.) ... a to se mi >>> nechtelo instalovat ... ale treba je to spatny zaver. Moc jsem to >>> nezkoumal. >>> >>> Honza >>> >>> >>> 2010/1/24 Petr Dlouhý <petr.dlouhy na email.cz>: >>>> Není to trochu nově vynalezené kolo, když tu mám osmosis? >>>> >>>> [1] >>>> http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004310.html >>>> >>>> On Sun, 24 Jan 2010 02:08:17 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >>>> wrote: >>>> >>>>> Ahoj, udělal jsem si utilitku pro vyjmutí části území ze souboru *.osm >>>>> mapy katastrálních území >>>>> http://lkabrt.aspone.cz/osm/kucr.zip. >>>>> Třeba se také někomu bude hodit (ať již jako binárka nebo zdroják k >>>>> zakomentování do celku). >>>>> >>>>> Upozorňuji, že nejde o nic obecného (i když by to možná zobecnit šlo), >>>>> ale je to dělané na míru tomuto souboru. Rychlost nemám s čím >>>>> porovnat, na mém stroji to trvá tak 10 sekund. Dělá to všechno v >>>>> paměti, takže to zabere pro daný konkrétní soubor asi 260 MB RAM. >>>>> Používá to XmlTextReader a XmlTextWriter místo LINQ. >>>>> >>>>> Zadá se vstupní soubor, výstupní soubor a obdélník (north, west, >>>>> south, east). Výsledný soubor obsahuje všechny >>>>> nodes, ways a relations, které alespoň jedním nodem zasahují do daného >>>>> obdélníku. >>>>> >>>>> Příklad použití: >>>>> ExtractBoundingBox.exe -north 50.50 -west 16.10278129 -south 50.49 >>>>> -east 16.123 -input "kucr-jmena.osm" -output kucr-part.osm >>>>> >>>>> Ke stažení: >>>>> http://jabi.aspone.cz/osm/ExtractBoundingBox-bin.rar (binárka pro >>>>> .NET) >>>>> http://jabi.aspone.cz/osm/ExtractBoundingBox-src.rar (zdrojáky v C#) >>>>> >>>>> Použil jsem k tomu parser parametrů z CUZK.Common.dll, snad autor >>>>> nebude >>>>> proti. >>>>> >>>>> Honza >>>>> >>>>> _______________________________________________ >>>>> 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 >

> Já nemyslel GUI v tom smyslu, že tam bude 5 tlačítek a ty budou > spouštět tyhle skripty. Ale co je třeba dělat? > > Pro adresní body: > - vybrat území, které mne zajímá (zajímavá informace zde bude, co už > je hotové a co nikoli ... zatím není skoro nic, ale časem...) > - automaticky stáhnou potřebná data (mapování, adresy, hranice kat. > území, dlaždice) a OCRovat > - pak je třeba manuální kontrola mapování, adres, výsledku OCRu - > zejména pro kontrolu OCRu se hodí možnost v GUI si zobrazit daný text > v podobě výřezu obrázku (zcela automaticky, aniž bych musel něco > složitě někde hledat či zadávát) > - automaticky provést mergování > - opět kontrola výsledků > - ... > > Pro zakreslování domů to bude také zajímavé ... nějaké poloautomatický > rozpoznávání obrysů, možnost korektur, ověřování na fotomapě, ruční > zakreslení budov, návaznost na adresní body, ... > > Možnosti pluginů do JOSM neznám, zatím ani Czechadress. Ale nemyslím, > že bude jednoduché to do toho nějak vhodně napasovat, aby s tím šlo > pohodlně pracovat. Přecijen republika je velká a tak zpracování takové > velké oblasti dá mnoho práce. Takže investice do co nejpohodlnějšího > GUI pro práci se vyplatí. Čím jednodušší to bude, tím více lidí se do > toho zapojí. Určitě jsou lidi, kteří by do toho šli, ale je to na ně > moc složité. Jak jsem pochopil, tak zatím na tom dělají vlastně jen > programátoři (nebo alespoň převážně). Přitom je tam spousta manuální > práce, která z principu programátorské schopnosti nevyžaduje, pokud by > bylo nějaké rozumné programové vybavení. > > Co je podle tebe třeba teď dělat? Mapovací soubor apod. je krátkodobý > cíl. Myslím alespoň ze střednědobého pohledu. > > Honza > > > 2010/1/24 Petr Dlouhý <petr.dlouhy na email.cz>: >> Co se týče skriptů, tak myslím, že je třeba se vydat jinou cestou. >> Pokud to jde alespoň trochu jednoduše udělat, tak by ten skript měl >> dokázat pracovat s celou mapou katastrálních území. Nemůže být problém z >> toho souboru vytáhnout pouze ty relace (ty moc nezabírají), a hranice >> tahat jen podle potřeby. >> Pokud se navíc vytvoří mapovací soubor pro celou ČR, tak to celý proces >> výrazně zjednoduší. Pro to není potřeba žádné GUI, manuální práce na >> začištění ale asi bude potřeba vždy. >> >> Co se týče pozdějších manuálních, tak na to existuje Czechaddress plugin >> do JOSM. Takže vlastně GUI. >> >> On Sun, 24 Jan 2010 02:27:55 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >> wrote: >> >>> A hlavně mým cílem je, aby celý proces byl poměrně jednoduchý ... >>> integrovaný časem do nějaké GUI, protože i když, jak tady někdo psal, >>> se to může zdát jako jednorázový proces, tak >>> >>> a) je natolik pracný, že je třeba distribuovat mezi více lidí (teď >>> nemyslím jen adresní body, ale tahání informací z katastrálních map) >>> b) informace v katastru se mění (aktualizují), takže čím více bude >>> proces automatický, tím lepší pro pozdější aktualizace >>> >>> Přecijen tohle mi přijde snadněji použitelné (i když nechci tvrdit, že >>> tam to je nějak extra složité - nevím. >>> >>> Honza >>> >>> >>> 2010/1/24 Jan Bilak <jan.bilak.osm na gmail.com>: >>>> Asi ano, ale kdyz jsem osmosis zkousel, tak vzdycky spadnul na nejakou >>>> podovnou vyjimku. Pak jsem v rychlosti dospel k zaveru, ze asi ke sve >>>> cinnosti potrebuje nejakou DB (PostreSQL apod.) ... a to se mi >>>> nechtelo instalovat ... ale treba je to spatny zaver. Moc jsem to >>>> nezkoumal. >>>> >>>> Honza >>>> >>>> >>>> 2010/1/24 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>> Není to trochu nově vynalezené kolo, když tu mám osmosis? >>>>> >>>>> [1] >>>>> http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004310.html >>>>> >>>>> On Sun, 24 Jan 2010 02:08:17 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >>>>> wrote: >>>>> >>>>>> Ahoj, udělal jsem si utilitku pro vyjmutí části území ze souboru *.osm >>>>>> mapy katastrálních území >>>>>> http://lkabrt.aspone.cz/osm/kucr.zip. >>>>>> Třeba se také někomu bude hodit (ať již jako binárka nebo zdroják k >>>>>> zakomentování do celku). >>>>>> >>>>>> Upozorňuji, že nejde o nic obecného (i když by to možná zobecnit šlo), >>>>>> ale je to dělané na míru tomuto souboru. Rychlost nemám s čím >>>>>> porovnat, na mém stroji to trvá tak 10 sekund. Dělá to všechno v >>>>>> paměti, takže to zabere pro daný konkrétní soubor asi 260 MB RAM. >>>>>> Používá to XmlTextReader a XmlTextWriter místo LINQ. >>>>>> >>>>>> Zadá se vstupní soubor, výstupní soubor a obdélník (north, west, >>>>>> south, east). Výsledný soubor obsahuje všechny >>>>>> nodes, ways a relations, které alespoň jedním nodem zasahují do daného >>>>>> obdélníku. >>>>>> >>>>>> Příklad použití: >>>>>> ExtractBoundingBox.exe -north 50.50 -west 16.10278129 -south 50.49 >>>>>> -east 16.123 -input "kucr-jmena.osm" -output kucr-part.osm >>>>>> >>>>>> Ke stažení: >>>>>> http://jabi.aspone.cz/osm/ExtractBoundingBox-bin.rar (binárka pro >>>>>> .NET) >>>>>> http://jabi.aspone.cz/osm/ExtractBoundingBox-src.rar (zdrojáky v C#) >>>>>> >>>>>> Použil jsem k tomu parser parametrů z CUZK.Common.dll, snad autor >>>>>> nebude >>>>>> proti. >>>>>> >>>>>> Honza >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >

> > "Veškeré údaje na internetových stránkách ČSÚ si může kdokoliv převzít > pro své účely bezplatně, pouze s podmínkou, že uvede jako zdroj ČSÚ. > Je doporučováno uvádět i datum, kdy údaje byly převzaty."

> Já nemyslel GUI v tom smyslu, že tam bude 5 tlačítek a ty budou > spouštět tyhle skripty. Ale co je třeba dělat?

> > Pro adresní body: > - vybrat území, které mne zajímá (zajímavá informace zde bude, co už > je hotové a co nikoli ... zatím není skoro nic, ale časem...) > - automaticky stáhnou potřebná data (mapování, adresy, hranice kat. > území, dlaždice) a OCRovat > - pak je třeba manuální kontrola mapování, adres, výsledku OCRu - > zejména pro kontrolu OCRu se hodí možnost v GUI si zobrazit daný text > v podobě výřezu obrázku (zcela automaticky, aniž bych musel něco > složitě někde hledat či zadávát) > - automaticky provést mergování > - opět kontrola výsledků > - ... >

> Pro zakreslování domů to bude také zajímavé ... nějaké poloautomatický > rozpoznávání obrysů, možnost korektur, ověřování na fotomapě, ruční > zakreslení budov, návaznost na adresní body, ... >

> Možnosti pluginů do JOSM neznám, zatím ani Czechadress. Ale nemyslím, > že bude jednoduché to do toho nějak vhodně napasovat, aby s tím šlo > pohodlně pracovat. Přecijen republika je velká a tak zpracování takové > velké oblasti dá mnoho práce. Takže investice do co nejpohodlnějšího > GUI pro práci se vyplatí. Čím jednodušší to bude, tím více lidí se do > toho zapojí. Určitě jsou lidi, kteří by do toho šli, ale je to na ně > moc složité. Jak jsem pochopil, tak zatím na tom dělají vlastně jen > programátoři (nebo alespoň převážně). Přitom je tam spousta manuální > práce, která z principu programátorské schopnosti nevyžaduje, pokud by > bylo nějaké rozumné programové vybavení.

> Co je podle tebe třeba teď dělat? Mapovací soubor apod. je krátkodobý > cíl. Myslím alespoň ze střednědobého pohledu. > > Honza >

> (mé velmi hrubé odhady se pohybují od 50 do 100 hodin jenom pro 2. fázi).

> Asi ano, ale kdyz jsem osmosis zkousel, tak vzdycky spadnul na nejakou > podovnou vyjimku. Pak jsem v rychlosti dospel k zaveru, ze asi ke sve > cinnosti potrebuje nejakou DB (PostreSQL apod.) ... a to se mi > nechtelo instalovat ... ale treba je to spatny zaver. Moc jsem to > nezkoumal.

> Co se týče skriptů, tak myslím, že je třeba se vydat jinou cestou. > Pokud to jde alespoň trochu jednoduše udělat, tak by ten skript měl > dokázat pracovat s celou mapou katastrálních území.

> Pardon, myslel jsem dní. > > On Sun, 24 Jan 2010 08:46:16 +0100, Petr Dlouhý <petr.dlouhy na email.cz> > wrote: > >> (mé velmi hrubé odhady se pohybují od 50 do 100 hodin jenom pro 2. fázi).

> Jestli myslis cisteho vypocetniho casu, tak bych rekl, ze je to > pesimisticky odhad. Podle toho, jak rychle probiha vypocet u me, bych > to odhadnul na 30 - 50 dni. Limitujici je tady rychlost procesoru. > Nedavno jsem zkousel oblast cca 20 x 25 km a rozpoznavani bezelo neco > pres 5 hodin. Muj pocitac pritom neni zadne "delo" - Intel Core2 Duo @ > 2Ghz.

> To docela odpovídá. Já mám počítač ještě pomalejší, jednojádrový a podle > něj jsem to odhadoval. > Každopádně je to poměrně dost, a chtělo by to možná zapojit i ty, kdo mají > dost procesorového a málo osobního času. > > On Sun, 24 Jan 2010 10:53:38 +0100, Lukas Kabrt<lukas na kabrt.cz> wrote: > > >> Jestli myslis cisteho vypocetniho casu, tak bych rekl, ze je to >> pesimisticky odhad. Podle toho, jak rychle probiha vypocet u me, bych >> to odhadnul na 30 - 50 dni. Limitujici je tady rychlost procesoru. >> Nedavno jsem zkousel oblast cca 20 x 25 km a rozpoznavani bezelo neco >> pres 5 hodin. Muj pocitac pritom neni zadne "delo" - Intel Core2 Duo @ >> 2Ghz. >> > >

> To docela odpovídá. Já mám počítač ještě pomalejší, jednojádrový a podle > něj jsem to odhadoval. > Každopádně je to poměrně dost, a chtělo by to možná zapojit i ty, kdo mají > dost procesorového a málo osobního času. > > On Sun, 24 Jan 2010 10:53:38 +0100, Lukas Kabrt<lukas na kabrt.cz> wrote: > >> Jestli myslis cisteho vypocetniho casu, tak bych rekl, ze je to >> pesimisticky odhad. Podle toho, jak rychle probiha vypocet u me, bych >> to odhadnul na 30 - 50 dni. Limitujici je tady rychlost procesoru. >> Nedavno jsem zkousel oblast cca 20 x 25 km a rozpoznavani bezelo neco >> pres 5 hodin. Muj pocitac pritom neni zadne "delo" - Intel Core2 Duo @ >> 2Ghz. > >

> Mam malo osobniho casu, ale jsem schopen pripravit virtualni masinu s > debianem pro zajemce, ktery to uchodi. Je tam 2x2.8GHz XEON a 4GB > pameti. Pokud by to pomohlo...

> Mam malo osobniho casu, ale jsem schopen pripravit virtualni masinu s > debianem pro zajemce, ktery to uchodi. Je tam 2x2.8GHz XEON a 4GB > pameti. Pokud by to pomohlo... > > K > > Dne 24.1.2010 10:58, Petr Dlouhý napsal(a): >> To docela odpovídá. Já mám počítač ještě pomalejší, jednojádrový a podle >> něj jsem to odhadoval. >> Každopádně je to poměrně dost, a chtělo by to možná zapojit i ty, kdo >> mají >> dost procesorového a málo osobního času. >>

> Háček je v tom "bezplatně". U OSM nikdo nezakazuje, aby byla data > prodávána. Je otázka, zdali se ale nejedná o úřední dílo - v tom případě > by si ČSÚ takové podmínky diktovat asi nemohl. > > On Sun, 24 Jan 2010 04:46:05 +0100, Jan Bilak <jan.bilak.osm na gmail.com> > wrote: > >> >> "Veškeré údaje na internetových stránkách ČSÚ si může kdokoliv převzít >> pro své účely bezplatně, pouze s podmínkou, že uvede jako zdroj ČSÚ. >> Je doporučováno uvádět i datum, kdy údaje byly převzaty." > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

>> Pardon, myslel jsem dní. >> >> On Sun, 24 Jan 2010 08:46:16 +0100, Petr Dlouhý <petr.dlouhy na email.cz> >> wrote: >> >>> (mé velmi hrubé odhady se pohybují od 50 do 100 hodin jenom pro 2. fázi). > > Jestli myslis cisteho vypocetniho casu, tak bych rekl, ze je to > pesimisticky odhad. Podle toho, jak rychle probiha vypocet u me, bych > to odhadnul na 30 - 50 dni. Limitujici je tady rychlost procesoru. > Nedavno jsem zkousel oblast cca 20 x 25 km a rozpoznavani bezelo neco > pres 5 hodin. Muj pocitac pritom neni zadne "delo" - Intel Core2 Duo @ > 2Ghz. > > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Já myslím, že hodně času žere spouštění nového procesu pro OCR. Pokud > lze OCRu předhodit obrázek, který bude obsahovat více textů (a pak > rozpoznat, co je co), nebo mu předhodit více obrázků (vícestránkový > dokument), tak by to mohlo jít rychleji. Přecijen OCRka se běžně > použivají na čtení hustého textu na A4 a s rozpoznání trvá chvilku. > > Honza > > > Dne 24. ledna 2010 10:53 Lukas Kabrt <lukas na kabrt.cz> napsal(a): >>> Pardon, myslel jsem dní. >>> >>> On Sun, 24 Jan 2010 08:46:16 +0100, Petr Dlouhý <petr.dlouhy na email.cz> >>> wrote: >>> >>>> (mé velmi hrubé odhady se pohybují od 50 do 100 hodin jenom pro 2. fázi). >> >> Jestli myslis cisteho vypocetniho casu, tak bych rekl, ze je to >> pesimisticky odhad. Podle toho, jak rychle probiha vypocet u me, bych >> to odhadnul na 30 - 50 dni. Limitujici je tady rychlost procesoru. >> Nedavno jsem zkousel oblast cca 20 x 25 km a rozpoznavani bezelo neco >> pres 5 hodin. Muj pocitac pritom neni zadne "delo" - Intel Core2 Duo @ >> 2Ghz. >> >> -- >> Lukas >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >

> > Problem to neni. Kdyz jsem program vytvarel, tak jsem nevedel o tom, > ze existuje vektorizovana mapa k.u. a tak jsem k.u. kreslil rucne. > Vzdycky jen par k.u., ktere jsem chtel zpracovat. Takze me rychlost > zpracovani OSM souboru nejak netrapila. Na vektorizovanou mapu jsem > narazil az kdyz jsem mel program hotovy a jeste jsem se nedostal k > tomu ho predelat - dalsi polozka do TODO listu :-) > > Koukal jsem, ze by sla pouzit knihovna pro praci s OSM soubory z > programu Kosmos [1], takze s tim nakonec asi ani nebude tolik prace. > > [1] http://wiki.openstreetmap.org/wiki/Kosmos > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> > Problem to neni. Kdyz jsem program vytvarel, tak jsem nevedel o tom, > ze existuje vektorizovana mapa k.u. a tak jsem k.u. kreslil rucne. > Vzdycky jen par k.u., ktere jsem chtel zpracovat. Takze me rychlost > zpracovani OSM souboru nejak netrapila. Na vektorizovanou mapu jsem > narazil az kdyz jsem mel program hotovy a jeste jsem se nedostal k > tomu ho predelat - dalsi polozka do TODO listu :-) > > Koukal jsem, ze by sla pouzit knihovna pro praci s OSM soubory z > programu Kosmos [1], takze s tim nakonec asi ani nebude tolik prace. > > [1] http://wiki.openstreetmap.org/wiki/Kosmos > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Nemyslím si, že je to háček. Mluví se o bezplatném převzetí od ČSÚ > (tedy, že není za to třeba platit ČSÚ). Ale nikoli o tom, že by se > data nesměla prodávat (bezplatných produktech, kde budou data použita, > nekomerční účely apod.).

> A ČSÚ má mimo jiné na svých stránkách i mapy ... ale většina věcí je > tam stejná s katastrem. Např.: > http://apl.czso.cz/irso/mapa.jsp?budId=207400&obrprvId=184459

> To docela odpovídá. Já mám počítač ještě pomalejší, jednojádrový a podle > něj jsem to odhadoval. > Každopádně je to poměrně dost, a chtělo by to možná zapojit i ty, kdo mají > dost procesorového a málo osobního času.

> ------------ Původní zpráva ------------ > Od: Karel Volný <kavol na seznam.cz> > Předmět: Re: [Talk-cz] Import adres z katastralni mapy > Datum: 26.1.2010 10:50:35 > ---------------------------------------- > Dne Ne 24. ledna 2010 Petr Dlouhý napsal(a): > > To docela odpovídá. Já mám počítač ještě pomalejší, jednojádrový a podle > > něj jsem to odhadoval. > > Každopádně je to poměrně dost, a chtělo by to možná zapojit i ty, kdo mají > > dost procesorového a málo osobního času. > > já se taky hlásím, jestli je to ještě aktuální ... Core i5, bohužel s KVM mi > qemu řve, že umí jen jeden procesor, a bez KVM je to neskutečně pomalé ... ale > jestli se to dá rozumně rozdělit, klidně si ty virtuální mašiny pustím tři :) > > K. > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

> Jinak to Qemu je kvůli bezpečnosti? Ten program totiž jinak na Linuxu > chodí.

> Tak jsem trochu zapracoval na mape katastralnich uzemi, aby se k.u. > nemuseli kreslit rucne. > > Vektorizovanou mapu k.u. od hanoje [1] jsem zacistil (slouceni > duplicitnich bodu, odtraneni fragmentu po vektorizaci, pospojovani > prerusenych linii) a vytvoril na ni relace pro jednotliva k.u. > > Mapu jsem dal dohromady s daty co mi poslal Martin Kupec (nazvy > katastralnich uzemi a jejich poloha). Vysledek je ke stazeni tady [2]. > > Trocha statistiky: > CR ma 13027 k.u. > Martin mi poslal data pro 12171 k.u. > Mapa ma definovano 13028 relaci > > Mapa je jenom prozatmni, pri prirazeni se vyskytly nejake chyby (vic > nazvu pro jedno k.u., jedna se ale o jednotky, max. desitky pripadu) > To bych resil az budou hotova data pro vsechy k.u. Stejne tak je v > mape 1 relace navic - pravdepodobne nekde zustal nejaky fragment, ten > se taky objevi, az se priradi vsechny nazvy. > > Pokud se nekdo pousti do importu adres, tak mu tohle snad usetri trochu casu. > > [1] http://osm.templ.net/kucr.osm.bz2 > [2] http://lkabrt.aspone.cz/osm/kucr.zip

> ------------ Původní zpráva ------------ > Od: Pavel Machek <pavel na ucw.cz> > Předmět: Re: [Talk-cz] Import adres z katastralni mapy > Datum: 26.1.2010 14:58:51 > ---------------------------------------- > On Thu 2010-01-21 16:50:15, Lukas Kabrt wrote: > > Tak jsem trochu zapracoval na mape katastralnich uzemi, aby se k.u. > > nemuseli kreslit rucne. > > > > Vektorizovanou mapu k.u. od hanoje [1] jsem zacistil (slouceni > > duplicitnich bodu, odtraneni fragmentu po vektorizaci, pospojovani > > prerusenych linii) a vytvoril na ni relace pro jednotliva k.u. > > > > Mapu jsem dal dohromady s daty co mi poslal Martin Kupec (nazvy > > katastralnich uzemi a jejich poloha). Vysledek je ke stazeni tady [2]. > > > > Trocha statistiky: > > CR ma 13027 k.u. > > Martin mi poslal data pro 12171 k.u. > > Mapa ma definovano 13028 relaci > > > > Mapa je jenom prozatmni, pri prirazeni se vyskytly nejake chyby (vic > > nazvu pro jedno k.u., jedna se ale o jednotky, max. desitky pripadu) > > To bych resil az budou hotova data pro vsechy k.u. Stejne tak je v > > mape 1 relace navic - pravdepodobne nekde zustal nejaky fragment, ten > > se taky objevi, az se priradi vsechny nazvy. > > > > Pokud se nekdo pousti do importu adres, tak mu tohle snad usetri trochu casu. > > > > [1] http://osm.templ.net/kucr.osm.bz2 > > [2] http://lkabrt.aspone.cz/osm/kucr.zip > > Jaky je dalsi plan? Upload do osm? Nebo se jeste budou nejak cistit? > > Pavel > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

> Provedl jsem par zmen v programu tile-processor, binarky [1] i > zdrojove kody [2] muzete stahovat z mych stranek. > > Hlavni zmeny: > rychlost - OCR utitlita se ted spousti pouze jednou pro kazdou > dlazdici - prineslo to cca dvojnasobnou rychlost zpracovani > drobne zvyseni presnosti - presnejsi orez popisku a vynechani budov > blizko praveho okraje (tak jak navrhoval Petr Dlouhy) > pridano logovani cinnosti > osetreni chyb - program by se ted mel byt schopny zotavit z vetsiny > chyb, pouze zaloguje co se stalo a pokracuje v cinnosti > > V binarkach jsou dve verze tile processoru - jedna pro LINUX s upravou > od Petra Dlouheho ([3], bod 2), druha bez ni. Nechal jsem dve verze, > protoze u me verze s upravou dava o neco horsi vysledky pri OCR (cca o > 1 - 2% vice chyb) > > Progam jsem zkousel na platforme Win/.NET a Win/MONO a funguji bez > problemu. Nekoho bych poprosil aby vyzkousel jestli neni nejaky > problem na Linuxu. > > > Distribuovane pocitani > Diky vsem, kteri se ozvali a nabidli se, ze pomuzou s vypoctem. > > Rozdelil jsem CR na dlazdice 0.2 x 0.2 stupne, celkem je to 302 > dlazdic. Hranice jsou definovany v CSV souboru [4], prilozena je i > prehledova mapka. Zpracovani jedne dlazdice by se melo vejit do 1 > hodiny. > > CSV soubor ma nasledujici format > ID,sever,vychod,jih,zapad > > Pro koordinaci jsem na wiki zalozil stranku [5]. Pokud se rozhodnete > pomoct, zapiste na wiki, jake dlazdice zpracujete - at se neco > nepocita vicekrat. Dlazdice prosim vybirejte postupne, at v tom neni > zmatek. > > Moje idea dalsiho postupu je takova, ze vysledky vypoctu (CSV a LOG > soubory) zpracuju, pripadne opravim data na mistech, kde se vyskytnul > nejaky error a vysledek umistim nekde na web k dalsimu vyuziti pro > import adres. > > Postup > 1) na wiki napsat dlazdice, ktere se chystam zpracovat > 2) ze souboru [4] zjistit hranice dlazdic > 3) stahnout data z WMS CUZK > > tile-downloader.exe -north [sever] -west [zapad] -south [jih] -east > [vychos] -addressPoints -output [ID-Dlazdice] > > 4) zpracovat dlazdici > > tile-processor.exe -tiles [ID-Dlazdice] - output [ID-Dlazdice].csv > > 5) zabalit vytvorene soubory (CSV a LOG) a vysledek nekam uplodovat > nebo zaslat na mail osm na kabrt.cz > > [1] http://lkabrt.aspone.cz/osm/cuzk.zip > [2] http://lkabrt.aspone.cz/osm/cuzk-source.zip > [3] http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004312.html > [4] http://lkabrt.aspone.cz/osm/oblasti.zip > [5] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR/Prubeh_Zpracovani > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> V binarkach jsou dve verze tile processoru - jedna pro LINUX s upravou > od Petra Dlouheho ([3], bod 2), druha bez ni. Nechal jsem dve verze, > protoze u me verze s upravou dava o neco horsi vysledky pri OCR (cca o > 1 - 2% vice chyb)

> Progam jsem zkousel na platforme Win/.NET a Win/MONO a funguji bez > problemu. Nekoho bych poprosil aby vyzkousel jestli neni nejaky > problem na Linuxu.

> Tomu moc nerozumím, můj postup byl takový, že jsem vyříznul z dlaždice > číslo (což by měla být bezestrátová konverze) a potom jsem to zvětšil (což > by měla být stejná konverze jako předtím. Postup by mohl být nepatrně > náročnější na výpočetní výkon, ale výsledek by snad měl být stejný, ne? > Leda že by tam došlo k nějaké ztrátě při převodu mezi různými počty barev > - to by šlo asi eliminovat.

> nebylo by lepší ukládat a přibalit potom k výsledku i kousky mapy s > těmi čísly? Zrychlila by se ruční kontrola, zda to OCR rozpoznal > správně. Aneb bylo by možné pak jednoduše třeba zobrazit číslo v > textové podobě a vedle číslo v obrázkové podobě. A stejně už se to > stahuje, ořezává, ... jen to ukládat.

>> nebylo by lepší ukládat a přibalit potom k výsledku i kousky mapy s >> těmi čísly? Zrychlila by se ruční kontrola, zda to OCR rozpoznal >> správně. Aneb bylo by možné pak jednoduše třeba zobrazit číslo v >> textové podobě a vedle číslo v obrázkové podobě. A stejně už se to >> stahuje, ořezává, ... jen to ukládat. > > Technicky to neni zadny problem, ale moc se mi to nelibi > 1) Je to spousta dat > 2) Kontorlovat se to da dobre v JOSM (nebo v jinem editoru), vcetne > doplneni prislusnych addr tagu > 3) Stejne vetsina spatne rozpoznanych popisku jsou budovy bez > c.p./c.e., jako treba garaze nahustene vedle sebe - v editoru pak > jednim pohledem a par kliknutima vyresim treba 30 spatne rozpoznanych > napisu najednou > > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Při zkusmém zpracování oblasti 4 se zdá že mi nějak nefunguje > rozpoznávání. Výsledný csv je prázdný a v logu errory podobné tomuto: > > [ERROR] Tile: 4\14.8270_50.8700_14.8320_50.8750-budovy.png      Could not > find file 'E:\cuzk\5d8577a6-a71a-454b-9785-354a446ef9d5.tif.txt'.; > > přitom stažené obrázky jsou v pořádku, tile processor se tváří že také > něco dělá: > > Performing OCR (25 labels): .Processing tile: > 15.0250_51.0185_15.0300_51.0235-budovy    .. > Performing OCR (4 labels): .Processing tile: > 15.0250_51.0230_15.0300_51.0280-budovy     . > Processing tile: 15.0250_51.0275_15.0300_51.0325-budovy

> To mas pravdu, asi jsem blbe identifikoval pricinu. Pravy duvod je asi > ten, ze ty jsi vyrezy zvetsoval 3x a ja jen 2x. Tesseract si to potom > pravdepodobne prebere trochu jinak. Pravdou je, ze obcas lepe > zafunguje ta upravena verze. Kdyz to porovnam u nejakeho vetsiho > souboru dat, tak to vychazi priblezne 1 az 2% v neprospech upravene

> 2010/1/26 Jiri Parkan <jparkan na gmail.com>: >> Při zkusmém zpracování oblasti 4 se zdá že mi nějak nefunguje >> rozpoznávání. Výsledný csv je prázdný a v logu errory podobné tomuto: >> >> [ERROR] Tile: 4\14.8270_50.8700_14.8320_50.8750-budovy.png      Could not >> find file 'E:\cuzk\5d8577a6-a71a-454b-9785-354a446ef9d5.tif.txt'.; >> >> přitom stažené obrázky jsou v pořádku, tile processor se tváří že také >> něco dělá: >> >> Performing OCR (25 labels): .Processing tile: >> 15.0250_51.0185_15.0300_51.0235-budovy    .. >> Performing OCR (4 labels): .Processing tile: >> 15.0250_51.0230_15.0300_51.0280-budovy     . >> Processing tile: 15.0250_51.0275_15.0300_51.0325-budovy > > To vypada, ze nefunguje OCR utilita, muzes vyzkouset spustit rucne? > > "tesseract jmeno_jednoho_z_tech_tifu output.txt -l cuzk" > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Mam malo osobniho casu, ale jsem schopen pripravit virtualni masinu s > debianem pro zajemce, ktery to uchodi. Je tam 2x2.8GHz XEON a 4GB > pameti. Pokud by to pomohlo... > > K > > Dne 24.1.2010 10:58, Petr Dlouhý napsal(a): > >> To docela odpovídá. Já mám počítač ještě pomalejší, jednojádrový a podle >> něj jsem to odhadoval. >> Každopádně je to poměrně dost, a chtělo by to možná zapojit i ty, kdo mají >> dost procesorového a málo osobního času. >> >> On Sun, 24 Jan 2010 10:53:38 +0100, Lukas Kabrt<lukas na kabrt.cz> wrote: >> >> >> >>> Jestli myslis cisteho vypocetniho casu, tak bych rekl, ze je to >>> pesimisticky odhad. Podle toho, jak rychle probiha vypocet u me, bych >>> to odhadnul na 30 - 50 dni. Limitujici je tady rychlost procesoru. >>> Nedavno jsem zkousel oblast cca 20 x 25 km a rozpoznavani bezelo neco >>> pres 5 hodin. Muj pocitac pritom neni zadne "delo" - Intel Core2 Duo @ >>> 2Ghz. >>> >>> >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Provedl jsem par zmen v programu tile-processor, binarky [1] i > zdrojove kody [2] muzete stahovat z mych stranek. > > Hlavni zmeny: > rychlost - OCR utitlita se ted spousti pouze jednou pro kazdou > dlazdici - prineslo to cca dvojnasobnou rychlost zpracovani > drobne zvyseni presnosti - presnejsi orez popisku a vynechani budov > blizko praveho okraje (tak jak navrhoval Petr Dlouhy) > pridano logovani cinnosti > osetreni chyb - program by se ted mel byt schopny zotavit z vetsiny > chyb, pouze zaloguje co se stalo a pokracuje v cinnosti > > V binarkach jsou dve verze tile processoru - jedna pro LINUX s upravou > od Petra Dlouheho ([3], bod 2), druha bez ni. Nechal jsem dve verze, > protoze u me verze s upravou dava o neco horsi vysledky pri OCR (cca o > 1 - 2% vice chyb) > > Progam jsem zkousel na platforme Win/.NET a Win/MONO a funguji bez > problemu. Nekoho bych poprosil aby vyzkousel jestli neni nejaky > problem na Linuxu. > > > Distribuovane pocitani > Diky vsem, kteri se ozvali a nabidli se, ze pomuzou s vypoctem. > > Rozdelil jsem CR na dlazdice 0.2 x 0.2 stupne, celkem je to 302 > dlazdic. Hranice jsou definovany v CSV souboru [4], prilozena je i > prehledova mapka. Zpracovani jedne dlazdice by se melo vejit do 1 > hodiny. > > CSV soubor ma nasledujici format > ID,sever,vychod,jih,zapad > > Pro koordinaci jsem na wiki zalozil stranku [5]. Pokud se rozhodnete > pomoct, zapiste na wiki, jake dlazdice zpracujete - at se neco > nepocita vicekrat. Dlazdice prosim vybirejte postupne, at v tom neni > zmatek. > > Moje idea dalsiho postupu je takova, ze vysledky vypoctu (CSV a LOG > soubory) zpracuju, pripadne opravim data na mistech, kde se vyskytnul > nejaky error a vysledek umistim nekde na web k dalsimu vyuziti pro > import adres. > > Postup > 1) na wiki napsat dlazdice, ktere se chystam zpracovat > 2) ze souboru [4] zjistit hranice dlazdic > 3) stahnout data z WMS CUZK > > tile-downloader.exe -north [sever] -west [zapad] -south [jih] -east > [vychos] -addressPoints -output [ID-Dlazdice] > > 4) zpracovat dlazdici > > tile-processor.exe -tiles [ID-Dlazdice] - output [ID-Dlazdice].csv > > 5) zabalit vytvorene soubory (CSV a LOG) a vysledek nekam uplodovat > nebo zaslat na mail osm na kabrt.cz > > [1] http://lkabrt.aspone.cz/osm/cuzk.zip > [2] http://lkabrt.aspone.cz/osm/cuzk-source.zip > [3] > http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004312.html > [4] http://lkabrt.aspone.cz/osm/oblasti.zip > [5] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR/Prubeh_Zpracovani > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Je to tak? Pokud ano, tak by to chtělo uživatele důrazně varovat, protože > by se mohlo stát, že výsledek bude pomíchaný a nikdo si toho nevšimne. > Nešlo by s tím něco udělat?

> Progam jsem zkousel na platforme Win/.NET a Win/MONO a funguji bez > problemu. Nekoho bych poprosil aby vyzkousel jestli neni nejaky > problem na Linuxu.

> Hm, tak bohužel program na Linuxu nefunguje (tedy pod Wine ano). > Důvodem je neimplementovaná metoda System.Drawing.Image.SaveAdd v Linuxové > verzi knihovny GDI+. > Má někdo nápad, jak by to šlo jednoduše obejít? > > On Tue, 26 Jan 2010 20:10:09 +0100, Lukas Kabrt <lukas na kabrt.cz> wrote: > >> Progam jsem zkousel na platforme Win/.NET a Win/MONO a funguji bez >> problemu. Nekoho bych poprosil aby vyzkousel jestli neni nejaky >> problem na Linuxu. > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Má někdo nápad, jak by to šlo jednoduše obejít?

> 2010/1/27 Petr Dlouhý <petr.dlouhy na email.cz>: >> Má někdo nápad, jak by to šlo jednoduše obejít? > > Vyzkousel jsem pouziti tiffcp jak navrhoval Jan Bilak. Na WIN mi to > funguje bez problemu. Stahovat muzete opet z mych stranek [1]. Je to o > neco pomalejsi, nez kdyz mutli-page tiff vytvarim primo v > tile-processor, ale pokud to bude fungovat na LINUXU, tak je to > prijatelna obet. Porad je to totiz rychlejsi, nez puvodni verze. > > [1] http://lkabrt.aspone.cz/osm/cuzk-test.zip > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Moje idea dalsiho postupu je takova, ze vysledky vypoctu (CSV a LOG > soubory) zpracuju, pripadne opravim data na mistech, kde se vyskytnul > nejaky error a vysledek umistim nekde na web k dalsimu vyuziti pro > import adres.

>        uz jsem skoro dopracoval svoje davky, ale nastal maly problem. > >        v tech cca 80 tile je cca 850 erroru v logach. Mam to nejak >        resit, nebo uz si je zkusis udelat znova sam? > >        Vypada to ze tesseract sem tam nejak spadl nebo neco takoveho >        provedl.

> >        uz jsem skoro dopracoval svoje davky, ale nastal maly problem. > > > >        v tech cca 80 tile je cca 850 erroru v logach. Mam to nejak > >        resit, nebo uz si je zkusis udelat znova sam? > > > >        Vypada to ze tesseract sem tam nejak spadl nebo neco takoveho > >        provedl. > > Resit to nijak nemusis, uz jsem si napsal skriptik, ktery projde logy > a mista kde se vyskytnul error zpracuje znova.

> ------------ Původní zpráva ------------ > Od: Lukas Kabrt <lukas na kabrt.cz> > Předmět: Re: [Talk-cz] Import adres z katastralni mapy > Datum: 02.2.2010 10:05:16 > ---------------------------------------- > >        uz jsem skoro dopracoval svoje davky, ale nastal maly problem. > > > >        v tech cca 80 tile je cca 850 erroru v logach. Mam to nejak > >        resit, nebo uz si je zkusis udelat znova sam? > > > >        Vypada to ze tesseract sem tam nejak spadl nebo neco takoveho > >        provedl. > > Resit to nijak nemusis, uz jsem si napsal skriptik, ktery projde logy > a mista kde se vyskytnul error zpracuje znova. > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

> přemýšlel jsem o tom, jestli by nešel vyrobit i skript, co projde všechny adresní body, které nevyhovují vzoru č.e./č.p./bez č.e./č.p a zpracoval je znovu s vyšším rozlišením.

> Tak jsem uploadoval na server vysledky, odkaz je na wiki ([1]). > > Nevim jak je to se zpracovanim zbylych tilu, ale kdyz mi nekdo neco > uvolni, tak to klidne jeste spocitam :-). Zjistil jsem ze ten stoj co > jsem na to zneuzil se nejak moc zbytecne flaka... > > [1] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR/Prubeh_Zpracovani > > Martin Kupec > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Tak jsem uploadoval na server vysledky, odkaz je na wiki ([1]). > > Nevim jak je to se zpracovanim zbylych tilu, ale kdyz mi nekdo neco > uvolni, tak to klidne jeste spocitam :-). Zjistil jsem ze ten stoj co > jsem na to zneuzil se nejak moc zbytecne flaka... > > [1] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR/Prubeh_Zpracovani > > Martin Kupec > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Ahoj, > > můžeš kdyžtak udělat 10 - 49 a 60 - 69 ještě jednou? Já to dělal ještě se > starou verzí tile-processoru, takže chybí logy.

> Tak jsem uploadoval na server vysledky, odkaz je na wiki ([1]). > > Nevim jak je to se zpracovanim zbylych tilu, ale kdyz mi nekdo neco > uvolni, tak to klidne jeste spocitam :-). Zjistil jsem ze ten stoj co > jsem na to zneuzil se nejak moc zbytecne flaka... > > [1] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR/Prubeh_Zpracovani > > Martin Kupec > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Ahoj, > > tak na Kubajzově stroji je (po kratší odstávce) už taky vše spočítané a > uploadované. > > On Tue, 02 Feb 2010 22:52:06 +0100, Martin Kupec <magon na jkopava.cz> > wrote: > >> Tak jsem uploadoval na server vysledky, odkaz je na wiki ([1]). >> >> Nevim jak je to se zpracovanim zbylych tilu, ale kdyz mi nekdo neco >> uvolni, tak to klidne jeste spocitam :-). Zjistil jsem ze ten stoj co >> jsem na to zneuzil se nejak moc zbytecne flaka... >> >> [1] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR/Prubeh_Zpracovani >> >> Martin Kupec >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > >

> Ahoj, > > začal jsem s imortem adresních bodů v Praze-západ, ale zjistil jsem jeden > celkem zásadní problém. > Zdá se, že evidenční čísla jsou o něco blíž k tečce než ta popisná - > důsledkem je to, že pokud je v čísle číslice 2, tak se občas stane, že jí > to rozezná jako 7. Těch případů je tolik, že dělat to ručně pro celou ČR > by byla nepředstavitelná práce (nehledě na to, že by se to špatně > přiřadilo) - bylo by tedy dobré vyřešit to nějak automaticky. > > Otázka je jak problém vyřešit. Asi nejlepší bude znovu rozpoznat ty > evidenční čísla, ve kterých je 7 - byl by to tedy stejný problém jako jsem > už navrhoval s čísly, která nebyla rozpoznána vůbec. Máš na to Lukáši > skript, nebo ho mám vyrobit? > > On Wed, 10 Feb 2010 01:48:34 +0100, Petr Dlouhý <petr.dlouhy na email.cz> > wrote: > >> Ahoj, >> >> tak na Kubajzově stroji je (po kratší odstávce) už taky vše spočítané a >> uploadované. >> >> On Tue, 02 Feb 2010 22:52:06 +0100, Martin Kupec <magon na jkopava.cz> >> wrote: >> >>> Tak jsem uploadoval na server vysledky, odkaz je na wiki ([1]). >>> >>> Nevim jak je to se zpracovanim zbylych tilu, ale kdyz mi nekdo neco >>> uvolni, tak to klidne jeste spocitam :-). Zjistil jsem ze ten stoj co >>> jsem na to zneuzil se nejak moc zbytecne flaka... >>> >>> [1] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR/Prubeh_Zpracovani >>> >>>      Martin Kupec >>> >>> >>> _______________________________________________ >>> 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 >

> Ahoj, > > ještě jsem si říkal, že možná nebylo špatné rozpoznávání dělat na > základě podobnosti vzoru jednotlivých číslic. Když je to psané jedním > fontem, jednou velikostí, vždy stejně natočené a bez nějakých kazů > vzniklým skenováním, tak by tato metoda musela být vysoce spolehlivá. > Dokonce podle pozorování jsou znaky zarovnané na celé pixely (ale mohu > se plést - koukal jsem na to jen letmo). > > Výhoda je v tom, že je to metoda prakticky zcela spolehlivá. Pokud > text něco překrývá, tak to odhalí (neshoduje se s žádným vzorem > číslice/písmena). Pokud se naopak znak shoduje se vzorem, tak je > prakticky jisté, že jde o tento znak. Teoreticky by nějaký jiný objekt > mohl udělat např. z písmene I písmeno T, ale aby to zcela přesně > odpovídalo vzoru, to je podle mne menší pravděpodobnost, než vyhrát > první cenu v nějaké loterii. > > Algoritmus rozpoznávání by přitom byl myslím velmi jednoduše > naprogramovatelný, rychlý a nepotřeboval by nějaké externí OCRy. To se > sice může zdát jako zbytečnost, ale mělo by to význam při > aktualizacích. Tedy nyní se celý import pojal jako jednorázový import. > Ale data se budou měnit a nebylo by od věci, kdyby se periodicky našly > změny, doplnila nová čísla domů apod. > > Zkusím to ověřit na příkladu. > > Honza > > > 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: >> Ahoj, >> >> začal jsem s imortem adresních bodů v Praze-západ, ale zjistil jsem >> jeden >> celkem zásadní problém. >> Zdá se, že evidenční čísla jsou o něco blíž k tečce než ta popisná - >> důsledkem je to, že pokud je v čísle číslice 2, tak se občas stane, že >> jí >> to rozezná jako 7. Těch případů je tolik, že dělat to ručně pro celou ČR >> by byla nepředstavitelná práce (nehledě na to, že by se to špatně >> přiřadilo) - bylo by tedy dobré vyřešit to nějak automaticky. >> >> Otázka je jak problém vyřešit. Asi nejlepší bude znovu rozpoznat ty >> evidenční čísla, ve kterých je 7 - byl by to tedy stejný problém jako >> jsem >> už navrhoval s čísly, která nebyla rozpoznána vůbec. Máš na to Lukáši >> skript, nebo ho mám vyrobit? >> >> On Wed, 10 Feb 2010 01:48:34 +0100, Petr Dlouhý <petr.dlouhy na email.cz> >> wrote: >> >>> Ahoj, >>> >>> tak na Kubajzově stroji je (po kratší odstávce) už taky vše spočítané a >>> uploadované. >>> >>> On Tue, 02 Feb 2010 22:52:06 +0100, Martin Kupec <magon na jkopava.cz> >>> wrote: >>> >>>> Tak jsem uploadoval na server vysledky, odkaz je na wiki ([1]). >>>> >>>> Nevim jak je to se zpracovanim zbylych tilu, ale kdyz mi nekdo neco >>>> uvolni, tak to klidne jeste spocitam :-). Zjistil jsem ze ten stoj co >>>> jsem na to zneuzil se nejak moc zbytecne flaka... >>>> >>>> [1] >>>> http://wiki.openstreetmap.org/wiki/Import_Adres_ČR/Prubeh_Zpracovani >>>> >>>> Martin Kupec >>>> >>>> >>>> _______________________________________________ >>>> 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

> Ahoj, > > to by možná fungovalo líp, ale je otázka, jestli to stojí za tu práci, > když už mám funkční program. > > Ty změny se samozřejmě časem budou muset udělat, takže by to určitě nebyla > zbytečná práce. Zajímavý by byl taky nějaký obecný diff plugin pro JOSM. > > On Thu, 11 Feb 2010 18:29:27 +0100, Jan Bilak <jan.bilak.osm na gmail.com> > wrote: > >> Ahoj, >> >> ještě jsem si říkal, že možná nebylo špatné rozpoznávání dělat na >> základě podobnosti vzoru jednotlivých číslic. Když je to psané jedním >> fontem, jednou velikostí, vždy stejně natočené a bez nějakých kazů >> vzniklým skenováním, tak by tato metoda musela být vysoce spolehlivá. >> Dokonce podle pozorování jsou znaky zarovnané na celé pixely (ale mohu >> se plést - koukal jsem na to jen letmo). >> >> Výhoda je v tom, že je to metoda prakticky zcela spolehlivá. Pokud >> text něco překrývá, tak to odhalí (neshoduje se s žádným vzorem >> číslice/písmena). Pokud se naopak znak shoduje se vzorem, tak je >> prakticky jisté, že jde o tento znak. Teoreticky by nějaký jiný objekt >> mohl udělat např. z písmene I písmeno T, ale aby to zcela přesně >> odpovídalo vzoru, to je podle mne menší pravděpodobnost, než vyhrát >> první cenu v nějaké loterii. >> >> Algoritmus rozpoznávání by přitom byl myslím velmi jednoduše >> naprogramovatelný, rychlý a nepotřeboval by nějaké externí OCRy. To se >> sice může zdát jako zbytečnost, ale mělo by to význam při >> aktualizacích. Tedy nyní se celý import pojal jako jednorázový import. >> Ale data se budou měnit a nebylo by od věci, kdyby se periodicky našly >> změny, doplnila nová čísla domů apod. >> >> Zkusím to ověřit na příkladu. >> >> Honza >> >> >> 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: >>> Ahoj, >>> >>> začal jsem s imortem adresních bodů v Praze-západ, ale zjistil jsem >>> jeden >>> celkem zásadní problém. >>> Zdá se, že evidenční čísla jsou o něco blíž k tečce než ta popisná - >>> důsledkem je to, že pokud je v čísle číslice 2, tak se občas stane, že >>> jí >>> to rozezná jako 7. Těch případů je tolik, že dělat to ručně pro celou ČR >>> by byla nepředstavitelná práce (nehledě na to, že by se to špatně >>> přiřadilo) - bylo by tedy dobré vyřešit to nějak automaticky. >>> >>> Otázka je jak problém vyřešit. Asi nejlepší bude znovu rozpoznat ty >>> evidenční čísla, ve kterých je 7 - byl by to tedy stejný problém jako >>> jsem >>> už navrhoval s čísly, která nebyla rozpoznána vůbec. Máš na to Lukáši >>> skript, nebo ho mám vyrobit? >>> >>> On Wed, 10 Feb 2010 01:48:34 +0100, Petr Dlouhý <petr.dlouhy na email.cz> >>> wrote: >>> >>>> Ahoj, >>>> >>>> tak na Kubajzově stroji je (po kratší odstávce) už taky vše spočítané a >>>> uploadované. >>>> >>>> On Tue, 02 Feb 2010 22:52:06 +0100, Martin Kupec <magon na jkopava.cz> >>>> wrote: >>>> >>>>> Tak jsem uploadoval na server vysledky, odkaz je na wiki ([1]). >>>>> >>>>> Nevim jak je to se zpracovanim zbylych tilu, ale kdyz mi nekdo neco >>>>> uvolni, tak to klidne jeste spocitam :-). Zjistil jsem ze ten stoj co >>>>> jsem na to zneuzil se nejak moc zbytecne flaka... >>>>> >>>>> [1] >>>>> http://wiki.openstreetmap.org/wiki/Import_Adres_ČR/Prubeh_Zpracovani >>>>> >>>>>      Martin Kupec >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >

> začal jsem s imortem adresních bodů v Praze-západ, ale zjistil jsem jeden > celkem zásadní problém. > Zdá se, že evidenční čísla jsou o něco blíž k tečce než ta popisná - > důsledkem je to, že pokud je v čísle číslice 2, tak se občas stane, že jí > to rozezná jako 7. Těch případů je tolik, že dělat to ručně pro celou ČR > by byla nepředstavitelná práce (nehledě na to, že by se to špatně > přiřadilo) - bylo by tedy dobré vyřešit to nějak automaticky.

> Nešlo by program naučit správně poznávat dvojku, která splynula > s tečkou?

> Nerozumím. Problém o kterém jsem mluvil je, že to pozná dvojku, které byl > uříznut spodek jako sedmičku.

> On Thu, 11 Feb 2010 19:36:13 +0100, Stanislav Brabec <utx na penguin.cz> > wrote: > > > Nešlo by program naučit správně poznávat dvojku, která splynula > > s tečkou? > >

> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat uříznutou > dvojku? Pokud to ovšem nezvýší riziko chyby jinde.

> 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 >

> 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

> 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 >

> 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

> 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 >

> 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 >> >

> 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 >>> >> >

> 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 >>>> >>> >> >

> 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

> 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 >

> 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 >> >

> ------------ 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 > > >

> 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 >>> >> >

> 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 >

> 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 >> >

> -Č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

> 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

> Aha, tak to jsem předtím nepochopil. V tom případě se ale u některých "bez > č.p./č.e." detekují nějaké mezery nebo jiný bordel za nimi a možná jsem > viděl i případ, kdy se nějaké číslo prodloužilo o číslice, které tam > neměly být (pokusím se to najít). > > Dlaždice je na [1], je tam víc takových bodů, co se nedetekovali. > Testovací data se pokusím nahrát, je toho kolem 200MB. > > [1] > http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png > > On Sat, 13 Feb 2010 01:10:29 +0100, Jan Bilak <jan.bilak.osm na gmail.com> > wrote: > >> 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 > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Aha, tak to jsem předtím nepochopil. V tom případě se ale u některých "bez > č.p./č.e." detekují nějaké mezery nebo jiný bordel za nimi a možná jsem > viděl i případ, kdy se nějaké číslo prodloužilo o číslice, které tam > neměly být (pokusím se to najít). > > Dlaždice je na [1], je tam víc takových bodů, co se nedetekovali. > Testovací data se pokusím nahrát, je toho kolem 200MB. > > [1] > http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png > > On Sat, 13 Feb 2010 01:10:29 +0100, Jan Bilak <jan.bilak.osm na gmail.com> > wrote: > >> 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 > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Ano, to prodloužení o něco bude řešit ta kontrola (už je celkem jedno, > zda prodloužení čísla nebo popisu "bez č.p./č.e.". Tedy alespoň jsem o > tom přesvědčen. Do vypořádání se s copyrightem a přidání té kontroly > to není zcela spolehlivé. Může to jak zkrátit číslo, tak prodloužit - > teoreticky i možná změnit. > Díky za příklad i data. > Honza

> Zkoušel jsem tu dlaždici > http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png > a nenašel jsem žádný bod, který by to nedetekovalo. Nechal jsem si > udělat modrou tečku do původní bitmapy na každý detekovaný bod ... a > ruční kontrolou byly všechny omodřené a žádný červený nezbyl. > Prosím o jeden případ bodu (číslo popisné, souřadnici v pixelech nebo > tak něco), který se ti nedetekoval. > Do csv mi to napsalo 186 řádek. Tedy to našlo 186 bodů. Tobě také? > Honza

> Ahoj, > > 186 souhlasí, ty chybějící body jsou vždy "bez č.p./č.e.". Chybí například > bod pod č.p. 1 a 121 na souřadnicích 50,13254; 14,33821. > > On Sat, 13 Feb 2010 01:58:07 +0100, Jan Bilak <jan.bilak.osm na gmail.com> > wrote: > >> Zkoušel jsem tu dlaždici >> http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png >> a nenašel jsem žádný bod, který by to nedetekovalo. Nechal jsem si >> udělat modrou tečku do původní bitmapy na každý detekovaný bod ... a >> ruční kontrolou byly všechny omodřené a žádný červený nezbyl. >> Prosím o jeden případ bodu (číslo popisné, souřadnici v pixelech nebo >> tak něco), který se ti nedetekoval. >> Do csv mi to napsalo 186 řádek. Tedy to našlo 186 bodů. Tobě také? >> Honza > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> ------------ 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 03:02:22 > ---------------------------------------- > Ahoj, > > 186 souhlasí, ty chybějící body jsou vždy "bez č.p./č.e.". Chybí například > bod pod č.p. 1 a 121 na souřadnicích 50,13254; 14,33821. > > On Sat, 13 Feb 2010 01:58:07 +0100, Jan Bilak <jan.bilak.osm na gmail.com> > wrote: >

> Omlouvám se. To není chyba - Merge nevygeneruje pro "bez č.p./č.e." žádný bod, takže je všechno v pořádku. > > >> ------------ 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 03:02:22 >> ---------------------------------------- >> Ahoj, >> >> 186 souhlasí, ty chybějící body jsou vždy "bez č.p./č.e.". Chybí například >> bod pod č.p. 1 a 121 na souřadnicích 50,13254; 14,33821. >> >> On Sat, 13 Feb 2010 01:58:07 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >> wrote: >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Posílám testovací data (měl by to být celý okres Praha-západ) na [2].

> Jedno upozornění - ta data jsem stahoval na třikrát, a potom to sesypal do > jednoho adresáře (v domnění, že se překrývající dlaždice požerou, což se > ale nestalo protože nejsou zaokrouhlovány stejně). V adresáři jsou tedy v > překrývajících oblastech shodné dlaždice akorát s posunem. > > Pokud bys chtěl jednotlivé dlaždice rozdělit do původních adresářů, tak na > [1] jsou seznamy souborů z jednotlivých původních adresářů. > > [1] http://www.flyshare.cz/stahni/46192/pz.tar.gz > > On Sat, 13 Feb 2010 02:07:28 +0100, Petr Dlouhý <petr.dlouhy na email.cz> > wrote: > >> Posílám testovací data (měl by to být celý okres Praha-západ) na [2]. > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Ahoj. > > Dal jsem tam betu 3 ... http://jabi.aspone.cz/osm/OcrBeta3.zip > > Pridava drive zminovanou podminku, ktera umoznuje detekovat, zda jde o > jednoznacne rozpoznani nebo je treba rucni kontrola. > Dale meni stavy rozpoznani: > [CHECK] ... je treba rucni kontrola > [OVERLAP] ... byl tam prekryv, ale melo by to byt jednoznacne (spise > pro debug ucely a overeni programu) > > Doslo i ke zmene parametru programu: > > Command line options are: >  -tiles [..]     (*) Path to downloaded tiles >  -output [..]    (*) Output filename >  -log [..]       Log filename >  -all            Log all >  -overlap        Log overlap >  -threads [..]   Thread count > (*) Required. > > Defaultni logovani pri uvedeni souboru logu je takove, ze se loguji > jen CHECK body. Lze zapnout i overlap body nebo vsechny. > Na Monu je asi problem s vicevlaknovym provozem (asi je treba jeste > navic neco zamykat nebo tak neco), tak pribyl argument pro urceni > poctu vlaken. Pri problemech nastavte na hodnotu 1. > > A dale cernou barvu povazuji za cervenou. Pokud s tim budou problemy, > lze zvolit variantu s orezem a vetsim prekryvem nebo dynamicke > stahovani zazoomovane oblasti (pracnejsi). > > Honza > > > > 2010/2/13 Petr Dlouhý <petr.dlouhy na email.cz>: >> Jedno upozornění - ta data jsem stahoval na třikrát, a potom to sesypal do >> jednoho adresáře (v domnění, že se překrývající dlaždice požerou, což se >> ale nestalo protože nejsou zaokrouhlovány stejně). V adresáři jsou tedy v >> překrývajících oblastech shodné dlaždice akorát s posunem. >> >> Pokud bys chtěl jednotlivé dlaždice rozdělit do původních adresářů, tak na >> [1] jsou seznamy souborů z jednotlivých původních adresářů. >> >> [1] http://www.flyshare.cz/stahni/46192/pz.tar.gz >> >> On Sat, 13 Feb 2010 02:07:28 +0100, Petr Dlouhý <petr.dlouhy na email.cz> >> wrote: >> >>> Posílám testovací data (měl by to být celý okres Praha-západ) na [2]. >> >> >> -- >> Petr Dlouhý >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >

> Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) - > oprava "padání". > Honza

> Ahoj, > > je tam stále ten problém s pamětí. Když jsem zkoušel adresář pz1, tak to > po nějaké době začne náhle konzumovat velké množství paměti (zabere mi to > cca 1,7 GB paměti +  0,5 GB swapu). Není to způsobené programem samotným > (dlouhou dobu se paměť téměř nezabírá), ale ani jednotlivou dlaždicí > (během finále se stále ještě dlaždice mění). > > On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak <jan.bilak.osm na gmail.com> > wrote: > >> Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) - >> oprava "padání". >> Honza > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Právě to zkouším na těch tvých datech Prahy ... ještě nejsem u konce. > Pravda je, že mám 4 GB RAM, takže 2,3 GB by mi systém možná přežil, > kdyby odswapoval všechno ostatní.... zkusím sledovat paměť. Lukáš tam > volal explicitně Garbage Collector tuším po zpracování každé dlaždice, > zkusím to tam případně vrátit - třeba pro to měl dobrý důvod (já to > odstranil jako zbytečně zdržující).

> Ahoj, > > je tam stále ten problém s pamětí. Když jsem zkoušel adresář pz1, tak to > po nějaké době začne náhle konzumovat velké množství paměti (zabere mi to > cca 1,7 GB paměti +  0,5 GB swapu). Není to způsobené programem samotným > (dlouhou dobu se paměť téměř nezabírá), ale ani jednotlivou dlaždicí > (během finále se stále ještě dlaždice mění). > > On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak <jan.bilak.osm na gmail.com> > wrote: > >> Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) - >> oprava "padání". >> Honza > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Dal jsem tam novou verzi beta3 (na stejné místo). Má navíc parametr > -gc, kterým lze zařídit zavolání Garbace Collectoru po zpracování > každé dlaždice. Tím se výrazně sníží paměťové nároky, ale za cenu > nějakého snížení rychlosti. > > Zkus to prosím. > > Mne to ve Windows žere bez -gc spičkově tak 650 MB, s -gc tak 250 MB. > To při použití dvou vláken. Jinak jsem zatím po zpracování dalších > dlaždic z Prahy problém nenarazil. > > Honza > > > > 2010/2/13 Petr Dlouhý <petr.dlouhy na email.cz>: >> Ahoj, >> >> je tam stále ten problém s pamětí. Když jsem zkoušel adresář pz1, tak to >> po nějaké době začne náhle konzumovat velké množství paměti (zabere mi to >> cca 1,7 GB paměti +  0,5 GB swapu). Není to způsobené programem samotným >> (dlouhou dobu se paměť téměř nezabírá), ale ani jednotlivou dlaždicí >> (během finále se stále ještě dlaždice mění). >> >> On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >> wrote: >> >>> Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) - >>> oprava "padání". >>> Honza >> >> >> -- >> Petr Dlouhý >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >

> Projel jsem všechny dlaždice, které jsi mi poslal. Na problém jsem > nenarazil. Možné je to specifické chování Mona - já to dělám pod > .NETem (třeba vím, že pod Monem mi aplikace vždycky padala, když jsem > přistupoval ke konzoli z více vláken, zato .NET to automaticky > synchronizoval apod.). Nevím - těžko se ladí něco, co se mi > neprojevuje. > > Zdrojáky jsou tady: > http://jabi.aspone.cz/osm/FindAddressPoints-beta3-src.zip > > Pokud by se problém nepodařilo odstranit, tak je možné to dělat pod > Windows. Zase tak dlouho to myslím netrvá, aby byla třeba dělat akce > na způsob SETI na home. > > Honza > > > 2010/2/13 Jan Bilak <jan.bilak.osm na gmail.com>: >> Dal jsem tam novou verzi beta3 (na stejné místo). Má navíc parametr >> -gc, kterým lze zařídit zavolání Garbace Collectoru po zpracování >> každé dlaždice. Tím se výrazně sníží paměťové nároky, ale za cenu >> nějakého snížení rychlosti. >> >> Zkus to prosím. >> >> Mne to ve Windows žere bez -gc spičkově tak 650 MB, s -gc tak 250 MB. >> To při použití dvou vláken. Jinak jsem zatím po zpracování dalších >> dlaždic z Prahy problém nenarazil. >> >> Honza >> >> >> >> 2010/2/13 Petr Dlouhý <petr.dlouhy na email.cz>: >>> Ahoj, >>> >>> je tam stále ten problém s pamětí. Když jsem zkoušel adresář pz1, tak to >>> po nějaké době začne náhle konzumovat velké množství paměti (zabere mi to >>> cca 1,7 GB paměti +  0,5 GB swapu). Není to způsobené programem samotným >>> (dlouhou dobu se paměť téměř nezabírá), ale ani jednotlivou dlaždicí >>> (během finále se stále ještě dlaždice mění). >>> >>> On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >>> wrote: >>> >>>> Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) - >>>> oprava "padání". >>>> Honza >>> >>> >>> -- >>> Petr Dlouhý >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >

> Tady jsou výsledná *.csv a logy z tvých dat Prahy: > http://www.flyshare.cz/stahni/46207/praha.zip > > Zpracovával jsem to po 5 částech - jsou očíslovány stejně *.csv a logy > (stejná čísla patří k sobě). > > Honza > > > > 2010/2/13 Jan Bilak <jan.bilak.osm na gmail.com>: >> Projel jsem všechny dlaždice, které jsi mi poslal. Na problém jsem >> nenarazil. Možné je to specifické chování Mona - já to dělám pod >> .NETem (třeba vím, že pod Monem mi aplikace vždycky padala, když jsem >> přistupoval ke konzoli z více vláken, zato .NET to automaticky >> synchronizoval apod.). Nevím - těžko se ladí něco, co se mi >> neprojevuje. >> >> Zdrojáky jsou tady: >> http://jabi.aspone.cz/osm/FindAddressPoints-beta3-src.zip >> >> Pokud by se problém nepodařilo odstranit, tak je možné to dělat pod >> Windows. Zase tak dlouho to myslím netrvá, aby byla třeba dělat akce >> na způsob SETI na home. >> >> Honza >> >> >> 2010/2/13 Jan Bilak <jan.bilak.osm na gmail.com>: >>> Dal jsem tam novou verzi beta3 (na stejné místo). Má navíc parametr >>> -gc, kterým lze zařídit zavolání Garbace Collectoru po zpracování >>> každé dlaždice. Tím se výrazně sníží paměťové nároky, ale za cenu >>> nějakého snížení rychlosti. >>> >>> Zkus to prosím. >>> >>> Mne to ve Windows žere bez -gc spičkově tak 650 MB, s -gc tak 250 MB. >>> To při použití dvou vláken. Jinak jsem zatím po zpracování dalších >>> dlaždic z Prahy problém nenarazil. >>> >>> Honza >>> >>> >>> >>> 2010/2/13 Petr Dlouhý <petr.dlouhy na email.cz>: >>>> Ahoj, >>>> >>>> je tam stále ten problém s pamětí. Když jsem zkoušel adresář pz1, tak to >>>> po nějaké době začne náhle konzumovat velké množství paměti (zabere mi to >>>> cca 1,7 GB paměti +  0,5 GB swapu). Není to způsobené programem samotným >>>> (dlouhou dobu se paměť téměř nezabírá), ale ani jednotlivou dlaždicí >>>> (během finále se stále ještě dlaždice mění). >>>> >>>> On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >>>> wrote: >>>> >>>>> Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) - >>>>> oprava "padání". >>>>> Honza >>>> >>>> >>>> -- >>>> Petr Dlouhý >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >> >

> Ahoj, > mas k tomu jeste nejake zasadni postrehy (co je treba upravit)? Tedy > krome toho, ze ti to zacne plnit pamet, protoze to se mi nepodarilo > nasimulovat a ani nemam zadny napad, cim by to mohlo byt. > Honza

> Ahoj, > > zatím jsem se na to zběžně podíval. Jediná chyba, kterou jsem našel je, že > se několikrát detekovalo [OVERLAP] a řada mezer bez jakéhokoliv textu. > Uzlů s [CHECK][OVERLAP] jsem našel na třetině okresu 8, a to ještě ve > všech případech  kromě jednoho byl řetězec správně (kromě mezer na konci). > > Jinak s tím garbage collectorem to funguje, nezkoušel jsem kolik to > zpomaluje, ale jestli myslíš že se to projeví, tak by ho možná šlo volat > jen jednou za 100 dlaždic (nebo něco takového). Asi je v Monu nějaká chyba > a GC najednou přestane automaticky fungovat. > > On Sun, 14 Feb 2010 18:40:26 +0100, Jan Bilak <jan.bilak.osm na gmail.com> > wrote: > >> Ahoj, >> mas k tomu jeste nejake zasadni postrehy (co je treba upravit)? Tedy >> krome toho, ze ti to zacne plnit pamet, protoze to se mi nepodarilo >> nasimulovat a ani nemam zadny napad, cim by to mohlo byt. >> Honza > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Ahoj, > pokud máš někde po ruce csv výpis (kde jsou souřadnice těch chyb s > mezerami), tam mi jej prosím pošli. Kouknul bych se, proč to nastává a > co se s tím dá dělat. Může to způsobovat i nějaké méně viditelné > chyby. U těch dat Prahy, které jsi mne poslal, se toto nestalo. > S tím GC to volat třeba po 100 mapkách asi nemá smysl, protože každá > bitmapa v paměti zabere asi 50 MB (4000x4000 px a v RGB 3 byte na > pixel) a k tomu ještě další pomocné struktury ... celé se to musí > násobit počtem vláken ... tedy alokuje se tam velké množství paměti. > Ale ten rozdíl časů nemusí být velký, protože i při standardním > chování se musí GC volat celkem často.

> Ahoj, > > právě že to nastává u těch dat z Prahy-západ (generoval jsem to ale sám), > například: > > 50.1673801,14.3893938,[OVERLAP] > 50.1025125,14.4268763,[OVERLAP] > 50.1025113,14.4268763,[OVERLAP] > 50.0950088,14.3479638,[OVERLAP] > 50.0950088,14.3479650,[OVERLAP] > > S tím GC není problém, že by vůbec nefungoval - problém je s tím, že > najednou přestane fungovat (po delší době bezproblémového výpočtu). > Souhlasím ale, že zapnutí GC asi nemá velký vliv na výkon, takže to > nemusíš řešit. > > On Sun, 14 Feb 2010 23:30:56 +0100, Jan Bilak <jan.bilak.osm na gmail.com> > wrote: > >> Ahoj, >> pokud máš někde po ruce csv výpis (kde jsou souřadnice těch chyb s >> mezerami), tam mi jej prosím pošli. Kouknul bych se, proč to nastává a >> co se s tím dá dělat. Může to způsobovat i nějaké méně viditelné >> chyby. U těch dat Prahy, které jsi mne poslal, se toto nestalo. >> S tím GC to volat třeba po 100 mapkách asi nemá smysl, protože každá >> bitmapa v paměti zabere asi 50 MB (4000x4000 px a v RGB 3 byte na >> pixel) a k tomu ještě další pomocné struktury ... celé se to musí >> násobit počtem vláken ... tedy alokuje se tam velké množství paměti. >> Ale ten rozdíl časů nemusí být velký, protože i při standardním >> chování se musí GC volat celkem často. > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Máš pravdu, hledal jsem to nějak špatně - mám to v logách... Omlouvám se. > > Honza > > > 2010/2/14 Petr Dlouhý <petr.dlouhy na email.cz>: >> Ahoj, >> >> právě že to nastává u těch dat z Prahy-západ (generoval jsem to ale sám), >> například: >> >> 50.1673801,14.3893938,[OVERLAP] >> 50.1025125,14.4268763,[OVERLAP] >> 50.1025113,14.4268763,[OVERLAP] >> 50.0950088,14.3479638,[OVERLAP] >> 50.0950088,14.3479650,[OVERLAP] >> >> S tím GC není problém, že by vůbec nefungoval - problém je s tím, že >> najednou přestane fungovat (po delší době bezproblémového výpočtu). >> Souhlasím ale, že zapnutí GC asi nemá velký vliv na výkon, takže to >> nemusíš řešit. >> >> On Sun, 14 Feb 2010 23:30:56 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >> wrote: >> >>> Ahoj, >>> pokud máš někde po ruce csv výpis (kde jsou souřadnice těch chyb s >>> mezerami), tam mi jej prosím pošli. Kouknul bych se, proč to nastává a >>> co se s tím dá dělat. Může to způsobovat i nějaké méně viditelné >>> chyby. U těch dat Prahy, které jsi mne poslal, se toto nestalo. >>> S tím GC to volat třeba po 100 mapkách asi nemá smysl, protože každá >>> bitmapa v paměti zabere asi 50 MB (4000x4000 px a v RGB 3 byte na >>> pixel) a k tomu ještě další pomocné struktury ... celé se to musí >>> násobit počtem vláken ... tedy alokuje se tam velké množství paměti. >>> Ale ten rozdíl časů nemusí být velký, protože i při standardním >>> chování se musí GC volat celkem často. >> >> >> -- >> Petr Dlouhý >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >

> Ahoj, > > ja byl ted tyden pryc, proto jsem se do diskuze a reseni problemu > nezapojil. > > Pokud spravne chapu situaci, tak problem je u c.e., ve kterych je > cislice 2 se obcas stava a obcas se stava, ze se rozpozna jako 7. Jak > jsem z diskuze pochopil, tak Honza Bilak napsal programek, ktery vezme > celou dlazdici a provede OCR jinym zpusobem. > > Ja mam pripravene skripty na docisteni vysledku (slouceni dat z > dlazdic, vymazani duplicit zpusobenych prekryvem dlazdic, vyfiltorvani > bodu ktere neodpovidaji vzoru c.p., c.e., bez cp./c.e a jejich stazeni > ve vyssim rozliseni a znovuprovedeni OCR - vyreseni prokryvajicich se > napisu) > > Vysledky po stazeni detailu a znovuprovedeni OCR jsou celkem dobre. Na > datech, co byla spocitana minuly tyden (cca 2/3 republiky) je po > znovuprovedeni OCR jen 1050 adresnich bodu, ktere neodpovidaji > zadanemu vzoru. > > Myslim, ze by bylo zbytecne zpracovavat celou CR znovu. Z dat si muzu > vytahnout c.e., ktera obsahuji cislici 7, stahnout si detail ve vyssim > rozliceni a ten misto terreractem zpracovat algoritmem od Honzy. > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Ahoj, > > algoritmus po Honzových úpravách pracuje výrazně rychleji a dokáže > detekovat překrývající se čísla s téměř 100% úspěšností (na rozsáhlém > území jsou to jednotky chyb). Vzhledem k tomu, že je to možné zpracovat za > několik dnů na jednom PC, tak bych řekl, že se to předělat vyplatí. > > On Mon, 15 Feb 2010 09:44:58 +0100, Lukas Kabrt <lukas na kabrt.cz> wrote: > >> Ahoj, >> >> ja byl ted tyden pryc, proto jsem se do diskuze a reseni problemu >> nezapojil. >> >> Pokud spravne chapu situaci, tak problem je u c.e., ve kterych je >> cislice 2 se obcas stava a obcas se stava, ze se rozpozna jako 7. Jak >> jsem z diskuze pochopil, tak Honza Bilak napsal programek, ktery vezme >> celou dlazdici a provede OCR jinym zpusobem. >> >> Ja mam pripravene skripty na docisteni vysledku (slouceni dat z >> dlazdic, vymazani duplicit zpusobenych prekryvem dlazdic, vyfiltorvani >> bodu ktere neodpovidaji vzoru c.p., c.e., bez cp./c.e a jejich stazeni >> ve vyssim rozliseni a znovuprovedeni OCR - vyreseni prokryvajicich se >> napisu) >> >> Vysledky po stazeni detailu a znovuprovedeni OCR jsou celkem dobre. Na >> datech, co byla  spocitana minuly tyden (cca 2/3 republiky) je po >> znovuprovedeni OCR jen 1050 adresnich bodu, ktere neodpovidaji >> zadanemu vzoru. >> >> Myslim, ze by bylo zbytecne zpracovavat celou CR znovu. Z dat si muzu >> vytahnout c.e., ktera obsahuji cislici 7, stahnout si detail ve vyssim >> rozliceni a ten misto terreractem zpracovat algoritmem od Honzy. >> -- >> Lukas >> >> _______________________________________________ >> 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 >

> Obecne mam obavu, ze tesseract se muze splest a rozpoznat cislo > spatne, i kdyz vysledek rozpoznani odpovida vzoru. Zato muj OCR na > miru detektuje pripady, kdy si neni jisty, a loguje je, aby je bylo > mozne rucne zkontrolovat. Pritom je jich dostatecne maly pocet na to, > aby rucni kontrola byla proveditelna. Pokud v programu neni chyba (coz > nevylucuji), tak by program nemel popisek rozpoznat spatne, aniz by > jej oznacil, ze si neni jisty.

> ------------ Původní zpráva ------------ > Od: Lukas Kabrt <lukas na kabrt.cz> > Předmět: Re: [Talk-cz] Import adres z katastralni mapy > Datum: 17.2.2010 15:38:57 > ----------------------------------------

> BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program pracuje. > > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

> Princip práce Honzova programu se dá jednoduše poznat z logových souborů. > > Zdrojáky by asi bylo nejlepší nahrát na <http://svn.openstreetmap.org/applications/utils/>, abychom se s nimi při příštím importu zase setkali, a aby se jimi mohli inspirovat i ostatní. > > >> ------------ Původní zpráva ------------ >> Od: Lukas Kabrt <lukas na kabrt.cz> >> Předmět: Re: [Talk-cz] Import adres z katastralni mapy >> Datum: 17.2.2010 15:38:57 >> ---------------------------------------- > >> BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program pracuje. >> >> -- >> Lukas >> >> _______________________________________________ >> 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 >

> Ahoj, > > odkaz na zdrojáky jsem do této konference už zasílal (na betu 3) - o > pár příspěvků výše jej najdeš. Beta 4 upravovala jen drobnosti. Ještě > zdrojáky trochu upravím (po formální stránce - refaktoring, komentáře, > ...) ... a pak, když vymyslíte vhodné místo na SVN, tak tam nahraju. > > Obecně si ale myslím, že je vhodné dělat tyto utility jako class > library (v případě .NETu) s nějakým rozumným interfacem, aby je bylo > možné začlěňovat do celku. Tedy místo dlouhého postupu, co spouštět v > jakém pořadí, tak pak mít utilitku s příjemným rozhraním (ať již > konzolovým nebo GUI), která tohle všechno zařídí. A přitom jednotlivé > části řešené jako vyměnitelné a nahraditelné jinou implementací. > > Jinak mám velké pochybnosti o tom, že se budou dostatečně často data > aktualizovat. Už to nebude mít takový ten "wow" efekt, kdy na mapách > přibude mnoho dat a tak se do toho nikomu nebude moc chtít, když to > bude složité. > > Honza > > > 2010/2/17 Petr Dlouhý <petr.dlouhy na email.cz>: >> Princip práce Honzova programu se dá jednoduše poznat z logových souborů. >> >> Zdrojáky by asi bylo nejlepší nahrát na <http://svn.openstreetmap.org/applications/utils/>, abychom se s nimi při příštím importu zase setkali, a aby se jimi mohli inspirovat i ostatní. >> >> >>> ------------ Původní zpráva ------------ >>> Od: Lukas Kabrt <lukas na kabrt.cz> >>> Předmět: Re: [Talk-cz] Import adres z katastralni mapy >>> Datum: 17.2.2010 15:38:57 >>> ---------------------------------------- >> >>> BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program pracuje. >>> >>> -- >>> Lukas >>> >>> _______________________________________________ >>> 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 >> >

> A mimochodem nejde o můj program ... je to upravený ten tvůj. > > Honza > > > 2010/2/17 Jan Bilak <jan.bilak.osm na gmail.com>: >> Ahoj, >> >> odkaz na zdrojáky jsem do této konference už zasílal (na betu 3) - o >> pár příspěvků výše jej najdeš. Beta 4 upravovala jen drobnosti. Ještě >> zdrojáky trochu upravím (po formální stránce - refaktoring, komentáře, >> ...) ... a pak, když vymyslíte vhodné místo na SVN, tak tam nahraju. >> >> Obecně si ale myslím, že je vhodné dělat tyto utility jako class >> library (v případě .NETu) s nějakým rozumným interfacem, aby je bylo >> možné začlěňovat do celku. Tedy místo dlouhého postupu, co spouštět v >> jakém pořadí, tak pak mít utilitku s příjemným rozhraním (ať již >> konzolovým nebo GUI), která tohle všechno zařídí. A přitom jednotlivé >> části řešené jako vyměnitelné a nahraditelné jinou implementací. >> >> Jinak mám velké pochybnosti o tom, že se budou dostatečně často data >> aktualizovat. Už to nebude mít takový ten "wow" efekt, kdy na mapách >> přibude mnoho dat a tak se do toho nikomu nebude moc chtít, když to >> bude složité. >> >> Honza >> >> >> 2010/2/17 Petr Dlouhý <petr.dlouhy na email.cz>: >>> Princip práce Honzova programu se dá jednoduše poznat z logových souborů. >>> >>> Zdrojáky by asi bylo nejlepší nahrát na <http://svn.openstreetmap.org/applications/utils/>, abychom se s nimi při příštím importu zase setkali, a aby se jimi mohli inspirovat i ostatní. >>> >>> >>>> ------------ Původní zpráva ------------ >>>> Od: Lukas Kabrt <lukas na kabrt.cz> >>>> Předmět: Re: [Talk-cz] Import adres z katastralni mapy >>>> Datum: 17.2.2010 15:38:57 >>>> ---------------------------------------- >>> >>>> BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program pracuje. >>>> >>>> -- >>>> Lukas >>>> >>>> _______________________________________________ >>>> 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 >>> >> >

> Ahoj, > > par informací, co je nového ohledně importu adres. > > Znovu jsem provedl OCR s vylepšeným programem. Výsledek je na [1] > > Vylepšil jsem program merge-cuzk-db [2] > - lepší detekce problémů (duplicity) > - možnost zpracování více *.map souborů najednou > - rychlejší zpracování osm a xml souborů (bez problémů lze používat > soubor s hranicemi k.ú. pro celou ČR) > > - změna označení nekonzistentních dat (tag note místo tagu fixme) - > podle toho co jsem koukal, tak fixme se používá pro závažnější > pronlémy > > Na wiki [3] je pár bodů k nové verzi programu. Postupně tam budu > přidávat odkazy na zip soubory s daty pro jednotlivé okresy (archiv > obsahuje map soubory, soubor s polohami budov a výsledkem ocr, osm > soubory pro obce, kde je předpoklad, že map soubor je správný). V > současné době jsou na wiki odkazy na prvních 5 souborů. > > Pokud se někdo pustíte do importu, tak prosím data aspoň zběžně > zkontrolujte - jestli jsem neudělal nějakou chyby, které jsem si > nevšimnul. Víc očí, víc vidí :-) > > [1] lkabrt.aspone.cz/osm/cz.zip > [2] http://osm.kabrt.cz/home/adresy.zip?attredirects=0&d=1 > [3] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR#P.C5.99ehled_import.C5.AF > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Chtěl jsem se na to podívat, ale chce to po mě .NET Framework 4.0.3... > Nějak si nejsem jistý, kterou z těch mnoha verzí co MS nabízí mám > nainstalovat a po předchoízch zkušenostech, kdy mi instalace .NET 3.5 > rozhasila některé věci se mi do toho ani moc nechce. > Můžeš dát podrobnější návod, případně link na správnou verzi?

> 2010/2/23 Jan Dudík <jan.dudik na gmail.com>: >> Chtěl jsem se na to podívat, ale chce to po mě .NET Framework 4.0.3... >> Nějak si nejsem jistý, kterou z těch mnoha verzí co MS nabízí mám >> nainstalovat a po předchoízch zkušenostech, kdy mi instalace .NET 3.5 >> rozhasila některé věci se mi do toho ani moc nechce. >> Můžeš dát podrobnější návod, případně link na správnou verzi? > > .NET Framework 4.0 bych určitě běžným uživatelům nedoporučoval > instalovat, zatím to není finální verze a zaděláte si na možné > problémy, až budete instalovat ostrou verzi (mluvím z vlastní > zkušenosti s aktualizací z Beta 1 na Beta 2…). > > -- Petr Kadlec / Mormegil

> Chtěl jsem se na to podívat, ale chce to po mě .NET Framework 4.0.3... > Nějak si nejsem jistý, kterou z těch mnoha verzí co MS nabízí mám > nainstalovat a po předchoízch zkušenostech, kdy mi instalace .NET 3.5 > rozhasila některé věci se mi do toho ani moc nechce. > Můžeš dát podrobnější návod, případně link na správnou verzi?

>> Chtěl jsem se na to podívat, ale chce to po mě .NET Framework 4.0.3... >> Nějak si nejsem jistý, kterou z těch mnoha verzí co MS nabízí mám >> nainstalovat a po předchoízch zkušenostech, kdy mi instalace .NET 3.5 >> rozhasila některé věci se mi do toho ani moc nechce. >> Můžeš dát podrobnější návod, případně link na správnou verzi? > > Za .NET framework 4 se omlouvám, používám Beta verzi nového Visual > Studia a ta má defaultně nastavené použití .NET frameworku 4, nějak > jsem si to neuvědomil. > > Tady [1] program zkompilován pro verzi 3.5. > > [1] http://sites.google.com/a/kabrt.cz/osm/home/adresy.zip?attredirects=0&d=1 > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Ve staženém souboru (Beroun) už jsou všechny výstupy udělané, proč je > tedy třeba zprovozňovat program?

> tam, kde jsou konflikty mi program spadne.

> BTW, co ten import ktastrálních území? soubor existuje, proč není > zároveň nahrán?