« zpět na výpis měsíce |

[Talk-cz] Import adres z katastralni mapy

Vlákno 16.1. - 23.2.2010, počet zpráv: 160


16.1.2010 03:52:27 (#1)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
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? Pokud chcete import vyzkouset sami, tak ctete dal. Pro provedeni importu je potreba 1) balicek programu ode me - lkabrt.aspone.cz/osm/cuzk.zip (potreba je .NET framework 3.5) pokud si nekdo chce prohlednou zdrojove kody lkabrt.aspone.cz/osm/cuzk-source.zip 2) databaze adresnich bodu [3] 3) zakreslene katastralni uzemi v OSM souboru (pouzil jsem vyrez z vektorizovne mapy od hanoje [4], kam jsem rucne doplnil relace a nazvy katastralnich uzemi) 4) trochu casu - jak vaseho, tak vaseho pocitace :-) Postup 1) stazeni katastralni mapy (staci definicni body budov) - program tile-downloader.exe parametry programu: -north, -south, -east, -west - definuje oblast ke stazeni -addressPoints - stahne definicni body budov -map - stahne katastralni mapu -output - adresar pro ulozeni stazenych souboru priklad: tile-downloader.exe -north 50.6647 -west 16.0285 -south 50.4902 -east 16.4517 - addressPoints -output data/broumovsko 2) nalezeni a rozpoznani adresnich bodu - program tile-processor.exe parametry programu: -tiles - adresar se stazenymi soubory -output - soubor pro ulozeni vysledku priklad: tile-processor.exe -tiles data/broumovsko -output data/broumovsko.csv Vystupem programu je CSV soubor se souradnicemi adresnich bodu a jejich popisem, tak jak ho rozpoznalo OCR 3) vytvoreni XML souboru, ktery definuje prirazeni mezi katastralnim uzemim a obci / casti obce z databaze adresnich bodu Prirazeni muze byt (podle toho, co jsem odpozoroval) 1:N nebo N:1 tzn. jedno katastralni uzemi muze tvorit vice casti obce nebo jedna obec / cast obce muze byt tvorena vice katastralnimi uzemimi format souboru je nasledujici: <project> <territory name="Mezim?st?"> <district country-region="Kr?lov?hradeck? kraj" region="Broumov" town="Mezim?st?" townDistrict="Mezim?st?" /> </territory> <territory name="Starost?n"> <district country-region="Kr?lov?hradeck? kraj" region="Broumov" town="Mezim?st?" townDistrict="Mezim?st?" /> </territory> <territory name="Trutnov"> <district country-region="Kr?lov?hradeck? kraj" region="Trutnov" town="Trutnov" townDistrict="Doln? p?edm?st?" /> <district country-region="Kr?lov?hradeck? kraj" region="Trutnov" town="Trutnov" townDistrict="Doln? Star? m?sto" /> </territory> <territory name="J?vka"> <district country-region="Kr?lov?hradeck? kraj" region="Trutnov" town="J?vka" /> </territory> </project> atribut name u elementu territory odpovida nazvu katastralniho uzemi z OSM atributy elementu district definuji oblast / cast obce z databaze [2] country-region -kraj region -oblast town -obec townDistrict -cast 4)Prirazeni adres z databaze bodum z mapy - program merge-cuzk-db.exe parametry: -addressesDB - XML soubor s databazi adres [2] -territories - OSM soubor s definovanymi katasrtalnimi uzemimi -addressPoints - CSV soubor z bodu 2) -mappings - XML soubor z bodu 3) -output - definuje umisteni a jmeno souboru ([path]/[output- filename-prefix]) priklad: merge-cuzk-db.exe -mappings ms.map -territories borders.osm -addressPoints ms.csv - addressesDB adresy.xml -output output/ms vystupem progamu jsou 3 soubory: [output-filename-prefix]-matched.osm - obsahuje body, kterym se podarilo jednoznacne priradit adresu [output-filename-prefix]-unmatched.osm - obsahuje body, kterym se nepodarilo jednoznacne priradit adresu [output-filename-prefix]-unmatched-ap.txt - obsahuje seznam adres, kterym se nepodarilo priradit zadny bod 5)Docisteni dat Data v souboru ...-matched.osm by mela byt v poradku, soubor obsahuje pouze adresni body, kterym se podarilo jednoznacne priradit adresu. Soubor ...-unmatched.osm je treba rucne zkontrolovat, obsahuje body, ke kterym se nepodarilo najit v databazi adresu. Vetsina z techto bodu jsou budovy bez c.p./c.e. (napr. garaze, ktere jsou na mape blizko, popisky se prekryvaji a ocr si s tim nedokaze poradit). Jak se vyporadat s nekonzistenci dat v KM a databazi adres je, jak uz jsem psal, otazkou diskuze. Soubor ...-unmatches-ap.txt - seznam adres z databaze MVCR, ke kterym se nepodarilo najit zadny bod na mape. 6) Docisteno, zkontrolovano - hura uplodovat na server :-) Lukas [1] http://lists.openstreetmap.org/pipermail/talk-cz/2009-June/003318.html [2] http://www.openstreetmap.org/?lat=50.5956&lon=16.2606&zoom=12&layers=B000FTF [3] http://aplikace.mvcr.cz/adresa/adresy.zip [4] http://osm.templ.net/kucr.osm.bz2

16.1.2010 07:31:40 (#2)
gravatar

hanoj

<ehanoj at gmail.com>
713
Ahoj, jenom strucne: 1) vyborne!!! zobrazit citaci
> [output-filename-prefix]-unmatched.osm - obsahuje body, kterym se nepodarilo > jednoznacne priradit adresu
2) ano, uploadovat s nejakym tagem o nesparovani. Databaze MVCR neni vubec autoritativni a uz vubec ne bez chyb. Nenalezenych 5% si myslim odhadem odpovida me zkusenosti... zobrazit citaci
> 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) 4) dal bys obsah toto webu na wiki stranku + odkaz na wikistranku "Czech Republic/freemap" diky a zdravi hanoj

16.1.2010 08:17:32 (#3)
gravatar

Martin Kupec

<magon at jkopava.cz>
36
On Sat, Jan 16, 2010 at 07:31:40PM +0100, hanoj wrote: zobrazit citaci
> 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)
Asi by stalo za to udelat presnejsi update stavu k.u. Katastralnich uzemi CR je 13027 a ja mam tabulku 12171 paru pozice <-> jmeno/cislo. Tohle je vysledek scriptu a jeste jej hodlam vylepsi, popripade dodelat zbylych cca 850 bodu rucne. 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. Ta posledni faze jeste nezacala, ale blizka se na lepsi casy. Martin Kupec

16.1.2010 09:36:27 (#4)
gravatar

hanoj

<ehanoj at gmail.com>
713
zobrazit citaci
> ? ? ? ?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.
*** aby nedoslo k mylce, konkretne na toto GRASS uz nepotrebujes. Muzes pracovat treba v pythonu s SHP formatem nebo s OSM. A zrejme nepujde o polygony ale o way v relaci... [1] http://osm.templ.net/kucr.png [2] http://osm.templ.net/kucr.osm.bz2 [3] http://osm.templ.net/kucr.shp_jtsk.tar.bz2 [4] http://osm.templ.net/kucr.shp_wgs84.tar.bz2 zdravi te hanoj

16.1.2010 11:56:28 (#5)
gravatar

Radomír Černoch

<radomir.cernoch at gmail.com>
139
Dobr? den, 2010/1/16 Lukas Kabrt <lukas at kabrt.cz>: zobrazit citaci
> 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?
Existuje mo?nost pou??t datab?zi ?esk? po?ty nam?sto datab?ze MV?R. Dle jejich vyj?d?en? je toti? mo?n? pou??vat data z adresy 'psc.cpost.cz' neomezen? bez jak?chkoli licen?n?ch podm?nek (na rozd?l od placen? datab?ze, kterou je zato mo?n? pou??vat off-line). Kvalitu datab?ze ?esk? po?ty nedok??i zcela posoudit. Jen v?m, ?e v n?kter?ch m?stech je p?esn?j?? ne? MV?R. Se strojov?m dotazov?n?m na web ?esk? po?ty jsem d??ve experimentoval s dobr?mi v?sledky. Pokud bude z?jem, po?lu skripty (je to hrozn? bastl BASH+XSTL+RUBY+JAVA, ale funguje). S pozdravem, Radom?r ?ernoch

18.1.2010 01:13:35 (#6)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
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. zobrazit citaci
>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

18.1.2010 09:11:46 (#7)
gravatar

Martin Kupec

<magon at jkopava.cz>
36
On Mon, Jan 18, 2010 at 01:13:35AM +0100, Lukas Kabrt wrote: zobrazit citaci
> 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 ...
Takze ti staci dodat ty bodiky? Ja se na ty mapy jeste nestihl podivat bohuzel. Martin Kupec

19.1.2010 09:11:03 (#8)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

19.1.2010 09:14:55 (#9)
gravatar

Jiri Parkan

<jparkan at gmail.com>
47
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>: zobrazit citaci
> 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 >

19.1.2010 09:51:46 (#10)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
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 Lukas 2010/1/19 Jiri Parkan <jparkan at gmail.com>: zobrazit citaci
> 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 >

20.1.2010 01:12:41 (#11)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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 On Tue, 19 Jan 2010 21:51:46 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote: zobrazit citaci
> 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
-- Petr Dlouh? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: debug.txt URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100120/3c7a4d83/attachment.txt>

20.1.2010 01:26:03 (#12)
gravatar

Aleš Janda

<openstreetmap at kyblsoft.cz>
85
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: zobrazit citaci
> 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 >

20.1.2010 02:18:10 (#13)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> 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?
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]. zobrazit citaci
> 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
... zobrazit citaci
> 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...
tile-processorby kdyztak slo upravit tak aby behal na .NET Framework 3.0, mozna i 2.0. Pro beh merge-cuzk-db.exe ale je .NET Framework 3.5 urcite potreba. Pro zpracovani XML souboru tam pozivam Xml.Linq a ten je az od .NET Framework 3.5. Zbezne jsem koukal na MONO a Xml.Linq tam je, takze pod MONO by to snad behat mohlo. [1] http://lkabrt.aspone.cz/osm/tile-processor.zip -- Lukas

20.1.2010 02:33:59 (#14)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Ahoj, d?ky za opravu, nyn? to vypad?, ?e se dostal o kousek d?l. Program vyp??e n?sleduj?c? hl??en?: mono tile-processor.exe -tiles output -output output.csv Processing tile: 14,6603_49,8538_14,6653_49,8588-budovy .. Performing OCR: 1/119xdg-open: unexpected argument '/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp' Try 'xdg-open --help' for more information. Unhandled Exception: System.IO.FileNotFoundException: Could not find file "/home/petr/soubory/nezarazeno/rsdosm/adresy/label.txt". File name: '/home/petr/soubory/nezarazeno/rsdosm/adresy/label.txt' at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share) [0x00000] at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) at System.IO.File.OpenRead (System.String path) [0x00000] at System.IO.StreamReader..ctor (System.String path, System.Text.Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize) [0x00000] at System.IO.StreamReader..ctor (System.String path) [0x00000] at (wrapper remoting-invoke-with-check) System.IO.StreamReader:.ctor (string) at CUZK.ExtractAddresses.TileAnalyzer.ExtractLabel (Point pt, System.Drawing.Bitmap map) [0x00000] at CUZK.ExtractAddresses.TileAnalyzer.Analyze (System.String filename) [0x00000] at CUZK.ExtractAddresses.Program.Main (System.String[] args) [0x00000] 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: mono tile-processor.exe -tiles output -output output.csv Processing tile: 14,6603_49,8538_14,6653_49,8588-budovy .. Performing OCR: 1/119xdg-open: unexpected argument '/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp' Try 'xdg-open --help' for more information. 2/119xdg-open: unexpected argument '/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp' Try 'xdg-open --help' for more information. 3/119xdg-open: unexpected argument '/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp' Try 'xdg-open --help' for more information. 4/119xdg-open: unexpected argument '/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp' Try 'xdg-open --help' for more information. 5/119xdg-open: unexpected argument '/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp' Try 'xdg-open --help' for more information. 6/119xdg-open: unexpected argument '/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp' Try 'xdg-open --help' for more information. 7/119xdg-open: unexpected argument '/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp' Try 'xdg-open --help' for more information. 8/119xdg-open: unexpected argument '/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp' Try 'xdg-open --help' for more information. 9/119xdg-open: unexpected argument '/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp' Try 'xdg-open --help' for more information. 10/119xdg-open: unexpected argument '/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp' Try 'xdg-open --help' for more information. 11/119xdg-open: unexpected argument '/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp' Try 'xdg-open --help' for more information. ...a tak po??d d?l. On Wed, 20 Jan 2010 14:18:10 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote: zobrazit citaci
> 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].
-- Petr Dlouh?

20.1.2010 03:06:44 (#15)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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 On Wed, 20 Jan 2010 13:26:03 +0100, Ale? Janda <openstreetmap at kyblsoft.cz> wrote: zobrazit citaci
> 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
-- Petr Dlouh?

20.1.2010 03:13:03 (#16)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Ahoj, 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. On Mon, 18 Jan 2010 01:13:35 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote: zobrazit citaci
> 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?

20.1.2010 04:35:58 (#17)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Ahoj, 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. On Wed, 20 Jan 2010 15:06:44 +0100, Petr Dlouh? <petr.dlouhy at email.cz> wrote: zobrazit citaci
> 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
-- Petr Dlouh? -------------- next part -------------- A non-text attachment was scrubbed... Name: output.csv Type: text/comma-separated-values Size: 8487 bytes Desc: not available URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100120/62a6a212/attachment.bin> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: debug.txt URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100120/62a6a212/attachment.txt>

20.1.2010 09:37:07 (#18)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
>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:
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 ... zobrazit citaci
>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.
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. zobrazit citaci
>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?
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. zobrazit citaci
>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.
Ty errory to vypisuje i na WIN, jedna se o nejaky problem v tesseract.exe, na strankach maji k tomu vytvoreny ticket, s tim ze program ale funguje spravne. [1] http://lkabrt.aspone.cz/osm/cuzk.zip -- Lukas

20.1.2010 10:49:12 (#19)
gravatar

Martin Kupec

<magon at jkopava.cz>
36
On Wed, Jan 20, 2010 at 09:37:07PM +0100, Lukas Kabrt wrote: zobrazit citaci
> 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? Kdyz jsem se snazil vytvorit seznam bodu kat. uz. tak jsem si s tim hral a jmena jsem vzdal a vytahl je z databaze podle cisel. Martin Kupec

20.1.2010 11:31:29 (#20)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> ? ? ? ?Muzu se zeptat, zda pouzivate nejak upraveny/nauceny tesseract > ? ? ? ?na ceske znaky, nebo to cestinu uspesne neumi?
Pro verzi 3.0 uz existuje i cestina. Verze 3.0 je v stadiu prerelease, nejsou pro ni binarky a tak je potreba si stahnou zdrojove kody [1] a zkompilovat. Soubor pro cestinu je v adresari tessdata tamtez (ces.traineddata). Nebude ale zpetne kompatibilni s tesseract 2.04. Puvodne jsem pozival verzi 2.04 ale tam jsem narazil na nejake problemy na starsich pocitacich s WinXP. Pro verzi 2.04 jsem mel vytvoreny vlastni jazyk, kde byly definovany pouze znaky ktere se vyskytuji na katastralni mape - bez?pe. 0123456789. Uspesnost rozpoznavani byla o neco lepsi nez ted s celou abecedou, ale to se da celkem dobre vykonpenzovat postprocesingem - stejne zamenuje porad stejne znaky jako o/0, ./_ apod. Chtel jsem si vytvorit vlastni jazyk i pro verzi 3.0 ale nenasel jsem k tomu zadny nastroj. [1] http://tesseract-ocr.googlecode.com/svn/trunk/ -- Lukas

20.1.2010 11:31:43 (#21)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

20.1.2010 11:36:54 (#22)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Tak jsem je?t? trochu hledal, a snad jsem nalezl ?e?en?. Vypad? to, ?e probl?m je zp?soben bugem [1], a workaround je uveden? v uk?zkov?m program? z p??lohy toho bugu. [1] https://bugzilla.novell.com/show_bug.cgi?id=385497 zobrazit citaci
> ------------ 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 > > >
Petr Dlouh? petr.dlouhy at email.cz

21.1.2010 04:50:15 (#23)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
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

21.1.2010 08:11:21 (#24)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
D?ky, te? to u? (p?es Wine) funguje. Na datech z Broumovska jsem vyzkou?el, ?e funguje i merge-cuzk-db. Poprosil bych tedy akor?t, jestli bys nemohl aplikovat workaround, kter? jsem pos?lal - aby ostatn? nemuseli slo?it? rozj??d?t Mono pod Wine. On Wed, 20 Jan 2010 21:37:07 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote: zobrazit citaci
> 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.
-- Petr Dlouh?

21.1.2010 08:23:39 (#25)
gravatar

Martin Kupec

<magon at jkopava.cz>
36
On Thu, Jan 21, 2010 at 04:50:15PM +0100, Lukas Kabrt wrote: zobrazit citaci
> 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.
Super. Ja zkusim stahnout tesseract 3.0. s cestinou a dodelat ty zbyvajici k.u. Myslim ze do konce vikendu bych to mohl zvladnout. Martin Kupec

21.1.2010 10:12:45 (#26)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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. On Wed, 20 Jan 2010 14:18:10 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote: zobrazit citaci
> 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].
-- Petr Dlouh?

22.1.2010 02:03:54 (#27)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> 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.
Ahoj, updatoval jsem zdrojaky [1] i zkompilovane soubory [2] u me na strankach, tak muzes stahovat. [1] http://lkabrt.aspone.cz/osm/cuzk-source.zip [2] http://lkabrt.aspone.cz/osm/cuzk.zip -- Lukas

22.1.2010 03:29:59 (#28)
gravatar

Jiri Parkan

<jparkan at gmail.com>
47
2010/1/21 Lukas Kabrt <lukas at kabrt.cz>: zobrazit citaci
> 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
Ahoj, 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?. Parkis zobrazit citaci
> > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

22.1.2010 03:42:58 (#29)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> 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?.
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. Dalsi moznost je pouzit osmosis [1]. Prikaz pro orez bude neco jako osmosis --read-xml file=test.osm --sort-0.6 --bounding-box top=50.69 left=15.76 bottom=50.27 right=16.5 clipIncompleteEntities=true --write-xml file=result.osm Nekdo me treba doplni s dalsimi moznostmi. [1] http://wiki.openstreetmap.org/wiki/Osmosis -- Lukas

22.1.2010 09:46:24 (#30)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Ahoj, m?l bych je?t? jednu ot?zku: 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). On Wed, 20 Jan 2010 21:37:07 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote: zobrazit citaci
> 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.
-- Petr Dlouh?

23.1.2010 12:47:38 (#31)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
J? je?t? dopln?, ?e je nutn? je?t? nechat naj?t "selected | parent selected", aby se vybrali i relace. On Fri, 22 Jan 2010 15:42:58 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote: zobrazit citaci
> 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.
-- Petr Dlouh?

23.1.2010 11:07:26 (#32)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> 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).
Ano vim o tom, ze cim vetsi rozliseni, tim mensi cisla a tim padem i mensi riziko prekryvu. Nijak exaktne jsem to nemeril, ale pro to meritko, ktere jsem zvolil se mi zda uspesnot dostatecna i pro mesta, kde jsou budovy "nalepeny" na sebe. Nejvetsi procento chyb pripada na budovy bez cp/ce - bloky garazi apod. Slo mi o to najit rozumny kompromis mezi prekryvem napisu a mnozstvi dlazdic, ktere je potreba zpracovat. 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) -- Lukas

23.1.2010 11:41:20 (#33)
gravatar

Martin Kupec

<magon at jkopava.cz>
36
On Sat, Jan 23, 2010 at 11:07:26AM +0100, Lukas Kabrt wrote: zobrazit citaci
> 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)
Presne tohle reseni delam u katastralnich uzemi. Ale tech je pouze cca 13k v republice, takze tam to funguje pekne. Martin

23.1.2010 06:14:37 (#34)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Zdrav?m, m?m probl?m s pou?it?m poloautomatick?ho importova?e z katastr?ln? mapy. Zkou?el jsem to na uk?zkov?m ?zem?. V?stup z kroku 2 se zd? b?t v pohod? (n?jak? drobn? chyby v rozpozn?v?n?, ale to se dalo ?ekat): 50.4860413,16.1035088,?.p.256 50.4861788,16.1038375,?.p.251 50.4863550,16.1043138,?.p.250 50.4862125,16.1050900,bez ?.p./?.e. ... Zde je mi zcela jasn? princip ... st?hnou se p??slu?n? dla?dice v PNG, najdou se tam te?ky, vyseknou popisky do mal?ch bitmap, nechaj? rozpoznat pomoc? OCR a popisky spolu se sou?adnicemi te?ky se zap??? do souboru. D?le u? se trochu ztr?c?m. 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??. Jinak ??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. Pro pokus jsem vzal XML soubor z dokumentace cuzk-postup.txt. 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. Pak -addressesDB - XML soubor s databazi adres [2] -territories - OSM soubor s definovanymi katasrtalnimi uzemimi -addressPoints - CSV soubor z bodu 2) -mappings - XML soubor z bodu 3) Tak?e jako prvn? parametr jsem dal soubor address.xml. U druh?ho parametru nev?m. Zkou?el jsem http://osm.templ.net/kucr.osm.bz2 a http://lkabrt.aspone.cz/osm/kucr.zip. T?et? parametr je asi jasn? - ten CVS vygenerovan? z jednom z p?edchoz?m kroku. ?tvrt? parametr - to je to XML p?evzat? pro pokus z dokumentace. A po spu?t?n? merge to d?l? toto: 1) V p??pad? pou?it? http://osm.templ.net/kucr.osm.bz2 program skon?? v?jimkou p?i Matching building definition points with addresses DB ...: Neo?et?en? v?jimka: System.InvalidOperationException: Posloupnost neobsahuje ??dn? prvky. v System.Linq.Enumerable.Single[TSource](IEnumerable`1 source) v CUZK.MergeDBWithPoints.AddressesFinder.Initialize(Dictionary`2 unassignedBuildngDefinitionPoints, Dictionary`2 unassignedAddressPoints) v CUZK.MergeDBWithPoints.AddressesFinder.FindAddressesAssignment() v CUZK.MergeDBWithPoints.Program.Main(String[] args) 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. D?ky p?edem za odpov?di Honza

23.1.2010 08:40:13 (#35)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> 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.
zobrazit citaci
> 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. zobrazit citaci
> ??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. zobrazit citaci
>kter?ch jsou tis?ce(?)
Presne 13027. zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci ten muzes pouzit, ale je potreba zkotrolovat, jestli tam je zadany to k.u. o ktery se zajimas - nazvy jeste nejsou kompletni. zobrazit citaci
> ?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. zobrazit citaci
> 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. zobrazit citaci
> 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

23.1.2010 09:50:19 (#36)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Na kontrolu naimportovan?ch adresn?ch bod? pln? posta?uje plugin Czechaddress do JOSM. Poloautomatick? obkreslov?n? by asi taky bylo nejlep?? ud?lat formou pluginu do JOSM. On Sat, 23 Jan 2010 18:14:37 +0100, Jan Bilak <jan.bilak.osm at gmail.com> wrote: zobrazit citaci
> 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.
-- Petr Dlouh?

23.1.2010 09:50:22 (#37)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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.
-- Petr Dlouh?

23.1.2010 09:53:51 (#38)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Omlouv?m se, po??dn? jsem si to nep?e?etl. Pou?iju samoz?ejm? to ze str?nek CUZK. On Sat, 23 Jan 2010 21:50:22 +0100, Petr Dlouh? <petr.dlouhy at email.cz> wrote: zobrazit citaci
> 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. > >
-- Petr Dlouh?

24.1.2010 02:08:17 (#39)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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

24.1.2010 02:14:18 (#40)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

24.1.2010 02:19:01 (#41)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >

24.1.2010 02:27:55 (#42)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >> >

24.1.2010 02:35:26 (#43)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Padat by nem?l (nev?m, co ??k?, m??e? se pokusit nahl?sit chybu), a datab?zi pokud v?m nepot?ebuje. U? jsem ho dlouho nepou?il, i ten kucr.zip se mi da?? pom?rn? dob?e vyst??hout i pomoc? JOSM (a to m?m docela star? po??ta?). Ono toti? kdy? se to zv?t?? (nen? zobrazen? cel? mapa nar?z), tak u? to jede docela rychle. On Sun, 24 Jan 2010 02:19:01 +0100, Jan Bilak <jan.bilak.osm at gmail.com> wrote: zobrazit citaci
> 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 >
-- Petr Dlouh?

24.1.2010 02:44:11 (#44)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

24.1.2010 03:12:20 (#45)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Ahoj, d?ky, u? se mi poda?ilo. Jeden post?eh je ten, ?e soubor mapov?n? nesm? obsahovat nic nav?c, ne? je nutn?. Pokud je tam n?jak? mapov?n? nav?c (neexistuje k tomu katastr?ln? ?zem? v *.osm mapce apod.), tak to p?i mergov?n? spadne. Honza 2010/1/23 Lukas Kabrt <lukas at kabrt.cz>: zobrazit citaci
>> 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 >

24.1.2010 03:54:13 (#46)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >

24.1.2010 04:46:05 (#47)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Ahoj. K vyu?it? dat z ?S? ... na str?nce: http://www.czso.cz/csu/redakce.nsf/i/zasady_cenove_strategie_v_csu_ se p??e: "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." Pod "sv?m ??elem" si mohu p?edstavit kde co ... t?eba vytv??en? open source mapy. Patrn? nejde jen o osobn? vyu?it?, tam by nem?lo smysl uv?d?t zdroj. 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 Honza 2010/1/24 Jan Bilak <jan.bilak.osm at gmail.com>: zobrazit citaci
> 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 >> >

24.1.2010 08:09:57 (#48)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> > "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?

24.1.2010 08:46:16 (#49)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
On Sun, 24 Jan 2010 03:54:13 +0100, Jan Bilak <jan.bilak.osm at gmail.com> wrote: zobrazit citaci
> 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?
J? vid?m zat?m nejv?t?? probl?m ve v?po?etn? n?ro?nosti cel?ho procesu (m? velmi hrub? odhady se pohybuj? od 50 do 100 hodin jenom pro 2. f?zi). Mo?n? by bylo lep?? ud?lat n?co ve stylu Seti at home - rozd?lit republiku na ?tverce rozumn? velikosti (zpracov?n? ~1 hodina). Program by si zjistil, kter? ?zem? je?t? chyb?, a uploadnul n?kam by v?sledn? soubory (asi ty 3 .osm + .csv). A? by to bylo hotov?, tak by se to rozsekalo na men?? celky (nap??klad ORP), a lidi by to mohli manu?ln? kontrolovat a uploadovat. Manu?ln? kontrolu jde bez probl?mu prov?st v JOSM, dokonce i p?vodn? OCRkovan? text je tam vid?t. Kontrola by taky ?la zv??it vytvo??n?m n?jak? str?nky ve stylu <http://tools.geofabrik.de/osmi/>, kter? by porovn?vala datab?ze adres s OSM. Dlouhodob? hledisko bych p??li? ne?e?il, proto?e dal?? korekce adresn?ch bod? prob?hne nejd??ve za rok, a to m??e b?t situace ?pln? jin? (m??e b?t dostupn? n?jak? dostupn? datab?ze, WMS katastr?ln?ho ??adu se m??e zm?nit, ...). zobrazit citaci
> > 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? > - ... >
Zakreslov?n? dom? je, mysl?m, ?pln? jin? poh?dka. Ta mapa je slo?en? z ??st?, kter? byli kresleny ru?n? snad je?t? za Rakouska Uherska a z ??st?, kter? vznikly renderingem vektorov? KM. Nev?m tak?, jak je to s dostupnost? vektorov? KM. N?vaznost na adresn? body bych moc ne?e?il, jinak moc nev?m, jak to ud?lat. Asi bych ale asi ned?lal vlastn? GUI, ale ?e?il to taky formou pluginu do JOSM, proto?e s t?m um? pracovat asi nejv?c lid? a u? je tam plno n?stroj? implementovan?ch. zobrazit citaci
> 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, ... >
Czechadress je ur?en na manu?ln? dola?ov?n? adres s pomoc? datab?ze MV?R (tedy byl ur?en i na hromadn? zan??en? bod?, ale to te? odpad?). zobrazit citaci
> 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?.
Vy?e?it poloautomatick? rozpozn?v?n? budov z katastr?ln? mapy by bylo jist? p??nosn?. Chce to ale prozkoumat v?echny mo?nosti (vektorov? KM, nen? mi moc jasn? jak by to m?lo fungovat). Pak je tady spousta dal??ch v?c?: -Export mapov?ch zna?ek z Wiki do XML (pro mo?nosti dal??ho vytv??en? -Kontrolor relac? (seznam relac? ve stylu [1] + historie) -Kontrolor v?eho mo?n?ho co je?t? kontrolov?no nen? -Dod?l?n? paraleln?ch turistick?ch tras ve stylu seznam.cz do Mapniku (Osmarenderu) -Dal?? pr?ce na OpenTrackMap -Dal?? renderery v?c?, kter? je?t? renderov?ny nejsou [1] http://wiki.openstreetmap.org/wiki/Cyklotrasy_v_?R zobrazit citaci
> 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 >
-- Petr Dlouh?

24.1.2010 09:05:25 (#50)
gravatar

Petr Dlouhý

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

24.1.2010 10:28:05 (#51)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> 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.
Urcite funguje i bez DB. pouzivam vyvojovou verzi 0.33 [1] a funguje bez problemu. Musel jsem ale pouzit soubor osmosis.bat z predchozi verze a dopnit do promenne EXEC pridat chybejci knihovnu commons-compress-1.0.jar [1] http://dev.openstreetmap.de:23457/hudson/job/osmosis-SNAPSHOT-ant/lastSuccessfulBuild/artifact/trunk/dist/ -- Lukas

24.1.2010 10:37:08 (#52)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> 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?.
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

24.1.2010 10:53:38 (#53)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> 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

24.1.2010 10:58:05 (#54)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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.
-- Petr Dlouh?

24.1.2010 11:09:38 (#55)
gravatar

Kubajz

<kubajz at kbx.cz>
614
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): zobrazit citaci
> 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. >> > >

24.1.2010 11:15:03 (#56)
gravatar

Aleš Janda

<openstreetmap at kyblsoft.cz>
85
Ahoj, j? bych se klidn? p?idal. Pendluju mezi 2j?drem a 3j?drem, ob? pom?rn? v?konn? a m?lo vyu?it? :-) V?kon te? v?nuju tiles at home, ale v tomhle vid?m v?t?? smysl. Sta?ilo by, kdyby n?s bylo p?r, a do dvou t?dn? bysme to m?li :-) Program by m?l j?t ale p?eru?it a znova obnovit, nem?l by to b?t jeden velk? cyklus, aby ?lo p?ech?zet mezi po??ta?i. Jinak jak tu tak sleduju diskusi, tak velice chv?l?m va?e po?iny :-) Ale? Janda On 24.1.2010 10:58, Petr Dlouh? napsal/a: zobrazit citaci
> 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. > >

24.1.2010 11:21:23 (#57)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Na OCR by pam?? nen? moc pot?eba. Klidn? to tam rozb?hnu. On Sun, 24 Jan 2010 11:09:38 +0100, Kubajz <kubajz at kbx.cz> wrote: zobrazit citaci
> 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...
-- Petr Dlouh?

24.1.2010 11:21:27 (#58)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Pam?? nen? moc pot?eba, tak?e to stejn? potrv? kolem 20 dn?. Klidn? to tam rozjedu, ale stejn? se to mus? rozd?lit do ?tverc? o ur?it? rozloze. On Sun, 24 Jan 2010 11:09:38 +0100, Kubajz <kubajz at kbx.cz> wrote: zobrazit citaci
> 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. >>
-- Petr Dlouh?

24.1.2010 12:03:01 (#59)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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.). Honza 2010/1/24 Petr Dlouh? <petr.dlouhy at email.cz>: zobrazit citaci
> 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 >

24.1.2010 12:07:32 (#60)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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): zobrazit citaci
>> 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 >

24.1.2010 12:18:04 (#61)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Tady je .NET? wrapper nad DLL. Ale p??? tam, ?e Tesseract m? memory leaky, tak?e to ?as o ?asu spadne. Ale n?jak? d?vky (v?ce popisk? najednou) by to mohlo zvl?dnout. http://www.pixel-technology.com/freeware/tessnet2/ Honza 2010/1/24 Jan Bilak <jan.bilak.osm at gmail.com>: zobrazit citaci
> 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 >> >

24.1.2010 03:20:08 (#62)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Ahoj, sta?? pou??t Dictionary, a u? to funguje rozum? rychle (i kdy? cel? ?R asi je?t? ne - po minut? mi zabrala celou pam??). Opravil jsem i p?dy p?i chyb?j?c?ch relac?ch, i kdy? oprava je dost quick&dirty. Pos?l?m zdroj?ky zm?n?n?ch soubor? i funk?n? program. On Sun, 24 Jan 2010 10:37:08 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote: zobrazit citaci
> > 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
-- Petr Dlouh? -------------- next part -------------- A non-text attachment was scrubbed... Name: CUZK.MergeDBWithPoints1.tar.gz Type: application/x-gzip Size: 30465 bytes Desc: not available URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100124/8dd8ea8c/attachment.bin>

24.1.2010 03:46:20 (#63)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Ahoj, sta?? pou??t Dictionary, a u? to funguje rozum? rychle (i kdy? cel? ?R asi je?t? ne - po minut? mi zabrala celou pam??). Opravil jsem i p?dy p?i chyb?j?c?ch relac?ch, i kdy? oprava je dost quick&dirty. Pos?l?m zdroj?ky zm?n?n?ch soubor? i funk?n? program. On Sun, 24 Jan 2010 10:37:08 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote: zobrazit citaci
> > 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
-- Petr Dlouh? -------------- next part -------------- A non-text attachment was scrubbed... Name: CUZK.MergeDBWithPoints.tar.gz Type: application/x-gzip Size: 20594 bytes Desc: not available URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100124/d6bf63aa/attachment.bin>

24.1.2010 06:33:51 (#64)
gravatar

hanoj

<ehanoj at gmail.com>
713
zobrazit citaci
> 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.).
*** take to tak vnimam, zvlaste po rozhovorech s VUV TGM... Oni neco jako open source neznaji a nemluvi k nemu. hanoj

24.1.2010 06:40:43 (#65)
gravatar

hanoj

<ehanoj at gmail.com>
713
zobrazit citaci
> 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
*** ty mapy jsou mashup. Velka cast se taha z CUZK! hanoj

26.1.2010 10:50:12 (#66)
gravatar

Karel Volný

<kavol at seznam.cz>
526
Dne Ne 24. ledna 2010 Petr Dlouh? napsal(a): zobrazit citaci
> 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.

26.1.2010 11:41:15 (#67)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
OK, tak?e rozum? automaticky jdou ud?lat prvn? dva kroky - t?et? krok je taky mo?n?, ale jen pro ta ?zem?, kter? nen? nutn? manu?ln? rozd?lovat. Cht?lo by to tedy ur?it rozum? velkou jednotu zpracov?n? - oblast jej?? zpracov?n? trv? zpracovat n?jak? rozumn? ?as (nap?. 1 hodinu). D?le pak vytvo?it skripty, kter? budou volat ty programy. Klidn? takov? skript pro Linux vytvo??m, kdy? budu zn?t velikost jednotky. Jinak to Qemu je kv?li bezpe?nosti? Ten program toti? jinak na Linuxu chod?. zobrazit citaci
> ------------ 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 > > >
Petr Dlouh? petr.dlouhy at email.cz

26.1.2010 12:52:40 (#68)
gravatar

Karel Volný

<kavol at seznam.cz>
526
... zobrazit citaci
> Jinak to Qemu je kv?li bezpe?nosti? Ten program toti? jinak na Linuxu > chod?.
tak n?jak ... a kv?li pohodl? s t?m, jak hladce nyn? virtualizace jde, jsem si n?jak navykl rozch?zet v?ci na ?ist? instalaci (nap?. pokud si nebudu cht?t nab?t hubu jako o V?noc?ch s OTM, nen? nic jednodu???ho ne? nahodit virtualizovan? Ubuntu nebo na ?em autor postup vyladil, zat?mco na desktopu mi d?l bude spokojen? chroupat Gentoo); nav?c jde-li o n?co, co trv? d?le a nelze p?eru?it, nen? t?eba m?t re?ln? stroj po??d online, virtu?ln? se d? v mezi?ase zmrazit K.

26.1.2010 02:58:09 (#69)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
On Thu 2010-01-21 16:50:15, Lukas Kabrt wrote: zobrazit citaci
> 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

26.1.2010 03:02:12 (#70)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
?ti d?l: http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004354.html zobrazit citaci
> ------------ 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 > > >
Petr Dlouh? petr.dlouhy at email.cz

26.1.2010 08:10:09 (#71)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
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

26.1.2010 09:41:14 (#72)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Ahoj, 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. Honza 2010/1/26 Lukas Kabrt <lukas at kabrt.cz>: zobrazit citaci
> 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 >

26.1.2010 10:23:54 (#73)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
D?ky za synchronizaci postupu. On Tue, 26 Jan 2010 20:10:09 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote: 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. zobrazit citaci
> 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)
Bohu?el Mono pro Win narozd?l od Mona pro Linux pou??v? nativn? Windowsov? knihovny (Mono pro Linux pou??v? m?sto nich knihovny Mona), tak?e se v?sledek m??e li?it. A? se k tomu dostanu, tak to vyzkou??m. zobrazit citaci
> 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?

26.1.2010 10:40:31 (#74)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> 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.
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 verze. -- Lukas

26.1.2010 10:52:29 (#75)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> 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

26.1.2010 10:54:59 (#76)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Ok, kdy? jsi schopn? to kontrolovat v JOSM, tak nen? probl?m. Ale nezapome?, ?e toho bude spousta. Honza 2010/1/26 Lukas Kabrt <lukas at kabrt.cz>: zobrazit citaci
>> 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 >

26.1.2010 10:57:44 (#77)
gravatar

Jiri Parkan

<jparkan at gmail.com>
47
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 . ale z?stane po n?m jen kupa tif? a vysledek nikde. Tak nev?m co d?l?m ?patn? :)

26.1.2010 11:04:20 (#78)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
2010/1/26 Jiri Parkan <jparkan at gmail.com>: zobrazit citaci
> 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

26.1.2010 11:04:39 (#79)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Jo, je?t? jsem ud?lal jednu zm?nu v merge skriptu. ?asto se stalo, ?e p?i OCR eviden?n?ch ??sel to vynechalo ob? te?ky, tak?e by merge m?l rozpoznat i "?e70". On Tue, 26 Jan 2010 22:40:31 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote: zobrazit citaci
> 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
-- Petr Dlouh?

26.1.2010 11:35:07 (#80)
gravatar

Jiri Parkan

<jparkan at gmail.com>
47
Sypu si popel na hlavu, n?jak jsem opomn?l rozbalit adres?? testdata. Te? u? v?e funguje jak m?, z?tra snad dod?m n?jak? v?sledky. 2010/1/26 Lukas Kabrt <lukas at kabrt.cz>: zobrazit citaci
> 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 >

27.1.2010 11:26:58 (#81)
gravatar

Jakub Sýkora

<kubajz at kbx.cz>
614
Pro potreby komunity jsem dnes predal pristup Petrovi Dlouhemu na server s 4 x 3.4GHz Xeon s 4GB pameti. Doufam, ze to pomuze k rychlejsimu vyreseni nasich potreb :) K P.S.: Presneji jsou to jen dve dvoujadra Kubajz napsal(a): zobrazit citaci
> 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 >

27.1.2010 12:31:14 (#82)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Dovolil bych si je?t? jednu pozn?mku. Program si ukl?d? pomocn? soubory do aktu?ln?ho adres??e s konstantn?m jm?nem (pokud se od minul? verze nic nezm?nilo). Jestli tomu dob?e rozum?m, tak nemohu spustit v?c instanc? t?ch skript? v jednom adres??i bez toho, aby se nepopraly (budou si OCRkovat ??sla navz?jem). 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? On Tue, 26 Jan 2010 20:10:09 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote: zobrazit citaci
> 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
-- Petr Dlouh?

27.1.2010 01:30:45 (#83)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> 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?
Ne, uz to tak neni, jen jsem to zapomnel zapsat do provedenych zmen. Program si uklada pomocne soubory stale do aktualniho adresare, ale pod unikatnim jmenem (GUID), takze bez problemu muze bezet vice instanci v jednom adresari. -- Lukas

27.1.2010 02:21:37 (#84)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Ahoj, tak v?po?et u? zat??uje v?echna 4 j?dra na Kubajzov? stroji. Ud?lal jsem si na to skripty, kter?m sta?? jen p?edhodit rozsah dla?dic, a ony pak u? v?e ud?laj? samy. Nejsou n?jak ??asn?, ale mohlo by to n?komu u?et?it pr?ci, tak?e jsou v p??loze. -- Petr Dlouh? -------------- next part -------------- A non-text attachment was scrubbed... Name: tile-do.sh Type: application/octet-stream Size: 502 bytes Desc: not available URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100127/d74ee818/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: tile-more.sh Type: application/octet-stream Size: 57 bytes Desc: not available URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100127/d74ee818/attachment-0001.obj>

27.1.2010 05:38:52 (#85)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

27.1.2010 05:47:01 (#86)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Nem?m zku?enost ... ale nepomohlo by t?eba toto? http://www.remotesensing.org/libtiff/man/tiffcp.1.html Honza 2010/1/27 Petr Dlouh? <petr.dlouhy at email.cz>: zobrazit citaci
> 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 >

29.1.2010 05:28:48 (#87)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
2010/1/27 Petr Dlouh? <petr.dlouhy at email.cz>: zobrazit citaci
> 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

29.1.2010 09:35:31 (#88)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Ahoj, d?ky - vypad? to, ?e to funguje (tedy musel jsem updatovat tesseract z verze 2.03 na 2.04). On Fri, 29 Jan 2010 17:28:48 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote: zobrazit citaci
> 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
-- Petr Dlouh?

2.2.2010 09:59:03 (#89)
gravatar

Martin Kupec

<magon at jkopava.cz>
36
On Tue, Jan 26, 2010 at 08:10:09PM +0100, Lukas Kabrt wrote: zobrazit citaci
> 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. Az dodelam poslednich par tilu, tak to cele nejak uploadtnu a na wiki dam odkaz. Martin Kupec

2.2.2010 10:04:40 (#90)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> ? ? ? ?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

2.2.2010 10:07:50 (#91)
gravatar

Martin Kupec

<magon at jkopava.cz>
36
On Tue, Feb 02, 2010 at 10:04:40AM +0100, Lukas Kabrt wrote: zobrazit citaci
> > ? ? ? ?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.
Ok super. Asi nejsem sam kdo sem tam ma chybu. Uvazoval jsem jestli neco takoveho nezbastlit, ale pak me napadlo ze uz to mozna nekdo udelal. Moje vysledky poslu nekdky k veceru. Jeste to zpracovava 3 tily, tak to necham dobehnout a vecer to uploaduju. Martin

2.2.2010 01:31:25 (#92)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Ahoj, 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. zobrazit citaci
> ------------ 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 > > >
Petr Dlouh? petr.dlouhy at email.cz

2.2.2010 06:31:54 (#93)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> 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.
Koukal jsem kolika pripadu by se to tykalo a pokud za spravne rozpoznane budeme povazovat i ruzne varianty (ce, c.e, ce., apod.) tak to odhaduju na cca 200 000 pripadu. To by se asi dalo zvladnout. Schvalne zkusim neco vytvorit ... -- Lukas

2.2.2010 10:52:06 (#94)
gravatar

Martin Kupec

<magon at jkopava.cz>
36
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

3.2.2010 05:57:15 (#95)
gravatar

Kubajz

<kubajz at kbx.cz>
614
No ja jsem se vcera od kamarada dozvedel, ze v dohledne dobe dostaneme ctyrXeon s 30GB pameti. Takze az zase nekdo vymysli nejakou takovouhle ptakovinu, tak procesoru bude dost :) K Dne 2.2.2010 22:52, Martin Kupec napsal(a): zobrazit citaci
> 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 >

3.2.2010 07:39:02 (#96)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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. On Tue, 02 Feb 2010 22:52:06 +0100, Martin Kupec <magon at jkopava.cz> wrote: zobrazit citaci
> 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?

3.2.2010 08:45:09 (#97)
gravatar

Martin Kupec

<magon at jkopava.cz>
36
On Wed, Feb 03, 2010 at 07:39:02AM +0100, Petr Dlouh? wrote: zobrazit citaci
> 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.
Ok, pracuje se na tom. Martin

10.2.2010 01:48:34 (#98)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

11.2.2010 06:13:22 (#99)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

11.2.2010 06:29:27 (#100)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >

11.2.2010 06:40:51 (#101)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

11.2.2010 06:47:45 (#102)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Ahoj, jasn? ... to je dobr? ot?zka. Ale ono by to neznamelalo to cel? p?ed?lat. Prakticky by to bylo sp??e roz???en? st?vaj?c?ho. Jen m?sto zavol?n? extern?ho OCR by se zavolalo jedno??elov? "intern? OCR". Honza 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>: zobrazit citaci
> 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 >

11.2.2010 07:36:13 (#103)
gravatar

Stanislav Brabec

<utx at penguin.cz>
152
Petr Dlouh? p??e v ?t 11. 02. 2010 v 18:13 +0100: zobrazit citaci
> 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? -- Stanislav Brabec http://www.penguin.cz/~utx

11.2.2010 08:15:59 (#104)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> Ne?lo by program nau?it spr?vn? pozn?vat dvojku, kter? splynula > s te?kou?
-- Petr Dlouh?

11.2.2010 08:30:56 (#105)
gravatar

Stanislav Brabec

<utx at penguin.cz>
152
Petr Dlouh? p??e v ?t 11. 02. 2010 v 20:15 +0100: zobrazit citaci
> Nerozum?m. Probl?m o kter?m jsem mluvil je, ?e to pozn? dvojku, kter? byl > u??znut spodek jako sedmi?ku.
Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat u??znutou dvojku? Pokud to ov?em nezv??? riziko chyby jinde. zobrazit citaci
> 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? > >
-- Stanislav Brabec http://www.penguin.cz/~utx

11.2.2010 08:49:44 (#106)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

12.2.2010 04:25:19 (#107)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >

12.2.2010 02:11:48 (#108)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

12.2.2010 03:39:54 (#109)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >

12.2.2010 04:50:30 (#110)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

12.2.2010 04:54:47 (#111)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >

12.2.2010 07:32:38 (#112)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >> >

12.2.2010 07:46:17 (#113)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Doplnil jsem tam chyb?j?c? ??slici 4. Honza 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>: zobrazit citaci
> 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 >>> >> >

12.2.2010 10:05:40 (#114)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >>>> >>> >> >

13.2.2010 12:28:20 (#115)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

13.2.2010 12:38:12 (#116)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >

13.2.2010 12:44:56 (#117)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >> >

13.2.2010 01:02:58 (#118)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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. zobrazit citaci
> ------------ 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

13.2.2010 01:05:07 (#119)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Ty body, kter? nemaj? rozpoznan? popisky, jsou mysl?m p??li? u kraje. Tedy nyn? tam m?m n?jak? tvrd? limit podle vzd?lenosti bodu od kraje (tu??m 120px od prav?ho okraje, a cca 20 od horn?ho). Na plo?e, kde to m? rozpozn?vat, je t?eba se dohodnout. Pokud m?? n?jak? p??pad, kter? nen? takto bl?zko kraje, tak mi pros?m po?li dla?dici. P?id?m tamk takov?m bod?m zat?m popisek [out-of-box] do csv souboru. A ocen?m i zasl?n? dla?dice, kde bod nebyl nalezen v?bec. Honza 2010/2/13 Jan Bilak <jan.bilak.osm at gmail.com>: zobrazit citaci
> 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 >>> >> >

13.2.2010 01:10:29 (#120)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >

13.2.2010 01:13:59 (#121)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Dal jsem tam betu 2 ... http://jabi.aspone.cz/osm/OcrBeta2.zip Je v?cevl?knov?, trochu p?epracovan? v?pis do konzole (?asov? odhad do konce apod.). + zapisuje do csv souboru info o tom, ?e bod je moc bl?zko kraje dla?dice. Honza 2010/2/13 Jan Bilak <jan.bilak.osm at gmail.com>: zobrazit citaci
> 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 >> >

13.2.2010 01:28:39 (#122)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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. 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. On Sat, 13 Feb 2010 00:28:20 +0100, Petr Dlouh? <petr.dlouhy at email.cz> wrote: zobrazit citaci
> -?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
-- Petr Dlouh?

13.2.2010 01:28:42 (#123)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

13.2.2010 01:32:41 (#124)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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 2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>: zobrazit citaci
> 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 >

13.2.2010 01:58:07 (#125)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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 2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>: zobrazit citaci
> 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 >

13.2.2010 02:07:28 (#126)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Ahoj, na?el jsem p??pad, kdy se slila dv? ??sla dohromady (testov?no v bet? 1) - je to na dla?dici [1], ??slo 2341. Nevid?m d?vod, pro? by se vlastn? m?ly ta ??sla prodlu?ovat nebo zkracovat o dal?? ??slice - pokud se tam p?iplete dal?? adresn? bod ve stejn?m m?st?, m?lo by se tam p?ipl?st i "?" nebo "b", tak?e by se nem?l p?i Merge v?bec p?i?adit -> jde to opravit ru?n? (a sta?? tedy minimalizovat po?et p??pad? na ?nosnou mez). Zkracovat by se snad nem?lo to ??slo nikdy (pokud skon??me v?as p?ed prav?m okrajem), pokud tam bude velk? zmatek, tak se ve v?sledku m??e objevit nanejv?? "?". Zm?nit snad tak? ne. Pos?l?m testovac? data (m?l by to b?t cel? okres Praha-z?pad) na [2]. Zkou?el jsem betu 2, ale m? probl?m s pam?t? - kdy? to generuju na velk? oblasti, tak po n?jak? dob? spadne na zapln?n? pam?ti. Beta 1 byla v po??dku. [1] http://www.flyshare.cz/stahni/46190/14.2327_50.0796_14.2377_50.0846-budovy.png [2] http://www.flyshare.cz/stahni/46188/pz.tar.bz2 On Sat, 13 Feb 2010 01:32:41 +0100, Jan Bilak <jan.bilak.osm at gmail.com> wrote: zobrazit citaci
> 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
-- Petr Dlouh?

13.2.2010 03:01:44 (#127)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

13.2.2010 03:02:58 (#128)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Ahoj, d?ky, kouknu se na to, kde je probl?m. Honza 2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>: zobrazit citaci
> 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 >

13.2.2010 03:04:33 (#129)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Omlouv?m se. To nen? chyba - Merge nevygeneruje pro "bez ?.p./?.e." ??dn? bod, tak?e je v?echno v po??dku. zobrazit citaci
> ------------ 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: >

13.2.2010 03:07:15 (#130)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
OK, nic se nestalo. Hlavn?, ?e se to vyjasnilo. Honza 2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>: zobrazit citaci
> 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 >

13.2.2010 03:26:47 (#131)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> Pos?l?m testovac? data (m?l by to b?t cel? okres Praha-z?pad) na [2].
-- Petr Dlouh?

13.2.2010 05:46:34 (#132)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >

13.2.2010 06:10:37 (#133)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Je?t? jsem tam hodil malinko opravenou betu3 (na stejn? m?sto) - oprava "pad?n?". Honza 2010/2/13 Jan Bilak <jan.bilak.osm at gmail.com>: zobrazit citaci
> 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 >> >

13.2.2010 06:47:20 (#134)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> Je?t? jsem tam hodil malinko opravenou betu3 (na stejn? m?sto) - > oprava "pad?n?". > Honza
-- Petr Dlouh?

13.2.2010 06:54:12 (#135)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Ahoj, mne se stalo n?co podobn?ho, kdy? jsem tam nechal v adres??i PNG?ko, kter? jsem generoval z p?vodn?ch PNG tak, ?e jsem tam dopl?oval modr? te?ky (kv?li hled?n? toho chyb?j?c?ho bodu, kter? nakonec nechyb?l). Ale to mi sp??e za?alo stra?n? rychle plnit log. 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?). Jinak v?sledky jsou podle mne velmi p?kn? ... asi 9 bod? k ru?n? kontrole z cca 3000 dla?dic a n?jak?ch 50000 bod?. A to je v Praze, kde jsou p?ekryvy ?ast?j?? ne? na venkov?. Honza 2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>: zobrazit citaci
> 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 >

13.2.2010 07:05:00 (#136)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
J? mysl?m, ?e by se?ral klidn? i 4 GB - on prost? najednou za?ne ?r?t na ka?dou dla?dici t?eba 100 MB nav?c (p?ed t?m ale 10 minut po??tal v po??dku). Samoz?ejm?, ?e kdy? v?echno se?ere, tak ho shod?m, nebo spadne s?m. On Sat, 13 Feb 2010 18:54:12 +0100, Jan Bilak <jan.bilak.osm at gmail.com> wrote: zobrazit citaci
> 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?).
-- Petr Dlouh?

13.2.2010 07:07:55 (#137)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >

13.2.2010 07:31:55 (#138)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >> >

13.2.2010 07:39:10 (#139)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >>> >> >

14.2.2010 06:40:26 (#140)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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 2010/2/13 Jan Bilak <jan.bilak.osm at gmail.com>: zobrazit citaci
> 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 >>>> >>> >> >

14.2.2010 07:41:23 (#141)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

14.2.2010 11:30:56 (#142)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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. Honza 2010/2/14 Petr Dlouh? <petr.dlouhy at email.cz>: zobrazit citaci
> 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 >

14.2.2010 11:43:22 (#143)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

14.2.2010 11:48:12 (#144)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >

15.2.2010 12:51:12 (#145)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Ahoj. Jedn? se o ?patn? detekovan? body. Tedy ona detekovan? te?ka dan?ho rozm?ru vznikla slit?m popisk? nebo se te?ka zv?t?ila, proto?e se slila s popiskem. Tedy takov?to body nejsou ve skute?nosti adresn? body. Nov? verze beta 4 s drobn?mi ?pravami: a) takov?to body ozna?uje [CHECK][OVERLAP][NOT POINT] (kv?li mo?nosti kontroly, pokud se potvrd? spr?vn? funkce programu, tak je m??e program klidn? zcela vynech?vat) b) spou?t? vl?kna s men?? prioritou, aby program mohl b??et na pozad?, ani? by to v?razn? zpomalovalo ostatn? programy c) vynech?v? pr?zdn? dla?dice 4000x4000 je?t? p?ed rozbalen?m bitmapy v pam?ti (kontroluje velikost a CRC32 souboru) d) odd?luje mo?nosti v p??pad? nejednozna?nosti svisl?tkem, tedy m?sto ?[?.p.bez ?.p./?.e.] je ?[?.p.|bez ?.p./?.e.] e) v logu form?tuje sou?adnice (lon, lat) stejn? jako v csv kv?li snadn?m dohled?v?n? http://jabi.aspone.cz/osm/OcrBeta4.zip Honza 2010/2/14 Jan Bilak <jan.bilak.osm at gmail.com>: zobrazit citaci
> 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 >> >

15.2.2010 09:44:58 (#146)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
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

15.2.2010 12:05:01 (#147)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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?

15.2.2010 03:29:06 (#148)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Ahoj, nezkousel jsem porovnavat vysledky z tesseractu a meho rozpoznavani vzoru, ale myslim, ze by to slo snadno. Staci nejaka data, ktera byla zpracovana tesseractem, zpracovat take timto. Oba csv soubory seradit a pouzit nejaky klasicky diff. 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. To byl hlavni cil, proc jsem OCR delal - zajisteni spolehlivosti. Zvyseni rychlosti bylo druhorade, i kdyz je to prijemne. Honza 2010/2/15 Petr Dlouh? <petr.dlouhy at email.cz>: zobrazit citaci
> 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 >

17.2.2010 03:38:21 (#149)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> 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.
Tak ja jsem zkusil porovnat vysledky puvodniho a tveho programu. Puvodni program skutecne dela chyby u budov s c.e., mimo zminovaneho problemu 2/7 jeste obcas dochazi k zamene 6/8. U budov s c.p. jsou ve vetsine pripadu stejne. Narazil jsem na par rozdilu, ktere tvuj program oznacuje jako [CHECK]. Takze, i kdyz uz je vse spocitane, tak asi mate pravdu, ze by stalo za to rozpoznani udelat znovu. Mrzi me to, netusil jsem ze tesseract si s tim neporadi a pri testovani jsem si tohohle problemu nevsimnul. BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program pracuje. -- Lukas

17.2.2010 03:50:38 (#150)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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?. zobrazit citaci
> ------------ 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 > ----------------------------------------
zobrazit citaci
> 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

17.2.2010 04:15:34 (#151)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >

17.2.2010 04:17:16 (#152)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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>: zobrazit citaci
> 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 >> >

17.2.2010 05:08:35 (#153)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Ne? to n?jak uprav?m ... tak zat?m je?t? p?ikl?d?m beta4 zdroj?ky pro z?jemce: http://jabi.aspone.cz/osm/FindAddressPoints-beta4-src.zip Honza 2010/2/17 Jan Bilak <jan.bilak.osm at gmail.com>: zobrazit citaci
> 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 >>> >> >

23.2.2010 12:28:24 (#154)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
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

23.2.2010 08:42:07 (#155)
gravatar

Jan Dudík

<jan.dudik at gmail.com>
277 645
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? J&D 2010/2/23 Lukas Kabrt <lukas at kabrt.cz>: zobrazit citaci
> 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 >
-- -- Ing. Jan Dud?k

23.2.2010 09:56:52 (#156)
gravatar

Petr Kadlec

<petr.kadlec at gmail.com>
201 937
2010/2/23 Jan Dud?k <jan.dudik at gmail.com>: zobrazit citaci
> 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

23.2.2010 11:43:21 (#157)
gravatar

Jan Dudík

<jan.dudik at gmail.com>
277 645
Dne 23. ?nora 2010 9:56 Petr Kadlec <petr.kadlec at gmail.com> napsal(a): zobrazit citaci
> 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
Tek?e dotaz zn?, zda lze tuto pr?ci ud?lat i jinak, s dostupn?mi prost?edky (JOSM, Java, NET <4) J&D

23.2.2010 12:33:56 (#158)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> 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

23.2.2010 07:58:30 (#159)
gravatar

Jan Dudík

<jan.dudik at gmail.com>
277 645
Je?t? jeden dotaz: 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? J&D 2010/2/23 Lukas Kabrt <lukas at kabrt.cz>: zobrazit citaci
>> 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 >
-- -- Ing. Jan Dud?k

23.2.2010 08:34:59 (#160)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> Ve sta?en?m souboru (Beroun) u? jsou v?echny v?stupy ud?lan?, pro? je > tedy t?eba zprovoz?ovat program?
V?stupy jsou ud?lan? pro m?sta, kde se poda?il automaticky vytvo?it *.map soubor. U dal??ch (n?zev souboru za??n? podtr??tkem) je n?jak? nejasnost v *.map souboru. Je pot?eba map soubor upravit a vygenerovat osm soubory - proto je pot?eba zprovoznit program. zobrazit citaci
> tam, kde jsou konflikty mi program spadne.
M??u se zeptat co vyp??e za chybu? (spustit p?es p??kazov? ??dek, pak z?stane chyba na obrazovace) zobrazit citaci
> BTW, co ten import ktastr?ln?ch ?zem?? soubor existuje, pro? nen? > z?rove? nahr?n?
Nahr?n nen?, proto?e to je?t? nikdo neud?lal :-) A nahr?vat ho sou?asn? s adresami mi nep?ijde jako ??astn? n?pad - je nutn? vy?e?it konflikty s existuj?c?mi daty, napojen? na existuj?c? relace apod. -- Lukas

« zpět na výpis měsíce