> [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 at 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 at 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 at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > -- > Petr Dlouh? > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> -- >> Petr Dlouh? >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > -- > Petr Dlouh? > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> -- >> Petr Dlouh? >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at 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 at 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 at 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 at 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 at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> -- >>> Petr Dlouh? >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> -- >>>> Petr Dlouh? >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > -- > Petr Dlouh? > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>>> >>>>> -- >>>>> Petr Dlouh? >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> -- >> Petr Dlouh? >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at kabrt.cz> napsal(a): >>> Pardon, myslel jsem dn?. >>> >>> On Sun, 24 Jan 2010 08:46:16 +0100, Petr Dlouh? <petr.dlouhy at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> > > > -- > Petr Dlouh? > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at 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 at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >> >> >> -- >> Petr Dlouh? >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>> >>> >>> -- >>> Petr Dlouh? >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > -- > Petr Dlouh? > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at 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 at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > -- > Petr Dlouh? > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> -- >> Petr Dlouh? >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> -- >>> Petr Dlouh? >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > -- > Petr Dlouh? > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> -- >>>> Petr Dlouh? >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> -- >> Petr Dlouh? >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>>> >>>>> -- >>>>> Petr Dlouh? >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> -- >>> Petr Dlouh? >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>>> >>>>>> -- >>>>>> Petr Dlouh? >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> -- >>>> Petr Dlouh? >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at 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 at gmail.com>: >> Doplnil jsem tam chyb?j?c? ??slici 4. >> >> Honza >> >> 2010/2/12 Jan Bilak <jan.bilak.osm at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz at openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Petr Dlouh? >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>>> >>>>> -- >>>>> Petr Dlouh? >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>> >>> >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at gmail.com>: >>> Doplnil jsem tam chyb?j?c? ??slici 4. >>> >>> Honza >>> >>> 2010/2/12 Jan Bilak <jan.bilak.osm at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Petr Dlouh? >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz at openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>>> >>>>>> -- >>>>>> Petr Dlouh? >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > -- > Petr Dlouh? > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at gmail.com>: >>>> Doplnil jsem tam chyb?j?c? ??slici 4. >>>> >>>> Honza >>>> >>>> 2010/2/12 Jan Bilak <jan.bilak.osm at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >>>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk-cz mailing list >>>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Petr Dlouh? >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz at openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Petr Dlouh? >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> -- >> Petr Dlouh? >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >

> ------------ P?vodn? zpr?va ------------ > Od: Petr Dlouh? <petr.dlouhy at 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 at 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 at gmail.com>: > >> Doplnil jsem tam chyb?j?c? ??slici 4. > >> > >> Honza > >> > >> 2010/2/12 Jan Bilak <jan.bilak.osm at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org > >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Talk-cz mailing list > >>>>>>>> Talk-cz at openstreetmap.org > >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Petr Dlouh? > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Talk-cz mailing list > >>>>>>> Talk-cz at openstreetmap.org > >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Talk-cz mailing list > >>>>>> Talk-cz at openstreetmap.org > >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>> > >>>>> > >>>>> -- > >>>>> Petr Dlouh? > >>>>> > >>>>> _______________________________________________ > >>>>> Talk-cz mailing list > >>>>> Talk-cz at openstreetmap.org > >>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>> > >>>> > >>> > >> > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz at openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > > -- > Petr Dlouh? > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at 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 at gmail.com>: >>>>> Doplnil jsem tam chyb?j?c? ??slici 4. >>>>> >>>>> Honza >>>>> >>>>> 2010/2/12 Jan Bilak <jan.bilak.osm at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >>>>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Talk-cz mailing list >>>>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Petr Dlouh? >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk-cz mailing list >>>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Petr Dlouh? >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz at openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> -- >>> Petr Dlouh? >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at 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 at 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 at 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 at gmail.com>: >> >> Doplnil jsem tam chyb?j?c? ??slici 4. >> >> >> >> Honza >> >> >> >> 2010/2/12 Jan Bilak <jan.bilak.osm at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >> >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> _______________________________________________ >> >>>>>>>> Talk-cz mailing list >> >>>>>>>> Talk-cz at openstreetmap.org >> >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >> >>>>>>> >> >>>>>>> >> >>>>>>> -- >> >>>>>>> Petr Dlouh? >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> Talk-cz mailing list >> >>>>>>> Talk-cz at openstreetmap.org >> >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >> >>>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Talk-cz mailing list >> >>>>>> Talk-cz at openstreetmap.org >> >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Petr Dlouh? >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Talk-cz mailing list >> >>>>> Talk-cz at openstreetmap.org >> >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >> >>>>> >> >>>> >> >>> >> >> >> > >> > _______________________________________________ >> > Talk-cz mailing list >> > Talk-cz at openstreetmap.org >> > http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> -- >> Petr Dlouh? >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> > > Petr Dlouh? > petr.dlouhy at email.cz > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at 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 at gmail.com>: >>> >> Doplnil jsem tam chyb?j?c? ??slici 4. >>> >> >>> >> Honza >>> >> >>> >> 2010/2/12 Jan Bilak <jan.bilak.osm at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >>> >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>>>>>>>> >>> >>>>>>>> >>> >>>>>>>> _______________________________________________ >>> >>>>>>>> Talk-cz mailing list >>> >>>>>>>> Talk-cz at openstreetmap.org >>> >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> -- >>> >>>>>>> Petr Dlouh? >>> >>>>>>> >>> >>>>>>> _______________________________________________ >>> >>>>>>> Talk-cz mailing list >>> >>>>>>> Talk-cz at openstreetmap.org >>> >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>>>>>> >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> Talk-cz mailing list >>> >>>>>> Talk-cz at openstreetmap.org >>> >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> Petr Dlouh? >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> Talk-cz mailing list >>> >>>>> Talk-cz at openstreetmap.org >>> >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>>>> >>> >>>> >>> >>> >>> >> >>> > >>> > _______________________________________________ >>> > Talk-cz mailing list >>> > Talk-cz at openstreetmap.org >>> > http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> -- >>> Petr Dlouh? >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> >> >> Petr Dlouh? >> petr.dlouhy at email.cz >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> ------------ P?vodn? zpr?va ------------ > Od: Petr Dlouh? <petr.dlouhy at 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 at 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 at 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 at gmail.com> >> wrote: >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at home. > > Honza > > > 2010/2/13 Jan Bilak <jan.bilak.osm at 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 at 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 at 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 at 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 at 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 at home. >> >> Honza >> >> >> 2010/2/13 Jan Bilak <jan.bilak.osm at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > -- > Petr Dlouh? > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at 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 at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> > > Petr Dlouh? > petr.dlouhy at email.cz > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> >> >> Petr Dlouh? >> petr.dlouhy at email.cz >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at 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 at 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 at 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 at 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 at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> >>> >>> Petr Dlouh? >>> petr.dlouhy at email.cz >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at 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 at 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 at 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 at 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?