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

19.1.2010 09:51:46 (#10)
gravatar

Lukas Kabrt

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

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

21.1.2010 04:50:15 (#23)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
96
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 na 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 na 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>
96
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 na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

22.1.2010 03:42:58 (#29)
gravatar

Lukas Kabrt

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

24.1.2010 02:08:17 (#39)
gravatar

Jan Bilak

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

24.1.2010 02:27:55 (#42)
gravatar

Jan Bilak

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

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

24.1.2010 03:12:20 (#45)
gravatar

Jan Bilak

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

24.1.2010 04:46:05 (#47)
gravatar

Jan Bilak

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

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

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

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

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 na 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 na 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>
151
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 na 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 na gmail.com> > wrote: > >> >> "Veškeré údaje na internetových stránkách ČSÚ si může kdokoliv převzít >> pro své účely bezplatně, pouze s podmínkou, že uvede jako zdroj ČSÚ. >> Je doporučováno uvádět i datum, kdy údaje byly převzaty." > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

24.1.2010 12:07:32 (#60)
gravatar

Jan Bilak

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

24.1.2010 12:18:04 (#61)
gravatar

Jan Bilak

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

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 na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
-- Petr Dlouhý ------------- další část --------------- A non-text attachment was scrubbed... Name: CUZK.MergeDBWithPoints1.tar.gz Type: application/x-gzip Size: 30465 bytes Desc: [žádný popis není k dispozici] URL: <https://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 na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
-- Petr Dlouhý ------------- další část --------------- A non-text attachment was scrubbed... Name: CUZK.MergeDBWithPoints.tar.gz Type: application/x-gzip Size: 20594 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100124/d6bf63aa/attachment.bin>

24.1.2010 06:33:51 (#64)
gravatar

hanoj

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

26.1.2010 12:52:40 (#68)
gravatar

Karel Volný

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

26.1.2010 08:10:09 (#71)
gravatar

Lukas Kabrt

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

26.1.2010 09:41:14 (#72)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
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 na 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 na kabrt.cz > > [1] http://lkabrt.aspone.cz/osm/cuzk.zip > [2] http://lkabrt.aspone.cz/osm/cuzk-source.zip > [3] http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004312.html > [4] http://lkabrt.aspone.cz/osm/oblasti.zip > [5] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR/Prubeh_Zpracovani > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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

27.1.2010 11:26:58 (#81)
gravatar

Jakub Sýkora

<kubajz at kbx.cz>
618
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 na kabrt.cz> wrote: >> >> >> >>> Jestli myslis cisteho vypocetniho casu, tak bych rekl, ze je to >>> pesimisticky odhad. Podle toho, jak rychle probiha vypocet u me, bych >>> to odhadnul na 30 - 50 dni. Limitujici je tady rychlost procesoru. >>> Nedavno jsem zkousel oblast cca 20 x 25 km a rozpoznavani bezelo neco >>> pres 5 hodin. Muj pocitac pritom neni zadne "delo" - Intel Core2 Duo @ >>> 2Ghz. >>> >>> >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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 na 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 na kabrt.cz > > [1] http://lkabrt.aspone.cz/osm/cuzk.zip > [2] http://lkabrt.aspone.cz/osm/cuzk-source.zip > [3] > http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004312.html > [4] http://lkabrt.aspone.cz/osm/oblasti.zip > [5] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR/Prubeh_Zpracovani > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
-- Petr Dlouhý

27.1.2010 01:30:45 (#83)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
96
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ý ------------- další část --------------- A non-text attachment was scrubbed... Name: tile-do.sh Type: application/octet-stream Size: 502 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100127/d74ee818/attachment.obj> ------------- další část --------------- A non-text attachment was scrubbed... Name: tile-more.sh Type: application/octet-stream Size: 57 bytes Desc: [žádný popis není k dispozici] URL: <https://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 na 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>
151
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 na 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 na kabrt.cz> wrote: > >> Progam jsem zkousel na platforme Win/.NET a Win/MONO a funguji bez >> problemu. Nekoho bych poprosil aby vyzkousel jestli neni nejaky >> problem na Linuxu. > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

29.1.2010 05:28:48 (#87)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
96
2010/1/27 Petr Dlouhý <petr.dlouhy na 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 na kabrt.cz> wrote: zobrazit citaci
> 2010/1/27 Petr Dlouhý <petr.dlouhy na email.cz>: >> Má někdo nápad, jak by to šlo jednoduše obejít? > > Vyzkousel jsem pouziti tiffcp jak navrhoval Jan Bilak. Na WIN mi to > funguje bez problemu. Stahovat muzete opet z mych stranek [1]. Je to o > neco pomalejsi, nez kdyz mutli-page tiff vytvarim primo v > tile-processor, ale pokud to bude fungovat na LINUXU, tak je to > prijatelna obet. Porad je to totiz rychlejsi, nez puvodni verze. > > [1] http://lkabrt.aspone.cz/osm/cuzk-test.zip > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
-- 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>
96
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 na kabrt.cz> > Předmět: Re: [Talk-cz] Import adres z katastralni mapy > Datum: 02.2.2010 10:05:16 > ---------------------------------------- > >        uz jsem skoro dopracoval svoje davky, ale nastal maly problem. > > > >        v tech cca 80 tile je cca 850 erroru v logach. Mam to nejak > >        resit, nebo uz si je zkusis udelat znova sam? > > > >        Vypada to ze tesseract sem tam nejak spadl nebo neco takoveho > >        provedl. > > Resit to nijak nemusis, uz jsem si napsal skriptik, ktery projde logy > a mista kde se vyskytnul error zpracuje znova. > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >
Petr Dlouhý petr.dlouhy na email.cz

2.2.2010 06:31:54 (#93)
gravatar

Lukas Kabrt

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

11.2.2010 06:29:27 (#100)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
Ahoj, ještě jsem si říkal, že možná nebylo špatné rozpoznávání dělat na základě podobnosti vzoru jednotlivých číslic. Když je to psané jedním fontem, jednou velikostí, vždy stejně natočené a bez nějakých kazů vzniklým skenováním, tak by tato metoda musela být vysoce spolehlivá. Dokonce podle pozorování jsou znaky zarovnané na celé pixely (ale mohu se plést - koukal jsem na to jen letmo). Výhoda je v tom, že je to metoda prakticky zcela spolehlivá. Pokud text něco překrývá, tak to odhalí (neshoduje se s žádným vzorem číslice/písmena). Pokud se naopak znak shoduje se vzorem, tak je prakticky jisté, že jde o tento znak. Teoreticky by nějaký jiný objekt mohl udělat např. z písmene I písmeno T, ale aby to zcela přesně odpovídalo vzoru, to je podle mne menší pravděpodobnost, než vyhrát první cenu v nějaké loterii. Algoritmus rozpoznávání by přitom byl myslím velmi jednoduše naprogramovatelný, rychlý a nepotřeboval by nějaké externí OCRy. To se sice může zdát jako zbytečnost, ale mělo by to význam při aktualizacích. Tedy nyní se celý import pojal jako jednorázový import. Ale data se budou měnit a nebylo by od věci, kdyby se periodicky našly změny, doplnila nová čísla domů apod. Zkusím to ověřit na příkladu. Honza 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: 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 na email.cz> > wrote: > >> Ahoj, >> >> tak na Kubajzově stroji je (po kratší odstávce) už taky vše spočítané a >> uploadované. >> >> On Tue, 02 Feb 2010 22:52:06 +0100, Martin Kupec <magon na jkopava.cz> >> wrote: >> >>> Tak jsem uploadoval na server vysledky, odkaz je na wiki ([1]). >>> >>> Nevim jak je to se zpracovanim zbylych tilu, ale kdyz mi nekdo neco >>> uvolni, tak to klidne jeste spocitam :-). Zjistil jsem ze ten stoj co >>> jsem na to zneuzil se nejak moc zbytecne flaka... >>> >>> [1] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR/Prubeh_Zpracovani >>> >>>      Martin Kupec >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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

11.2.2010 06:47:45 (#102)
gravatar

Jan Bilak

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

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 na 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 na 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 na 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>
151
Ahoj, pokusná implementace je velmi rychlá a měla by být i spolehlivá. Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas zpracování jednoho adresního bodu je 17 ms. To vše v jednom vlákně a tedy to zatěžuje jen jedno jádro procesoru. Zítra to snad dodělám do použitelného stavu. Honza 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: 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 na penguin.cz> > wrote: > >> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat uříznutou >> dvojku? Pokud to ovšem nezvýší riziko chyby jinde. > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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 na 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 na email.cz>: >> Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat pouze >> ta >> evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je tam ta >> dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že by to >> nešlo >> uříznout o trochu níž. Problém je, že už jsme to udělali špatně, takže >> by >> to bylo dobré napravit bez toho, abychom museli všechno předělávat. >> >> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec <utx na penguin.cz> >> wrote: >> >>> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat uříznutou >>> dvojku? Pokud to ovšem nezvýší riziko chyby jinde. >> >> >> -- >> Petr Dlouhý >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
-- Petr Dlouhý

12.2.2010 03:39:54 (#109)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
Ahoj, k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým rozlišením ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho detekovat oblasti, které obsahují adresní body. A jen tyto úseky stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit množství stahovaných dat. Přijde mi, že nejpomalejší bude právě stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas prodloužil. Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, které byste mohli někam hodit zazipované, abych to nemusel stahovat z WMS pro testování? Honza 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: 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 na gmail.com> > wrote: > >> Ahoj, >> >> pokusná implementace je velmi rychlá a měla by být i spolehlivá. >> >> Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. >> Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas >> zpracování jednoho adresního bodu je 17 ms. To vše v jednom vlákně a >> tedy to zatěžuje jen jedno jádro procesoru. >> >> Zítra to snad dodělám do použitelného stavu. >> >> Honza >> >> >> 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: >>> Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat pouze >>> ta >>> evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je tam ta >>> dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že by to >>> nešlo >>> uříznout o trochu níž. Problém je, že už jsme to udělali špatně, takže >>> by >>> to bylo dobré napravit bez toho, abychom museli všechno předělávat. >>> >>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec <utx na penguin.cz> >>> wrote: >>> >>>> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat uříznutou >>>> dvojku? Pokud to ovšem nezvýší riziko chyby jinde. >>> >>> >>> -- >>> Petr Dlouhý >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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 na 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 na email.cz>: >> Ahoj, >> >> zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, tak by >> možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší >> detekci >> u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším >> zoomem, >> tak to bude další plus). >> >> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >> wrote: >> >>> Ahoj, >>> >>> pokusná implementace je velmi rychlá a měla by být i spolehlivá. >>> >>> Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. >>> Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas >>> zpracování jednoho adresního bodu je 17 ms. To vše v jednom vlákně a >>> tedy to zatěžuje jen jedno jádro procesoru. >>> >>> Zítra to snad dodělám do použitelného stavu. >>> >>> Honza >>> >>> >>> 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: >>>> Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat >>>> pouze >>>> ta >>>> evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je tam ta >>>> dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že by to >>>> nešlo >>>> uříznout o trochu níž. Problém je, že už jsme to udělali špatně, takže >>>> by >>>> to bylo dobré napravit bez toho, abychom museli všechno předělávat. >>>> >>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec <utx na penguin.cz> >>>> wrote: >>>> >>>>> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat uříznutou >>>>> dvojku? Pokud to ovšem nezvýší riziko chyby jinde. >>>> >>>> >>>> -- >>>> Petr Dlouhý >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> -- >> Petr Dlouhý >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
-- Petr Dlouhý

12.2.2010 04:54:47 (#111)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude výrazně lepší než byla (to už je myslím teď). Ale stoprocentní samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A také jim to bude zatěžovat servery, když se to přežene s rychlostí stahování (mnoho vláken apod.). Honza 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: 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 na gmail.com> > wrote: > >> Ahoj, >> k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým rozlišením >> ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho >> detekovat oblasti, které obsahují adresní body. A jen tyto úseky >> stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit >> množství stahovaných dat. Přijde mi, že nejpomalejší bude právě >> stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas >> prodloužil. >> >> Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, >> které byste mohli někam hodit zazipované, abych to nemusel stahovat z >> WMS pro testování? >> >> Honza >> >> >> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >>> Ahoj, >>> >>> zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, tak by >>> možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší >>> detekci >>> u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším >>> zoomem, >>> tak to bude další plus). >>> >>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >>> wrote: >>> >>>> Ahoj, >>>> >>>> pokusná implementace je velmi rychlá a měla by být i spolehlivá. >>>> >>>> Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. >>>> Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas >>>> zpracování jednoho adresního bodu je 17 ms. To vše v jednom vlákně a >>>> tedy to zatěžuje jen jedno jádro procesoru. >>>> >>>> Zítra to snad dodělám do použitelného stavu. >>>> >>>> Honza >>>> >>>> >>>> 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>> Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat >>>>> pouze >>>>> ta >>>>> evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je tam ta >>>>> dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že by to >>>>> nešlo >>>>> uříznout o trochu níž. Problém je, že už jsme to udělali špatně, takže >>>>> by >>>>> to bylo dobré napravit bez toho, abychom museli všechno předělávat. >>>>> >>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec <utx na penguin.cz> >>>>> wrote: >>>>> >>>>>> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat uříznutou >>>>>> dvojku? Pokud to ovšem nezvýší riziko chyby jinde. >>>>> >>>>> >>>>> -- >>>>> Petr Dlouhý >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> -- >>> Petr Dlouhý >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

12.2.2010 07:32:38 (#112)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
K vyzkoušení: http://jabi.aspone.cz/osm/OcrBeta1.zip Má to stejné ovládání jako původní tile-processor, ale navíc možnost logování: FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv -log log.txt -all -log log.txt ... pokud se toto uvede, tak program bude logovat nerozpoznané body nebo ty, které byly narušené překryvem. Pokud se uvede navíc -all, tak se budou logovat všechny body. Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je to také textový soubor, který když zobrazíte fontem s pevnou šířkou, tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při spuštění v aktuálním adresáři. Honza 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: 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 na email.cz>: >> Kvůli překryvům - čísla se s rozlišením zmenšují. >> Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících se >> číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. >> Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím >> zabralo počítání. >> >> Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc cenu, >> protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat příliš >> mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení může >> nastat spíš tím, že je nutné zpracovat větší množství obrazové informace. >> >> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >> wrote: >> >>> Ahoj, >>> k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým rozlišením >>> ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho >>> detekovat oblasti, které obsahují adresní body. A jen tyto úseky >>> stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit >>> množství stahovaných dat. Přijde mi, že nejpomalejší bude právě >>> stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas >>> prodloužil. >>> >>> Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, >>> které byste mohli někam hodit zazipované, abych to nemusel stahovat z >>> WMS pro testování? >>> >>> Honza >>> >>> >>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >>>> Ahoj, >>>> >>>> zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, tak by >>>> možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší >>>> detekci >>>> u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším >>>> zoomem, >>>> tak to bude další plus). >>>> >>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >>>> wrote: >>>> >>>>> Ahoj, >>>>> >>>>> pokusná implementace je velmi rychlá a měla by být i spolehlivá. >>>>> >>>>> Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. >>>>> Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas >>>>> zpracování jednoho adresního bodu je 17 ms. To vše v jednom vlákně a >>>>> tedy to zatěžuje jen jedno jádro procesoru. >>>>> >>>>> Zítra to snad dodělám do použitelného stavu. >>>>> >>>>> Honza >>>>> >>>>> >>>>> 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>>> Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat >>>>>> pouze >>>>>> ta >>>>>> evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je tam ta >>>>>> dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že by to >>>>>> nešlo >>>>>> uříznout o trochu níž. Problém je, že už jsme to udělali špatně, takže >>>>>> by >>>>>> to bylo dobré napravit bez toho, abychom museli všechno předělávat. >>>>>> >>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec <utx na penguin.cz> >>>>>> wrote: >>>>>> >>>>>>> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat uříznutou >>>>>>> dvojku? Pokud to ovšem nezvýší riziko chyby jinde. >>>>>> >>>>>> >>>>>> -- >>>>>> Petr Dlouhý >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz na openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> -- >>>> Petr Dlouhý >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> -- >> Petr Dlouhý >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >

12.2.2010 07:46:17 (#113)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
Doplnil jsem tam chybějící číslici 4. Honza 2010/2/12 Jan Bilak <jan.bilak.osm na 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 na gmail.com>: >> Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude >> výrazně lepší než byla (to už je myslím teď). Ale stoprocentní >> samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. >> >> Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou >> dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A >> také jim to bude zatěžovat servery, když se to přežene s rychlostí >> stahování (mnoho vláken apod.). >> >> Honza >> >> >> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >>> Kvůli překryvům - čísla se s rozlišením zmenšují. >>> Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících se >>> číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. >>> Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím >>> zabralo počítání. >>> >>> Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc cenu, >>> protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat příliš >>> mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení může >>> nastat spíš tím, že je nutné zpracovat větší množství obrazové informace. >>> >>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >>> wrote: >>> >>>> Ahoj, >>>> k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým rozlišením >>>> ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho >>>> detekovat oblasti, které obsahují adresní body. A jen tyto úseky >>>> stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit >>>> množství stahovaných dat. Přijde mi, že nejpomalejší bude právě >>>> stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas >>>> prodloužil. >>>> >>>> Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, >>>> které byste mohli někam hodit zazipované, abych to nemusel stahovat z >>>> WMS pro testování? >>>> >>>> Honza >>>> >>>> >>>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>> Ahoj, >>>>> >>>>> zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, tak by >>>>> možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší >>>>> detekci >>>>> u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším >>>>> zoomem, >>>>> tak to bude další plus). >>>>> >>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >>>>> wrote: >>>>> >>>>>> Ahoj, >>>>>> >>>>>> pokusná implementace je velmi rychlá a měla by být i spolehlivá. >>>>>> >>>>>> Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. >>>>>> Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas >>>>>> zpracování jednoho adresního bodu je 17 ms. To vše v jednom vlákně a >>>>>> tedy to zatěžuje jen jedno jádro procesoru. >>>>>> >>>>>> Zítra to snad dodělám do použitelného stavu. >>>>>> >>>>>> Honza >>>>>> >>>>>> >>>>>> 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>>>> Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat >>>>>>> pouze >>>>>>> ta >>>>>>> evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je tam ta >>>>>>> dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že by to >>>>>>> nešlo >>>>>>> uříznout o trochu níž. Problém je, že už jsme to udělali špatně, takže >>>>>>> by >>>>>>> to bylo dobré napravit bez toho, abychom museli všechno předělávat. >>>>>>> >>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec <utx na penguin.cz> >>>>>>> wrote: >>>>>>> >>>>>>>> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat uříznutou >>>>>>>> dvojku? Pokud to ovšem nezvýší riziko chyby jinde. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Petr Dlouhý >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz na openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz na openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>>> >>>>> -- >>>>> Petr Dlouhý >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> -- >>> Petr Dlouhý >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >

12.2.2010 10:05:40 (#114)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy. Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne. Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze červenou barvu. Jsou 3 možnosti jak to řešit: a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z těch částí mapy, které copyright není. Výhody: Nejlepší výsledky. Nevýhody: Nutnost stahovat více dat z WMS. b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody: Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale nemusí to znamenat nic, i když se to trefí. c) Provádět ruční kontrolu všech popisků s překryvem (těch může být hodně). Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít postřehnutelně horší výsledky. Honza 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: zobrazit citaci
> Doplnil jsem tam chybějící číslici 4. > > Honza > > 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >> K vyzkoušení: >> http://jabi.aspone.cz/osm/OcrBeta1.zip >> >> Má to stejné ovládání jako původní tile-processor, ale navíc možnost logování: >> >> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv >> -log log.txt -all >> >> -log log.txt ... pokud se toto uvede, tak program bude logovat >> nerozpoznané body nebo ty, které byly narušené překryvem. >> >> Pokud se uvede navíc -all, tak se budou logovat všechny body. >> >> Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je >> to také textový soubor, který když zobrazíte fontem s pevnou šířkou, >> tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za >> č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při >> spuštění v aktuálním adresáři. >> >> Honza >> >> >> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >>> Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude >>> výrazně lepší než byla (to už je myslím teď). Ale stoprocentní >>> samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. >>> >>> Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou >>> dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A >>> také jim to bude zatěžovat servery, když se to přežene s rychlostí >>> stahování (mnoho vláken apod.). >>> >>> Honza >>> >>> >>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >>>> Kvůli překryvům - čísla se s rozlišením zmenšují. >>>> Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících se >>>> číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. >>>> Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím >>>> zabralo počítání. >>>> >>>> Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc cenu, >>>> protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat příliš >>>> mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení může >>>> nastat spíš tím, že je nutné zpracovat větší množství obrazové informace. >>>> >>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >>>> wrote: >>>> >>>>> Ahoj, >>>>> k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým rozlišením >>>>> ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho >>>>> detekovat oblasti, které obsahují adresní body. A jen tyto úseky >>>>> stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit >>>>> množství stahovaných dat. Přijde mi, že nejpomalejší bude právě >>>>> stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas >>>>> prodloužil. >>>>> >>>>> Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, >>>>> které byste mohli někam hodit zazipované, abych to nemusel stahovat z >>>>> WMS pro testování? >>>>> >>>>> Honza >>>>> >>>>> >>>>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>>> Ahoj, >>>>>> >>>>>> zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, tak by >>>>>> možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší >>>>>> detekci >>>>>> u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším >>>>>> zoomem, >>>>>> tak to bude další plus). >>>>>> >>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Ahoj, >>>>>>> >>>>>>> pokusná implementace je velmi rychlá a měla by být i spolehlivá. >>>>>>> >>>>>>> Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. >>>>>>> Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas >>>>>>> zpracování jednoho adresního bodu je 17 ms. To vše v jednom vlákně a >>>>>>> tedy to zatěžuje jen jedno jádro procesoru. >>>>>>> >>>>>>> Zítra to snad dodělám do použitelného stavu. >>>>>>> >>>>>>> Honza >>>>>>> >>>>>>> >>>>>>> 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>>>>> Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat >>>>>>>> pouze >>>>>>>> ta >>>>>>>> evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je tam ta >>>>>>>> dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že by to >>>>>>>> nešlo >>>>>>>> uříznout o trochu níž. Problém je, že už jsme to udělali špatně, takže >>>>>>>> by >>>>>>>> to bylo dobré napravit bez toho, abychom museli všechno předělávat. >>>>>>>> >>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec <utx na penguin.cz> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat uříznutou >>>>>>>>> dvojku? Pokud to ovšem nezvýší riziko chyby jinde. >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Petr Dlouhý >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz na openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz na openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>>> >>>>>> -- >>>>>> Petr Dlouhý >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz na openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> -- >>>> Petr Dlouhý >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >> >

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 na 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 na gmail.com>: >> Doplnil jsem tam chybějící číslici 4. >> >> Honza >> >> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >>> K vyzkoušení: >>> http://jabi.aspone.cz/osm/OcrBeta1.zip >>> >>> Má to stejné ovládání jako původní tile-processor, ale navíc možnost >>> logování: >>> >>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv >>> -log log.txt -all >>> >>> -log log.txt ... pokud se toto uvede, tak program bude logovat >>> nerozpoznané body nebo ty, které byly narušené překryvem. >>> >>> Pokud se uvede navíc -all, tak se budou logovat všechny body. >>> >>> Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je >>> to také textový soubor, který když zobrazíte fontem s pevnou šířkou, >>> tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za >>> č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při >>> spuštění v aktuálním adresáři. >>> >>> Honza >>> >>> >>> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >>>> Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude >>>> výrazně lepší než byla (to už je myslím teď). Ale stoprocentní >>>> samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. >>>> >>>> Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou >>>> dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A >>>> také jim to bude zatěžovat servery, když se to přežene s rychlostí >>>> stahování (mnoho vláken apod.). >>>> >>>> Honza >>>> >>>> >>>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>> Kvůli překryvům - čísla se s rozlišením zmenšují. >>>>> Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících >>>>> se >>>>> číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. >>>>> Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím >>>>> zabralo počítání. >>>>> >>>>> Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc >>>>> cenu, >>>>> protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat >>>>> příliš >>>>> mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení >>>>> může >>>>> nastat spíš tím, že je nutné zpracovat větší množství obrazové >>>>> informace. >>>>> >>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak >>>>> <jan.bilak.osm na gmail.com> >>>>> wrote: >>>>> >>>>>> Ahoj, >>>>>> k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým >>>>>> rozlišením >>>>>> ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho >>>>>> detekovat oblasti, které obsahují adresní body. A jen tyto úseky >>>>>> stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit >>>>>> množství stahovaných dat. Přijde mi, že nejpomalejší bude právě >>>>>> stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas >>>>>> prodloužil. >>>>>> >>>>>> Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, >>>>>> které byste mohli někam hodit zazipované, abych to nemusel stahovat >>>>>> z >>>>>> WMS pro testování? >>>>>> >>>>>> Honza >>>>>> >>>>>> >>>>>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>>>> Ahoj, >>>>>>> >>>>>>> zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, >>>>>>> tak by >>>>>>> možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší >>>>>>> detekci >>>>>>> u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším >>>>>>> zoomem, >>>>>>> tak to bude další plus). >>>>>>> >>>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak >>>>>>> <jan.bilak.osm na gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Ahoj, >>>>>>>> >>>>>>>> pokusná implementace je velmi rychlá a měla by být i spolehlivá. >>>>>>>> >>>>>>>> Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. >>>>>>>> Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas >>>>>>>> zpracování jednoho adresního bodu je 17 ms. To vše v jednom >>>>>>>> vlákně a >>>>>>>> tedy to zatěžuje jen jedno jádro procesoru. >>>>>>>> >>>>>>>> Zítra to snad dodělám do použitelného stavu. >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>>> >>>>>>>> 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>>>>>> Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat >>>>>>>>> pouze >>>>>>>>> ta >>>>>>>>> evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je >>>>>>>>> tam ta >>>>>>>>> dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že >>>>>>>>> by to >>>>>>>>> nešlo >>>>>>>>> uříznout o trochu níž. Problém je, že už jsme to udělali špatně, >>>>>>>>> takže >>>>>>>>> by >>>>>>>>> to bylo dobré napravit bez toho, abychom museli všechno >>>>>>>>> předělávat. >>>>>>>>> >>>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec >>>>>>>>> <utx na penguin.cz> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat >>>>>>>>>> uříznutou >>>>>>>>>> dvojku? Pokud to ovšem nezvýší riziko chyby jinde. >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Petr Dlouhý >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz na openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Petr Dlouhý >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz na openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz na openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>>> >>>>> -- >>>>> Petr Dlouhý >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>> >>> >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
-- Petr Dlouhý

13.2.2010 12:38:12 (#116)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
Ahoj, ten copyright je vlevo nahoře, ale pak i na souřadnici cca [530,510] px. Ta detekce bodů ... toho jsem si nevšiml. Jak to kontroluješ? Check ... to značí opravdu i nepatrný překryv. Pokud si to není jisté, tak je tam znak otazník a v hranatých závorkách seznam možností. Ještě tam dám jednu kontrolu a mělo byt o být myslím 100% spolehlivé, když tam nebude žádný červený bod chybět (tedy je třeba použít možnost a) nebo b) vypořádání se s copyrightem). Ořez před detekcí nedělám ... detekce si sama řídí, kdy skončit. Check by nemělo být nic, co by bylo třeba ručně kontrolovat - až se vyřeší ten copyright a přidám tam tu jednu drobnou kontrolu. Těch možností, kdy se tam objeví otazník (není si to jisté) je myslím minimum. Zatím se mi to nestalo. Honza 2010/2/13 Petr Dlouhý <petr.dlouhy na email.cz>: 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 na gmail.com> > wrote: > >> Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy. >> Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne. >> Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze >> červenou barvu. Jsou 3 možnosti jak to řešit: >> >> a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z >> těch částí mapy, které copyright není. Výhody: Nejlepší výsledky. >> Nevýhody: Nutnost stahovat více dat z WMS. >> >> b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy >> downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody: >> Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem >> - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale >> nemusí to znamenat nic, i když se to trefí. >> >> c) Provádět ruční kontrolu všech popisků s překryvem (těch může být >> hodně). >> >> Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený >> názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít >> postřehnutelně horší výsledky. >> >> Honza >> >> >> >> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >>> Doplnil jsem tam chybějící číslici 4. >>> >>> Honza >>> >>> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >>>> K vyzkoušení: >>>> http://jabi.aspone.cz/osm/OcrBeta1.zip >>>> >>>> Má to stejné ovládání jako původní tile-processor, ale navíc možnost >>>> logování: >>>> >>>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv >>>> -log log.txt -all >>>> >>>> -log log.txt ... pokud se toto uvede, tak program bude logovat >>>> nerozpoznané body nebo ty, které byly narušené překryvem. >>>> >>>> Pokud se uvede navíc -all, tak se budou logovat všechny body. >>>> >>>> Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je >>>> to také textový soubor, který když zobrazíte fontem s pevnou šířkou, >>>> tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za >>>> č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při >>>> spuštění v aktuálním adresáři. >>>> >>>> Honza >>>> >>>> >>>> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >>>>> Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude >>>>> výrazně lepší než byla (to už je myslím teď). Ale stoprocentní >>>>> samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. >>>>> >>>>> Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou >>>>> dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A >>>>> také jim to bude zatěžovat servery, když se to přežene s rychlostí >>>>> stahování (mnoho vláken apod.). >>>>> >>>>> Honza >>>>> >>>>> >>>>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>>> Kvůli překryvům - čísla se s rozlišením zmenšují. >>>>>> Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících >>>>>> se >>>>>> číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. >>>>>> Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím >>>>>> zabralo počítání. >>>>>> >>>>>> Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc >>>>>> cenu, >>>>>> protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat >>>>>> příliš >>>>>> mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení >>>>>> může >>>>>> nastat spíš tím, že je nutné zpracovat větší množství obrazové >>>>>> informace. >>>>>> >>>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak >>>>>> <jan.bilak.osm na gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Ahoj, >>>>>>> k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým >>>>>>> rozlišením >>>>>>> ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho >>>>>>> detekovat oblasti, které obsahují adresní body. A jen tyto úseky >>>>>>> stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit >>>>>>> množství stahovaných dat. Přijde mi, že nejpomalejší bude právě >>>>>>> stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas >>>>>>> prodloužil. >>>>>>> >>>>>>> Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, >>>>>>> které byste mohli někam hodit zazipované, abych to nemusel stahovat >>>>>>> z >>>>>>> WMS pro testování? >>>>>>> >>>>>>> Honza >>>>>>> >>>>>>> >>>>>>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>>>>> Ahoj, >>>>>>>> >>>>>>>> zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, >>>>>>>> tak by >>>>>>>> možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší >>>>>>>> detekci >>>>>>>> u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším >>>>>>>> zoomem, >>>>>>>> tak to bude další plus). >>>>>>>> >>>>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak >>>>>>>> <jan.bilak.osm na gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Ahoj, >>>>>>>>> >>>>>>>>> pokusná implementace je velmi rychlá a měla by být i spolehlivá. >>>>>>>>> >>>>>>>>> Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. >>>>>>>>> Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas >>>>>>>>> zpracování jednoho adresního bodu je 17 ms. To vše v jednom >>>>>>>>> vlákně a >>>>>>>>> tedy to zatěžuje jen jedno jádro procesoru. >>>>>>>>> >>>>>>>>> Zítra to snad dodělám do použitelného stavu. >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>>> >>>>>>>>> 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>>>>>>> Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat >>>>>>>>>> pouze >>>>>>>>>> ta >>>>>>>>>> evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je >>>>>>>>>> tam ta >>>>>>>>>> dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že >>>>>>>>>> by to >>>>>>>>>> nešlo >>>>>>>>>> uříznout o trochu níž. Problém je, že už jsme to udělali špatně, >>>>>>>>>> takže >>>>>>>>>> by >>>>>>>>>> to bylo dobré napravit bez toho, abychom museli všechno >>>>>>>>>> předělávat. >>>>>>>>>> >>>>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec >>>>>>>>>> <utx na penguin.cz> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat >>>>>>>>>>> uříznutou >>>>>>>>>>> dvojku? Pokud to ovšem nezvýší riziko chyby jinde. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Petr Dlouhý >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk-cz mailing list >>>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Petr Dlouhý >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz na openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz na openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>>> >>>>>> -- >>>>>> Petr Dlouhý >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz na openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

13.2.2010 12:44:56 (#117)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
Jinak ... když si povolíš logování, tak se loguje i grafická reprezentace toho textu, takže tam uvidíš, co a jak to rozpoznává. Honza 2010/2/13 Jan Bilak <jan.bilak.osm na gmail.com>: 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 na email.cz>: >> Ahoj, >> >> ten copyright je jen úplně nahoře na každé dlaždici, nebo se pletu? Pokud >> tomu tak je, tak bych volil možnost a), protože je to minimum z velikosti >> dlaždice, a ty se už stejně stahují s přesahem (kvůli tomu, že se čísla >> kreslí jen na dlaždici s tečkou). >> >> Jinak jsem se koukal na ten skript, a zdá se to velice dobré. Myslím, že >> by stálo za to to přepočítat, vzhledem k tomu, že je to tak 20x rychlejší, >> tak to asi nebude problém udělat na jednou počítači. >> >> Chyby vidím následující: >> >> -Některé adresní body nejsou vůbec detekovány, a u některých je prázdný >> text (přestože jsou daleko od všeho). >> -Často se objevuje [CHECK] i u bodů, které byly detekovány správně. Pokud >> je to v případech, kdy se čísla už skutečně překrývají, tak OK. Jenom se >> ptám, jestli není možné zvolit agresivnější ořez před detekcí (pozor na >> jiné posunutí č.e. vs č.p.). >> -V případech, kdy se objeví [CHECK], tak by asi skript měl stáhnout číslo >> ve vyšším rozlišení a detekovat to. >> >> >> On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >> wrote: >> >>> Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy. >>> Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne. >>> Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze >>> červenou barvu. Jsou 3 možnosti jak to řešit: >>> >>> a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z >>> těch částí mapy, které copyright není. Výhody: Nejlepší výsledky. >>> Nevýhody: Nutnost stahovat více dat z WMS. >>> >>> b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy >>> downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody: >>> Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem >>> - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale >>> nemusí to znamenat nic, i když se to trefí. >>> >>> c) Provádět ruční kontrolu všech popisků s překryvem (těch může být >>> hodně). >>> >>> Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený >>> názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít >>> postřehnutelně horší výsledky. >>> >>> Honza >>> >>> >>> >>> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >>>> Doplnil jsem tam chybějící číslici 4. >>>> >>>> Honza >>>> >>>> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >>>>> K vyzkoušení: >>>>> http://jabi.aspone.cz/osm/OcrBeta1.zip >>>>> >>>>> Má to stejné ovládání jako původní tile-processor, ale navíc možnost >>>>> logování: >>>>> >>>>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv >>>>> -log log.txt -all >>>>> >>>>> -log log.txt ... pokud se toto uvede, tak program bude logovat >>>>> nerozpoznané body nebo ty, které byly narušené překryvem. >>>>> >>>>> Pokud se uvede navíc -all, tak se budou logovat všechny body. >>>>> >>>>> Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je >>>>> to také textový soubor, který když zobrazíte fontem s pevnou šířkou, >>>>> tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za >>>>> č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při >>>>> spuštění v aktuálním adresáři. >>>>> >>>>> Honza >>>>> >>>>> >>>>> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >>>>>> Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude >>>>>> výrazně lepší než byla (to už je myslím teď). Ale stoprocentní >>>>>> samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. >>>>>> >>>>>> Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou >>>>>> dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A >>>>>> také jim to bude zatěžovat servery, když se to přežene s rychlostí >>>>>> stahování (mnoho vláken apod.). >>>>>> >>>>>> Honza >>>>>> >>>>>> >>>>>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>>>> Kvůli překryvům - čísla se s rozlišením zmenšují. >>>>>>> Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících >>>>>>> se >>>>>>> číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. >>>>>>> Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím >>>>>>> zabralo počítání. >>>>>>> >>>>>>> Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc >>>>>>> cenu, >>>>>>> protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat >>>>>>> příliš >>>>>>> mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení >>>>>>> může >>>>>>> nastat spíš tím, že je nutné zpracovat větší množství obrazové >>>>>>> informace. >>>>>>> >>>>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak >>>>>>> <jan.bilak.osm na gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Ahoj, >>>>>>>> k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým >>>>>>>> rozlišením >>>>>>>> ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho >>>>>>>> detekovat oblasti, které obsahují adresní body. A jen tyto úseky >>>>>>>> stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit >>>>>>>> množství stahovaných dat. Přijde mi, že nejpomalejší bude právě >>>>>>>> stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas >>>>>>>> prodloužil. >>>>>>>> >>>>>>>> Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, >>>>>>>> které byste mohli někam hodit zazipované, abych to nemusel stahovat >>>>>>>> z >>>>>>>> WMS pro testování? >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>>> >>>>>>>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>>>>>> Ahoj, >>>>>>>>> >>>>>>>>> zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, >>>>>>>>> tak by >>>>>>>>> možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší >>>>>>>>> detekci >>>>>>>>> u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším >>>>>>>>> zoomem, >>>>>>>>> tak to bude další plus). >>>>>>>>> >>>>>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak >>>>>>>>> <jan.bilak.osm na gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Ahoj, >>>>>>>>>> >>>>>>>>>> pokusná implementace je velmi rychlá a měla by být i spolehlivá. >>>>>>>>>> >>>>>>>>>> Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. >>>>>>>>>> Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas >>>>>>>>>> zpracování jednoho adresního bodu je 17 ms. To vše v jednom >>>>>>>>>> vlákně a >>>>>>>>>> tedy to zatěžuje jen jedno jádro procesoru. >>>>>>>>>> >>>>>>>>>> Zítra to snad dodělám do použitelného stavu. >>>>>>>>>> >>>>>>>>>> Honza >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>>>>>>>> Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat >>>>>>>>>>> pouze >>>>>>>>>>> ta >>>>>>>>>>> evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je >>>>>>>>>>> tam ta >>>>>>>>>>> dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že >>>>>>>>>>> by to >>>>>>>>>>> nešlo >>>>>>>>>>> uříznout o trochu níž. Problém je, že už jsme to udělali špatně, >>>>>>>>>>> takže >>>>>>>>>>> by >>>>>>>>>>> to bylo dobré napravit bez toho, abychom museli všechno >>>>>>>>>>> předělávat. >>>>>>>>>>> >>>>>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec >>>>>>>>>>> <utx na penguin.cz> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat >>>>>>>>>>>> uříznutou >>>>>>>>>>>> dvojku? Pokud to ovšem nezvýší riziko chyby jinde. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Petr Dlouhý >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Talk-cz mailing list >>>>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk-cz mailing list >>>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Petr Dlouhý >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz na openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Petr Dlouhý >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz na openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> -- >> Petr Dlouhý >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >

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 na email.cz> > Předmět: Re: [Talk-cz] Import adres z katastralni mapy > Datum: 13.2.2010 00:29:16 > ---------------------------------------- > Ahoj, > > ten copyright je jen úplně nahoře na každé dlaždici, nebo se pletu? Pokud > tomu tak je, tak bych volil možnost a), protože je to minimum z velikosti > dlaždice, a ty se už stejně stahují s přesahem (kvůli tomu, že se čísla > kreslí jen na dlaždici s tečkou). > > Jinak jsem se koukal na ten skript, a zdá se to velice dobré. Myslím, že > by stálo za to to přepočítat, vzhledem k tomu, že je to tak 20x rychlejší, > tak to asi nebude problém udělat na jednou počítači. > > Chyby vidím následující: > > -Některé adresní body nejsou vůbec detekovány, a u některých je prázdný > text (přestože jsou daleko od všeho). > -Často se objevuje [CHECK] i u bodů, které byly detekovány správně. Pokud > je to v případech, kdy se čísla už skutečně překrývají, tak OK. Jenom se > ptám, jestli není možné zvolit agresivnější ořez před detekcí (pozor na > jiné posunutí č.e. vs č.p.). > -V případech, kdy se objeví [CHECK], tak by asi skript měl stáhnout číslo > ve vyšším rozlišení a detekovat to. > > > On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak <jan.bilak.osm na gmail.com> > wrote: > > > Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy. > > Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne. > > Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze > > červenou barvu. Jsou 3 možnosti jak to řešit: > > > > a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z > > těch částí mapy, které copyright není. Výhody: Nejlepší výsledky. > > Nevýhody: Nutnost stahovat více dat z WMS. > > > > b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy > > downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody: > > Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem > > - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale > > nemusí to znamenat nic, i když se to trefí. > > > > c) Provádět ruční kontrolu všech popisků s překryvem (těch může být > > hodně). > > > > Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený > > názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít > > postřehnutelně horší výsledky. > > > > Honza > > > > > > > > 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: > >> Doplnil jsem tam chybějící číslici 4. > >> > >> Honza > >> > >> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: > >>> K vyzkoušení: > >>> http://jabi.aspone.cz/osm/OcrBeta1.zip > >>> > >>> Má to stejné ovládání jako původní tile-processor, ale navíc možnost > >>> logování: > >>> > >>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv > >>> -log log.txt -all > >>> > >>> -log log.txt ... pokud se toto uvede, tak program bude logovat > >>> nerozpoznané body nebo ty, které byly narušené překryvem. > >>> > >>> Pokud se uvede navíc -all, tak se budou logovat všechny body. > >>> > >>> Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je > >>> to také textový soubor, který když zobrazíte fontem s pevnou šířkou, > >>> tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za > >>> č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při > >>> spuštění v aktuálním adresáři. > >>> > >>> Honza > >>> > >>> > >>> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: > >>>> Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude > >>>> výrazně lepší než byla (to už je myslím teď). Ale stoprocentní > >>>> samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. > >>>> > >>>> Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou > >>>> dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A > >>>> také jim to bude zatěžovat servery, když se to přežene s rychlostí > >>>> stahování (mnoho vláken apod.). > >>>> > >>>> Honza > >>>> > >>>> > >>>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: > >>>>> Kvůli překryvům - čísla se s rozlišením zmenšují. > >>>>> Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících > >>>>> se > >>>>> číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. > >>>>> Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím > >>>>> zabralo počítání. > >>>>> > >>>>> Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc > >>>>> cenu, > >>>>> protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat > >>>>> příliš > >>>>> mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení > >>>>> může > >>>>> nastat spíš tím, že je nutné zpracovat větší množství obrazové > >>>>> informace. > >>>>> > >>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak > >>>>> <jan.bilak.osm na gmail.com> > >>>>> wrote: > >>>>> > >>>>>> Ahoj, > >>>>>> k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým > >>>>>> rozlišením > >>>>>> ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho > >>>>>> detekovat oblasti, které obsahují adresní body. A jen tyto úseky > >>>>>> stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit > >>>>>> množství stahovaných dat. Přijde mi, že nejpomalejší bude právě > >>>>>> stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas > >>>>>> prodloužil. > >>>>>> > >>>>>> Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, > >>>>>> které byste mohli někam hodit zazipované, abych to nemusel stahovat > >>>>>> z > >>>>>> WMS pro testování? > >>>>>> > >>>>>> Honza > >>>>>> > >>>>>> > >>>>>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: > >>>>>>> Ahoj, > >>>>>>> > >>>>>>> zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, > >>>>>>> tak by > >>>>>>> možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší > >>>>>>> detekci > >>>>>>> u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším > >>>>>>> zoomem, > >>>>>>> tak to bude další plus). > >>>>>>> > >>>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak > >>>>>>> <jan.bilak.osm na gmail.com> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> Ahoj, > >>>>>>>> > >>>>>>>> pokusná implementace je velmi rychlá a měla by být i spolehlivá. > >>>>>>>> > >>>>>>>> Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. > >>>>>>>> Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas > >>>>>>>> zpracování jednoho adresního bodu je 17 ms. To vše v jednom > >>>>>>>> vlákně a > >>>>>>>> tedy to zatěžuje jen jedno jádro procesoru. > >>>>>>>> > >>>>>>>> Zítra to snad dodělám do použitelného stavu. > >>>>>>>> > >>>>>>>> Honza > >>>>>>>> > >>>>>>>> > >>>>>>>> 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: > >>>>>>>>> Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat > >>>>>>>>> pouze > >>>>>>>>> ta > >>>>>>>>> evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je > >>>>>>>>> tam ta > >>>>>>>>> dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že > >>>>>>>>> by to > >>>>>>>>> nešlo > >>>>>>>>> uříznout o trochu níž. Problém je, že už jsme to udělali špatně, > >>>>>>>>> takže > >>>>>>>>> by > >>>>>>>>> to bylo dobré napravit bez toho, abychom museli všechno > >>>>>>>>> předělávat. > >>>>>>>>> > >>>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec > >>>>>>>>> <utx na penguin.cz> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat > >>>>>>>>>> uříznutou > >>>>>>>>>> dvojku? Pokud to ovšem nezvýší riziko chyby jinde. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Petr Dlouhý > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Talk-cz mailing list > >>>>>>>>> Talk-cz na openstreetmap.org > >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Talk-cz mailing list > >>>>>>>> Talk-cz na openstreetmap.org > >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Petr Dlouhý > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Talk-cz mailing list > >>>>>>> Talk-cz na openstreetmap.org > >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Talk-cz mailing list > >>>>>> Talk-cz na openstreetmap.org > >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>> > >>>>> > >>>>> -- > >>>>> Petr Dlouhý > >>>>> > >>>>> _______________________________________________ > >>>>> Talk-cz mailing list > >>>>> Talk-cz na openstreetmap.org > >>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>> > >>>> > >>> > >> > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz na openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >
Petr Dlouhý petr.dlouhy na email.cz

13.2.2010 01:05:07 (#119)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
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 na 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 na gmail.com>: >> Ahoj, >> ten copyright je vlevo nahoře, ale pak i na souřadnici cca [530,510] px. >> >> Ta detekce bodů ... toho jsem si nevšiml. Jak to kontroluješ? >> >> Check ... to značí opravdu i nepatrný překryv. Pokud si to není jisté, >> tak je tam znak otazník a v hranatých závorkách seznam možností. Ještě >> tam dám jednu kontrolu a mělo byt o být myslím 100% spolehlivé, když >> tam nebude žádný červený bod chybět (tedy je třeba použít možnost a) >> nebo b) vypořádání se s copyrightem). >> >> Ořez před detekcí nedělám ... detekce si sama řídí, kdy skončit. >> >> Check by nemělo být nic, co by bylo třeba ručně kontrolovat - až se >> vyřeší ten copyright a přidám tam tu jednu drobnou kontrolu. Těch >> možností, kdy se tam objeví otazník (není si to jisté) je myslím >> minimum. Zatím se mi to nestalo. >> >> Honza >> >> >> 2010/2/13 Petr Dlouhý <petr.dlouhy na email.cz>: >>> Ahoj, >>> >>> ten copyright je jen úplně nahoře na každé dlaždici, nebo se pletu? Pokud >>> tomu tak je, tak bych volil možnost a), protože je to minimum z velikosti >>> dlaždice, a ty se už stejně stahují s přesahem (kvůli tomu, že se čísla >>> kreslí jen na dlaždici s tečkou). >>> >>> Jinak jsem se koukal na ten skript, a zdá se to velice dobré. Myslím, že >>> by stálo za to to přepočítat, vzhledem k tomu, že je to tak 20x rychlejší, >>> tak to asi nebude problém udělat na jednou počítači. >>> >>> Chyby vidím následující: >>> >>> -Některé adresní body nejsou vůbec detekovány, a u některých je prázdný >>> text (přestože jsou daleko od všeho). >>> -Často se objevuje [CHECK] i u bodů, které byly detekovány správně. Pokud >>> je to v případech, kdy se čísla už skutečně překrývají, tak OK. Jenom se >>> ptám, jestli není možné zvolit agresivnější ořez před detekcí (pozor na >>> jiné posunutí č.e. vs č.p.). >>> -V případech, kdy se objeví [CHECK], tak by asi skript měl stáhnout číslo >>> ve vyšším rozlišení a detekovat to. >>> >>> >>> On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >>> wrote: >>> >>>> Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy. >>>> Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne. >>>> Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze >>>> červenou barvu. Jsou 3 možnosti jak to řešit: >>>> >>>> a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z >>>> těch částí mapy, které copyright není. Výhody: Nejlepší výsledky. >>>> Nevýhody: Nutnost stahovat více dat z WMS. >>>> >>>> b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy >>>> downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody: >>>> Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem >>>> - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale >>>> nemusí to znamenat nic, i když se to trefí. >>>> >>>> c) Provádět ruční kontrolu všech popisků s překryvem (těch může být >>>> hodně). >>>> >>>> Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený >>>> názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít >>>> postřehnutelně horší výsledky. >>>> >>>> Honza >>>> >>>> >>>> >>>> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >>>>> Doplnil jsem tam chybějící číslici 4. >>>>> >>>>> Honza >>>>> >>>>> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >>>>>> K vyzkoušení: >>>>>> http://jabi.aspone.cz/osm/OcrBeta1.zip >>>>>> >>>>>> Má to stejné ovládání jako původní tile-processor, ale navíc možnost >>>>>> logování: >>>>>> >>>>>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv >>>>>> -log log.txt -all >>>>>> >>>>>> -log log.txt ... pokud se toto uvede, tak program bude logovat >>>>>> nerozpoznané body nebo ty, které byly narušené překryvem. >>>>>> >>>>>> Pokud se uvede navíc -all, tak se budou logovat všechny body. >>>>>> >>>>>> Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je >>>>>> to také textový soubor, který když zobrazíte fontem s pevnou šířkou, >>>>>> tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za >>>>>> č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při >>>>>> spuštění v aktuálním adresáři. >>>>>> >>>>>> Honza >>>>>> >>>>>> >>>>>> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >>>>>>> Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude >>>>>>> výrazně lepší než byla (to už je myslím teď). Ale stoprocentní >>>>>>> samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. >>>>>>> >>>>>>> Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou >>>>>>> dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A >>>>>>> také jim to bude zatěžovat servery, když se to přežene s rychlostí >>>>>>> stahování (mnoho vláken apod.). >>>>>>> >>>>>>> Honza >>>>>>> >>>>>>> >>>>>>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>>>>> Kvůli překryvům - čísla se s rozlišením zmenšují. >>>>>>>> Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících >>>>>>>> se >>>>>>>> číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. >>>>>>>> Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím >>>>>>>> zabralo počítání. >>>>>>>> >>>>>>>> Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc >>>>>>>> cenu, >>>>>>>> protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat >>>>>>>> příliš >>>>>>>> mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení >>>>>>>> může >>>>>>>> nastat spíš tím, že je nutné zpracovat větší množství obrazové >>>>>>>> informace. >>>>>>>> >>>>>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak >>>>>>>> <jan.bilak.osm na gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Ahoj, >>>>>>>>> k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým >>>>>>>>> rozlišením >>>>>>>>> ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho >>>>>>>>> detekovat oblasti, které obsahují adresní body. A jen tyto úseky >>>>>>>>> stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit >>>>>>>>> množství stahovaných dat. Přijde mi, že nejpomalejší bude právě >>>>>>>>> stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas >>>>>>>>> prodloužil. >>>>>>>>> >>>>>>>>> Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, >>>>>>>>> které byste mohli někam hodit zazipované, abych to nemusel stahovat >>>>>>>>> z >>>>>>>>> WMS pro testování? >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>>> >>>>>>>>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>>>>>>> Ahoj, >>>>>>>>>> >>>>>>>>>> zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, >>>>>>>>>> tak by >>>>>>>>>> možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší >>>>>>>>>> detekci >>>>>>>>>> u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším >>>>>>>>>> zoomem, >>>>>>>>>> tak to bude další plus). >>>>>>>>>> >>>>>>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak >>>>>>>>>> <jan.bilak.osm na gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Ahoj, >>>>>>>>>>> >>>>>>>>>>> pokusná implementace je velmi rychlá a měla by být i spolehlivá. >>>>>>>>>>> >>>>>>>>>>> Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. >>>>>>>>>>> Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas >>>>>>>>>>> zpracování jednoho adresního bodu je 17 ms. To vše v jednom >>>>>>>>>>> vlákně a >>>>>>>>>>> tedy to zatěžuje jen jedno jádro procesoru. >>>>>>>>>>> >>>>>>>>>>> Zítra to snad dodělám do použitelného stavu. >>>>>>>>>>> >>>>>>>>>>> Honza >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: >>>>>>>>>>>> Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat >>>>>>>>>>>> pouze >>>>>>>>>>>> ta >>>>>>>>>>>> evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je >>>>>>>>>>>> tam ta >>>>>>>>>>>> dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že >>>>>>>>>>>> by to >>>>>>>>>>>> nešlo >>>>>>>>>>>> uříznout o trochu níž. Problém je, že už jsme to udělali špatně, >>>>>>>>>>>> takže >>>>>>>>>>>> by >>>>>>>>>>>> to bylo dobré napravit bez toho, abychom museli všechno >>>>>>>>>>>> předělávat. >>>>>>>>>>>> >>>>>>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec >>>>>>>>>>>> <utx na penguin.cz> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat >>>>>>>>>>>>> uříznutou >>>>>>>>>>>>> dvojku? Pokud to ovšem nezvýší riziko chyby jinde. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Petr Dlouhý >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Talk-cz mailing list >>>>>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Talk-cz mailing list >>>>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Petr Dlouhý >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk-cz mailing list >>>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Petr Dlouhý >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz na openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> -- >>> Petr Dlouhý >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >

13.2.2010 01:10:29 (#120)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
Ořez by mohl být nižší, ale já to každý sloupec reprezentuji 16-bitovým číslem (16 řádek) a pak s tím dělám různé bitové operace. Takže 15 by se mi nehodilo... Tyhle nápady jsou dobré, ale nejsou třeba. Algoritmus totiž funguje tak, že se snaží najít napřed přesnou shodu. A pokud přesná shoda není, tak najít všechny možnosti, které tam mohou být. Pokud je více možností, co by tam mohlo být, tak to do textu přidá ?. Pokud jedna možnost, tak ji to bere jako správnou. A pokud žádá možnost, tak to končí. Check je jen indikace toho, že tam nebyla přesná shoda. Otazník je indikace toho, že to bylo mnohoznačné. Zatím tam tedy chybí jedna kontrola, která teoreticky může způsobit chybu bez otázníku (jen s checkem). Ale to opravím a pravděpodobnost takové chyby je velmi malá. Testovací data by se mi hodila, pokud máš kam dát nějaký archiv (klidně na nějaký free one-file hosting typu rapidshare - ale účet tam nikde nemám, tak aby to bylo reálné stáhnout zdarma). Honza 2010/2/13 Petr Dlouhý <petr.dlouhy na email.cz>: 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 na email.cz> >> Předmět: Re: [Talk-cz] Import adres z katastralni mapy >> Datum: 13.2.2010 00:29:16 >> ---------------------------------------- >> Ahoj, >> >> ten copyright je jen úplně nahoře na každé dlaždici, nebo se pletu? Pokud >> tomu tak je, tak bych volil možnost a), protože je to minimum z velikosti >> dlaždice, a ty se už stejně stahují s přesahem (kvůli tomu, že se čísla >> kreslí jen na dlaždici s tečkou). >> >> Jinak jsem se koukal na ten skript, a zdá se to velice dobré. Myslím, že >> by stálo za to to přepočítat, vzhledem k tomu, že je to tak 20x rychlejší, >> tak to asi nebude problém udělat na jednou počítači. >> >> Chyby vidím následující: >> >> -Některé adresní body nejsou vůbec detekovány, a u některých je prázdný >> text (přestože jsou daleko od všeho). >> -Často se objevuje [CHECK] i u bodů, které byly detekovány správně. Pokud >> je to v případech, kdy se čísla už skutečně překrývají, tak OK. Jenom se >> ptám, jestli není možné zvolit agresivnější ořez před detekcí (pozor na >> jiné posunutí č.e. vs č.p.). >> -V případech, kdy se objeví [CHECK], tak by asi skript měl stáhnout číslo >> ve vyšším rozlišení a detekovat to. >> >> >> On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >> wrote: >> >> > Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy. >> > Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne. >> > Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze >> > červenou barvu. Jsou 3 možnosti jak to řešit: >> > >> > a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z >> > těch částí mapy, které copyright není. Výhody: Nejlepší výsledky. >> > Nevýhody: Nutnost stahovat více dat z WMS. >> > >> > b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy >> > downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody: >> > Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem >> > - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale >> > nemusí to znamenat nic, i když se to trefí. >> > >> > c) Provádět ruční kontrolu všech popisků s překryvem (těch může být >> > hodně). >> > >> > Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený >> > názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít >> > postřehnutelně horší výsledky. >> > >> > Honza >> > >> > >> > >> > 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >> >> Doplnil jsem tam chybějící číslici 4. >> >> >> >> Honza >> >> >> >> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >> >>> K vyzkoušení: >> >>> http://jabi.aspone.cz/osm/OcrBeta1.zip >> >>> >> >>> Má to stejné ovládání jako původní tile-processor, ale navíc možnost >> >>> logování: >> >>> >> >>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv >> >>> -log log.txt -all >> >>> >> >>> -log log.txt ... pokud se toto uvede, tak program bude logovat >> >>> nerozpoznané body nebo ty, které byly narušené překryvem. >> >>> >> >>> Pokud se uvede navíc -all, tak se budou logovat všechny body. >> >>> >> >>> Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je >> >>> to také textový soubor, který když zobrazíte fontem s pevnou šířkou, >> >>> tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za >> >>> č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při >> >>> spuštění v aktuálním adresáři. >> >>> >> >>> Honza >> >>> >> >>> >> >>> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >> >>>> Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude >> >>>> výrazně lepší než byla (to už je myslím teď). Ale stoprocentní >> >>>> samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. >> >>>> >> >>>> Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou >> >>>> dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A >> >>>> také jim to bude zatěžovat servery, když se to přežene s rychlostí >> >>>> stahování (mnoho vláken apod.). >> >>>> >> >>>> Honza >> >>>> >> >>>> >> >>>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >> >>>>> Kvůli překryvům - čísla se s rozlišením zmenšují. >> >>>>> Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících >> >>>>> se >> >>>>> číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. >> >>>>> Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím >> >>>>> zabralo počítání. >> >>>>> >> >>>>> Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc >> >>>>> cenu, >> >>>>> protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat >> >>>>> příliš >> >>>>> mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení >> >>>>> může >> >>>>> nastat spíš tím, že je nutné zpracovat větší množství obrazové >> >>>>> informace. >> >>>>> >> >>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak >> >>>>> <jan.bilak.osm na gmail.com> >> >>>>> wrote: >> >>>>> >> >>>>>> Ahoj, >> >>>>>> k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým >> >>>>>> rozlišením >> >>>>>> ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho >> >>>>>> detekovat oblasti, které obsahují adresní body. A jen tyto úseky >> >>>>>> stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit >> >>>>>> množství stahovaných dat. Přijde mi, že nejpomalejší bude právě >> >>>>>> stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas >> >>>>>> prodloužil. >> >>>>>> >> >>>>>> Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, >> >>>>>> které byste mohli někam hodit zazipované, abych to nemusel stahovat >> >>>>>> z >> >>>>>> WMS pro testování? >> >>>>>> >> >>>>>> Honza >> >>>>>> >> >>>>>> >> >>>>>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >> >>>>>>> Ahoj, >> >>>>>>> >> >>>>>>> zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, >> >>>>>>> tak by >> >>>>>>> možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší >> >>>>>>> detekci >> >>>>>>> u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším >> >>>>>>> zoomem, >> >>>>>>> tak to bude další plus). >> >>>>>>> >> >>>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak >> >>>>>>> <jan.bilak.osm na gmail.com> >> >>>>>>> wrote: >> >>>>>>> >> >>>>>>>> Ahoj, >> >>>>>>>> >> >>>>>>>> pokusná implementace je velmi rychlá a měla by být i spolehlivá. >> >>>>>>>> >> >>>>>>>> Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. >> >>>>>>>> Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas >> >>>>>>>> zpracování jednoho adresního bodu je 17 ms. To vše v jednom >> >>>>>>>> vlákně a >> >>>>>>>> tedy to zatěžuje jen jedno jádro procesoru. >> >>>>>>>> >> >>>>>>>> Zítra to snad dodělám do použitelného stavu. >> >>>>>>>> >> >>>>>>>> Honza >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: >> >>>>>>>>> Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat >> >>>>>>>>> pouze >> >>>>>>>>> ta >> >>>>>>>>> evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je >> >>>>>>>>> tam ta >> >>>>>>>>> dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že >> >>>>>>>>> by to >> >>>>>>>>> nešlo >> >>>>>>>>> uříznout o trochu níž. Problém je, že už jsme to udělali špatně, >> >>>>>>>>> takže >> >>>>>>>>> by >> >>>>>>>>> to bylo dobré napravit bez toho, abychom museli všechno >> >>>>>>>>> předělávat. >> >>>>>>>>> >> >>>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec >> >>>>>>>>> <utx na penguin.cz> >> >>>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>>> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat >> >>>>>>>>>> uříznutou >> >>>>>>>>>> dvojku? Pokud to ovšem nezvýší riziko chyby jinde. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> -- >> >>>>>>>>> Petr Dlouhý >> >>>>>>>>> >> >>>>>>>>> _______________________________________________ >> >>>>>>>>> Talk-cz mailing list >> >>>>>>>>> Talk-cz na openstreetmap.org >> >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> _______________________________________________ >> >>>>>>>> Talk-cz mailing list >> >>>>>>>> Talk-cz na openstreetmap.org >> >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >> >>>>>>> >> >>>>>>> >> >>>>>>> -- >> >>>>>>> Petr Dlouhý >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> Talk-cz mailing list >> >>>>>>> Talk-cz na openstreetmap.org >> >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >> >>>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Talk-cz mailing list >> >>>>>> Talk-cz na openstreetmap.org >> >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Petr Dlouhý >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Talk-cz mailing list >> >>>>> Talk-cz na openstreetmap.org >> >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >> >>>>> >> >>>> >> >>> >> >> >> > >> > _______________________________________________ >> > Talk-cz mailing list >> > Talk-cz na openstreetmap.org >> > http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> -- >> Petr Dlouhý >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> > > Petr Dlouhý > petr.dlouhy na email.cz > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

13.2.2010 01:13:59 (#121)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
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 na 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 na email.cz>: >> Ahoj, >> >> teprv teď jsem si všiml toho krásného logu. Ořez by mohl být o 1 pixel >> nižší a o něco užší (nevím ale kolikaciferná je nejdelší adresa). >> Další nápady na snížení množství [CHECK] jsou: >>        Pokud adresa začíná na "bez č.p./č.e." tak není nutné dávat [CHECK], ale >> stačí oříznout zbytek řetězce (tím se vyřadí tak polovina případů). >>        Pokud je tam navíc pouze pár bodů nižších než číslice/písmeno, nemohou ji >> tvořit, a tudíž není nutné dávat [CHECK], protože se tam nemohl připlést >> nějaký další adresný bod, který by musel začínat na č nebo b. >> >> Pro vypořádání s copyrightem existuje ještě možnost d) - pokud si skript není jist výsledkem, tak si stáhne zazoomované číslo, takže mu muže být copyright jedno. >> Spolehlivé to není hlavně v místech, kde je několik adres v jednom shluku (poměrně blízko sebe). >> >> Kontroluju to tak, že si vygeneruju adresní body pomocí Merge skriptu a >> otevřu to v JOSM. >> >> PS. Jestli pořád sháníš testovací data, můžu ti poslat celou prahu-západ, myslel jsem, že už jsem jí smazal, ale není tomu tak. >> >>> ------------ Původní zpráva ------------ >>> Od: Petr Dlouhý <petr.dlouhy na email.cz> >>> Předmět: Re: [Talk-cz] Import adres z katastralni mapy >>> Datum: 13.2.2010 00:29:16 >>> ---------------------------------------- >>> Ahoj, >>> >>> ten copyright je jen úplně nahoře na každé dlaždici, nebo se pletu? Pokud >>> tomu tak je, tak bych volil možnost a), protože je to minimum z velikosti >>> dlaždice, a ty se už stejně stahují s přesahem (kvůli tomu, že se čísla >>> kreslí jen na dlaždici s tečkou). >>> >>> Jinak jsem se koukal na ten skript, a zdá se to velice dobré. Myslím, že >>> by stálo za to to přepočítat, vzhledem k tomu, že je to tak 20x rychlejší, >>> tak to asi nebude problém udělat na jednou počítači. >>> >>> Chyby vidím následující: >>> >>> -Některé adresní body nejsou vůbec detekovány, a u některých je prázdný >>> text (přestože jsou daleko od všeho). >>> -Často se objevuje [CHECK] i u bodů, které byly detekovány správně. Pokud >>> je to v případech, kdy se čísla už skutečně překrývají, tak OK. Jenom se >>> ptám, jestli není možné zvolit agresivnější ořez před detekcí (pozor na >>> jiné posunutí č.e. vs č.p.). >>> -V případech, kdy se objeví [CHECK], tak by asi skript měl stáhnout číslo >>> ve vyšším rozlišení a detekovat to. >>> >>> >>> On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >>> wrote: >>> >>> > Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy. >>> > Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne. >>> > Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze >>> > červenou barvu. Jsou 3 možnosti jak to řešit: >>> > >>> > a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z >>> > těch částí mapy, které copyright není. Výhody: Nejlepší výsledky. >>> > Nevýhody: Nutnost stahovat více dat z WMS. >>> > >>> > b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy >>> > downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody: >>> > Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem >>> > - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale >>> > nemusí to znamenat nic, i když se to trefí. >>> > >>> > c) Provádět ruční kontrolu všech popisků s překryvem (těch může být >>> > hodně). >>> > >>> > Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený >>> > názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít >>> > postřehnutelně horší výsledky. >>> > >>> > Honza >>> > >>> > >>> > >>> > 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >>> >> Doplnil jsem tam chybějící číslici 4. >>> >> >>> >> Honza >>> >> >>> >> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >>> >>> K vyzkoušení: >>> >>> http://jabi.aspone.cz/osm/OcrBeta1.zip >>> >>> >>> >>> Má to stejné ovládání jako původní tile-processor, ale navíc možnost >>> >>> logování: >>> >>> >>> >>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv >>> >>> -log log.txt -all >>> >>> >>> >>> -log log.txt ... pokud se toto uvede, tak program bude logovat >>> >>> nerozpoznané body nebo ty, které byly narušené překryvem. >>> >>> >>> >>> Pokud se uvede navíc -all, tak se budou logovat všechny body. >>> >>> >>> >>> Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je >>> >>> to také textový soubor, který když zobrazíte fontem s pevnou šířkou, >>> >>> tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za >>> >>> č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při >>> >>> spuštění v aktuálním adresáři. >>> >>> >>> >>> Honza >>> >>> >>> >>> >>> >>> 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>: >>> >>>> Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude >>> >>>> výrazně lepší než byla (to už je myslím teď). Ale stoprocentní >>> >>>> samozřejmě ne - když překryv bude velký, tak to určitě nepůjde. >>> >>>> >>> >>>> Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou >>> >>>> dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A >>> >>>> také jim to bude zatěžovat servery, když se to přežene s rychlostí >>> >>>> stahování (mnoho vláken apod.). >>> >>>> >>> >>>> Honza >>> >>>> >>> >>>> >>> >>>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >>> >>>>> Kvůli překryvům - čísla se s rozlišením zmenšují. >>> >>>>> Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících >>> >>>>> se >>> >>>>> číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí. >>> >>>>> Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím >>> >>>>> zabralo počítání. >>> >>>>> >>> >>>>> Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc >>> >>>>> cenu, >>> >>>>> protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat >>> >>>>> příliš >>> >>>>> mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení >>> >>>>> může >>> >>>>> nastat spíš tím, že je nutné zpracovat větší množství obrazové >>> >>>>> informace. >>> >>>>> >>> >>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak >>> >>>>> <jan.bilak.osm na gmail.com> >>> >>>>> wrote: >>> >>>>> >>> >>>>>> Ahoj, >>> >>>>>> k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým >>> >>>>>> rozlišením >>> >>>>>> ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho >>> >>>>>> detekovat oblasti, které obsahují adresní body. A jen tyto úseky >>> >>>>>> stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit >>> >>>>>> množství stahovaných dat. Přijde mi, že nejpomalejší bude právě >>> >>>>>> stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas >>> >>>>>> prodloužil. >>> >>>>>> >>> >>>>>> Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti, >>> >>>>>> které byste mohli někam hodit zazipované, abych to nemusel stahovat >>> >>>>>> z >>> >>>>>> WMS pro testování? >>> >>>>>> >>> >>>>>> Honza >>> >>>>>> >>> >>>>>> >>> >>>>>> 2010/2/12 Petr Dlouhý <petr.dlouhy na email.cz>: >>> >>>>>>> Ahoj, >>> >>>>>>> >>> >>>>>>> zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, >>> >>>>>>> tak by >>> >>>>>>> možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší >>> >>>>>>> detekci >>> >>>>>>> u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším >>> >>>>>>> zoomem, >>> >>>>>>> tak to bude další plus). >>> >>>>>>> >>> >>>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak >>> >>>>>>> <jan.bilak.osm na gmail.com> >>> >>>>>>> wrote: >>> >>>>>>> >>> >>>>>>>> Ahoj, >>> >>>>>>>> >>> >>>>>>>> pokusná implementace je velmi rychlá a měla by být i spolehlivá. >>> >>>>>>>> >>> >>>>>>>> Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s. >>> >>>>>>>> Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas >>> >>>>>>>> zpracování jednoho adresního bodu je 17 ms. To vše v jednom >>> >>>>>>>> vlákně a >>> >>>>>>>> tedy to zatěžuje jen jedno jádro procesoru. >>> >>>>>>>> >>> >>>>>>>> Zítra to snad dodělám do použitelného stavu. >>> >>>>>>>> >>> >>>>>>>> Honza >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> 2010/2/11 Petr Dlouhý <petr.dlouhy na email.cz>: >>> >>>>>>>>> Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat >>> >>>>>>>>> pouze >>> >>>>>>>>> ta >>> >>>>>>>>> evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je >>> >>>>>>>>> tam ta >>> >>>>>>>>> dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že >>> >>>>>>>>> by to >>> >>>>>>>>> nešlo >>> >>>>>>>>> uříznout o trochu níž. Problém je, že už jsme to udělali špatně, >>> >>>>>>>>> takže >>> >>>>>>>>> by >>> >>>>>>>>> to bylo dobré napravit bez toho, abychom museli všechno >>> >>>>>>>>> předělávat. >>> >>>>>>>>> >>> >>>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec >>> >>>>>>>>> <utx na penguin.cz> >>> >>>>>>>>> wrote: >>> >>>>>>>>> >>> >>>>>>>>>> Aha, tak to jsme si nerozuměli. Nejde naučit ho poznávat >>> >>>>>>>>>> uříznutou >>> >>>>>>>>>> dvojku? Pokud to ovšem nezvýší riziko chyby jinde. >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> -- >>> >>>>>>>>> Petr Dlouhý >>> >>>>>>>>> >>> >>>>>>>>> _______________________________________________ >>> >>>>>>>>> Talk-cz mailing list >>> >>>>>>>>> Talk-cz na openstreetmap.org >>> >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>>>>>>>> >>> >>>>>>>> >>> >>>>>>>> _______________________________________________ >>> >>>>>>>> Talk-cz mailing list >>> >>>>>>>> Talk-cz na openstreetmap.org >>> >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> -- >>> >>>>>>> Petr Dlouhý >>> >>>>>>> >>> >>>>>>> _______________________________________________ >>> >>>>>>> Talk-cz mailing list >>> >>>>>>> Talk-cz na openstreetmap.org >>> >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>>>>>> >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> Talk-cz mailing list >>> >>>>>> Talk-cz na openstreetmap.org >>> >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> Petr Dlouhý >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> Talk-cz mailing list >>> >>>>> Talk-cz na openstreetmap.org >>> >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>>>> >>> >>>> >>> >>> >>> >> >>> > >>> > _______________________________________________ >>> > Talk-cz mailing list >>> > Talk-cz na openstreetmap.org >>> > http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> -- >>> Petr Dlouhý >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> >> >> Petr Dlouhý >> petr.dlouhy na email.cz >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >

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 na 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 na 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>
151
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 na 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 na gmail.com> > wrote: > >> Ořez by mohl být nižší, ale já to každý sloupec reprezentuji >> 16-bitovým číslem (16 řádek) a pak s tím dělám různé bitové operace. >> Takže 15 by se mi nehodilo... >> Tyhle nápady jsou dobré, ale nejsou třeba. Algoritmus totiž funguje >> tak, že se snaží najít napřed přesnou shodu. A pokud přesná shoda >> není, tak najít všechny možnosti, které tam mohou být. Pokud je více >> možností, co by tam mohlo být, tak to do textu přidá ?. Pokud jedna >> možnost, tak ji to bere jako správnou. A pokud žádá možnost, tak to >> končí. Check je jen indikace toho, že tam nebyla přesná shoda. Otazník >> je indikace toho, že to bylo mnohoznačné. Zatím tam tedy chybí jedna >> kontrola, která teoreticky může způsobit chybu bez otázníku (jen s >> checkem). Ale to opravím a pravděpodobnost takové chyby je velmi malá. >> Testovací data by se mi hodila, pokud máš kam dát nějaký archiv >> (klidně na nějaký free one-file hosting typu rapidshare - ale účet tam >> nikde nemám, tak aby to bylo reálné stáhnout zdarma). >> Honza > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

13.2.2010 01:58:07 (#125)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
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 na 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 na gmail.com> > wrote: > >> Ořez by mohl být nižší, ale já to každý sloupec reprezentuji >> 16-bitovým číslem (16 řádek) a pak s tím dělám různé bitové operace. >> Takže 15 by se mi nehodilo... >> Tyhle nápady jsou dobré, ale nejsou třeba. Algoritmus totiž funguje >> tak, že se snaží najít napřed přesnou shodu. A pokud přesná shoda >> není, tak najít všechny možnosti, které tam mohou být. Pokud je více >> možností, co by tam mohlo být, tak to do textu přidá ?. Pokud jedna >> možnost, tak ji to bere jako správnou. A pokud žádá možnost, tak to >> končí. Check je jen indikace toho, že tam nebyla přesná shoda. Otazník >> je indikace toho, že to bylo mnohoznačné. Zatím tam tedy chybí jedna >> kontrola, která teoreticky může způsobit chybu bez otázníku (jen s >> checkem). Ale to opravím a pravděpodobnost takové chyby je velmi malá. >> Testovací data by se mi hodila, pokud máš kam dát nějaký archiv >> (klidně na nějaký free one-file hosting typu rapidshare - ale účet tam >> nikde nemám, tak aby to bylo reálné stáhnout zdarma). >> Honza > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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 na 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 na 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>
151
Ahoj, díky, kouknu se na to, kde je problém. Honza 2010/2/13 Petr Dlouhý <petr.dlouhy na 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 na gmail.com> > wrote: > >> Zkoušel jsem tu dlaždici >> http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png >> a nenašel jsem žádný bod, který by to nedetekovalo. Nechal jsem si >> udělat modrou tečku do původní bitmapy na každý detekovaný bod ... a >> ruční kontrolou byly všechny omodřené a žádný červený nezbyl. >> Prosím o jeden případ bodu (číslo popisné, souřadnici v pixelech nebo >> tak něco), který se ti nedetekoval. >> Do csv mi to napsalo 186 řádek. Tedy to našlo 186 bodů. Tobě také? >> Honza > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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

13.2.2010 03:07:15 (#130)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
OK, nic se nestalo. Hlavně, že se to vyjasnilo. Honza 2010/2/13 Petr Dlouhý <petr.dlouhy na 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 na email.cz> >> Předmět: Re: [Talk-cz] Import adres z katastralni mapy >> Datum: 13.2.2010 03:02:22 >> ---------------------------------------- >> Ahoj, >> >> 186 souhlasí, ty chybějící body jsou vždy "bez č.p./č.e.". Chybí například >> bod pod č.p. 1 a 121 na souřadnicích 50,13254; 14,33821. >> >> On Sat, 13 Feb 2010 01:58:07 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >> wrote: >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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 na 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>
151
Ahoj. Dal jsem tam betu 3 ... http://jabi.aspone.cz/osm/OcrBeta3.zip Pridava drive zminovanou podminku, ktera umoznuje detekovat, zda jde o jednoznacne rozpoznani nebo je treba rucni kontrola. Dale meni stavy rozpoznani: [CHECK] ... je treba rucni kontrola [OVERLAP] ... byl tam prekryv, ale melo by to byt jednoznacne (spise pro debug ucely a overeni programu) Doslo i ke zmene parametru programu: Command line options are: -tiles [..] (*) Path to downloaded tiles -output [..] (*) Output filename -log [..] Log filename -all Log all -overlap Log overlap -threads [..] Thread count (*) Required. Defaultni logovani pri uvedeni souboru logu je takove, ze se loguji jen CHECK body. Lze zapnout i overlap body nebo vsechny. Na Monu je asi problem s vicevlaknovym provozem (asi je treba jeste navic neco zamykat nebo tak neco), tak pribyl argument pro urceni poctu vlaken. Pri problemech nastavte na hodnotu 1. A dale cernou barvu povazuji za cervenou. Pokud s tim budou problemy, lze zvolit variantu s orezem a vetsim prekryvem nebo dynamicke stahovani zazoomovane oblasti (pracnejsi). Honza 2010/2/13 Petr Dlouhý <petr.dlouhy na email.cz>: 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 na email.cz> > wrote: > >> Posílám testovací data (měl by to být celý okres Praha-západ) na [2]. > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

13.2.2010 06:10:37 (#133)
gravatar

Jan Bilak

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

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 na 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>
151
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 na 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 na gmail.com> > wrote: > >> Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) - >> oprava "padání". >> Honza > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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 na 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>
151
Dal jsem tam novou verzi beta3 (na stejné místo). Má navíc parametr -gc, kterým lze zařídit zavolání Garbace Collectoru po zpracování každé dlaždice. Tím se výrazně sníží paměťové nároky, ale za cenu nějakého snížení rychlosti. Zkus to prosím. Mne to ve Windows žere bez -gc spičkově tak 650 MB, s -gc tak 250 MB. To při použití dvou vláken. Jinak jsem zatím po zpracování dalších dlaždic z Prahy problém nenarazil. Honza 2010/2/13 Petr Dlouhý <petr.dlouhy na email.cz>: 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 na gmail.com> > wrote: > >> Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) - >> oprava "padání". >> Honza > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

13.2.2010 07:31:55 (#138)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
Projel jsem všechny dlaždice, které jsi mi poslal. Na problém jsem nenarazil. Možné je to specifické chování Mona - já to dělám pod .NETem (třeba vím, že pod Monem mi aplikace vždycky padala, když jsem přistupoval ke konzoli z více vláken, zato .NET to automaticky synchronizoval apod.). Nevím - těžko se ladí něco, co se mi neprojevuje. Zdrojáky jsou tady: http://jabi.aspone.cz/osm/FindAddressPoints-beta3-src.zip Pokud by se problém nepodařilo odstranit, tak je možné to dělat pod Windows. Zase tak dlouho to myslím netrvá, aby byla třeba dělat akce na způsob SETI na home. Honza 2010/2/13 Jan Bilak <jan.bilak.osm na gmail.com>: 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 na email.cz>: >> Ahoj, >> >> je tam stále ten problém s pamětí. Když jsem zkoušel adresář pz1, tak to >> po nějaké době začne náhle konzumovat velké množství paměti (zabere mi to >> cca 1,7 GB paměti +  0,5 GB swapu). Není to způsobené programem samotným >> (dlouhou dobu se paměť téměř nezabírá), ale ani jednotlivou dlaždicí >> (během finále se stále ještě dlaždice mění). >> >> On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak <jan.bilak.osm na gmail.com> >> wrote: >> >>> Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) - >>> oprava "padání". >>> Honza >> >> >> -- >> Petr Dlouhý >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >

13.2.2010 07:39:10 (#139)
gravatar

Jan Bilak

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

14.2.2010 06:40:26 (#140)
gravatar

Jan Bilak

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

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 na 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>
151
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 na 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 na gmail.com> > wrote: > >> Ahoj, >> mas k tomu jeste nejake zasadni postrehy (co je treba upravit)? Tedy >> krome toho, ze ti to zacne plnit pamet, protoze to se mi nepodarilo >> nasimulovat a ani nemam zadny napad, cim by to mohlo byt. >> Honza > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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 na 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>
151
Máš pravdu, hledal jsem to nějak špatně - mám to v logách... Omlouvám se. Honza 2010/2/14 Petr Dlouhý <petr.dlouhy na email.cz>: 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 na gmail.com> > wrote: > >> Ahoj, >> pokud máš někde po ruce csv výpis (kde jsou souřadnice těch chyb s >> mezerami), tam mi jej prosím pošli. Kouknul bych se, proč to nastává a >> co se s tím dá dělat. Může to způsobovat i nějaké méně viditelné >> chyby. U těch dat Prahy, které jsi mne poslal, se toto nestalo. >> S tím GC to volat třeba po 100 mapkách asi nemá smysl, protože každá >> bitmapa v paměti zabere asi 50 MB (4000x4000 px a v RGB 3 byte na >> pixel) a k tomu ještě další pomocné struktury ... celé se to musí >> násobit počtem vláken ... tedy alokuje se tam velké množství paměti. >> Ale ten rozdíl časů nemusí být velký, protože i při standardním >> chování se musí GC volat celkem často. > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

15.2.2010 12:51:12 (#145)
gravatar

Jan Bilak

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

15.2.2010 09:44:58 (#146)
gravatar

Lukas Kabrt

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

17.2.2010 03:38:21 (#149)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
96
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 na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >
Petr Dlouhý petr.dlouhy na email.cz

17.2.2010 04:15:34 (#151)
gravatar

Jan Bilak

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

17.2.2010 04:17:16 (#152)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
A mimochodem nejde o můj program ... je to upravený ten tvůj. Honza 2010/2/17 Jan Bilak <jan.bilak.osm na gmail.com>: 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 na email.cz>: >> Princip práce Honzova programu se dá jednoduše poznat z logových souborů. >> >> Zdrojáky by asi bylo nejlepší nahrát na <http://svn.openstreetmap.org/applications/utils/>, abychom se s nimi při příštím importu zase setkali, a aby se jimi mohli inspirovat i ostatní. >> >> >>> ------------ Původní zpráva ------------ >>> Od: Lukas Kabrt <lukas na kabrt.cz> >>> Předmět: Re: [Talk-cz] Import adres z katastralni mapy >>> Datum: 17.2.2010 15:38:57 >>> ---------------------------------------- >> >>> BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program pracuje. >>> >>> -- >>> Lukas >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> >> >> Petr Dlouhý >> petr.dlouhy na email.cz >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >

17.2.2010 05:08:35 (#153)
gravatar

Jan Bilak

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

23.2.2010 12:28:24 (#154)
gravatar

Lukas Kabrt

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