Import adres z katastralni mapy

160 zpráv
Zpět na přehled

Import adres z katastralni mapy

160 zpráv PJLMHJKJ 14 účastníků 111 min čtení
  1. Lukas Kabrt lukas na kabrt.cz #m8099c2
    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
  2. hanoj ehanoj na gmail.com #mabd203
    Ahoj, jenom strucne: 1) vyborne!!!
    [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...
    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
  3. Martin Kupec magon na jkopava.cz #m0e3368
    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
  4. hanoj ehanoj na gmail.com #me73043
    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
  5. Radomír Černoch radomir.cernoch na gmail.com #m1ff563
    Dobrý den, 2010/1/16 Lukas Kabrt <lukas na kabrt.cz>:
    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
  6. Lukas Kabrt lukas na kabrt.cz #ma8ac35
    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
  7. Martin Kupec magon na jkopava.cz #m44b679
    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
  8. Petr Dlouhý petr.dlouhy na email.cz #mc07178
    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.
  9. Jiri Parkan jparkan na gmail.com #m28c561
    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>:
  10. Lukas Kabrt lukas na kabrt.cz #m5e8df1
    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>:
  11. Petr Dlouhý petr.dlouhy na email.cz #mc1b953
    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
  12. Aleš Janda openstreetmap na kyblsoft.cz #m3026b6
    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
  13. Lukas Kabrt lukas na kabrt.cz #mb67474
    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].
    Dneska jsem to zkoušel pod wine. Bohužel nevyřešil, píše to $ wine tile-processor.exe -tiles data/oblast/ -output data/oblast.csv
    ...
    Asi to chce ten .NET Framework 3.5, ale ten je ve Wine označen jako garbage, tak jsem to zatím dál nezkoušel...
    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
  14. Petr Dlouhý petr.dlouhy na email.cz #m4f815e
    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.
  15. Petr Dlouhý petr.dlouhy na email.cz #md6dce8
    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>
  16. Petr Dlouhý petr.dlouhy na email.cz #mc083ec
    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.
  17. Petr Dlouhý petr.dlouhy na email.cz #m233108
    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>
  18. Lukas Kabrt lukas na kabrt.cz #mbd7580
    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 ...
    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.
    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.
    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
  19. Martin Kupec magon na jkopava.cz #meaab44
    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. Lukas Kabrt lukas na kabrt.cz #mea89ca
    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/
  21. Petr Dlouhý petr.dlouhy na email.cz #ma2d8c8
    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.
  22. Petr Dlouhý petr.dlouhy na email.cz #m948740
    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
    ---------------------------------------- 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.
    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ý petr.dlouhy na email.cz
  23. Lukas Kabrt lukas na kabrt.cz #mf9c4cc
    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
  24. Petr Dlouhý petr.dlouhy na email.cz #m3da9fe
    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.
  25. Martin Kupec magon na jkopava.cz #mc61594
    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
  26. Petr Dlouhý petr.dlouhy na email.cz #m6e999a
    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.
  27. Lukas Kabrt lukas na kabrt.cz #m6e4d45
    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
  28. Jiri Parkan jparkan na gmail.com #m9281fb
    2010/1/21 Lukas Kabrt <lukas na kabrt.cz>:
    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
  29. Lukas Kabrt lukas na kabrt.cz #mf08b71
    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
  30. Petr Dlouhý petr.dlouhy na email.cz #m1e90ff
    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).
  31. Petr Dlouhý petr.dlouhy na email.cz #m31ab54
    Já ještě doplní, že je nutné ještě nechat najít "selected | parent selected", aby se vybrali i relace.
  32. Lukas Kabrt lukas na kabrt.cz #m7b0a36
    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)
  33. Martin Kupec magon na jkopava.cz #m088649
    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
  34. Jan Bilak jan.bilak.osm na gmail.com #m5c2980
    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
  35. Lukas Kabrt lukas na kabrt.cz #md7d58b
    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
  36. Petr Dlouhý petr.dlouhy na email.cz #mca45b4
    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>
  37. Petr Dlouhý petr.dlouhy na email.cz #m69b4c2
    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?
  38. Petr Dlouhý petr.dlouhy na email.cz #m266004
    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>
  39. Jan Bilak jan.bilak.osm na gmail.com #medb45a
    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
  40. Petr Dlouhý petr.dlouhy na email.cz #m5c45de
    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>
  41. Jan Bilak jan.bilak.osm na gmail.com #m84f79a
    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>:
  42. Jan Bilak jan.bilak.osm na gmail.com #m52ee3c
    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>:
  43. Petr Dlouhý petr.dlouhy na email.cz #m9eefba
    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>
  44. Petr Dlouhý petr.dlouhy na email.cz #m7318f3
    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>
    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>
    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
    -- Petr Dlouhý
  45. Jan Bilak jan.bilak.osm na gmail.com #m7d37f8
    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>:
  46. Jan Bilak jan.bilak.osm na gmail.com #m7abbda
    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>:
  47. Jan Bilak jan.bilak.osm na gmail.com #m4e5b1f
    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>:
  48. Petr Dlouhý petr.dlouhy na email.cz #m3c3eda
    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>
  49. Petr Dlouhý petr.dlouhy na email.cz #m4e12e3
    On Sun, 24 Jan 2010 03:54:13 +0100, Jan Bilak <jan.bilak.osm na gmail.com>
    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, ...).
    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.
    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á).
    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
  50. Petr Dlouhý petr.dlouhy na email.cz #m58cf44
    Pardon, myslel jsem dní. On Sun, 24 Jan 2010 08:46:16 +0100, Petr Dlouhý <petr.dlouhy na email.cz>
  51. Lukas Kabrt lukas na kabrt.cz #mf93b59
    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/
  52. Lukas Kabrt lukas na kabrt.cz #m959108
    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
  53. Lukas Kabrt lukas na kabrt.cz #mdd8765
    Pardon, myslel jsem dní. On Sun, 24 Jan 2010 08:46:16 +0100, Petr Dlouhý <petr.dlouhy na email.cz>
    (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.
  54. Petr Dlouhý petr.dlouhy na email.cz #m3775a5
    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.
  55. Kubajz kubajz na kbx.cz #m81eea3
    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
  56. Aleš Janda openstreetmap na kyblsoft.cz #m3800bf
    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
  57. Petr Dlouhý petr.dlouhy na email.cz #mca4e1d
    Na OCR by paměť není moc potřeba. Klidně to tam rozběhnu.
  58. Petr Dlouhý petr.dlouhy na email.cz #me8a89e
    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.
  59. Jan Bilak jan.bilak.osm na gmail.com #m10e978
    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>:
  60. Jan Bilak jan.bilak.osm na gmail.com #m8f9c3f
    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
  61. Jan Bilak jan.bilak.osm na gmail.com #m7288e8
    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>:
  62. Petr Dlouhý petr.dlouhy na email.cz #mcb5135
    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.
    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
    -- Petr Dlouhý
  63. Petr Dlouhý petr.dlouhy na email.cz #mb450ca
    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.
    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
    -- Petr Dlouhý
  64. hanoj ehanoj na gmail.com #mb79bef
    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
  65. hanoj ehanoj na gmail.com #me08ea5
    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
  66. Karel Volný kavol na seznam.cz #m4e3d8d
    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.
  67. Petr Dlouhý petr.dlouhy na email.cz #m63a22e
    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í.
    ----------------------------------------
    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.
    Petr Dlouhý petr.dlouhy na email.cz
  68. Karel Volný kavol na seznam.cz #m512bef
    ...
    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.
  69. Pavel Machek pavel na ucw.cz #m1ac0a7
    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
  70. Petr Dlouhý petr.dlouhy na email.cz #m5810ec
    Čti dál: http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004354.html
    ----------------------------------------
    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
    Petr Dlouhý petr.dlouhy na email.cz
  71. Lukas Kabrt lukas na kabrt.cz #m632496
    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
  72. Jan Bilak jan.bilak.osm na gmail.com #mb9b1ea
    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>:
  73. Petr Dlouhý petr.dlouhy na email.cz #m236677
    Díky za synchronizaci postupu. 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.
    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.
  74. Lukas Kabrt lukas na kabrt.cz #m6c27d4
    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.
  75. Lukas Kabrt lukas na kabrt.cz #m418666
    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
  76. Jan Bilak jan.bilak.osm na gmail.com #ma780c8
    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>:
  77. Jiri Parkan jparkan na gmail.com #me41758
    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ě :)
  78. Lukas Kabrt lukas na kabrt.cz #m273edf
    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"
  79. Petr Dlouhý petr.dlouhy na email.cz #m6e9ce0
    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".
  80. Jiri Parkan jparkan na gmail.com #m603170
    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>:
  81. Jakub Sýkora kubajz na kbx.cz #m4d905f
    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
  82. Petr Dlouhý petr.dlouhy na email.cz #mcb1caf
    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?
    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
    -- Petr Dlouhý
  83. Lukas Kabrt lukas na kabrt.cz #mc2a13d
    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.
  84. Petr Dlouhý petr.dlouhy na email.cz #m48674d
    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.
  85. Petr Dlouhý petr.dlouhy na email.cz #m42e4ce
    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?
  86. Jan Bilak jan.bilak.osm na gmail.com #md70e89
    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>:
  87. Lukas Kabrt lukas na kabrt.cz #m032353
    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
  88. Petr Dlouhý petr.dlouhy na email.cz #m77e8f5
    Ahoj, díky - vypadá to, že to funguje (tedy musel jsem updatovat tesseract z verze 2.03 na 2.04).
    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
    -- Petr Dlouhý
  89. Martin Kupec magon na jkopava.cz #ma6cf09
    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
  90. Lukas Kabrt lukas na kabrt.cz #ma1bc9a
    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.
  91. Martin Kupec magon na jkopava.cz #m4d7bf7
    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
  92. Petr Dlouhý petr.dlouhy na email.cz #meb595b
    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.
    ----------------------------------------
    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.
    Petr Dlouhý petr.dlouhy na email.cz
  93. Lukas Kabrt lukas na kabrt.cz #md47e14
    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 ...
  94. Martin Kupec magon na jkopava.cz #mc65ffd
    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
  95. Kubajz kubajz na kbx.cz #mf0f32f
    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
  96. Petr Dlouhý petr.dlouhy na email.cz #m1ab243
    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.
  97. Martin Kupec magon na jkopava.cz #m0ef660
    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
  98. Petr Dlouhý petr.dlouhy na email.cz #md55a39
    Ahoj, tak na Kubajzově stroji je (po kratší odstávce) už taky vše spočítané a uploadované.
  99. Petr Dlouhý petr.dlouhy na email.cz #me220e3
    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>
  100. Jan Bilak jan.bilak.osm na gmail.com #mc8d548
    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>:
  101. Petr Dlouhý petr.dlouhy na email.cz #m385898
    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>
    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>
    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>
    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
    -- Petr Dlouhý
  102. Jan Bilak jan.bilak.osm na gmail.com #me92211
    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>:
  103. Stanislav Brabec utx na penguin.cz #m5f317b
    Petr Dlouhý píše v Čt 11. 02. 2010 v 18:13 +0100:
    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?
  104. Petr Dlouhý petr.dlouhy na email.cz #m855a2b
    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>
  105. Stanislav Brabec utx na penguin.cz #m63b67e
    Petr Dlouhý píše v Čt 11. 02. 2010 v 20:15 +0100:
    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.
  106. Petr Dlouhý petr.dlouhy na email.cz #m40346e
    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>
  107. Jan Bilak jan.bilak.osm na gmail.com #m76f7c4
    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>:
  108. Petr Dlouhý petr.dlouhy na email.cz #ma881d3
    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>
    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>
    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ý
  109. Jan Bilak jan.bilak.osm na gmail.com #m0fdd20
    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>:
  110. Petr Dlouhý petr.dlouhy na email.cz #ma55c7c
    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>
    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>
    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>
    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ý
    -- Petr Dlouhý
  111. Jan Bilak jan.bilak.osm na gmail.com #m67c57f
    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>:
  112. Jan Bilak jan.bilak.osm na gmail.com #m2758db
    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>:
  113. Jan Bilak jan.bilak.osm na gmail.com #mc78b6f
    Doplnil jsem tam chybějící číslici 4. Honza 2010/2/12 Jan Bilak <jan.bilak.osm na gmail.com>:
  114. Jan Bilak jan.bilak.osm na gmail.com #me13b86
    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>:
  115. Petr Dlouhý petr.dlouhy na email.cz #m4ad3c0
    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>
    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>
    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>
    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>
    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ý
    -- Petr Dlouhý
    -- Petr Dlouhý
  116. Jan Bilak jan.bilak.osm na gmail.com #m75df4c
    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>:
  117. Jan Bilak jan.bilak.osm na gmail.com #me3970d
    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>:
  118. Petr Dlouhý petr.dlouhy na email.cz #m3a49ba
    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.
    ---------------------------------------- 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>
    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>
    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>
    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>
    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ý
    -- Petr Dlouhý
    -- Petr Dlouhý
    Petr Dlouhý petr.dlouhy na email.cz
  119. Jan Bilak jan.bilak.osm na gmail.com #m68c851
    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>:
  120. Jan Bilak jan.bilak.osm na gmail.com #madaec8
    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>:
  121. Jan Bilak jan.bilak.osm na gmail.com #m541fb7
    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>:
  122. Petr Dlouhý petr.dlouhy na email.cz #m6fa108
    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>
  123. Petr Dlouhý petr.dlouhy na email.cz #mdfdde7
    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>
  124. Jan Bilak jan.bilak.osm na gmail.com #mec2868
    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>:
  125. Jan Bilak jan.bilak.osm na gmail.com #mdc9ec3
    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>:
  126. Petr Dlouhý petr.dlouhy na email.cz #mde4e8b
    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>
  127. Petr Dlouhý petr.dlouhy na email.cz #m598b38
    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>
  128. Jan Bilak jan.bilak.osm na gmail.com #m72d7a8
    Ahoj, díky, kouknu se na to, kde je problém. Honza 2010/2/13 Petr Dlouhý <petr.dlouhy na email.cz>:
  129. Petr Dlouhý petr.dlouhy na email.cz #ma26953
    Omlouvám se. To není chyba - Merge nevygeneruje pro "bez č.p./č.e." žádný bod, takže je všechno v pořádku.
  130. Jan Bilak jan.bilak.osm na gmail.com #m2a3afc
    OK, nic se nestalo. Hlavně, že se to vyjasnilo. Honza 2010/2/13 Petr Dlouhý <petr.dlouhy na email.cz>:
  131. Petr Dlouhý petr.dlouhy na email.cz #m77bdb6
    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>
  132. Jan Bilak jan.bilak.osm na gmail.com #mb4fe8f
    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>:
  133. Jan Bilak jan.bilak.osm na gmail.com #m54cd5e
    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>:
  134. Petr Dlouhý petr.dlouhy na email.cz #m068d6e
    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>
  135. Jan Bilak jan.bilak.osm na gmail.com #m028e50
    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>:
  136. Petr Dlouhý petr.dlouhy na email.cz #m96f799
    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>
  137. Jan Bilak jan.bilak.osm na gmail.com #mae547e
    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>:
  138. Jan Bilak jan.bilak.osm na gmail.com #m4f765c
    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>:
  139. Jan Bilak jan.bilak.osm na gmail.com #m0fd70b
    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>:
  140. Jan Bilak jan.bilak.osm na gmail.com #me5b9fd
    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>:
  141. Petr Dlouhý petr.dlouhy na email.cz #m7c8691
    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>
  142. Jan Bilak jan.bilak.osm na gmail.com #m064c43
    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>:
  143. Petr Dlouhý petr.dlouhy na email.cz #m8e1539
    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>
  144. Jan Bilak jan.bilak.osm na gmail.com #ma04720
    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>:
  145. Jan Bilak jan.bilak.osm na gmail.com #m251f81
    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>:
  146. Lukas Kabrt lukas na kabrt.cz #m59013f
    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.
  147. Petr Dlouhý petr.dlouhy na email.cz #mde7884
    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í.
    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.
    -- Petr Dlouhý
  148. Jan Bilak jan.bilak.osm na gmail.com #m78e36e
    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>:
  149. Lukas Kabrt lukas na kabrt.cz #m600438
    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.
  150. Petr Dlouhý petr.dlouhy na email.cz #mc63162
    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í.
    ---------------------------------------- BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program pracuje.
    Petr Dlouhý petr.dlouhy na email.cz
  151. Jan Bilak jan.bilak.osm na gmail.com #m46730d
    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>:
  152. Jan Bilak jan.bilak.osm na gmail.com #mf383fc
    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>:
  153. Jan Bilak jan.bilak.osm na gmail.com #mf73d22
    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>:
  154. Lukas Kabrt lukas na kabrt.cz #m63040e
    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
  155. Jan Dudík jan.dudik na gmail.com #m506677
    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>:
    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
    -- -- Ing. Jan Dudík
  156. Petr Kadlec petr.kadlec na gmail.com #md317bf
    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
  157. Jan Dudík jan.dudik na gmail.com #mc76025
    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
  158. Lukas Kabrt lukas na kabrt.cz #m38e3a8
    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
  159. Jan Dudík jan.dudik na gmail.com #m76113c
    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>:
    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
    -- -- Ing. Jan Dudík
  160. Lukas Kabrt lukas na kabrt.cz #m50c5b9
    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.
    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)
    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.
Napsat odpověď e-mailem… Odpovědět

Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.