[Talk-cz] Import adres z katastralni mapy
Vlákno 16.1. - 23.2.2010, počet zpráv: 160
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
Ahoj,
jenom strucne:
1) vyborne!!!
zobrazit citaci
> [output-filename-prefix]-unmatched.osm - obsahuje body, kterym se nepodarilo
> jednoznacne priradit adresu
2) ano, uploadovat s nejakym tagem o nesparovani. Databaze MVCR neni
vubec autoritativni a uz vubec ne bez chyb. Nenalezenych 5% si myslim
odhadem odpovida me zkusenosti...
zobrazit citaci
> zakreslene katastralni uzemi v OSM souboru (pouzil jsem vyrez z
> vektorizovne mapy od hanoje [4], kam jsem rucne doplnil relace a nazvy katastralnich uzemi)
3) Martin Kupec ted pracuje na dalsi fazi digitalizace, ktera je temer
hotova. Nasledovat bude faze, ktera je zatim jen v me abstraktni
myslence jak z:
* bodu - nesouci atributovou informaci o katastralnim uzemi (k.u.) a
lezici uvnitr k.u., priblizne uprostred
* a linii - nesouci prostorovou informaci o rozhrani k.u.
*nadelat relace*. (nemaly problemem je, ze linie nejsou vzdy spojite a
obcas jsou prerusene coz vzniklo umistenim loga CUZK, pripadne
nenavaznosti mezi jednotlivymi dlazdicemi)
4) dal bys obsah toto webu na wiki stranku + odkaz na wikistranku
"Czech Republic/freemap"
diky a zdravi
hanoj
On Sat, Jan 16, 2010 at 07:31:40PM +0100, hanoj wrote:
zobrazit citaci
> 3) Martin Kupec ted pracuje na dalsi fazi digitalizace, ktera je temer
> hotova. Nasledovat bude faze, ktera je zatim jen v me abstraktni
> myslence jak z:
> * bodu - nesouci atributovou informaci o katastralnim uzemi (k.u.) a
> lezici uvnitr k.u., priblizne uprostred
> * a linii - nesouci prostorovou informaci o rozhrani k.u.
>
> *nadelat relace*. (nemaly problemem je, ze linie nejsou vzdy spojite a
> obcas jsou prerusene coz vzniklo umistenim loga CUZK, pripadne
> nenavaznosti mezi jednotlivymi dlazdicemi)
Asi by stalo za to udelat presnejsi update stavu k.u.
Katastralnich uzemi CR je 13027 a ja mam tabulku 12171 paru
pozice <-> jmeno/cislo. Tohle je vysledek scriptu a jeste jej
hodlam vylepsi, popripade dodelat zbylych cca 850 bodu rucne.
Dalsi faze bude sehnat si od hanoje vektorizovane obrysy
katastralnich uzemi(nejak bojuju s GRASSem, takze si to nejak
nejsem schopen udelat sam) a pospojovat je na polygony a pridat
jim podle polohy nazvy.
Ta posledni faze jeste nezacala, ale blizka se na lepsi casy.
Martin Kupec
zobrazit citaci
> ? ? ? ?Dalsi faze bude sehnat si od hanoje vektorizovane obrysy
> ? ? ? ?katastralnich uzemi(nejak bojuju s GRASSem, takze si to nejak
> ? ? ? ?nejsem schopen udelat sam) a pospojovat je na polygony a pridat
> ? ? ? ?jim podle polohy nazvy.
*** aby nedoslo k mylce, konkretne na toto GRASS uz nepotrebujes.
Muzes pracovat treba v pythonu s SHP formatem nebo s OSM. A zrejme
nepujde o polygony ale o way v relaci...
[1] http://osm.templ.net/kucr.png
[2] http://osm.templ.net/kucr.osm.bz2
[3] http://osm.templ.net/kucr.shp_jtsk.tar.bz2
[4] http://osm.templ.net/kucr.shp_wgs84.tar.bz2
zdravi te
hanoj
Dobr? den,
2010/1/16 Lukas Kabrt <lukas at kabrt.cz>:
zobrazit citaci
> Zdravim,
>
> kdysi v lete jsem tady psal [1], jak zkousim importovat adresy a obrysy budov z
> katastralni mapy CUZK. Protoze jsem nemel prilis casu, tak jsem
> program pro import
> nedotahnul do konce. Ted jsem se k tomu vratil a do celkem pouzitelne
> podoby odelal aspon
> import adresnich bodu.
>
> Rozpoznavani obrysu budov se mi nepodarilo udelat natolik spolehlive,
> aby slo nejak
> rozumne pouzivat, takze to prozatim odkladam.
>
> Import jsem vyzkousel na uzemi ORP Broumov [2], jedna se asi o cca 40
> obci / mestskych
> casti na 31 katastralnich uzemich - cca 270km2.
>
> Vysledky jsou nasledujici:
> Broumovsko ? ? ?- 3500 adresnich bodu (nalezena jednoznacna shoda mezi KM
> a databazi MVCR)
> ? ? ? ? ? ? ? ?- 170 bodu z KM, ke kterym se nepodarilo nalezt zaznam v databazi adres
> ? ? ? ? ? ? ? ?- 300 adres, ke kterym se nepodarilo najit bod v KM
>
> Broumov - 800
> ? ? ? ? ? ? ? ?- 24
> ? ? ? ? ? ? ? ?- 200
>
> Mesto Broumov uvadim zvlast, protoze na jednom katastralnim uzemi jsou
> 4 mestske casti
> takze je potreba najit hranice mestkych casti rucne (napr. podle
> ulic). Navic se mi zda,
> ze je "neco shnileho" v databazi adres pro Broumov. Nevim, kde by
> mohlo byt 200 budov pro
> tech 200 adresnich bodu bez polohy. To se pri rucni kontrole snad
> prehlednout neda.
>
> Castou chybou je, ze v KM je uvedeno cislo evidencni a databazi adres
> cislo popisne. Na
> Broumovsku je to cca 50 pripadu. Pokud se podari zjistt, jaky zdroj je
> pravdivy, tak neni
> problem tyto chyby napravit.
>
> Ja jsem uploudoval pouze ty adresni body, pro ktere byla nalezena
> jendoznacna shoda.
> Jestli uplodovat i ty body, ke ktery se nepodarilo najit adresu v
> databazi MVCR (treba s
> tagem FIXME) zalezi na dohode. Jaky je na to vas nazor? Stalo by za to
> uchovavat nekde i
> seznam adres, ke kterym se nepodarilo najit bod v KM?
Existuje mo?nost pou??t datab?zi ?esk? po?ty nam?sto datab?ze MV?R.
Dle jejich vyj?d?en? je toti? mo?n? pou??vat data z adresy
'psc.cpost.cz' neomezen? bez jak?chkoli licen?n?ch podm?nek (na rozd?l
od placen? datab?ze, kterou je zato mo?n? pou??vat off-line).
Kvalitu datab?ze ?esk? po?ty nedok??i zcela posoudit. Jen v?m, ?e v
n?kter?ch m?stech je p?esn?j?? ne? MV?R.
Se strojov?m dotazov?n?m na web ?esk? po?ty jsem d??ve experimentoval
s dobr?mi v?sledky. Pokud bude z?jem, po?lu skripty (je to hrozn?
bastl BASH+XSTL+RUBY+JAVA, ale funguje).
S pozdravem,
Radom?r ?ernoch
Tak jsem na wiki [1] vytvoril stranku s informacemi o importu. Zaroven
jsem jsem updatoval program [2], tak aby generoval tagy FIXME pro ty
adresni body, kde prirazeni mezi databazi a mapou neni jednoznacne.
zobrazit citaci
>Martin Kupec
>Dalsi faze bude sehnat si od hanoje vektorizovane obrysy
>katastralnich uzemi(nejak bojuju s GRASSem, takze si to nejak
>nejsem schopen udelat sam) a pospojovat je na polygony a pridat
>jim podle polohy nazvy.
S mapou od hanoje jsem si dneska hral a vysledek vypada celkem
nadejne, takze mapu s polygony snad budu schopny dodat. Chci to jen
jeste trochu doladit ...
[1] http://wiki.openstreetmap.org/wiki/Import_Adres_?R
[2] http://lkabrt.aspone.cz/osm/cuzk.zip
On Mon, Jan 18, 2010 at 01:13:35AM +0100, Lukas Kabrt wrote:
zobrazit citaci
> S mapou od hanoje jsem si dneska hral a vysledek vypada celkem
> nadejne, takze mapu s polygony snad budu schopny dodat. Chci to jen
> jeste trochu doladit ...
Takze ti staci dodat ty bodiky?
Ja se na ty mapy jeste nestihl podivat bohuzel.
Martin Kupec
Ahoj,
zkou?el jsem tv?j skript, a narazil jsem na probl?m s tile-downloaderem.
Pou?t?m program na Linuxu pod Monem (2.4.2.3), a m?sto st?hnut?ch obr?zk?
je v t?ch souborech n?sleduj?c? text(def_body i kn, zkou?el jsem i p??klad
z tv?ho n?vodu):
<?xml version='1.0' encoding="ISO-8859-1" standalone="no" ?>
<!DOCTYPE ServiceExceptionReport SYSTEM
"http://schemas.opengeospatial.net/wms/1.1.1/exception_1_1_1.dtd">
<ServiceExceptionReport version="1.1.1">
<ServiceException>
msWMSLoadGetMapParams(): WMS server error. Wrong number of arguments for
BBOX.
</ServiceException>
</ServiceExceptionReport>
Chci se tedy zeptat, jestli nev?? zdali je probl?m zp?soben? Monem, jestli
je to n?jak? moment?ln? probl?m t?ch server?, nebo ??m to tedy je.
On Mon, 18 Jan 2010 01:13:35 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
> Tak jsem na wiki [1] vytvoril stranku s informacemi o importu. Zaroven
> jsem jsem updatoval program [2], tak aby generoval tagy FIXME pro ty
> adresni body, kde prirazeni mezi databazi a mapou neni jednoznacne.
>
>> Martin Kupec
>> Dalsi faze bude sehnat si od hanoje vektorizovane obrysy
>> katastralnich uzemi(nejak bojuju s GRASSem, takze si to nejak
>> nejsem schopen udelat sam) a pospojovat je na polygony a pridat
>> jim podle polohy nazvy.
>
> S mapou od hanoje jsem si dneska hral a vysledek vypada celkem
> nadejne, takze mapu s polygony snad budu schopny dodat. Chci to jen
> jeste trochu doladit ...
>
> [1] http://wiki.openstreetmap.org/wiki/Import_Adres_?R
> [2] http://lkabrt.aspone.cz/osm/cuzk.zip
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouh?
Tot?? u m? pod windows, cht?l jsem to z?tra zkoumat, ale vid?m ?e to
nebude jen m?j probl?m.
2010/1/19 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Ahoj,
>
> zkou?el jsem tv?j skript, a narazil jsem na probl?m s tile-downloaderem.
> Pou?t?m program na Linuxu pod Monem (2.4.2.3), a m?sto st?hnut?ch obr?zk?
> je v t?ch souborech n?sleduj?c? text(def_body i kn, zkou?el jsem i p??klad
> z tv?ho n?vodu):
>
> <?xml version='1.0' encoding="ISO-8859-1" standalone="no" ?>
> <!DOCTYPE ServiceExceptionReport SYSTEM
> "http://schemas.opengeospatial.net/wms/1.1.1/exception_1_1_1.dtd">
> <ServiceExceptionReport version="1.1.1">
> <ServiceException>
> msWMSLoadGetMapParams(): WMS server error. Wrong number of arguments for
> BBOX.
> </ServiceException>
> </ServiceExceptionReport>
>
> Chci se tedy zeptat, jestli nev?? zdali je probl?m zp?soben? Monem, jestli
> je to n?jak? moment?ln? probl?m t?ch server?, nebo ??m to tedy je.
>
>
> On Mon, 18 Jan 2010 01:13:35 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
>
>> Tak jsem na wiki [1] vytvoril stranku s informacemi o importu. Zaroven
>> jsem jsem updatoval program [2], tak aby generoval tagy FIXME pro ty
>> adresni body, kde prirazeni mezi databazi a mapou neni jednoznacne.
>>
>>> Martin Kupec
>>> Dalsi faze bude sehnat si od hanoje vektorizovane obrysy
>>> katastralnich uzemi(nejak bojuju s GRASSem, takze si to nejak
>>> nejsem schopen udelat sam) a pospojovat je na polygony a pridat
>>> jim podle polohy nazvy.
>>
>> S mapou od hanoje jsem si dneska hral a vysledek vypada celkem
>> nadejne, takze mapu s polygony snad budu schopny dodat. Chci to jen
>> jeste trochu doladit ...
>>
>> [1] http://wiki.openstreetmap.org/wiki/Import_Adres_?R
>> [2] http://lkabrt.aspone.cz/osm/cuzk.zip
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Omlouvam se za problem. Nejak jsem si neuvedomil, ze mam na pocitaci
anglice prostredi a tudiz desetinny oddelovac ".". Program jsem
upravil a ted by mel fungovat spravne, stahovat muzete opet na [1]
[1] http://lkabrt.aspone.cz/osm/cuzk.zip
Lukas
2010/1/19 Jiri Parkan <jparkan at gmail.com>:
zobrazit citaci
> Tot?? u m? pod windows, cht?l jsem to z?tra zkoumat, ale vid?m ?e to
> nebude jen m?j probl?m.
>
> 2010/1/19 Petr Dlouh? <petr.dlouhy at email.cz>:
>> Ahoj,
>>
>> zkou?el jsem tv?j skript, a narazil jsem na probl?m s tile-downloaderem.
>> Pou?t?m program na Linuxu pod Monem (2.4.2.3), a m?sto st?hnut?ch obr?zk?
>> je v t?ch souborech n?sleduj?c? text(def_body i kn, zkou?el jsem i p??klad
>> z tv?ho n?vodu):
>>
>> <?xml version='1.0' encoding="ISO-8859-1" standalone="no" ?>
>> <!DOCTYPE ServiceExceptionReport SYSTEM
>> "http://schemas.opengeospatial.net/wms/1.1.1/exception_1_1_1.dtd">
>> <ServiceExceptionReport version="1.1.1">
>> <ServiceException>
>> msWMSLoadGetMapParams(): WMS server error. Wrong number of arguments for
>> BBOX.
>> </ServiceException>
>> </ServiceExceptionReport>
>>
>> Chci se tedy zeptat, jestli nev?? zdali je probl?m zp?soben? Monem, jestli
>> je to n?jak? moment?ln? probl?m t?ch server?, nebo ??m to tedy je.
>>
>>
>> On Mon, 18 Jan 2010 01:13:35 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
>>
>>> Tak jsem na wiki [1] vytvoril stranku s informacemi o importu. Zaroven
>>> jsem jsem updatoval program [2], tak aby generoval tagy FIXME pro ty
>>> adresni body, kde prirazeni mezi databazi a mapou neni jednoznacne.
>>>
>>>> Martin Kupec
>>>> Dalsi faze bude sehnat si od hanoje vektorizovane obrysy
>>>> katastralnich uzemi(nejak bojuju s GRASSem, takze si to nejak
>>>> nejsem schopen udelat sam) a pospojovat je na polygony a pridat
>>>> jim podle polohy nazvy.
>>>
>>> S mapou od hanoje jsem si dneska hral a vysledek vypada celkem
>>> nadejne, takze mapu s polygony snad budu schopny dodat. Chci to jen
>>> jeste trochu doladit ...
>>>
>>> [1] http://wiki.openstreetmap.org/wiki/Import_Adres_?R
>>> [2] http://lkabrt.aspone.cz/osm/cuzk.zip
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>> --
>> Petr Dlouh?
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Ahoj,
tak stahov?n? u? funguje. Te? je zase probl?m s tile-processorem. Program
vyp??e, ?e mu chyb? ntdll.dll (cel? v?pis v debug m?du je v p??loze) a
skon??. V?c informac? o chyb?j?c?ch knihovn?ch je na [1], ale nev?m, kde
bych vzal ntdll.dll, resp. kdybych vzal tu windowsovou, tak by velmi
pravd?podobn? nefungovala - jedin? mo?nost, kterou vid?m je to zkusit
spustit cel? pod Wine.
M? n?kdo n?jak? n?pady, jak by se to dalo obej?t?
[1] http://www.mono-project.com/DllNotFoundException
On Tue, 19 Jan 2010 21:51:46 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
> Omlouvam se za problem. Nejak jsem si neuvedomil, ze mam na pocitaci
> anglice prostredi a tudiz desetinny oddelovac ".". Program jsem
> upravil a ted by mel fungovat spravne, stahovat muzete opet na [1]
> [1] http://lkabrt.aspone.cz/osm/cuzk.zip
--
Petr Dlouh?
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: debug.txt
URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100120/3c7a4d83/attachment.txt>
Dneska jsem to zkou?el pod wine. Bohu?el nevy?e?il, p??e to
$ wine tile-processor.exe -tiles data/oblast/ -output data/oblast.csv
File '/home/ales/.local/share/applications/wine-extension-skp.desktop' contains
invalid MIME type 'SKP' that is missing a slash
Processing tile: 16,1050_50,4842_16,1100_50,4892-budovy err:ole:CoInitializeEx
Attempt to change threading model of this apartment from multi-threaded to
apartment threaded
err:ole:marshal_object couldn't get IPSFactory buffer for interface
{9edde9e7-8dee-47ea-99df-e6faf2ed44bf}
err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hres=0x80040155
err:ole:CoMarshalInterface Failed to marshal the interface
{9edde9e7-8dee-47ea-99df-e6faf2ed44bf}, 80040155
fixme:ole:CoCreateInstance no instance created for interface
{9edde9e7-8dee-47ea-99df-e6faf2ed44bf} of class
{389ea17b-5078-4cde-b6ef-25c15175c751}, hres is 0x80040155
Unhandled Exception: System.Exception: Generic Error [GDI+ status: GenericError]
at System.Drawing.GDIPlus.CheckStatus (Status status) [0x00000]
at System.Drawing.Image.FromFile (System.String filename, Boolean
useEmbeddedColorManagement) [0x00000]
at System.Drawing.Image.FromFile (System.String filename) [0x00000]
at CUZK.ExtractAddresses.TileAnalyzer.Analyze (System.String filename) [0x00000]
at CUZK.ExtractAddresses.Program.Main (System.String[] args) [0x00000]
Asi to chce ten .NET Framework 3.5, ale ten je ve Wine ozna?en jako garbage, tak
jsem to zat?m d?l nezkou?el?
Ale? Janda
On 20.1.2010 13:12, Petr Dlouh? napsal/a:
zobrazit citaci
> Ahoj,
>
> tak stahov?n? u? funguje. Te? je zase probl?m s tile-processorem.
> Program vyp??e, ?e mu chyb? ntdll.dll (cel? v?pis v debug m?du je v
> p??loze) a skon??. V?c informac? o chyb?j?c?ch knihovn?ch je na [1], ale
> nev?m, kde bych vzal ntdll.dll, resp. kdybych vzal tu windowsovou, tak
> by velmi pravd?podobn? nefungovala - jedin? mo?nost, kterou vid?m je to
> zkusit spustit cel? pod Wine.
> M? n?kdo n?jak? n?pady, jak by se to dalo obej?t?
>
> [1] http://www.mono-project.com/DllNotFoundException
>
zobrazit citaci
> tak stahov?n? u? funguje. Te? je zase probl?m s tile-processorem. Program
> vyp??e, ?e mu chyb? ntdll.dll (cel? v?pis v debug m?du je v p??loze) a
> skon??. V?c informac? o chyb?j?c?ch knihovn?ch je na [1], ale nev?m, kde
> bych vzal ntdll.dll, resp. kdybych vzal tu windowsovou, tak by velmi
> pravd?podobn? nefungovala - jedin? mo?nost, kterou vid?m je to zkusit
> spustit cel? pod Wine.
> M? n?kdo n?jak? n?pady, jak by se to dalo obej?t?
s Linuxem nemam moc zkusenosti a ani s MONO jsem prilis nepracoval,
ale budu se snazit pomoct.
Pokud jsem ten error spravne rozklicoval, tak se mu nelibi poziti
knihovny AForge. Program jsem upravil tak, aby tuhle knihovnu
nepouzival. Upravena verze je ke stazeni na [1].
zobrazit citaci
> Dneska jsem to zkou?el pod wine. Bohu?el nevy?e?il, p??e to
> $ wine tile-processor.exe -tiles data/oblast/ -output data/oblast.csv
...
zobrazit citaci
> Asi to chce ten .NET Framework 3.5, ale ten je ve Wine ozna?en jako garbage, tak
> jsem to zat?m d?l nezkou?el...
tile-processorby kdyztak slo upravit tak aby behal na .NET Framework
3.0, mozna i 2.0. Pro beh merge-cuzk-db.exe ale je .NET Framework 3.5
urcite potreba. Pro zpracovani XML souboru tam pozivam Xml.Linq a ten
je az od .NET Framework 3.5.
Zbezne jsem koukal na MONO a Xml.Linq tam je, takze pod MONO by to
snad behat mohlo.
[1] http://lkabrt.aspone.cz/osm/tile-processor.zip
--
Lukas
Ahoj,
d?ky za opravu, nyn? to vypad?, ?e se dostal o kousek d?l. Program vyp??e
n?sleduj?c? hl??en?:
mono tile-processor.exe -tiles output -output output.csv
Processing tile: 14,6603_49,8538_14,6653_49,8588-budovy ..
Performing OCR: 1/119xdg-open: unexpected argument
'/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp'
Try 'xdg-open --help' for more information.
Unhandled Exception: System.IO.FileNotFoundException: Could not find file
"/home/petr/soubory/nezarazeno/rsdosm/adresy/label.txt".
File name: '/home/petr/soubory/nezarazeno/rsdosm/adresy/label.txt'
at System.IO.FileStream..ctor (System.String path, FileMode mode,
FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous,
FileOptions options) [0x00000]
at System.IO.FileStream..ctor (System.String path, FileMode mode,
FileAccess access, FileShare share) [0x00000]
at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor
(string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
at System.IO.File.OpenRead (System.String path) [0x00000]
at System.IO.StreamReader..ctor (System.String path,
System.Text.Encoding encoding, Boolean detectEncodingFromByteOrderMarks,
Int32 bufferSize) [0x00000]
at System.IO.StreamReader..ctor (System.String path) [0x00000]
at (wrapper remoting-invoke-with-check) System.IO.StreamReader:.ctor
(string)
at CUZK.ExtractAddresses.TileAnalyzer.ExtractLabel (Point pt,
System.Drawing.Bitmap map) [0x00000]
at CUZK.ExtractAddresses.TileAnalyzer.Analyze (System.String filename)
[0x00000]
at CUZK.ExtractAddresses.Program.Main (System.String[] args) [0x00000]
Co? ani nevypad?, ?e by byl probl?m s Monem. Co m? b?t v souboru
label.txt? Kdy? ten soubor vytvo??m a vlo??m tam n?jak? znaky, tak to
za?ne vypisovat:
mono tile-processor.exe -tiles output -output output.csv
Processing tile: 14,6603_49,8538_14,6653_49,8588-budovy ..
Performing OCR: 1/119xdg-open: unexpected argument
'/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp'
Try 'xdg-open --help' for more information.
2/119xdg-open: unexpected argument
'/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp'
Try 'xdg-open --help' for more information.
3/119xdg-open: unexpected argument
'/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp'
Try 'xdg-open --help' for more information.
4/119xdg-open: unexpected argument
'/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp'
Try 'xdg-open --help' for more information.
5/119xdg-open: unexpected argument
'/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp'
Try 'xdg-open --help' for more information.
6/119xdg-open: unexpected argument
'/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp'
Try 'xdg-open --help' for more information.
7/119xdg-open: unexpected argument
'/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp'
Try 'xdg-open --help' for more information.
8/119xdg-open: unexpected argument
'/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp'
Try 'xdg-open --help' for more information.
9/119xdg-open: unexpected argument
'/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp'
Try 'xdg-open --help' for more information.
10/119xdg-open: unexpected argument
'/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp'
Try 'xdg-open --help' for more information.
11/119xdg-open: unexpected argument
'/home/petr/soubory/nezarazeno/rsdosm/adresy/tmp.bmp'
Try 'xdg-open --help' for more information.
...a tak po??d d?l.
On Wed, 20 Jan 2010 14:18:10 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
> s Linuxem nemam moc zkusenosti a ani s MONO jsem prilis nepracoval,
> ale budu se snazit pomoct.
> Pokud jsem ten error spravne rozklicoval, tak se mu nelibi poziti
> knihovny AForge. Program jsem upravil tak, aby tuhle knihovnu
> nepouzival. Upravena verze je ke stazeni na [1].
--
Petr Dlouh?
Ahoj,
zjistil jsem, ?e probl?m je zp?soben knihovnou gdiplus. Kdy? to pust?? s
nativn?m (windowsov?m gdiplus), tak to vypisuje spousty error?, ale zd?
se, ?e to funguje.
Postup je tedy nakop?rovat do slo?ky k tile-processoru knihovnu
gdiplus.dll a spustit:
WINEDLLOVERRIDES="gdiplus=n" wine tile-processor.exe -tiles output -output
output.csv
On Wed, 20 Jan 2010 13:26:03 +0100, Ale? Janda <openstreetmap at kyblsoft.cz>
wrote:
zobrazit citaci
> Dneska jsem to zkou?el pod wine. Bohu?el nevy?e?il, p??e to
>
> $ wine tile-processor.exe -tiles data/oblast/ -output data/oblast.csv
> File '/home/ales/.local/share/applications/wine-extension-skp.desktop'
> contains
> invalid MIME type 'SKP' that is missing a slash
> Processing tile:
> 16,1050_50,4842_16,1100_50,4892-budovy err:ole:CoInitializeEx
> Attempt to change threading model of this apartment from multi-threaded
> to
> apartment threaded
> err:ole:marshal_object couldn't get IPSFactory buffer for interface
> {9edde9e7-8dee-47ea-99df-e6faf2ed44bf}
> err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub,
> hres=0x80040155
> err:ole:CoMarshalInterface Failed to marshal the interface
> {9edde9e7-8dee-47ea-99df-e6faf2ed44bf}, 80040155
> fixme:ole:CoCreateInstance no instance created for interface
> {9edde9e7-8dee-47ea-99df-e6faf2ed44bf} of class
> {389ea17b-5078-4cde-b6ef-25c15175c751}, hres is 0x80040155
>
> Unhandled Exception: System.Exception: Generic Error [GDI+ status:
> GenericError]
> at System.Drawing.GDIPlus.CheckStatus (Status status) [0x00000]
> at System.Drawing.Image.FromFile (System.String filename, Boolean
> useEmbeddedColorManagement) [0x00000]
> at System.Drawing.Image.FromFile (System.String filename) [0x00000]
> at CUZK.ExtractAddresses.TileAnalyzer.Analyze (System.String
> filename) [0x00000]
> at CUZK.ExtractAddresses.Program.Main (System.String[] args) [0x00000]
>
>
> Asi to chce ten .NET Framework 3.5, ale ten je ve Wine ozna?en jako
> garbage, tak
> jsem to zat?m d?l nezkou?el?
>
> Ale? Janda
>
>
> On 20.1.2010 13:12, Petr Dlouh? napsal/a:
>> Ahoj,
>>
>> tak stahov?n? u? funguje. Te? je zase probl?m s tile-processorem.
>> Program vyp??e, ?e mu chyb? ntdll.dll (cel? v?pis v debug m?du je v
>> p??loze) a skon??. V?c informac? o chyb?j?c?ch knihovn?ch je na [1], ale
>> nev?m, kde bych vzal ntdll.dll, resp. kdybych vzal tu windowsovou, tak
>> by velmi pravd?podobn? nefungovala - jedin? mo?nost, kterou vid?m je to
>> zkusit spustit cel? pod Wine.
>> M? n?kdo n?jak? n?pady, jak by se to dalo obej?t?
>>
>> [1] http://www.mono-project.com/DllNotFoundException
>>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouh?
Ahoj,
cht?l bych se zeptat, jak tv?j program ?e?? o?ez ??sel na okraj?ch
sta?en?ch dla?dic. Pt?m se pro jistotu, aby nevznikly zbyte?n? chyby.
On Mon, 18 Jan 2010 01:13:35 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
> Tak jsem na wiki [1] vytvoril stranku s informacemi o importu. Zaroven
> jsem jsem updatoval program [2], tak aby generoval tagy FIXME pro ty
> adresni body, kde prirazeni mezi databazi a mapou neni jednoznacne.
>
>> Martin Kupec
>> Dalsi faze bude sehnat si od hanoje vektorizovane obrysy
>> katastralnich uzemi(nejak bojuju s GRASSem, takze si to nejak
>> nejsem schopen udelat sam) a pospojovat je na polygony a pridat
>> jim podle polohy nazvy.
>
> S mapou od hanoje jsem si dneska hral a vysledek vypada celkem
> nadejne, takze mapu s polygony snad budu schopny dodat. Chci to jen
> jeste trochu doladit ...
>
> [1] http://wiki.openstreetmap.org/wiki/Import_Adres_?R
> [2] http://lkabrt.aspone.cz/osm/cuzk.zip
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouh?
Ahoj,
p?es Wine to funguje, ale v?sledek nen? je?t? po??d ide?ln?. Spo??tan?
poloha jednotliv?ch bod? toti? ned?v? ?pln? smysl - ob?as je tam NaN,
ob?as ??sla, mimo rozmez? dan?ho BBOX, ob?as ??sla v?t?? ne? 100000.
Nem??e b?t zase probl?m s desetinou te?kou/??rkou?
V p??loze pos?l?m v?stup z programu, a zkr?cen? v?pis programu. Wine r?d
vypisuje
velk? mno?stv? chyb, tak?e n?kter?ch ?daj? ve v?pisu si nen? t?eba v??mat.
On Wed, 20 Jan 2010 15:06:44 +0100, Petr Dlouh? <petr.dlouhy at email.cz>
wrote:
zobrazit citaci
> Ahoj,
> zjistil jsem, ?e probl?m je zp?soben knihovnou gdiplus. Kdy? to pust?? s
> nativn?m (windowsov?m gdiplus), tak to vypisuje spousty error?, ale zd?
> se, ?e to funguje.
> Postup je tedy nakop?rovat do slo?ky k tile-processoru knihovnu
> gdiplus.dll a spustit:
> WINEDLLOVERRIDES="gdiplus=n" wine tile-processor.exe -tiles output
> -output
> output.csv
--
Petr Dlouh?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output.csv
Type: text/comma-separated-values
Size: 8487 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100120/62a6a212/attachment.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: debug.txt
URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100120/62a6a212/attachment.txt>
zobrazit citaci
>Co? ani nevypad?, ?e by byl probl?m s Monem. Co m? b?t v souboru
>label.txt? Kdy? ten soubor vytvo??m a vlo??m tam n?jak? znaky, tak to
>za?ne vypisovat:
Program pracuje tak, ze vezme dla?dici, najde na n? definicni body
budov (cervene tecky) a k nim prislusejici text. Text ulozi do obrazku
"tmp.bmp" a potom ho rozpozna exetnim OCR programem (tesseract.exe).
Ten ulozi rozpoznany text prave do souboru label.txt
Proc program nefunguje, kdyz soubor label.txt pred spustenim
neexistuje je mi zahadou. Podle vystupu "output.csv" co jsi posilal,
tak rozpoznavani evidentne funguje ...
zobrazit citaci
>cht?l bych se zeptat, jak tv?j program ?e?? o?ez ??sel na okraj?ch
>sta?en?ch dla?dic. Pt?m se pro jistotu, aby nevznikly zbyte?n? chyby.
dlazdice se prekryvaji o 5% na kazde strane, takze temer jiste, ze
alespon na jedne dlazdici je text cely. Tile-processor vysledky nijak
nezpracovava, pouze ulozi polohu bodu a jemu prislusejici text. V
dalsim kroku, pri prirazovani adres jednotlivym bodum se nesmyslene
rozpoznany text vyfiltruje.
zobrazit citaci
>p?es Wine to funguje, ale v?sledek nen? je?t? po??d ide?ln?. Spo??tan?
>poloha jednotliv?ch bod? toti? ned?v? ?pln? smysl - ob?as je tam NaN,
>ob?as ??sla, mimo rozmez? dan?ho BBOX, ob?as ??sla v?t?? ne? 100000.
>Nem??e b?t zase probl?m s desetinou te?kou/??rkou?
Moje chyba. Tile-downloader ukladal dlazdice se spatny jmenem (opet
carka / tecka). Oprava opet na [1]. Pokud mas nejake dlazdice stazene,
tak staci carky v nazvech souboru nahradit za tecky.
zobrazit citaci
>V p??loze pos?l?m v?stup z programu, a zkr?cen? v?pis programu. Wine r?d vypisuje
>velk? mno?stv? chyb, tak?e n?kter?ch ?daj? ve v?pisu si nen? t?eba v??mat.
Ty errory to vypisuje i na WIN, jedna se o nejaky problem v
tesseract.exe, na strankach maji k tomu vytvoreny ticket, s tim ze
program ale funguje spravne.
[1] http://lkabrt.aspone.cz/osm/cuzk.zip
--
Lukas
On Wed, Jan 20, 2010 at 09:37:07PM +0100, Lukas Kabrt wrote:
zobrazit citaci
> Program pracuje tak, ze vezme dla?dici, najde na n? definicni body
> budov (cervene tecky) a k nim prislusejici text. Text ulozi do obrazku
> "tmp.bmp" a potom ho rozpozna exetnim OCR programem (tesseract.exe).
> Ten ulozi rozpoznany text prave do souboru label.txt
Muzu se zeptat, zda pouzivate nejak upraveny/nauceny tesseract
na ceske znaky, nebo to cestinu uspesne neumi?
Kdyz jsem se snazil vytvorit seznam bodu kat. uz. tak jsem si s
tim hral a jmena jsem vzdal a vytahl je z databaze podle cisel.
Martin Kupec
zobrazit citaci
> ? ? ? ?Muzu se zeptat, zda pouzivate nejak upraveny/nauceny tesseract
> ? ? ? ?na ceske znaky, nebo to cestinu uspesne neumi?
Pro verzi 3.0 uz existuje i cestina. Verze 3.0 je v stadiu prerelease,
nejsou pro ni binarky a tak je potreba si stahnou zdrojove kody [1] a
zkompilovat.
Soubor pro cestinu je v adresari tessdata tamtez (ces.traineddata).
Nebude ale zpetne kompatibilni s tesseract 2.04.
Puvodne jsem pozival verzi 2.04 ale tam jsem narazil na nejake
problemy na starsich pocitacich s WinXP. Pro verzi 2.04 jsem mel
vytvoreny vlastni jazyk, kde byly definovany pouze znaky ktere se
vyskytuji na katastralni mape - bez?pe. 0123456789. Uspesnost
rozpoznavani byla o neco lepsi nez ted s celou abecedou, ale to se da
celkem dobre vykonpenzovat postprocesingem - stejne zamenuje porad
stejne znaky jako o/0, ./_ apod. Chtel jsem si vytvorit vlastni jazyk
i pro verzi 3.0 ale nenasel jsem k tomu zadny nastroj.
[1] http://tesseract-ocr.googlecode.com/svn/trunk/
--
Lukas
Tak se to chovalo pod ?ist?m Monem, kde to nefunguje, a to ani s p??tomn?m
label.txt. Vypad? to, ?e m? probl?m spustit extern? aplikaci - mono
pou??v? xdg-open, co? je n?jak? program na spou?t?n? soubor? v u?ivatelem
preferovan?m prohl??e?i/editoru (m?sto toho, aby extern? program prost?
spustil).
Ten program se mi poda?ilo rozjet pod programem Wine na kter?m je
nainstalovan? Mono, a to jsem je?t? musel pou??t knihovnu gdiplus.dll z
Windows (v tomto p??pad? u? nep??tomnost label.txt nehraje roli). Wine je
implementace windowsov?ch knihoven pod Linuxem. Nen? to ide?ln? ?e?en?
(lep?? by bylo aby to fungovalo pod Monem p??mo, u? jenom kv?li tomu, ?e
pod Wine je to o n?co slo?it?j?? rozjet), ale pokud by probl?m zm?n?n? v
p?edchoz?m odstavci ne?el jednodu?e vy?e?it, tak se t?m nezab?vej, proto?e
jde pouze o jedno??elovou utilitu a sv?j ??el spln? i takto.
On Wed, 20 Jan 2010 21:37:07 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
> Program pracuje tak, ze vezme dla?dici, najde na n? definicni body
> budov (cervene tecky) a k nim prislusejici text. Text ulozi do obrazku
> "tmp.bmp" a potom ho rozpozna exetnim OCR programem (tesseract.exe).
> Ten ulozi rozpoznany text prave do souboru label.txt
> Proc program nefunguje, kdyz soubor label.txt pred spustenim
> neexistuje je mi zahadou. Podle vystupu "output.csv" co jsi posilal,
> tak rozpoznavani evidentne funguje ...
--
Petr Dlouh?
Tak jsem je?t? trochu hledal, a snad jsem nalezl ?e?en?. Vypad? to, ?e probl?m je zp?soben bugem [1], a workaround je uveden? v uk?zkov?m program? z p??lohy toho bugu.
[1] https://bugzilla.novell.com/show_bug.cgi?id=385497
zobrazit citaci
> ------------ P?vodn? zpr?va ------------
> Od: Petr Dlouh? <petr.dlouhy at email.cz>
> P?edm?t: Re: [Talk-cz] Import adres z katastralni mapy
> Datum: 20.1.2010 23:32:05
> ----------------------------------------
> Tak se to chovalo pod ?ist?m Monem, kde to nefunguje, a to ani s p??tomn?m
> label.txt. Vypad? to, ?e m? probl?m spustit extern? aplikaci - mono
> pou??v? xdg-open, co? je n?jak? program na spou?t?n? soubor? v u?ivatelem
> preferovan?m prohl??e?i/editoru (m?sto toho, aby extern? program prost?
> spustil).
>
> Ten program se mi poda?ilo rozjet pod programem Wine na kter?m je
> nainstalovan? Mono, a to jsem je?t? musel pou??t knihovnu gdiplus.dll z
> Windows (v tomto p??pad? u? nep??tomnost label.txt nehraje roli). Wine je
> implementace windowsov?ch knihoven pod Linuxem. Nen? to ide?ln? ?e?en?
> (lep?? by bylo aby to fungovalo pod Monem p??mo, u? jenom kv?li tomu, ?e
> pod Wine je to o n?co slo?it?j?? rozjet), ale pokud by probl?m zm?n?n? v
> p?edchoz?m odstavci ne?el jednodu?e vy?e?it, tak se t?m nezab?vej, proto?e
> jde pouze o jedno??elovou utilitu a sv?j ??el spln? i takto.
>
>
> On Wed, 20 Jan 2010 21:37:07 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
>
> > Program pracuje tak, ze vezme dla?dici, najde na n? definicni body
> > budov (cervene tecky) a k nim prislusejici text. Text ulozi do obrazku
> > "tmp.bmp" a potom ho rozpozna exetnim OCR programem (tesseract.exe).
> > Ten ulozi rozpoznany text prave do souboru label.txt
> > Proc program nefunguje, kdyz soubor label.txt pred spustenim
> > neexistuje je mi zahadou. Podle vystupu "output.csv" co jsi posilal,
> > tak rozpoznavani evidentne funguje ...
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
Petr Dlouh?
petr.dlouhy at email.cz
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
D?ky,
te? to u? (p?es Wine) funguje. Na datech z Broumovska jsem vyzkou?el, ?e
funguje i merge-cuzk-db. Poprosil bych tedy akor?t, jestli bys nemohl
aplikovat workaround, kter? jsem pos?lal - aby ostatn? nemuseli slo?it?
rozj??d?t Mono pod Wine.
On Wed, 20 Jan 2010 21:37:07 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
> Moje chyba. Tile-downloader ukladal dlazdice se spatny jmenem (opet
> carka / tecka). Oprava opet na [1]. Pokud mas nejake dlazdice stazene,
> tak staci carky v nazvech souboru nahradit za tecky.
--
Petr Dlouh?
On Thu, Jan 21, 2010 at 04:50:15PM +0100, Lukas Kabrt wrote:
zobrazit citaci
> Tak jsem trochu zapracoval na mape katastralnich uzemi, aby se k.u.
> nemuseli kreslit rucne.
>
> Vektorizovanou mapu k.u. od hanoje [1] jsem zacistil (slouceni
> duplicitnich bodu, odtraneni fragmentu po vektorizaci, pospojovani
> prerusenych linii) a vytvoril na ni relace pro jednotliva k.u.
>
> Mapu jsem dal dohromady s daty co mi poslal Martin Kupec (nazvy
> katastralnich uzemi a jejich poloha). Vysledek je ke stazeni tady [2].
>
> Trocha statistiky:
> CR ma 13027 k.u.
> Martin mi poslal data pro 12171 k.u.
> Mapa ma definovano 13028 relaci
>
> Mapa je jenom prozatmni, pri prirazeni se vyskytly nejake chyby (vic
> nazvu pro jedno k.u., jedna se ale o jednotky, max. desitky pripadu)
> To bych resil az budou hotova data pro vsechy k.u. Stejne tak je v
> mape 1 relace navic - pravdepodobne nekde zustal nejaky fragment, ten
> se taky objevi, az se priradi vsechny nazvy.
Super. Ja zkusim stahnout tesseract 3.0. s cestinou a dodelat ty
zbyvajici k.u.
Myslim ze do konce vikendu bych to mohl zvladnout.
Martin Kupec
Ahoj,
povedlo se mi zprovoznit kompilaci pod Monodevelop, tak?e si u? m??u
program upravit s?m (cht?l bych tam p?idat podporu pro nativn? Linuxov?
Tesseract, co? bude ten hlavn? probl?m pro? to nechod? jinak, ne? pod
Wine).
Po?li mi pros?m tedy aspo? zdroj?ky, ve kter?ch nepou??v?? knihovnu AForge.
On Wed, 20 Jan 2010 14:18:10 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
> Pokud jsem ten error spravne rozklicoval, tak se mu nelibi poziti
> knihovny AForge. Program jsem upravil tak, aby tuhle knihovnu
> nepouzival. Upravena verze je ke stazeni na [1].
--
Petr Dlouh?
zobrazit citaci
> Ahoj,
>
> povedlo se mi zprovoznit kompilaci pod Monodevelop, tak?e si u? m??u
> program upravit s?m (cht?l bych tam p?idat podporu pro nativn? Linuxov?
> Tesseract, co? bude ten hlavn? probl?m pro? to nechod? jinak, ne? pod
> Wine).
>
> Po?li mi pros?m tedy aspo? zdroj?ky, ve kter?ch nepou??v?? knihovnu AForge.
Ahoj,
updatoval jsem zdrojaky [1] i zkompilovane soubory [2] u me na
strankach, tak muzes stahovat.
[1] http://lkabrt.aspone.cz/osm/cuzk-source.zip
[2] http://lkabrt.aspone.cz/osm/cuzk.zip
--
Lukas
2010/1/21 Lukas Kabrt <lukas at kabrt.cz>:
zobrazit citaci
> Tak jsem trochu zapracoval na mape katastralnich uzemi, aby se k.u.
> nemuseli kreslit rucne.
>
> Vektorizovanou mapu k.u. od hanoje [1] jsem zacistil (slouceni
> duplicitnich bodu, odtraneni fragmentu po vektorizaci, pospojovani
> prerusenych linii) a vytvoril na ni relace pro jednotliva k.u.
>
> Mapu jsem dal dohromady s daty co mi poslal Martin Kupec (nazvy
> katastralnich uzemi a jejich poloha). Vysledek je ke stazeni tady [2].
>
> Trocha statistiky:
> CR ma 13027 k.u.
> Martin mi poslal data pro 12171 k.u.
> Mapa ma definovano 13028 relaci
>
> Mapa je jenom prozatmni, pri prirazeni se vyskytly nejake chyby (vic
> nazvu pro jedno k.u., jedna se ale o jednotky, max. desitky pripadu)
> To bych resil az budou hotova data pro vsechy k.u. Stejne tak je v
> mape 1 relace navic - pravdepodobne nekde zustal nejaky fragment, ten
> se taky objevi, az se priradi vsechny nazvy.
>
> Pokud se nekdo pousti do importu adres, tak mu tohle snad usetri trochu casu.
>
> [1] http://osm.templ.net/kucr.osm.bz2
> [2] http://lkabrt.aspone.cz/osm/kucr.zip
Ahoj,
m?l bych k tomu ryze praktick? dotaz. Jak?m zp?sobem z t?hle mapy
nejsn?ze vy??znout oblast kter? m? zaj?m?? P?i na?ten? do JOSM se s
takhle velou mapou ned? rozumn? pracovat, ka?dou akci prov?z?
minim?ln? n?kolikaminutov? ?ek?n?.
Parkis
zobrazit citaci
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
zobrazit citaci
> m?l bych k tomu ryze praktick? dotaz. Jak?m zp?sobem z t?hle mapy
> nejsn?ze vy??znout oblast kter? m? zaj?m?? P?i na?ten? do JOSM se s
> takhle velou mapou ned? rozumn? pracovat, ka?dou akci prov?z?
> minim?ln? n?kolikaminutov? ?ek?n?.
Jedna moznost je v JOSM si cast zkopirovat do nove vrstvy a pak
pracovat s ni. Chvili to trva, ale jednou se to da prezit.
Dalsi moznost je pouzit osmosis [1]. Prikaz pro orez bude neco jako
osmosis --read-xml file=test.osm --sort-0.6 --bounding-box top=50.69
left=15.76 bottom=50.27 right=16.5 clipIncompleteEntities=true
--write-xml file=result.osm
Nekdo me treba doplni s dalsimi moznostmi.
[1] http://wiki.openstreetmap.org/wiki/Osmosis
--
Lukas
Ahoj,
m?l bych je?t? jednu ot?zku:
Zkoumal si n?jak maxim?ln? rozli?en? CUZK a optimalizoval naj n? tv?j
program? Jde o to, ?e ??m v?t?? rozli?en? zvol??, t?m jsou ??sla men?? a
t?m je tak? men?? riziko p?ekryvu (kter? zp?sobuje nejv?c ?patn?
rozpoznan?ch ??sel).
On Wed, 20 Jan 2010 21:37:07 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
> dlazdice se prekryvaji o 5% na kazde strane, takze temer jiste, ze
> alespon na jedne dlazdici je text cely. Tile-processor vysledky nijak
> nezpracovava, pouze ulozi polohu bodu a jemu prislusejici text. V
> dalsim kroku, pri prirazovani adres jednotlivym bodum se nesmyslene
> rozpoznany text vyfiltruje.
--
Petr Dlouh?
J? je?t? dopln?, ?e je nutn? je?t? nechat naj?t "selected | parent
selected", aby se vybrali i relace.
On Fri, 22 Jan 2010 15:42:58 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
> Jedna moznost je v JOSM si cast zkopirovat do nove vrstvy a pak
> pracovat s ni. Chvili to trva, ale jednou se to da prezit.
--
Petr Dlouh?
zobrazit citaci
> Zkoumal si n?jak maxim?ln? rozli?en? CUZK a optimalizoval naj n? tv?j
> program? Jde o to, ?e ??m v?t?? rozli?en? zvol??, t?m jsou ??sla men?? a
> t?m je tak? men?? riziko p?ekryvu (kter? zp?sobuje nejv?c ?patn?
> rozpoznan?ch ??sel).
Ano vim o tom, ze cim vetsi rozliseni, tim mensi cisla a tim padem i
mensi riziko prekryvu. Nijak exaktne jsem to nemeril, ale pro to
meritko, ktere jsem zvolil se mi zda uspesnot dostatecna i pro mesta,
kde jsou budovy "nalepeny" na sebe. Nejvetsi procento chyb pripada na
budovy bez cp/ce - bloky garazi apod. Slo mi o to najit rozumny
kompromis mezi prekryvem napisu a mnozstvi dlazdic, ktere je potreba
zpracovat.
Moznosti by bylo nejdrive stahnout mapu v nizsim rozliseni, najit
definicni body budov a pak pro kazdou budovu stahnout detail. Tohle
reseni se mi ale moc nelibi, protoze by bylo nutne stahovat velke
mnozstvi detailu a hodne by to zpomalilo zpracovani. (Vcera jsem
zkousel rozpoznavani na plose cca 20 x 25 km a bylo tam okolo 90000
budov)
--
Lukas
On Sat, Jan 23, 2010 at 11:07:26AM +0100, Lukas Kabrt wrote:
zobrazit citaci
> Moznosti by bylo nejdrive stahnout mapu v nizsim rozliseni, najit
> definicni body budov a pak pro kazdou budovu stahnout detail. Tohle
> reseni se mi ale moc nelibi, protoze by bylo nutne stahovat velke
> mnozstvi detailu a hodne by to zpomalilo zpracovani. (Vcera jsem
> zkousel rozpoznavani na plose cca 20 x 25 km a bylo tam okolo 90000
> budov)
Presne tohle reseni delam u katastralnich uzemi. Ale tech je
pouze cca 13k v republice, takze tam to funguje pekne.
Martin
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
zobrazit citaci
> V kroku 3 (vytvoreni XML souboru, ktery definuje prirazeni mezi
> katastralnim uzemim a obci / casti obce z databaze adresnich bodu)
> jsem p?evzal XML z dokumentace. A k tomu se v??e prvn? dotaz. Kde
> berete tyto informace? A k ?emu je to dobr?? Upozor?uji, ?e nejsem
> zam?m??i?, ale program?tor, tak?e o struktu?e ?zem? toho moc nev?m, i
> kdy? jsem k t?to oblasti trochu p?i?ichnul.
zobrazit citaci
> Moje p?edstava je, ?e ??sla dom? jsou jedine?n? v ??sti obce (proto
> nap?. v nahl??en? do KN ??k?m obec, ??st obce, ??slo budovy). Proto je
> t?eba n?jak ur?it ??st obce, do kter? dan? ?zem? pat??.
Presne tak.
zobrazit citaci
> ??seln?ky ??st? obc? a jejich vztahy k obc?m, okres?m, kraj?m apod.
> jsou na ?esk?m Statistik?m ??ad?. Ale nev?m, zda je lze z licen?n?ch
> d?vod? pou??t (v? to n?kdo?). Ru?n? vytv??en? XML pro ka?d?
> katastr?ln? ?zem?, kter?ch jsou tis?ce(?) je pon?kud nepraktick? a
> hlavn? hroz? chyby.
Ano je to trochu neprakticke. Asi by to slo castecne automatizovat.
Muj postup je, ze si z databaze [1] vytahnu stukturu oblast - obec -
cast a z mapy nazvy k. u. a rucne prirazuju, vestinou je to jasne
(zatim stejne delam v mistech, ktere jakz takz znam). Prirazeni k.u. -
obec lze nalezt na strankach CUZK [2]. Jak je to s licenci nevim.
Problemy jsou ale s nekterymi castmi obci - na jednom k.u. muze byt
vice casti obce.
zobrazit citaci
>kter?ch jsou tis?ce(?)
Presne 13027.
zobrazit citaci
> A pak je t?eba ud?lat merge. Odkud poch?z? datab?ze adres? To je
> UIR-ADR? Z jak?ho p?vodn?ho zdroje poch?zej? hranice katastr?ln?ch
> ?zem??
Adresy pochazeni z webu MVCR [1], hranice k.u. ktere mam na strankach
jsou vektorizovane mapy CUZK - vektorizaci delal hanoj [3], a Martin
Kupec pracuje na OCR nazvu k.u., vysledek na mych strankach jeste neni
hotovy, chybi jeste cca 800 nazvu.
zobrazit citaci
> A co vlastn? merge d?l?? Moje p?edstava je, ?e pro ka?d? adresn? bod z
> toho CSV souboru vygenerovan?m v jednom z p?edchoz?ch krok? najde
> katastr?ln? ?zem?, jeho? hranice je v souboru dan?m parametrem
> territories.
Merge vezme CSV soubor se souradnicemi budov a rozpoznanym popiskem,
najde k.u., ve kterem se budova nachazi, podiva se do souboru *.map
jaka obec, mestska cast se na k.u. nachazi a podle toho se budove
pokusi priradit adresu z databaze MVCR.
zobrazit citaci
> U druh?ho parametru nev?m. Zkou?el jsem
> http://osm.templ.net/kucr.osm.bz2
ten urcite fungovat nebude, tam nejsou nazvy k.u.
zobrazit citaci
ten muzes pouzit, ale je potreba zkotrolovat, jestli tam je zadany to
k.u. o ktery se zajimas - nazvy jeste nejsou kompletni.
zobrazit citaci
> ?tvrt? parametr - to je to XML p?evzat? pro pokus z dokumentace.
priklad z dokumentace mozna nebude kompatiblni s mapu z
http://lkabrt.aspone.cz/osm/kucr.zip. Koukam, ze je to jeste z doby,
kdy jsem mapu zkousel malovat jen tak priblizne rucne, jen pro ucely
tohohle programu takze asi nesedi nazvy.
zobrazit citaci
> 2) V p??pad? pou?it? http://lkabrt.aspone.cz/osm/kucr.zip program
> vyt??? jedno j?dro procesoru a nic ... tedy nechal jsem to p?r des?tek
> minut (nebo m?m ?ekat d?le?). Posledn? hl??ka je, ?e Loading
> territories borders...
Pro parsovani XML pouzivam XML.LINQ, a ten neni delany na zpracovani
tak velkych souboru, proto si ze souboru kucr.zip vyriznu cast se
kterou chci pracovat [4]. S parsovanim XML dokumentu mozna neco
udelam, fakt to neni nejrychlejsi. XML.Linq ma ale tu vyhodu, ze se s
tim hezky pracuje, takze jsem ho pouzil pri vyvoji.
zobrazit citaci
> Dal?? v?c je, ?e ten XML soubor z kroku 2 definuje vztahy pomoc?
> n?zv?. Ale ty mysl?m nejsou jednozna?n?. P?itom ??seln?ky katastru i
> Stat. ??adu pou??vaj? pro ozna?en? obce, ??sti obce, katastr. ?zem?
> apod. tak? n?jak? ??seln? ID?ka (kupodivu dokonce stejn?).
Jmena k.u. jsou jedinecna, stejne tak kombinace oblast-obec-cast z databaze.
[1] http://aplikace.mvcr.cz/adresa/adresy.zip
[2] http://www.cuzk.cz/Dokument.aspx?PRARESKOD=10&MENUID=10015&AKCE=DOC:10-CISE_KUAP
[3] http://lists.openstreetmap.org/pipermail/talk-cz/2009-June/003204.html
[4] http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004310.html
--
Lukas
Na kontrolu naimportovan?ch adresn?ch bod? pln? posta?uje plugin
Czechaddress do JOSM.
Poloautomatick? obkreslov?n? by asi taky bylo nejlep?? ud?lat formou
pluginu do JOSM.
On Sat, 23 Jan 2010 18:14:37 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
> R?d bych pokra?oval v?vojem SW pro poloautomatick? zpracov?n?, proto?e
> o lep??m zdroji informac? ne? je katastr?ln? mapa nev?m. M?m p?edstavu
> n?jak? GUI, kde p?jdou obkreslovat budovy (s p??padn?m automatick?m
> n?vrhem), kontrolovat ??sla dom? apod. Ale nap?ed bych si r?d ujasnil
> sou?asnou situaci a zorientoval se v probl?mu.
--
Petr Dlouh?
Ahoj,
pracuji na gener?toru .map souboru. Pot?eboval bych ale seznam
katastr?ln?ch ?zem? a jejich ??sel, kter? Martin Kupec z?skal OCR
p?ehledek, podle ??sel ?zem? by to ?lo jednodu?e spojit.
Kde je mo?n? ten soubor z?skat?
On Sat, 23 Jan 2010 20:40:13 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
> Ano je to trochu neprakticke. Asi by to slo castecne automatizovat.
> Muj postup je, ze si z databaze [1] vytahnu stukturu oblast - obec -
> cast a z mapy nazvy k. u. a rucne prirazuju, vestinou je to jasne
> (zatim stejne delam v mistech, ktere jakz takz znam). Prirazeni k.u. -
> obec lze nalezt na strankach CUZK [2]. Jak je to s licenci nevim.
> Problemy jsou ale s nekterymi castmi obci - na jednom k.u. muze byt
> vice casti obce.
--
Petr Dlouh?
Omlouv?m se, po??dn? jsem si to nep?e?etl. Pou?iju samoz?ejm? to ze
str?nek CUZK.
On Sat, 23 Jan 2010 21:50:22 +0100, Petr Dlouh? <petr.dlouhy at email.cz>
wrote:
zobrazit citaci
> Ahoj,
>
> pracuji na gener?toru .map souboru. Pot?eboval bych ale seznam
> katastr?ln?ch ?zem? a jejich ??sel, kter? Martin Kupec z?skal OCR
> p?ehledek, podle ??sel ?zem? by to ?lo jednodu?e spojit.
> Kde je mo?n? ten soubor z?skat?
>
> On Sat, 23 Jan 2010 20:40:13 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
>
>> Ano je to trochu neprakticke. Asi by to slo castecne automatizovat.
>> Muj postup je, ze si z databaze [1] vytahnu stukturu oblast - obec -
>> cast a z mapy nazvy k. u. a rucne prirazuju, vestinou je to jasne
>> (zatim stejne delam v mistech, ktere jakz takz znam). Prirazeni k.u. -
>> obec lze nalezt na strankach CUZK [2]. Jak je to s licenci nevim.
>> Problemy jsou ale s nekterymi castmi obci - na jednom k.u. muze byt
>> vice casti obce.
>
>
--
Petr Dlouh?
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
Nen? to trochu nov? vynalezen? kolo, kdy? tu m?m osmosis?
[1]
http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004310.html
On Sun, 24 Jan 2010 02:08:17 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
> Ahoj, ud?lal jsem si utilitku pro vyjmut? ??sti ?zem? ze souboru *.osm
> mapy katastr?ln?ch ?zem?
> http://lkabrt.aspone.cz/osm/kucr.zip.
> T?eba se tak? n?komu bude hodit (a? ji? jako bin?rka nebo zdroj?k k
> zakomentov?n? do celku).
>
> Upozor?uji, ?e nejde o nic obecn?ho (i kdy? by to mo?n? zobecnit ?lo),
> ale je to d?lan? na m?ru tomuto souboru. Rychlost nem?m s ??m
> porovnat, na m?m stroji to trv? tak 10 sekund. D?l? to v?echno v
> pam?ti, tak?e to zabere pro dan? konkr?tn? soubor asi 260 MB RAM.
> Pou??v? to XmlTextReader a XmlTextWriter m?sto LINQ.
>
> Zad? se vstupn? soubor, v?stupn? soubor a obd?ln?k (north, west,
> south, east). V?sledn? soubor obsahuje v?echny
> nodes, ways a relations, kter? alespo? jedn?m nodem zasahuj? do dan?ho
> obd?ln?ku.
>
> P??klad pou?it?:
> ExtractBoundingBox.exe -north 50.50 -west 16.10278129 -south 50.49
> -east 16.123 -input "kucr-jmena.osm" -output kucr-part.osm
>
> Ke sta?en?:
> http://jabi.aspone.cz/osm/ExtractBoundingBox-bin.rar (bin?rka pro .NET)
> http://jabi.aspone.cz/osm/ExtractBoundingBox-src.rar (zdroj?ky v C#)
>
> Pou?il jsem k tomu parser parametr? z CUZK.Common.dll, snad autor nebude
> proti.
>
> Honza
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouh?
Asi ano, ale kdyz jsem osmosis zkousel, tak vzdycky spadnul na nejakou
podovnou vyjimku. Pak jsem v rychlosti dospel k zaveru, ze asi ke sve
cinnosti potrebuje nejakou DB (PostreSQL apod.) ... a to se mi
nechtelo instalovat ... ale treba je to spatny zaver. Moc jsem to
nezkoumal.
Honza
2010/1/24 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Nen? to trochu nov? vynalezen? kolo, kdy? tu m?m osmosis?
>
> [1]
> http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004310.html
>
> On Sun, 24 Jan 2010 02:08:17 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
> wrote:
>
>> Ahoj, ud?lal jsem si utilitku pro vyjmut? ??sti ?zem? ze souboru *.osm
>> mapy katastr?ln?ch ?zem?
>> http://lkabrt.aspone.cz/osm/kucr.zip.
>> T?eba se tak? n?komu bude hodit (a? ji? jako bin?rka nebo zdroj?k k
>> zakomentov?n? do celku).
>>
>> Upozor?uji, ?e nejde o nic obecn?ho (i kdy? by to mo?n? zobecnit ?lo),
>> ale je to d?lan? na m?ru tomuto souboru. Rychlost nem?m s ??m
>> porovnat, na m?m stroji to trv? tak 10 sekund. D?l? to v?echno v
>> pam?ti, tak?e to zabere pro dan? konkr?tn? soubor asi 260 MB RAM.
>> Pou??v? to XmlTextReader a XmlTextWriter m?sto LINQ.
>>
>> Zad? se vstupn? soubor, v?stupn? soubor a obd?ln?k (north, west,
>> south, east). V?sledn? soubor obsahuje v?echny
>> nodes, ways a relations, kter? alespo? jedn?m nodem zasahuj? do dan?ho
>> obd?ln?ku.
>>
>> P??klad pou?it?:
>> ExtractBoundingBox.exe -north 50.50 -west 16.10278129 -south 50.49
>> -east 16.123 -input "kucr-jmena.osm" -output kucr-part.osm
>>
>> Ke sta?en?:
>> http://jabi.aspone.cz/osm/ExtractBoundingBox-bin.rar (bin?rka pro .NET)
>> http://jabi.aspone.cz/osm/ExtractBoundingBox-src.rar (zdroj?ky v C#)
>>
>> Pou?il jsem k tomu parser parametr? z CUZK.Common.dll, snad autor nebude
>> proti.
>>
>> Honza
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
A hlavn? m?m c?lem je, aby cel? proces byl pom?rn? jednoduch? ...
integrovan? ?asem do n?jak? GUI, proto?e i kdy?, jak tady n?kdo psal,
se to m??e zd?t jako jednor?zov? proces, tak
a) je natolik pracn?, ?e je t?eba distribuovat mezi v?ce lid? (te?
nemysl?m jen adresn? body, ale tah?n? informac? z katastr?ln?ch map)
b) informace v katastru se m?n? (aktualizuj?), tak?e ??m v?ce bude
proces automatick?, t?m lep?? pro pozd?j?? aktualizace
P?ecijen tohle mi p?ijde snadn?ji pou?iteln? (i kdy? nechci tvrdit, ?e
tam to je n?jak extra slo?it? - nev?m.
Honza
2010/1/24 Jan Bilak <jan.bilak.osm at gmail.com>:
zobrazit citaci
> Asi ano, ale kdyz jsem osmosis zkousel, tak vzdycky spadnul na nejakou
> podovnou vyjimku. Pak jsem v rychlosti dospel k zaveru, ze asi ke sve
> cinnosti potrebuje nejakou DB (PostreSQL apod.) ... a to se mi
> nechtelo instalovat ... ale treba je to spatny zaver. Moc jsem to
> nezkoumal.
>
> Honza
>
>
> 2010/1/24 Petr Dlouh? <petr.dlouhy at email.cz>:
>> Nen? to trochu nov? vynalezen? kolo, kdy? tu m?m osmosis?
>>
>> [1]
>> http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004310.html
>>
>> On Sun, 24 Jan 2010 02:08:17 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>> wrote:
>>
>>> Ahoj, ud?lal jsem si utilitku pro vyjmut? ??sti ?zem? ze souboru *.osm
>>> mapy katastr?ln?ch ?zem?
>>> http://lkabrt.aspone.cz/osm/kucr.zip.
>>> T?eba se tak? n?komu bude hodit (a? ji? jako bin?rka nebo zdroj?k k
>>> zakomentov?n? do celku).
>>>
>>> Upozor?uji, ?e nejde o nic obecn?ho (i kdy? by to mo?n? zobecnit ?lo),
>>> ale je to d?lan? na m?ru tomuto souboru. Rychlost nem?m s ??m
>>> porovnat, na m?m stroji to trv? tak 10 sekund. D?l? to v?echno v
>>> pam?ti, tak?e to zabere pro dan? konkr?tn? soubor asi 260 MB RAM.
>>> Pou??v? to XmlTextReader a XmlTextWriter m?sto LINQ.
>>>
>>> Zad? se vstupn? soubor, v?stupn? soubor a obd?ln?k (north, west,
>>> south, east). V?sledn? soubor obsahuje v?echny
>>> nodes, ways a relations, kter? alespo? jedn?m nodem zasahuj? do dan?ho
>>> obd?ln?ku.
>>>
>>> P??klad pou?it?:
>>> ExtractBoundingBox.exe -north 50.50 -west 16.10278129 -south 50.49
>>> -east 16.123 -input "kucr-jmena.osm" -output kucr-part.osm
>>>
>>> Ke sta?en?:
>>> http://jabi.aspone.cz/osm/ExtractBoundingBox-bin.rar (bin?rka pro .NET)
>>> http://jabi.aspone.cz/osm/ExtractBoundingBox-src.rar (zdroj?ky v C#)
>>>
>>> Pou?il jsem k tomu parser parametr? z CUZK.Common.dll, snad autor nebude
>>> proti.
>>>
>>> Honza
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>> --
>> Petr Dlouh?
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
Padat by nem?l (nev?m, co ??k?, m??e? se pokusit nahl?sit chybu), a
datab?zi pokud v?m nepot?ebuje.
U? jsem ho dlouho nepou?il, i ten kucr.zip se mi da?? pom?rn? dob?e
vyst??hout i pomoc? JOSM (a to m?m docela star? po??ta?). Ono toti? kdy?
se to zv?t?? (nen? zobrazen? cel? mapa nar?z), tak u? to jede docela
rychle.
On Sun, 24 Jan 2010 02:19:01 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
> Asi ano, ale kdyz jsem osmosis zkousel, tak vzdycky spadnul na nejakou
> podovnou vyjimku. Pak jsem v rychlosti dospel k zaveru, ze asi ke sve
> cinnosti potrebuje nejakou DB (PostreSQL apod.) ... a to se mi
> nechtelo instalovat ... ale treba je to spatny zaver. Moc jsem to
> nezkoumal.
>
> Honza
>
--
Petr Dlouh?
Co se t??e skript?, tak mysl?m, ?e je t?eba se vydat jinou cestou.
Pokud to jde alespo? trochu jednodu?e ud?lat, tak by ten skript m?l
dok?zat pracovat s celou mapou katastr?ln?ch ?zem?. Nem??e b?t probl?m z
toho souboru vyt?hnout pouze ty relace (ty moc nezab?raj?), a hranice
tahat jen podle pot?eby.
Pokud se nav?c vytvo?? mapovac? soubor pro celou ?R, tak to cel? proces
v?razn? zjednodu??. Pro to nen? pot?eba ??dn? GUI, manu?ln? pr?ce na
za?i?t?n? ale asi bude pot?eba v?dy.
Co se t??e pozd?j??ch manu?ln?ch, tak na to existuje Czechaddress plugin
do JOSM. Tak?e vlastn? GUI.
On Sun, 24 Jan 2010 02:27:55 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
> A hlavn? m?m c?lem je, aby cel? proces byl pom?rn? jednoduch? ...
> integrovan? ?asem do n?jak? GUI, proto?e i kdy?, jak tady n?kdo psal,
> se to m??e zd?t jako jednor?zov? proces, tak
>
> a) je natolik pracn?, ?e je t?eba distribuovat mezi v?ce lid? (te?
> nemysl?m jen adresn? body, ale tah?n? informac? z katastr?ln?ch map)
> b) informace v katastru se m?n? (aktualizuj?), tak?e ??m v?ce bude
> proces automatick?, t?m lep?? pro pozd?j?? aktualizace
>
> P?ecijen tohle mi p?ijde snadn?ji pou?iteln? (i kdy? nechci tvrdit, ?e
> tam to je n?jak extra slo?it? - nev?m.
>
> Honza
>
>
> 2010/1/24 Jan Bilak <jan.bilak.osm at gmail.com>:
>> Asi ano, ale kdyz jsem osmosis zkousel, tak vzdycky spadnul na nejakou
>> podovnou vyjimku. Pak jsem v rychlosti dospel k zaveru, ze asi ke sve
>> cinnosti potrebuje nejakou DB (PostreSQL apod.) ... a to se mi
>> nechtelo instalovat ... ale treba je to spatny zaver. Moc jsem to
>> nezkoumal.
>>
>> Honza
>>
>>
>> 2010/1/24 Petr Dlouh? <petr.dlouhy at email.cz>:
>>> Nen? to trochu nov? vynalezen? kolo, kdy? tu m?m osmosis?
>>>
>>> [1]
>>> http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004310.html
>>>
>>> On Sun, 24 Jan 2010 02:08:17 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>>> wrote:
>>>
>>>> Ahoj, ud?lal jsem si utilitku pro vyjmut? ??sti ?zem? ze souboru *.osm
>>>> mapy katastr?ln?ch ?zem?
>>>> http://lkabrt.aspone.cz/osm/kucr.zip.
>>>> T?eba se tak? n?komu bude hodit (a? ji? jako bin?rka nebo zdroj?k k
>>>> zakomentov?n? do celku).
>>>>
>>>> Upozor?uji, ?e nejde o nic obecn?ho (i kdy? by to mo?n? zobecnit ?lo),
>>>> ale je to d?lan? na m?ru tomuto souboru. Rychlost nem?m s ??m
>>>> porovnat, na m?m stroji to trv? tak 10 sekund. D?l? to v?echno v
>>>> pam?ti, tak?e to zabere pro dan? konkr?tn? soubor asi 260 MB RAM.
>>>> Pou??v? to XmlTextReader a XmlTextWriter m?sto LINQ.
>>>>
>>>> Zad? se vstupn? soubor, v?stupn? soubor a obd?ln?k (north, west,
>>>> south, east). V?sledn? soubor obsahuje v?echny
>>>> nodes, ways a relations, kter? alespo? jedn?m nodem zasahuj? do dan?ho
>>>> obd?ln?ku.
>>>>
>>>> P??klad pou?it?:
>>>> ExtractBoundingBox.exe -north 50.50 -west 16.10278129 -south 50.49
>>>> -east 16.123 -input "kucr-jmena.osm" -output kucr-part.osm
>>>>
>>>> Ke sta?en?:
>>>> http://jabi.aspone.cz/osm/ExtractBoundingBox-bin.rar (bin?rka pro
>>>> .NET)
>>>> http://jabi.aspone.cz/osm/ExtractBoundingBox-src.rar (zdroj?ky v C#)
>>>>
>>>> Pou?il jsem k tomu parser parametr? z CUZK.Common.dll, snad autor
>>>> nebude
>>>> proti.
>>>>
>>>> Honza
>>>>
>>>> _______________________________________________
>>>> Talk-cz mailing list
>>>> Talk-cz at openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>>
>>> --
>>> Petr Dlouh?
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouh?
Ahoj,
d?ky, u? se mi poda?ilo. Jeden post?eh je ten, ?e soubor mapov?n?
nesm? obsahovat nic nav?c, ne? je nutn?. Pokud je tam n?jak? mapov?n?
nav?c (neexistuje k tomu katastr?ln? ?zem? v *.osm mapce apod.), tak
to p?i mergov?n? spadne.
Honza
2010/1/23 Lukas Kabrt <lukas at kabrt.cz>:
zobrazit citaci
>> V kroku 3 (vytvoreni XML souboru, ktery definuje prirazeni mezi
>> katastralnim uzemim a obci / casti obce z databaze adresnich bodu)
>> jsem p?evzal XML z dokumentace. A k tomu se v??e prvn? dotaz. Kde
>> berete tyto informace? A k ?emu je to dobr?? Upozor?uji, ?e nejsem
>> zam?m??i?, ale program?tor, tak?e o struktu?e ?zem? toho moc nev?m, i
>> kdy? jsem k t?to oblasti trochu p?i?ichnul.
>
>> Moje p?edstava je, ?e ??sla dom? jsou jedine?n? v ??sti obce (proto
>> nap?. v nahl??en? do KN ??k?m obec, ??st obce, ??slo budovy). Proto je
>> t?eba n?jak ur?it ??st obce, do kter? dan? ?zem? pat??.
>
> Presne tak.
>
>> ??seln?ky ??st? obc? a jejich vztahy k obc?m, okres?m, kraj?m apod.
>> jsou na ?esk?m Statistik?m ??ad?. Ale nev?m, zda je lze z licen?n?ch
>> d?vod? pou??t (v? to n?kdo?). Ru?n? vytv??en? XML pro ka?d?
>> katastr?ln? ?zem?, kter?ch jsou tis?ce(?) je pon?kud nepraktick? a
>> hlavn? hroz? chyby.
>
> Ano je to trochu neprakticke. Asi by to slo castecne automatizovat.
> Muj postup je, ze si z databaze [1] vytahnu stukturu oblast - obec -
> cast a z mapy nazvy k. u. a rucne prirazuju, vestinou je to jasne
> (zatim stejne delam v mistech, ktere jakz takz znam). Prirazeni k.u. -
> obec lze nalezt na strankach CUZK [2]. Jak je to s licenci nevim.
> Problemy jsou ale s nekterymi castmi obci - na jednom k.u. muze byt
> vice casti obce.
>
>>kter?ch jsou tis?ce(?)
>
> Presne 13027.
>
>> A pak je t?eba ud?lat merge. Odkud poch?z? datab?ze adres? To je
>> UIR-ADR? Z jak?ho p?vodn?ho zdroje poch?zej? hranice katastr?ln?ch
>> ?zem??
>
> Adresy pochazeni z webu MVCR [1], hranice k.u. ktere mam na strankach
> jsou vektorizovane mapy CUZK - vektorizaci delal hanoj [3], a Martin
> Kupec pracuje na OCR nazvu k.u., vysledek na mych strankach jeste neni
> hotovy, chybi jeste cca 800 nazvu.
>
>> A co vlastn? merge d?l?? Moje p?edstava je, ?e pro ka?d? adresn? bod z
>> toho CSV souboru vygenerovan?m v jednom z p?edchoz?ch krok? najde
>> katastr?ln? ?zem?, jeho? hranice je v souboru dan?m parametrem
>> territories.
>
> Merge vezme CSV soubor se souradnicemi budov a rozpoznanym popiskem,
> najde k.u., ve kterem se budova nachazi, podiva se do souboru *.map
> jaka obec, mestska cast se na k.u. nachazi a podle toho se budove
> pokusi priradit adresu z databaze MVCR.
>
>> U druh?ho parametru nev?m. Zkou?el jsem
>> http://osm.templ.net/kucr.osm.bz2
>
> ten urcite fungovat nebude, tam nejsou nazvy k.u.
>
>> http://lkabrt.aspone.cz/osm/kucr.zip.
>
> ten muzes pouzit, ale je potreba zkotrolovat, jestli tam je zadany to
> k.u. o ktery se zajimas - nazvy jeste nejsou kompletni.
>
>
>> ?tvrt? parametr - to je to XML p?evzat? pro pokus z dokumentace.
>
> priklad z dokumentace mozna nebude kompatiblni s mapu z
> http://lkabrt.aspone.cz/osm/kucr.zip. Koukam, ze je to jeste z doby,
> kdy jsem mapu zkousel malovat jen tak priblizne rucne, jen pro ucely
> tohohle programu takze asi nesedi nazvy.
>
>> 2) V p??pad? pou?it? http://lkabrt.aspone.cz/osm/kucr.zip program
>> vyt??? jedno j?dro procesoru a nic ... tedy nechal jsem to p?r des?tek
>> minut (nebo m?m ?ekat d?le?). Posledn? hl??ka je, ?e Loading
>> territories borders...
>
> Pro parsovani XML pouzivam XML.LINQ, a ten neni delany na zpracovani
> tak velkych souboru, proto si ze souboru kucr.zip vyriznu cast se
> kterou chci pracovat [4]. S parsovanim XML dokumentu mozna neco
> udelam, fakt to neni nejrychlejsi. XML.Linq ma ale tu vyhodu, ze se s
> tim hezky pracuje, takze jsem ho pouzil pri vyvoji.
>
>> Dal?? v?c je, ?e ten XML soubor z kroku 2 definuje vztahy pomoc?
>> n?zv?. Ale ty mysl?m nejsou jednozna?n?. P?itom ??seln?ky katastru i
>> Stat. ??adu pou??vaj? pro ozna?en? obce, ??sti obce, katastr. ?zem?
>> apod. tak? n?jak? ??seln? ID?ka (kupodivu dokonce stejn?).
>
> Jmena k.u. jsou jedinecna, stejne tak kombinace oblast-obec-cast z databaze.
>
> [1] http://aplikace.mvcr.cz/adresa/adresy.zip
> [2] http://www.cuzk.cz/Dokument.aspx?PRARESKOD=10&MENUID=10015&AKCE=DOC:10-CISE_KUAP
> [3] http://lists.openstreetmap.org/pipermail/talk-cz/2009-June/003204.html
> [4] http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004310.html
> --
> Lukas
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
J? nemyslel GUI v tom smyslu, ?e tam bude 5 tla??tek a ty budou
spou?t?t tyhle skripty. Ale co je t?eba d?lat?
Pro adresn? body:
- vybrat ?zem?, kter? mne zaj?m? (zaj?mav? informace zde bude, co u?
je hotov? a co nikoli ... zat?m nen? skoro nic, ale ?asem...)
- automaticky st?hnou pot?ebn? data (mapov?n?, adresy, hranice kat.
?zem?, dla?dice) a OCRovat
- pak je t?eba manu?ln? kontrola mapov?n?, adres, v?sledku OCRu -
zejm?na pro kontrolu OCRu se hod? mo?nost v GUI si zobrazit dan? text
v podob? v??ezu obr?zku (zcela automaticky, ani? bych musel n?co
slo?it? n?kde hledat ?i zad?v?t)
- automaticky prov?st mergov?n?
- op?t kontrola v?sledk?
- ...
Pro zakreslov?n? dom? to bude tak? zaj?mav? ... n?jak? poloautomatick?
rozpozn?v?n? obrys?, mo?nost korektur, ov??ov?n? na fotomap?, ru?n?
zakreslen? budov, n?vaznost na adresn? body, ...
Mo?nosti plugin? do JOSM nezn?m, zat?m ani Czechadress. Ale nemysl?m,
?e bude jednoduch? to do toho n?jak vhodn? napasovat, aby s t?m ?lo
pohodln? pracovat. P?ecijen republika je velk? a tak zpracov?n? takov?
velk? oblasti d? mnoho pr?ce. Tak?e investice do co nejpohodln?j??ho
GUI pro pr?ci se vyplat?. ??m jednodu??? to bude, t?m v?ce lid? se do
toho zapoj?. Ur?it? jsou lidi, kte?? by do toho ?li, ale je to na n?
moc slo?it?. Jak jsem pochopil, tak zat?m na tom d?laj? vlastn? jen
program?to?i (nebo alespo? p?ev??n?). P?itom je tam spousta manu?ln?
pr?ce, kter? z principu program?torsk? schopnosti nevy?aduje, pokud by
bylo n?jak? rozumn? programov? vybaven?.
Co je podle tebe t?eba te? d?lat? Mapovac? soubor apod. je kr?tkodob?
c?l. Mysl?m alespo? ze st?edn?dob?ho pohledu.
Honza
2010/1/24 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Co se t??e skript?, tak mysl?m, ?e je t?eba se vydat jinou cestou.
> Pokud to jde alespo? trochu jednodu?e ud?lat, tak by ten skript m?l
> dok?zat pracovat s celou mapou katastr?ln?ch ?zem?. Nem??e b?t probl?m z
> toho souboru vyt?hnout pouze ty relace (ty moc nezab?raj?), a hranice
> tahat jen podle pot?eby.
> Pokud se nav?c vytvo?? mapovac? soubor pro celou ?R, tak to cel? proces
> v?razn? zjednodu??. Pro to nen? pot?eba ??dn? GUI, manu?ln? pr?ce na
> za?i?t?n? ale asi bude pot?eba v?dy.
>
> Co se t??e pozd?j??ch manu?ln?ch, tak na to existuje Czechaddress plugin
> do JOSM. Tak?e vlastn? GUI.
>
> On Sun, 24 Jan 2010 02:27:55 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
> wrote:
>
>> A hlavn? m?m c?lem je, aby cel? proces byl pom?rn? jednoduch? ...
>> integrovan? ?asem do n?jak? GUI, proto?e i kdy?, jak tady n?kdo psal,
>> se to m??e zd?t jako jednor?zov? proces, tak
>>
>> a) je natolik pracn?, ?e je t?eba distribuovat mezi v?ce lid? (te?
>> nemysl?m jen adresn? body, ale tah?n? informac? z katastr?ln?ch map)
>> b) informace v katastru se m?n? (aktualizuj?), tak?e ??m v?ce bude
>> proces automatick?, t?m lep?? pro pozd?j?? aktualizace
>>
>> P?ecijen tohle mi p?ijde snadn?ji pou?iteln? (i kdy? nechci tvrdit, ?e
>> tam to je n?jak extra slo?it? - nev?m.
>>
>> Honza
>>
>>
>> 2010/1/24 Jan Bilak <jan.bilak.osm at gmail.com>:
>>> Asi ano, ale kdyz jsem osmosis zkousel, tak vzdycky spadnul na nejakou
>>> podovnou vyjimku. Pak jsem v rychlosti dospel k zaveru, ze asi ke sve
>>> cinnosti potrebuje nejakou DB (PostreSQL apod.) ... a to se mi
>>> nechtelo instalovat ... ale treba je to spatny zaver. Moc jsem to
>>> nezkoumal.
>>>
>>> Honza
>>>
>>>
>>> 2010/1/24 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>> Nen? to trochu nov? vynalezen? kolo, kdy? tu m?m osmosis?
>>>>
>>>> [1]
>>>> http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004310.html
>>>>
>>>> On Sun, 24 Jan 2010 02:08:17 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>>>> wrote:
>>>>
>>>>> Ahoj, ud?lal jsem si utilitku pro vyjmut? ??sti ?zem? ze souboru *.osm
>>>>> mapy katastr?ln?ch ?zem?
>>>>> http://lkabrt.aspone.cz/osm/kucr.zip.
>>>>> T?eba se tak? n?komu bude hodit (a? ji? jako bin?rka nebo zdroj?k k
>>>>> zakomentov?n? do celku).
>>>>>
>>>>> Upozor?uji, ?e nejde o nic obecn?ho (i kdy? by to mo?n? zobecnit ?lo),
>>>>> ale je to d?lan? na m?ru tomuto souboru. Rychlost nem?m s ??m
>>>>> porovnat, na m?m stroji to trv? tak 10 sekund. D?l? to v?echno v
>>>>> pam?ti, tak?e to zabere pro dan? konkr?tn? soubor asi 260 MB RAM.
>>>>> Pou??v? to XmlTextReader a XmlTextWriter m?sto LINQ.
>>>>>
>>>>> Zad? se vstupn? soubor, v?stupn? soubor a obd?ln?k (north, west,
>>>>> south, east). V?sledn? soubor obsahuje v?echny
>>>>> nodes, ways a relations, kter? alespo? jedn?m nodem zasahuj? do dan?ho
>>>>> obd?ln?ku.
>>>>>
>>>>> P??klad pou?it?:
>>>>> ExtractBoundingBox.exe -north 50.50 -west 16.10278129 -south 50.49
>>>>> -east 16.123 -input "kucr-jmena.osm" -output kucr-part.osm
>>>>>
>>>>> Ke sta?en?:
>>>>> http://jabi.aspone.cz/osm/ExtractBoundingBox-bin.rar (bin?rka pro
>>>>> .NET)
>>>>> http://jabi.aspone.cz/osm/ExtractBoundingBox-src.rar (zdroj?ky v C#)
>>>>>
>>>>> Pou?il jsem k tomu parser parametr? z CUZK.Common.dll, snad autor
>>>>> nebude
>>>>> proti.
>>>>>
>>>>> Honza
>>>>>
>>>>> _______________________________________________
>>>>> Talk-cz mailing list
>>>>> Talk-cz at openstreetmap.org
>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>
>>>>
>>>> --
>>>> Petr Dlouh?
>>>>
>>>> _______________________________________________
>>>> Talk-cz mailing list
>>>> Talk-cz at openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>
>>>
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Ahoj. K vyu?it? dat z ?S? ... na str?nce:
http://www.czso.cz/csu/redakce.nsf/i/zasady_cenove_strategie_v_csu_ se
p??e:
"Ve?ker? ?daje na internetov?ch str?nk?ch ?S? si m??e kdokoliv p?evz?t
pro sv? ??ely bezplatn?, pouze s podm?nkou, ?e uvede jako zdroj ?S?.
Je doporu?ov?no uv?d?t i datum, kdy ?daje byly p?evzaty."
Pod "sv?m ??elem" si mohu p?edstavit kde co ... t?eba vytv??en? open
source mapy. Patrn? nejde jen o osobn? vyu?it?, tam by nem?lo smysl
uv?d?t zdroj.
A ?S? m? mimo jin? na sv?ch str?nk?ch i mapy ... ale v?t?ina v?c? je
tam stejn? s katastrem. Nap?.:
http://apl.czso.cz/irso/mapa.jsp?budId=207400&obrprvId=184459
Honza
2010/1/24 Jan Bilak <jan.bilak.osm at gmail.com>:
zobrazit citaci
> J? nemyslel GUI v tom smyslu, ?e tam bude 5 tla??tek a ty budou
> spou?t?t tyhle skripty. Ale co je t?eba d?lat?
>
> Pro adresn? body:
> - vybrat ?zem?, kter? mne zaj?m? (zaj?mav? informace zde bude, co u?
> je hotov? a co nikoli ... zat?m nen? skoro nic, ale ?asem...)
> - automaticky st?hnou pot?ebn? data (mapov?n?, adresy, hranice kat.
> ?zem?, dla?dice) a OCRovat
> - pak je t?eba manu?ln? kontrola mapov?n?, adres, v?sledku OCRu -
> zejm?na pro kontrolu OCRu se hod? mo?nost v GUI si zobrazit dan? text
> v podob? v??ezu obr?zku (zcela automaticky, ani? bych musel n?co
> slo?it? n?kde hledat ?i zad?v?t)
> - automaticky prov?st mergov?n?
> - op?t kontrola v?sledk?
> - ...
>
> Pro zakreslov?n? dom? to bude tak? zaj?mav? ... n?jak? poloautomatick?
> rozpozn?v?n? obrys?, mo?nost korektur, ov??ov?n? na fotomap?, ru?n?
> zakreslen? budov, n?vaznost na adresn? body, ...
>
> Mo?nosti plugin? do JOSM nezn?m, zat?m ani Czechadress. Ale nemysl?m,
> ?e bude jednoduch? to do toho n?jak vhodn? napasovat, aby s t?m ?lo
> pohodln? pracovat. P?ecijen republika je velk? a tak zpracov?n? takov?
> velk? oblasti d? mnoho pr?ce. Tak?e investice do co nejpohodln?j??ho
> GUI pro pr?ci se vyplat?. ??m jednodu??? to bude, t?m v?ce lid? se do
> toho zapoj?. Ur?it? jsou lidi, kte?? by do toho ?li, ale je to na n?
> moc slo?it?. Jak jsem pochopil, tak zat?m na tom d?laj? vlastn? jen
> program?to?i (nebo alespo? p?ev??n?). P?itom je tam spousta manu?ln?
> pr?ce, kter? z principu program?torsk? schopnosti nevy?aduje, pokud by
> bylo n?jak? rozumn? programov? vybaven?.
>
> Co je podle tebe t?eba te? d?lat? Mapovac? soubor apod. je kr?tkodob?
> c?l. Mysl?m alespo? ze st?edn?dob?ho pohledu.
>
> Honza
>
>
> 2010/1/24 Petr Dlouh? <petr.dlouhy at email.cz>:
>> Co se t??e skript?, tak mysl?m, ?e je t?eba se vydat jinou cestou.
>> Pokud to jde alespo? trochu jednodu?e ud?lat, tak by ten skript m?l
>> dok?zat pracovat s celou mapou katastr?ln?ch ?zem?. Nem??e b?t probl?m z
>> toho souboru vyt?hnout pouze ty relace (ty moc nezab?raj?), a hranice
>> tahat jen podle pot?eby.
>> Pokud se nav?c vytvo?? mapovac? soubor pro celou ?R, tak to cel? proces
>> v?razn? zjednodu??. Pro to nen? pot?eba ??dn? GUI, manu?ln? pr?ce na
>> za?i?t?n? ale asi bude pot?eba v?dy.
>>
>> Co se t??e pozd?j??ch manu?ln?ch, tak na to existuje Czechaddress plugin
>> do JOSM. Tak?e vlastn? GUI.
>>
>> On Sun, 24 Jan 2010 02:27:55 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>> wrote:
>>
>>> A hlavn? m?m c?lem je, aby cel? proces byl pom?rn? jednoduch? ...
>>> integrovan? ?asem do n?jak? GUI, proto?e i kdy?, jak tady n?kdo psal,
>>> se to m??e zd?t jako jednor?zov? proces, tak
>>>
>>> a) je natolik pracn?, ?e je t?eba distribuovat mezi v?ce lid? (te?
>>> nemysl?m jen adresn? body, ale tah?n? informac? z katastr?ln?ch map)
>>> b) informace v katastru se m?n? (aktualizuj?), tak?e ??m v?ce bude
>>> proces automatick?, t?m lep?? pro pozd?j?? aktualizace
>>>
>>> P?ecijen tohle mi p?ijde snadn?ji pou?iteln? (i kdy? nechci tvrdit, ?e
>>> tam to je n?jak extra slo?it? - nev?m.
>>>
>>> Honza
>>>
>>>
>>> 2010/1/24 Jan Bilak <jan.bilak.osm at gmail.com>:
>>>> Asi ano, ale kdyz jsem osmosis zkousel, tak vzdycky spadnul na nejakou
>>>> podovnou vyjimku. Pak jsem v rychlosti dospel k zaveru, ze asi ke sve
>>>> cinnosti potrebuje nejakou DB (PostreSQL apod.) ... a to se mi
>>>> nechtelo instalovat ... ale treba je to spatny zaver. Moc jsem to
>>>> nezkoumal.
>>>>
>>>> Honza
>>>>
>>>>
>>>> 2010/1/24 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>> Nen? to trochu nov? vynalezen? kolo, kdy? tu m?m osmosis?
>>>>>
>>>>> [1]
>>>>> http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004310.html
>>>>>
>>>>> On Sun, 24 Jan 2010 02:08:17 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Ahoj, ud?lal jsem si utilitku pro vyjmut? ??sti ?zem? ze souboru *.osm
>>>>>> mapy katastr?ln?ch ?zem?
>>>>>> http://lkabrt.aspone.cz/osm/kucr.zip.
>>>>>> T?eba se tak? n?komu bude hodit (a? ji? jako bin?rka nebo zdroj?k k
>>>>>> zakomentov?n? do celku).
>>>>>>
>>>>>> Upozor?uji, ?e nejde o nic obecn?ho (i kdy? by to mo?n? zobecnit ?lo),
>>>>>> ale je to d?lan? na m?ru tomuto souboru. Rychlost nem?m s ??m
>>>>>> porovnat, na m?m stroji to trv? tak 10 sekund. D?l? to v?echno v
>>>>>> pam?ti, tak?e to zabere pro dan? konkr?tn? soubor asi 260 MB RAM.
>>>>>> Pou??v? to XmlTextReader a XmlTextWriter m?sto LINQ.
>>>>>>
>>>>>> Zad? se vstupn? soubor, v?stupn? soubor a obd?ln?k (north, west,
>>>>>> south, east). V?sledn? soubor obsahuje v?echny
>>>>>> nodes, ways a relations, kter? alespo? jedn?m nodem zasahuj? do dan?ho
>>>>>> obd?ln?ku.
>>>>>>
>>>>>> P??klad pou?it?:
>>>>>> ExtractBoundingBox.exe -north 50.50 -west 16.10278129 -south 50.49
>>>>>> -east 16.123 -input "kucr-jmena.osm" -output kucr-part.osm
>>>>>>
>>>>>> Ke sta?en?:
>>>>>> http://jabi.aspone.cz/osm/ExtractBoundingBox-bin.rar (bin?rka pro
>>>>>> .NET)
>>>>>> http://jabi.aspone.cz/osm/ExtractBoundingBox-src.rar (zdroj?ky v C#)
>>>>>>
>>>>>> Pou?il jsem k tomu parser parametr? z CUZK.Common.dll, snad autor
>>>>>> nebude
>>>>>> proti.
>>>>>>
>>>>>> Honza
>>>>>>
>>>>>> _______________________________________________
>>>>>> Talk-cz mailing list
>>>>>> Talk-cz at openstreetmap.org
>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>
>>>>>
>>>>> --
>>>>> Petr Dlouh?
>>>>>
>>>>> _______________________________________________
>>>>> Talk-cz mailing list
>>>>> Talk-cz at openstreetmap.org
>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>> --
>> Petr Dlouh?
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
H??ek je v tom "bezplatn?". U OSM nikdo nezakazuje, aby byla data
prod?v?na. Je ot?zka, zdali se ale nejedn? o ??edn? d?lo - v tom p??pad?
by si ?S? takov? podm?nky diktovat asi nemohl.
On Sun, 24 Jan 2010 04:46:05 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
>
> "Ve?ker? ?daje na internetov?ch str?nk?ch ?S? si m??e kdokoliv p?evz?t
> pro sv? ??ely bezplatn?, pouze s podm?nkou, ?e uvede jako zdroj ?S?.
> Je doporu?ov?no uv?d?t i datum, kdy ?daje byly p?evzaty."
--
Petr Dlouh?
On Sun, 24 Jan 2010 03:54:13 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
> J? nemyslel GUI v tom smyslu, ?e tam bude 5 tla??tek a ty budou
> spou?t?t tyhle skripty. Ale co je t?eba d?lat?
J? vid?m zat?m nejv?t?? probl?m ve v?po?etn? n?ro?nosti cel?ho procesu (m?
velmi hrub? odhady se pohybuj? od 50 do 100 hodin jenom pro 2. f?zi).
Mo?n? by bylo lep?? ud?lat n?co ve stylu Seti at home - rozd?lit republiku na
?tverce rozumn? velikosti (zpracov?n? ~1 hodina). Program by si zjistil,
kter? ?zem? je?t? chyb?, a uploadnul n?kam by v?sledn? soubory (asi ty 3
.osm + .csv). A? by to bylo hotov?, tak by se to rozsekalo na men?? celky
(nap??klad ORP), a lidi by to mohli manu?ln? kontrolovat a uploadovat.
Manu?ln? kontrolu jde bez probl?mu prov?st v JOSM, dokonce i p?vodn?
OCRkovan? text je tam vid?t.
Kontrola by taky ?la zv??it vytvo??n?m n?jak? str?nky ve stylu
<http://tools.geofabrik.de/osmi/>, kter? by porovn?vala datab?ze adres s
OSM.
Dlouhodob? hledisko bych p??li? ne?e?il, proto?e dal?? korekce adresn?ch
bod? prob?hne nejd??ve za rok, a to m??e b?t situace ?pln? jin? (m??e b?t
dostupn? n?jak? dostupn? datab?ze, WMS katastr?ln?ho ??adu se m??e zm?nit,
...).
zobrazit citaci
>
> Pro adresn? body:
> - vybrat ?zem?, kter? mne zaj?m? (zaj?mav? informace zde bude, co u?
> je hotov? a co nikoli ... zat?m nen? skoro nic, ale ?asem...)
> - automaticky st?hnou pot?ebn? data (mapov?n?, adresy, hranice kat.
> ?zem?, dla?dice) a OCRovat
> - pak je t?eba manu?ln? kontrola mapov?n?, adres, v?sledku OCRu -
> zejm?na pro kontrolu OCRu se hod? mo?nost v GUI si zobrazit dan? text
> v podob? v??ezu obr?zku (zcela automaticky, ani? bych musel n?co
> slo?it? n?kde hledat ?i zad?v?t)
> - automaticky prov?st mergov?n?
> - op?t kontrola v?sledk?
> - ...
>
Zakreslov?n? dom? je, mysl?m, ?pln? jin? poh?dka. Ta mapa je slo?en? z
??st?, kter? byli kresleny ru?n? snad je?t? za Rakouska Uherska a z ??st?,
kter? vznikly renderingem vektorov? KM. Nev?m tak?, jak je to s
dostupnost? vektorov? KM. N?vaznost na adresn? body bych moc ne?e?il,
jinak moc nev?m, jak to ud?lat. Asi bych ale asi ned?lal vlastn? GUI, ale
?e?il to taky formou pluginu do JOSM, proto?e s t?m um? pracovat asi
nejv?c lid? a u? je tam plno n?stroj? implementovan?ch.
zobrazit citaci
> Pro zakreslov?n? dom? to bude tak? zaj?mav? ... n?jak? poloautomatick?
> rozpozn?v?n? obrys?, mo?nost korektur, ov??ov?n? na fotomap?, ru?n?
> zakreslen? budov, n?vaznost na adresn? body, ...
>
Czechadress je ur?en na manu?ln? dola?ov?n? adres s pomoc? datab?ze MV?R
(tedy byl ur?en i na hromadn? zan??en? bod?, ale to te? odpad?).
zobrazit citaci
> Mo?nosti plugin? do JOSM nezn?m, zat?m ani Czechadress. Ale nemysl?m,
> ?e bude jednoduch? to do toho n?jak vhodn? napasovat, aby s t?m ?lo
> pohodln? pracovat. P?ecijen republika je velk? a tak zpracov?n? takov?
> velk? oblasti d? mnoho pr?ce. Tak?e investice do co nejpohodln?j??ho
> GUI pro pr?ci se vyplat?. ??m jednodu??? to bude, t?m v?ce lid? se do
> toho zapoj?. Ur?it? jsou lidi, kte?? by do toho ?li, ale je to na n?
> moc slo?it?. Jak jsem pochopil, tak zat?m na tom d?laj? vlastn? jen
> program?to?i (nebo alespo? p?ev??n?). P?itom je tam spousta manu?ln?
> pr?ce, kter? z principu program?torsk? schopnosti nevy?aduje, pokud by
> bylo n?jak? rozumn? programov? vybaven?.
Vy?e?it poloautomatick? rozpozn?v?n? budov z katastr?ln? mapy by bylo
jist? p??nosn?. Chce to ale prozkoumat v?echny mo?nosti (vektorov? KM,
nen? mi moc jasn? jak by to m?lo fungovat).
Pak je tady spousta dal??ch v?c?:
-Export mapov?ch zna?ek z Wiki do XML (pro mo?nosti dal??ho vytv??en?
-Kontrolor relac? (seznam relac? ve stylu [1] + historie)
-Kontrolor v?eho mo?n?ho co je?t? kontrolov?no nen?
-Dod?l?n? paraleln?ch turistick?ch tras ve stylu seznam.cz do Mapniku
(Osmarenderu)
-Dal?? pr?ce na OpenTrackMap
-Dal?? renderery v?c?, kter? je?t? renderov?ny nejsou
[1] http://wiki.openstreetmap.org/wiki/Cyklotrasy_v_?R
zobrazit citaci
> Co je podle tebe t?eba te? d?lat? Mapovac? soubor apod. je kr?tkodob?
> c?l. Mysl?m alespo? ze st?edn?dob?ho pohledu.
>
> Honza
>
--
Petr Dlouh?
Pardon, myslel jsem dn?.
On Sun, 24 Jan 2010 08:46:16 +0100, Petr Dlouh? <petr.dlouhy at email.cz>
wrote:
zobrazit citaci
> (m? velmi hrub? odhady se pohybuj? od 50 do 100 hodin jenom pro 2. f?zi).
--
Petr Dlouh?
zobrazit citaci
> Asi ano, ale kdyz jsem osmosis zkousel, tak vzdycky spadnul na nejakou
> podovnou vyjimku. Pak jsem v rychlosti dospel k zaveru, ze asi ke sve
> cinnosti potrebuje nejakou DB (PostreSQL apod.) ... a to se mi
> nechtelo instalovat ... ale treba je to spatny zaver. Moc jsem to
> nezkoumal.
Urcite funguje i bez DB. pouzivam vyvojovou verzi 0.33 [1] a funguje
bez problemu. Musel jsem ale pouzit soubor osmosis.bat z predchozi
verze a dopnit do promenne EXEC pridat chybejci knihovnu
commons-compress-1.0.jar
[1] http://dev.openstreetmap.de:23457/hudson/job/osmosis-SNAPSHOT-ant/lastSuccessfulBuild/artifact/trunk/dist/
--
Lukas
zobrazit citaci
> Co se t??e skript?, tak mysl?m, ?e je t?eba se vydat jinou cestou.
> Pokud to jde alespo? trochu jednodu?e ud?lat, tak by ten skript m?l
> dok?zat pracovat s celou mapou katastr?ln?ch ?zem?.
Problem to neni. Kdyz jsem program vytvarel, tak jsem nevedel o tom,
ze existuje vektorizovana mapa k.u. a tak jsem k.u. kreslil rucne.
Vzdycky jen par k.u., ktere jsem chtel zpracovat. Takze me rychlost
zpracovani OSM souboru nejak netrapila. Na vektorizovanou mapu jsem
narazil az kdyz jsem mel program hotovy a jeste jsem se nedostal k
tomu ho predelat - dalsi polozka do TODO listu :-)
Koukal jsem, ze by sla pouzit knihovna pro praci s OSM soubory z
programu Kosmos [1], takze s tim nakonec asi ani nebude tolik prace.
[1] http://wiki.openstreetmap.org/wiki/Kosmos
--
Lukas
zobrazit citaci
> Pardon, myslel jsem dn?.
>
> On Sun, 24 Jan 2010 08:46:16 +0100, Petr Dlouh? <petr.dlouhy at email.cz>
> wrote:
>
>> (m? velmi hrub? odhady se pohybuj? od 50 do 100 hodin jenom pro 2. f?zi).
Jestli myslis cisteho vypocetniho casu, tak bych rekl, ze je to
pesimisticky odhad. Podle toho, jak rychle probiha vypocet u me, bych
to odhadnul na 30 - 50 dni. Limitujici je tady rychlost procesoru.
Nedavno jsem zkousel oblast cca 20 x 25 km a rozpoznavani bezelo neco
pres 5 hodin. Muj pocitac pritom neni zadne "delo" - Intel Core2 Duo @
2Ghz.
--
Lukas
To docela odpov?d?. J? m?m po??ta? je?t? pomalej??, jednoj?drov? a podle
n?j jsem to odhadoval.
Ka?dop?dn? je to pom?rn? dost, a cht?lo by to mo?n? zapojit i ty, kdo maj?
dost procesorov?ho a m?lo osobn?ho ?asu.
On Sun, 24 Jan 2010 10:53:38 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
> Jestli myslis cisteho vypocetniho casu, tak bych rekl, ze je to
> pesimisticky odhad. Podle toho, jak rychle probiha vypocet u me, bych
> to odhadnul na 30 - 50 dni. Limitujici je tady rychlost procesoru.
> Nedavno jsem zkousel oblast cca 20 x 25 km a rozpoznavani bezelo neco
> pres 5 hodin. Muj pocitac pritom neni zadne "delo" - Intel Core2 Duo @
> 2Ghz.
--
Petr Dlouh?
Mam malo osobniho casu, ale jsem schopen pripravit virtualni masinu s
debianem pro zajemce, ktery to uchodi. Je tam 2x2.8GHz XEON a 4GB
pameti. Pokud by to pomohlo...
K
Dne 24.1.2010 10:58, Petr Dlouh? napsal(a):
zobrazit citaci
> To docela odpov?d?. J? m?m po??ta? je?t? pomalej??, jednoj?drov? a podle
> n?j jsem to odhadoval.
> Ka?dop?dn? je to pom?rn? dost, a cht?lo by to mo?n? zapojit i ty, kdo maj?
> dost procesorov?ho a m?lo osobn?ho ?asu.
>
> On Sun, 24 Jan 2010 10:53:38 +0100, Lukas Kabrt<lukas at kabrt.cz> wrote:
>
>
>> Jestli myslis cisteho vypocetniho casu, tak bych rekl, ze je to
>> pesimisticky odhad. Podle toho, jak rychle probiha vypocet u me, bych
>> to odhadnul na 30 - 50 dni. Limitujici je tady rychlost procesoru.
>> Nedavno jsem zkousel oblast cca 20 x 25 km a rozpoznavani bezelo neco
>> pres 5 hodin. Muj pocitac pritom neni zadne "delo" - Intel Core2 Duo @
>> 2Ghz.
>>
>
>
Ahoj,
j? bych se klidn? p?idal. Pendluju mezi 2j?drem a 3j?drem, ob? pom?rn? v?konn? a
m?lo vyu?it? :-)
V?kon te? v?nuju tiles at home, ale v tomhle vid?m v?t?? smysl. Sta?ilo by, kdyby
n?s bylo p?r, a do dvou t?dn? bysme to m?li :-)
Program by m?l j?t ale p?eru?it a znova obnovit, nem?l by to b?t jeden velk?
cyklus, aby ?lo p?ech?zet mezi po??ta?i.
Jinak jak tu tak sleduju diskusi, tak velice chv?l?m va?e po?iny :-)
Ale? Janda
On 24.1.2010 10:58, Petr Dlouh? napsal/a:
zobrazit citaci
> To docela odpov?d?. J? m?m po??ta? je?t? pomalej??, jednoj?drov? a podle
> n?j jsem to odhadoval.
> Ka?dop?dn? je to pom?rn? dost, a cht?lo by to mo?n? zapojit i ty, kdo maj?
> dost procesorov?ho a m?lo osobn?ho ?asu.
>
> On Sun, 24 Jan 2010 10:53:38 +0100, Lukas Kabrt<lukas at kabrt.cz> wrote:
>
>> Jestli myslis cisteho vypocetniho casu, tak bych rekl, ze je to
>> pesimisticky odhad. Podle toho, jak rychle probiha vypocet u me, bych
>> to odhadnul na 30 - 50 dni. Limitujici je tady rychlost procesoru.
>> Nedavno jsem zkousel oblast cca 20 x 25 km a rozpoznavani bezelo neco
>> pres 5 hodin. Muj pocitac pritom neni zadne "delo" - Intel Core2 Duo @
>> 2Ghz.
>
>
Na OCR by pam?? nen? moc pot?eba. Klidn? to tam rozb?hnu.
On Sun, 24 Jan 2010 11:09:38 +0100, Kubajz <kubajz at kbx.cz> wrote:
zobrazit citaci
> Mam malo osobniho casu, ale jsem schopen pripravit virtualni masinu s
> debianem pro zajemce, ktery to uchodi. Je tam 2x2.8GHz XEON a 4GB
> pameti. Pokud by to pomohlo...
--
Petr Dlouh?
Pam?? nen? moc pot?eba, tak?e to stejn? potrv? kolem 20 dn?.
Klidn? to tam rozjedu, ale stejn? se to mus? rozd?lit do ?tverc? o ur?it?
rozloze.
On Sun, 24 Jan 2010 11:09:38 +0100, Kubajz <kubajz at kbx.cz> wrote:
zobrazit citaci
> Mam malo osobniho casu, ale jsem schopen pripravit virtualni masinu s
> debianem pro zajemce, ktery to uchodi. Je tam 2x2.8GHz XEON a 4GB
> pameti. Pokud by to pomohlo...
>
> K
>
> Dne 24.1.2010 10:58, Petr Dlouh? napsal(a):
>> To docela odpov?d?. J? m?m po??ta? je?t? pomalej??, jednoj?drov? a podle
>> n?j jsem to odhadoval.
>> Ka?dop?dn? je to pom?rn? dost, a cht?lo by to mo?n? zapojit i ty, kdo
>> maj?
>> dost procesorov?ho a m?lo osobn?ho ?asu.
>>
--
Petr Dlouh?
Nemysl?m si, ?e je to h??ek. Mluv? se o bezplatn?m p?evzet? od ?S?
(tedy, ?e nen? za to t?eba platit ?S?). Ale nikoli o tom, ?e by se
data nesm?la prod?vat (bezplatn?ch produktech, kde budou data pou?ita,
nekomer?n? ??ely apod.).
Honza
2010/1/24 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> H??ek je v tom "bezplatn?". U OSM nikdo nezakazuje, aby byla data
> prod?v?na. Je ot?zka, zdali se ale nejedn? o ??edn? d?lo - v tom p??pad?
> by si ?S? takov? podm?nky diktovat asi nemohl.
>
> On Sun, 24 Jan 2010 04:46:05 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
> wrote:
>
>>
>> "Ve?ker? ?daje na internetov?ch str?nk?ch ?S? si m??e kdokoliv p?evz?t
>> pro sv? ??ely bezplatn?, pouze s podm?nkou, ?e uvede jako zdroj ?S?.
>> Je doporu?ov?no uv?d?t i datum, kdy ?daje byly p?evzaty."
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
J? mysl?m, ?e hodn? ?asu ?ere spou?t?n? nov?ho procesu pro OCR. Pokud
lze OCRu p?edhodit obr?zek, kter? bude obsahovat v?ce text? (a pak
rozpoznat, co je co), nebo mu p?edhodit v?ce obr?zk? (v?cestr?nkov?
dokument), tak by to mohlo j?t rychleji. P?ecijen OCRka se b??n?
pou?ivaj? na ?ten? hust?ho textu na A4 a s rozpozn?n? trv? chvilku.
Honza
Dne 24. ledna 2010 10:53 Lukas Kabrt <lukas at kabrt.cz> napsal(a):
zobrazit citaci
>> Pardon, myslel jsem dn?.
>>
>> On Sun, 24 Jan 2010 08:46:16 +0100, Petr Dlouh? <petr.dlouhy at email.cz>
>> wrote:
>>
>>> (m? velmi hrub? odhady se pohybuj? od 50 do 100 hodin jenom pro 2. f?zi).
>
> Jestli myslis cisteho vypocetniho casu, tak bych rekl, ze je to
> pesimisticky odhad. Podle toho, jak rychle probiha vypocet u me, bych
> to odhadnul na 30 - 50 dni. Limitujici je tady rychlost procesoru.
> Nedavno jsem zkousel oblast cca 20 x 25 km a rozpoznavani bezelo neco
> pres 5 hodin. Muj pocitac pritom neni zadne "delo" - Intel Core2 Duo @
> 2Ghz.
>
> --
> Lukas
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Tady je .NET? wrapper nad DLL. Ale p??? tam, ?e Tesseract m? memory
leaky, tak?e to ?as o ?asu spadne. Ale n?jak? d?vky (v?ce popisk?
najednou) by to mohlo zvl?dnout.
http://www.pixel-technology.com/freeware/tessnet2/
Honza
2010/1/24 Jan Bilak <jan.bilak.osm at gmail.com>:
zobrazit citaci
> J? mysl?m, ?e hodn? ?asu ?ere spou?t?n? nov?ho procesu pro OCR. Pokud
> lze OCRu p?edhodit obr?zek, kter? bude obsahovat v?ce text? (a pak
> rozpoznat, co je co), nebo mu p?edhodit v?ce obr?zk? (v?cestr?nkov?
> dokument), tak by to mohlo j?t rychleji. P?ecijen OCRka se b??n?
> pou?ivaj? na ?ten? hust?ho textu na A4 a s rozpozn?n? trv? chvilku.
>
> Honza
>
>
> Dne 24. ledna 2010 10:53 Lukas Kabrt <lukas at kabrt.cz> napsal(a):
>>> Pardon, myslel jsem dn?.
>>>
>>> On Sun, 24 Jan 2010 08:46:16 +0100, Petr Dlouh? <petr.dlouhy at email.cz>
>>> wrote:
>>>
>>>> (m? velmi hrub? odhady se pohybuj? od 50 do 100 hodin jenom pro 2. f?zi).
>>
>> Jestli myslis cisteho vypocetniho casu, tak bych rekl, ze je to
>> pesimisticky odhad. Podle toho, jak rychle probiha vypocet u me, bych
>> to odhadnul na 30 - 50 dni. Limitujici je tady rychlost procesoru.
>> Nedavno jsem zkousel oblast cca 20 x 25 km a rozpoznavani bezelo neco
>> pres 5 hodin. Muj pocitac pritom neni zadne "delo" - Intel Core2 Duo @
>> 2Ghz.
>>
>> --
>> Lukas
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
Ahoj,
sta?? pou??t Dictionary, a u? to funguje rozum? rychle (i kdy? cel? ?R asi
je?t? ne - po minut? mi zabrala celou pam??).
Opravil jsem i p?dy p?i chyb?j?c?ch relac?ch, i kdy? oprava je dost
quick&dirty.
Pos?l?m zdroj?ky zm?n?n?ch soubor? i funk?n? program.
On Sun, 24 Jan 2010 10:37:08 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
>
> Problem to neni. Kdyz jsem program vytvarel, tak jsem nevedel o tom,
> ze existuje vektorizovana mapa k.u. a tak jsem k.u. kreslil rucne.
> Vzdycky jen par k.u., ktere jsem chtel zpracovat. Takze me rychlost
> zpracovani OSM souboru nejak netrapila. Na vektorizovanou mapu jsem
> narazil az kdyz jsem mel program hotovy a jeste jsem se nedostal k
> tomu ho predelat - dalsi polozka do TODO listu :-)
>
> Koukal jsem, ze by sla pouzit knihovna pro praci s OSM soubory z
> programu Kosmos [1], takze s tim nakonec asi ani nebude tolik prace.
>
> [1] http://wiki.openstreetmap.org/wiki/Kosmos
> --
> Lukas
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouh?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CUZK.MergeDBWithPoints1.tar.gz
Type: application/x-gzip
Size: 30465 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100124/8dd8ea8c/attachment.bin>
Ahoj,
sta?? pou??t Dictionary, a u? to funguje rozum? rychle (i kdy? cel? ?R asi
je?t? ne - po minut? mi zabrala celou pam??).
Opravil jsem i p?dy p?i chyb?j?c?ch relac?ch, i kdy? oprava je dost
quick&dirty.
Pos?l?m zdroj?ky zm?n?n?ch soubor? i funk?n? program.
On Sun, 24 Jan 2010 10:37:08 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
>
> Problem to neni. Kdyz jsem program vytvarel, tak jsem nevedel o tom,
> ze existuje vektorizovana mapa k.u. a tak jsem k.u. kreslil rucne.
> Vzdycky jen par k.u., ktere jsem chtel zpracovat. Takze me rychlost
> zpracovani OSM souboru nejak netrapila. Na vektorizovanou mapu jsem
> narazil az kdyz jsem mel program hotovy a jeste jsem se nedostal k
> tomu ho predelat - dalsi polozka do TODO listu :-)
>
> Koukal jsem, ze by sla pouzit knihovna pro praci s OSM soubory z
> programu Kosmos [1], takze s tim nakonec asi ani nebude tolik prace.
>
> [1] http://wiki.openstreetmap.org/wiki/Kosmos
> --
> Lukas
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouh?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CUZK.MergeDBWithPoints.tar.gz
Type: application/x-gzip
Size: 20594 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100124/d6bf63aa/attachment.bin>
zobrazit citaci
> Nemysl?m si, ?e je to h??ek. Mluv? se o bezplatn?m p?evzet? od ?S?
> (tedy, ?e nen? za to t?eba platit ?S?). Ale nikoli o tom, ?e by se
> data nesm?la prod?vat (bezplatn?ch produktech, kde budou data pou?ita,
> nekomer?n? ??ely apod.).
*** take to tak vnimam, zvlaste po rozhovorech s VUV TGM... Oni neco
jako open source neznaji a nemluvi k nemu.
hanoj
zobrazit citaci
> A ?S? m? mimo jin? na sv?ch str?nk?ch i mapy ... ale v?t?ina v?c? je
> tam stejn? s katastrem. Nap?.:
> http://apl.czso.cz/irso/mapa.jsp?budId=207400&obrprvId=184459
*** ty mapy jsou mashup. Velka cast se taha z CUZK!
hanoj
Dne Ne 24. ledna 2010 Petr Dlouh? napsal(a):
zobrazit citaci
> To docela odpov?d?. J? m?m po??ta? je?t? pomalej??, jednoj?drov? a podle
> n?j jsem to odhadoval.
> Ka?dop?dn? je to pom?rn? dost, a cht?lo by to mo?n? zapojit i ty, kdo maj?
> dost procesorov?ho a m?lo osobn?ho ?asu.
j? se taky hl?s?m, jestli je to je?t? aktu?ln? ... Core i5, bohu?el s KVM mi
qemu ?ve, ?e um? jen jeden procesor, a bez KVM je to neskute?n? pomal? ... ale
jestli se to d? rozumn? rozd?lit, klidn? si ty virtu?ln? ma?iny pust?m t?i :)
K.
OK, tak?e rozum? automaticky jdou ud?lat prvn? dva kroky - t?et? krok je taky mo?n?, ale jen pro ta ?zem?, kter? nen? nutn? manu?ln? rozd?lovat.
Cht?lo by to tedy ur?it rozum? velkou jednotu zpracov?n? - oblast jej?? zpracov?n? trv? zpracovat n?jak? rozumn? ?as (nap?. 1 hodinu).
D?le pak vytvo?it skripty, kter? budou volat ty programy. Klidn? takov? skript pro Linux vytvo??m, kdy? budu zn?t velikost jednotky.
Jinak to Qemu je kv?li bezpe?nosti? Ten program toti? jinak na Linuxu chod?.
zobrazit citaci
> ------------ P?vodn? zpr?va ------------
> Od: Karel Voln? <kavol at seznam.cz>
> P?edm?t: Re: [Talk-cz] Import adres z katastralni mapy
> Datum: 26.1.2010 10:50:35
> ----------------------------------------
> Dne Ne 24. ledna 2010 Petr Dlouh? napsal(a):
> > To docela odpov?d?. J? m?m po??ta? je?t? pomalej??, jednoj?drov? a podle
> > n?j jsem to odhadoval.
> > Ka?dop?dn? je to pom?rn? dost, a cht?lo by to mo?n? zapojit i ty, kdo maj?
> > dost procesorov?ho a m?lo osobn?ho ?asu.
>
> j? se taky hl?s?m, jestli je to je?t? aktu?ln? ... Core i5, bohu?el s KVM mi
> qemu ?ve, ?e um? jen jeden procesor, a bez KVM je to neskute?n? pomal? ... ale
> jestli se to d? rozumn? rozd?lit, klidn? si ty virtu?ln? ma?iny pust?m t?i :)
>
> K.
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
Petr Dlouh?
petr.dlouhy at email.cz
...
zobrazit citaci
> Jinak to Qemu je kv?li bezpe?nosti? Ten program toti? jinak na Linuxu
> chod?.
tak n?jak ... a kv?li pohodl?
s t?m, jak hladce nyn? virtualizace jde, jsem si n?jak navykl rozch?zet v?ci
na ?ist? instalaci (nap?. pokud si nebudu cht?t nab?t hubu jako o V?noc?ch s
OTM, nen? nic jednodu???ho ne? nahodit virtualizovan? Ubuntu nebo na ?em autor
postup vyladil, zat?mco na desktopu mi d?l bude spokojen? chroupat Gentoo);
nav?c jde-li o n?co, co trv? d?le a nelze p?eru?it, nen? t?eba m?t re?ln?
stroj po??d online, virtu?ln? se d? v mezi?ase zmrazit
K.
On Thu 2010-01-21 16:50:15, Lukas Kabrt wrote:
zobrazit citaci
> Tak jsem trochu zapracoval na mape katastralnich uzemi, aby se k.u.
> nemuseli kreslit rucne.
>
> Vektorizovanou mapu k.u. od hanoje [1] jsem zacistil (slouceni
> duplicitnich bodu, odtraneni fragmentu po vektorizaci, pospojovani
> prerusenych linii) a vytvoril na ni relace pro jednotliva k.u.
>
> Mapu jsem dal dohromady s daty co mi poslal Martin Kupec (nazvy
> katastralnich uzemi a jejich poloha). Vysledek je ke stazeni tady [2].
>
> Trocha statistiky:
> CR ma 13027 k.u.
> Martin mi poslal data pro 12171 k.u.
> Mapa ma definovano 13028 relaci
>
> Mapa je jenom prozatmni, pri prirazeni se vyskytly nejake chyby (vic
> nazvu pro jedno k.u., jedna se ale o jednotky, max. desitky pripadu)
> To bych resil az budou hotova data pro vsechy k.u. Stejne tak je v
> mape 1 relace navic - pravdepodobne nekde zustal nejaky fragment, ten
> se taky objevi, az se priradi vsechny nazvy.
>
> Pokud se nekdo pousti do importu adres, tak mu tohle snad usetri trochu casu.
>
> [1] http://osm.templ.net/kucr.osm.bz2
> [2] http://lkabrt.aspone.cz/osm/kucr.zip
Jaky je dalsi plan? Upload do osm? Nebo se jeste budou nejak cistit?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
?ti d?l:
http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004354.html
zobrazit citaci
> ------------ P?vodn? zpr?va ------------
> Od: Pavel Machek <pavel at ucw.cz>
> P?edm?t: Re: [Talk-cz] Import adres z katastralni mapy
> Datum: 26.1.2010 14:58:51
> ----------------------------------------
> On Thu 2010-01-21 16:50:15, Lukas Kabrt wrote:
> > Tak jsem trochu zapracoval na mape katastralnich uzemi, aby se k.u.
> > nemuseli kreslit rucne.
> >
> > Vektorizovanou mapu k.u. od hanoje [1] jsem zacistil (slouceni
> > duplicitnich bodu, odtraneni fragmentu po vektorizaci, pospojovani
> > prerusenych linii) a vytvoril na ni relace pro jednotliva k.u.
> >
> > Mapu jsem dal dohromady s daty co mi poslal Martin Kupec (nazvy
> > katastralnich uzemi a jejich poloha). Vysledek je ke stazeni tady [2].
> >
> > Trocha statistiky:
> > CR ma 13027 k.u.
> > Martin mi poslal data pro 12171 k.u.
> > Mapa ma definovano 13028 relaci
> >
> > Mapa je jenom prozatmni, pri prirazeni se vyskytly nejake chyby (vic
> > nazvu pro jedno k.u., jedna se ale o jednotky, max. desitky pripadu)
> > To bych resil az budou hotova data pro vsechy k.u. Stejne tak je v
> > mape 1 relace navic - pravdepodobne nekde zustal nejaky fragment, ten
> > se taky objevi, az se priradi vsechny nazvy.
> >
> > Pokud se nekdo pousti do importu adres, tak mu tohle snad usetri trochu casu.
> >
> > [1] http://osm.templ.net/kucr.osm.bz2
> > [2] http://lkabrt.aspone.cz/osm/kucr.zip
>
> Jaky je dalsi plan? Upload do osm? Nebo se jeste budou nejak cistit?
>
> Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
Petr Dlouh?
petr.dlouhy at email.cz
Provedl jsem par zmen v programu tile-processor, binarky [1] i
zdrojove kody [2] muzete stahovat z mych stranek.
Hlavni zmeny:
rychlost - OCR utitlita se ted spousti pouze jednou pro kazdou
dlazdici - prineslo to cca dvojnasobnou rychlost zpracovani
drobne zvyseni presnosti - presnejsi orez popisku a vynechani budov
blizko praveho okraje (tak jak navrhoval Petr Dlouhy)
pridano logovani cinnosti
osetreni chyb - program by se ted mel byt schopny zotavit z vetsiny
chyb, pouze zaloguje co se stalo a pokracuje v cinnosti
V binarkach jsou dve verze tile processoru - jedna pro LINUX s upravou
od Petra Dlouheho ([3], bod 2), druha bez ni. Nechal jsem dve verze,
protoze u me verze s upravou dava o neco horsi vysledky pri OCR (cca o
1 - 2% vice chyb)
Progam jsem zkousel na platforme Win/.NET a Win/MONO a funguji bez
problemu. Nekoho bych poprosil aby vyzkousel jestli neni nejaky
problem na Linuxu.
Distribuovane pocitani
Diky vsem, kteri se ozvali a nabidli se, ze pomuzou s vypoctem.
Rozdelil jsem CR na dlazdice 0.2 x 0.2 stupne, celkem je to 302
dlazdic. Hranice jsou definovany v CSV souboru [4], prilozena je i
prehledova mapka. Zpracovani jedne dlazdice by se melo vejit do 1
hodiny.
CSV soubor ma nasledujici format
ID,sever,vychod,jih,zapad
Pro koordinaci jsem na wiki zalozil stranku [5]. Pokud se rozhodnete
pomoct, zapiste na wiki, jake dlazdice zpracujete - at se neco
nepocita vicekrat. Dlazdice prosim vybirejte postupne, at v tom neni
zmatek.
Moje idea dalsiho postupu je takova, ze vysledky vypoctu (CSV a LOG
soubory) zpracuju, pripadne opravim data na mistech, kde se vyskytnul
nejaky error a vysledek umistim nekde na web k dalsimu vyuziti pro
import adres.
Postup
1) na wiki napsat dlazdice, ktere se chystam zpracovat
2) ze souboru [4] zjistit hranice dlazdic
3) stahnout data z WMS CUZK
tile-downloader.exe -north [sever] -west [zapad] -south [jih] -east
[vychos] -addressPoints -output [ID-Dlazdice]
4) zpracovat dlazdici
tile-processor.exe -tiles [ID-Dlazdice] - output [ID-Dlazdice].csv
5) zabalit vytvorene soubory (CSV a LOG) a vysledek nekam uplodovat
nebo zaslat na mail osm at kabrt.cz
[1] http://lkabrt.aspone.cz/osm/cuzk.zip
[2] http://lkabrt.aspone.cz/osm/cuzk-source.zip
[3] http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004312.html
[4] http://lkabrt.aspone.cz/osm/oblasti.zip
[5] http://wiki.openstreetmap.org/wiki/Import_Adres_?R/Prubeh_Zpracovani
--
Lukas
Ahoj,
nebylo by lep?? ukl?dat a p?ibalit potom k v?sledku i kousky mapy s
t?mi ??sly? Zrychlila by se ru?n? kontrola, zda to OCR rozpoznal
spr?vn?. Aneb bylo by mo?n? pak jednodu?e t?eba zobrazit ??slo v
textov? podob? a vedle ??slo v obr?zkov? podob?. A stejn? u? se to
stahuje, o?ez?v?, ... jen to ukl?dat.
Honza
2010/1/26 Lukas Kabrt <lukas at kabrt.cz>:
zobrazit citaci
> Provedl jsem par zmen v programu tile-processor, binarky [1] i
> zdrojove kody [2] muzete stahovat z mych stranek.
>
> Hlavni zmeny:
> rychlost - OCR utitlita se ted spousti pouze jednou pro kazdou
> dlazdici - prineslo to cca dvojnasobnou rychlost zpracovani
> drobne zvyseni presnosti - presnejsi orez popisku a vynechani budov
> blizko praveho okraje (tak jak navrhoval Petr Dlouhy)
> pridano logovani cinnosti
> osetreni chyb - program by se ted mel byt schopny zotavit z vetsiny
> chyb, pouze zaloguje co se stalo a pokracuje v cinnosti
>
> V binarkach jsou dve verze tile processoru - jedna pro LINUX s upravou
> od Petra Dlouheho ([3], bod 2), druha bez ni. Nechal jsem dve verze,
> protoze u me verze s upravou dava o neco horsi vysledky pri OCR (cca o
> 1 - 2% vice chyb)
>
> Progam jsem zkousel na platforme Win/.NET a Win/MONO a funguji bez
> problemu. Nekoho bych poprosil aby vyzkousel jestli neni nejaky
> problem na Linuxu.
>
>
> Distribuovane pocitani
> Diky vsem, kteri se ozvali a nabidli se, ze pomuzou s vypoctem.
>
> Rozdelil jsem CR na dlazdice 0.2 x 0.2 stupne, celkem je to 302
> dlazdic. Hranice jsou definovany v CSV souboru [4], prilozena je i
> prehledova mapka. Zpracovani jedne dlazdice by se melo vejit do 1
> hodiny.
>
> CSV soubor ma nasledujici format
> ID,sever,vychod,jih,zapad
>
> Pro koordinaci jsem na wiki zalozil stranku [5]. Pokud se rozhodnete
> pomoct, zapiste na wiki, jake dlazdice zpracujete - at se neco
> nepocita vicekrat. Dlazdice prosim vybirejte postupne, at v tom neni
> zmatek.
>
> Moje idea dalsiho postupu je takova, ze vysledky vypoctu (CSV a LOG
> soubory) zpracuju, pripadne opravim data na mistech, kde se vyskytnul
> nejaky error a vysledek umistim nekde na web k dalsimu vyuziti pro
> import adres.
>
> Postup
> 1) na wiki napsat dlazdice, ktere se chystam zpracovat
> 2) ze souboru [4] zjistit hranice dlazdic
> 3) stahnout data z WMS CUZK
>
> tile-downloader.exe -north [sever] -west [zapad] -south [jih] -east
> [vychos] -addressPoints -output [ID-Dlazdice]
>
> 4) zpracovat dlazdici
>
> tile-processor.exe -tiles [ID-Dlazdice] - output [ID-Dlazdice].csv
>
> 5) zabalit vytvorene soubory (CSV a LOG) a vysledek nekam uplodovat
> nebo zaslat na mail osm at kabrt.cz
>
> [1] http://lkabrt.aspone.cz/osm/cuzk.zip
> [2] http://lkabrt.aspone.cz/osm/cuzk-source.zip
> [3] http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004312.html
> [4] http://lkabrt.aspone.cz/osm/oblasti.zip
> [5] http://wiki.openstreetmap.org/wiki/Import_Adres_?R/Prubeh_Zpracovani
> --
> Lukas
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
D?ky za synchronizaci postupu.
On Tue, 26 Jan 2010 20:10:09 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
Tomu moc nerozum?m, m?j postup byl takov?, ?e jsem vy??znul z dla?dice
??slo (co? by m?la b?t bezestr?tov? konverze) a potom jsem to zv?t?il (co?
by m?la b?t stejn? konverze jako p?edt?m. Postup by mohl b?t nepatrn?
n?ro?n?j?? na v?po?etn? v?kon, ale v?sledek by snad m?l b?t stejn?, ne?
Leda ?e by tam do?lo k n?jak? ztr?t? p?i p?evodu mezi r?zn?mi po?ty barev
- to by ?lo asi eliminovat.
zobrazit citaci
> V binarkach jsou dve verze tile processoru - jedna pro LINUX s upravou
> od Petra Dlouheho ([3], bod 2), druha bez ni. Nechal jsem dve verze,
> protoze u me verze s upravou dava o neco horsi vysledky pri OCR (cca o
> 1 - 2% vice chyb)
Bohu?el Mono pro Win narozd?l od Mona pro Linux pou??v? nativn? Windowsov?
knihovny (Mono pro Linux pou??v? m?sto nich knihovny Mona), tak?e se
v?sledek m??e li?it. A? se k tomu dostanu, tak to vyzkou??m.
zobrazit citaci
> Progam jsem zkousel na platforme Win/.NET a Win/MONO a funguji bez
> problemu. Nekoho bych poprosil aby vyzkousel jestli neni nejaky
> problem na Linuxu.
--
Petr Dlouh?
zobrazit citaci
> Tomu moc nerozum?m, m?j postup byl takov?, ?e jsem vy??znul z dla?dice
> ??slo (co? by m?la b?t bezestr?tov? konverze) a potom jsem to zv?t?il (co?
> by m?la b?t stejn? konverze jako p?edt?m. Postup by mohl b?t nepatrn?
> n?ro?n?j?? na v?po?etn? v?kon, ale v?sledek by snad m?l b?t stejn?, ne?
> Leda ?e by tam do?lo k n?jak? ztr?t? p?i p?evodu mezi r?zn?mi po?ty barev
> - to by ?lo asi eliminovat.
To mas pravdu, asi jsem blbe identifikoval pricinu. Pravy duvod je asi
ten, ze ty jsi vyrezy zvetsoval 3x a ja jen 2x. Tesseract si to potom
pravdepodobne prebere trochu jinak. Pravdou je, ze obcas lepe
zafunguje ta upravena verze. Kdyz to porovnam u nejakeho vetsiho
souboru dat, tak to vychazi priblezne 1 az 2% v neprospech upravene
verze.
--
Lukas
zobrazit citaci
> nebylo by lep?? ukl?dat a p?ibalit potom k v?sledku i kousky mapy s
> t?mi ??sly? Zrychlila by se ru?n? kontrola, zda to OCR rozpoznal
> spr?vn?. Aneb bylo by mo?n? pak jednodu?e t?eba zobrazit ??slo v
> textov? podob? a vedle ??slo v obr?zkov? podob?. A stejn? u? se to
> stahuje, o?ez?v?, ... jen to ukl?dat.
Technicky to neni zadny problem, ale moc se mi to nelibi
1) Je to spousta dat
2) Kontorlovat se to da dobre v JOSM (nebo v jinem editoru), vcetne
doplneni prislusnych addr tagu
3) Stejne vetsina spatne rozpoznanych popisku jsou budovy bez
c.p./c.e., jako treba garaze nahustene vedle sebe - v editoru pak
jednim pohledem a par kliknutima vyresim treba 30 spatne rozpoznanych
napisu najednou
--
Lukas
Ok, kdy? jsi schopn? to kontrolovat v JOSM, tak nen? probl?m. Ale
nezapome?, ?e toho bude spousta.
Honza
2010/1/26 Lukas Kabrt <lukas at kabrt.cz>:
zobrazit citaci
>> nebylo by lep?? ukl?dat a p?ibalit potom k v?sledku i kousky mapy s
>> t?mi ??sly? Zrychlila by se ru?n? kontrola, zda to OCR rozpoznal
>> spr?vn?. Aneb bylo by mo?n? pak jednodu?e t?eba zobrazit ??slo v
>> textov? podob? a vedle ??slo v obr?zkov? podob?. A stejn? u? se to
>> stahuje, o?ez?v?, ... jen to ukl?dat.
>
> Technicky to neni zadny problem, ale moc se mi to nelibi
> 1) Je to spousta dat
> 2) Kontorlovat se to da dobre v JOSM (nebo v jinem editoru), vcetne
> doplneni prislusnych addr tagu
> 3) Stejne vetsina spatne rozpoznanych popisku jsou budovy bez
> c.p./c.e., jako treba garaze nahustene vedle sebe - v editoru pak
> jednim pohledem a par kliknutima vyresim treba 30 spatne rozpoznanych
> napisu najednou
>
> --
> Lukas
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
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? :)
2010/1/26 Jiri Parkan <jparkan at gmail.com>:
zobrazit citaci
> P?i zkusm?m zpracov?n? oblasti 4 se zd? ?e mi n?jak nefunguje
> rozpozn?v?n?. V?sledn? csv je pr?zdn? a v logu errory podobn? tomuto:
>
> [ERROR] Tile: 4\14.8270_50.8700_14.8320_50.8750-budovy.png ? ? ?Could not
> find file 'E:\cuzk\5d8577a6-a71a-454b-9785-354a446ef9d5.tif.txt'.;
>
> p?itom sta?en? obr?zky jsou v po??dku, tile processor se tv??? ?e tak?
> n?co d?l?:
>
> Performing OCR (25 labels): .Processing tile:
> 15.0250_51.0185_15.0300_51.0235-budovy ? ?..
> Performing OCR (4 labels): .Processing tile:
> 15.0250_51.0230_15.0300_51.0280-budovy ? ? .
> Processing tile: 15.0250_51.0275_15.0300_51.0325-budovy
To vypada, ze nefunguje OCR utilita, muzes vyzkouset spustit rucne?
"tesseract jmeno_jednoho_z_tech_tifu output.txt -l cuzk"
--
Lukas
Jo, je?t? jsem ud?lal jednu zm?nu v merge skriptu. ?asto se stalo, ?e p?i
OCR eviden?n?ch ??sel to vynechalo ob? te?ky, tak?e by merge m?l rozpoznat
i "?e70".
On Tue, 26 Jan 2010 22:40:31 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
> To mas pravdu, asi jsem blbe identifikoval pricinu. Pravy duvod je asi
> ten, ze ty jsi vyrezy zvetsoval 3x a ja jen 2x. Tesseract si to potom
> pravdepodobne prebere trochu jinak. Pravdou je, ze obcas lepe
> zafunguje ta upravena verze. Kdyz to porovnam u nejakeho vetsiho
> souboru dat, tak to vychazi priblezne 1 az 2% v neprospech upravene
--
Petr Dlouh?
Sypu si popel na hlavu, n?jak jsem opomn?l rozbalit adres?? testdata.
Te? u? v?e funguje jak m?, z?tra snad dod?m n?jak? v?sledky.
2010/1/26 Lukas Kabrt <lukas at kabrt.cz>:
zobrazit citaci
> 2010/1/26 Jiri Parkan <jparkan at gmail.com>:
>> P?i zkusm?m zpracov?n? oblasti 4 se zd? ?e mi n?jak nefunguje
>> rozpozn?v?n?. V?sledn? csv je pr?zdn? a v logu errory podobn? tomuto:
>>
>> [ERROR] Tile: 4\14.8270_50.8700_14.8320_50.8750-budovy.png ? ? ?Could not
>> find file 'E:\cuzk\5d8577a6-a71a-454b-9785-354a446ef9d5.tif.txt'.;
>>
>> p?itom sta?en? obr?zky jsou v po??dku, tile processor se tv??? ?e tak?
>> n?co d?l?:
>>
>> Performing OCR (25 labels): .Processing tile:
>> 15.0250_51.0185_15.0300_51.0235-budovy ? ?..
>> Performing OCR (4 labels): .Processing tile:
>> 15.0250_51.0230_15.0300_51.0280-budovy ? ? .
>> Processing tile: 15.0250_51.0275_15.0300_51.0325-budovy
>
> To vypada, ze nefunguje OCR utilita, muzes vyzkouset spustit rucne?
>
> "tesseract jmeno_jednoho_z_tech_tifu output.txt -l cuzk"
> --
> Lukas
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Pro potreby komunity jsem dnes predal pristup Petrovi Dlouhemu na server
s 4 x 3.4GHz Xeon s 4GB pameti. Doufam, ze to pomuze k rychlejsimu
vyreseni nasich potreb :)
K
P.S.: Presneji jsou to jen dve dvoujadra
Kubajz napsal(a):
zobrazit citaci
> Mam malo osobniho casu, ale jsem schopen pripravit virtualni masinu s
> debianem pro zajemce, ktery to uchodi. Je tam 2x2.8GHz XEON a 4GB
> pameti. Pokud by to pomohlo...
>
> K
>
> Dne 24.1.2010 10:58, Petr Dlouh? napsal(a):
>
>> To docela odpov?d?. J? m?m po??ta? je?t? pomalej??, jednoj?drov? a podle
>> n?j jsem to odhadoval.
>> Ka?dop?dn? je to pom?rn? dost, a cht?lo by to mo?n? zapojit i ty, kdo maj?
>> dost procesorov?ho a m?lo osobn?ho ?asu.
>>
>> On Sun, 24 Jan 2010 10:53:38 +0100, Lukas Kabrt<lukas at kabrt.cz> wrote:
>>
>>
>>
>>> Jestli myslis cisteho vypocetniho casu, tak bych rekl, ze je to
>>> pesimisticky odhad. Podle toho, jak rychle probiha vypocet u me, bych
>>> to odhadnul na 30 - 50 dni. Limitujici je tady rychlost procesoru.
>>> Nedavno jsem zkousel oblast cca 20 x 25 km a rozpoznavani bezelo neco
>>> pres 5 hodin. Muj pocitac pritom neni zadne "delo" - Intel Core2 Duo @
>>> 2Ghz.
>>>
>>>
>>
>>
>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Dovolil bych si je?t? jednu pozn?mku. Program si ukl?d? pomocn? soubory do
aktu?ln?ho adres??e s konstantn?m jm?nem (pokud se od minul? verze nic
nezm?nilo). Jestli tomu dob?e rozum?m, tak nemohu spustit v?c instanc?
t?ch skript? v jednom adres??i bez toho, aby se nepopraly (budou si
OCRkovat ??sla navz?jem).
Je to tak? Pokud ano, tak by to cht?lo u?ivatele d?razn? varovat, proto?e
by se mohlo st?t, ?e v?sledek bude pom?chan? a nikdo si toho nev?imne.
Ne?lo by s t?m n?co ud?lat?
On Tue, 26 Jan 2010 20:10:09 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
> Provedl jsem par zmen v programu tile-processor, binarky [1] i
> zdrojove kody [2] muzete stahovat z mych stranek.
>
> Hlavni zmeny:
> rychlost - OCR utitlita se ted spousti pouze jednou pro kazdou
> dlazdici - prineslo to cca dvojnasobnou rychlost zpracovani
> drobne zvyseni presnosti - presnejsi orez popisku a vynechani budov
> blizko praveho okraje (tak jak navrhoval Petr Dlouhy)
> pridano logovani cinnosti
> osetreni chyb - program by se ted mel byt schopny zotavit z vetsiny
> chyb, pouze zaloguje co se stalo a pokracuje v cinnosti
>
> V binarkach jsou dve verze tile processoru - jedna pro LINUX s upravou
> od Petra Dlouheho ([3], bod 2), druha bez ni. Nechal jsem dve verze,
> protoze u me verze s upravou dava o neco horsi vysledky pri OCR (cca o
> 1 - 2% vice chyb)
>
> Progam jsem zkousel na platforme Win/.NET a Win/MONO a funguji bez
> problemu. Nekoho bych poprosil aby vyzkousel jestli neni nejaky
> problem na Linuxu.
>
>
> Distribuovane pocitani
> Diky vsem, kteri se ozvali a nabidli se, ze pomuzou s vypoctem.
>
> Rozdelil jsem CR na dlazdice 0.2 x 0.2 stupne, celkem je to 302
> dlazdic. Hranice jsou definovany v CSV souboru [4], prilozena je i
> prehledova mapka. Zpracovani jedne dlazdice by se melo vejit do 1
> hodiny.
>
> CSV soubor ma nasledujici format
> ID,sever,vychod,jih,zapad
>
> Pro koordinaci jsem na wiki zalozil stranku [5]. Pokud se rozhodnete
> pomoct, zapiste na wiki, jake dlazdice zpracujete - at se neco
> nepocita vicekrat. Dlazdice prosim vybirejte postupne, at v tom neni
> zmatek.
>
> Moje idea dalsiho postupu je takova, ze vysledky vypoctu (CSV a LOG
> soubory) zpracuju, pripadne opravim data na mistech, kde se vyskytnul
> nejaky error a vysledek umistim nekde na web k dalsimu vyuziti pro
> import adres.
>
> Postup
> 1) na wiki napsat dlazdice, ktere se chystam zpracovat
> 2) ze souboru [4] zjistit hranice dlazdic
> 3) stahnout data z WMS CUZK
>
> tile-downloader.exe -north [sever] -west [zapad] -south [jih] -east
> [vychos] -addressPoints -output [ID-Dlazdice]
>
> 4) zpracovat dlazdici
>
> tile-processor.exe -tiles [ID-Dlazdice] - output [ID-Dlazdice].csv
>
> 5) zabalit vytvorene soubory (CSV a LOG) a vysledek nekam uplodovat
> nebo zaslat na mail osm at kabrt.cz
>
> [1] http://lkabrt.aspone.cz/osm/cuzk.zip
> [2] http://lkabrt.aspone.cz/osm/cuzk-source.zip
> [3]
> http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004312.html
> [4] http://lkabrt.aspone.cz/osm/oblasti.zip
> [5] http://wiki.openstreetmap.org/wiki/Import_Adres_?R/Prubeh_Zpracovani
> --
> Lukas
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouh?
zobrazit citaci
> Je to tak? Pokud ano, tak by to cht?lo u?ivatele d?razn? varovat, proto?e
> by se mohlo st?t, ?e v?sledek bude pom?chan? a nikdo si toho nev?imne.
> Ne?lo by s t?m n?co ud?lat?
Ne, uz to tak neni, jen jsem to zapomnel zapsat do provedenych zmen.
Program si uklada pomocne soubory stale do aktualniho adresare, ale
pod unikatnim jmenem (GUID), takze bez problemu muze bezet vice
instanci v jednom adresari.
--
Lukas
Ahoj,
tak v?po?et u? zat??uje v?echna 4 j?dra na Kubajzov? stroji.
Ud?lal jsem si na to skripty, kter?m sta?? jen p?edhodit rozsah dla?dic, a
ony pak u? v?e ud?laj? samy. Nejsou n?jak ??asn?, ale mohlo by to n?komu
u?et?it pr?ci, tak?e jsou v p??loze.
--
Petr Dlouh?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tile-do.sh
Type: application/octet-stream
Size: 502 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100127/d74ee818/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tile-more.sh
Type: application/octet-stream
Size: 57 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100127/d74ee818/attachment-0001.obj>
Hm, tak bohu?el program na Linuxu nefunguje (tedy pod Wine ano).
D?vodem je neimplementovan? metoda System.Drawing.Image.SaveAdd v Linuxov?
verzi knihovny GDI+.
M? n?kdo n?pad, jak by to ?lo jednodu?e obej?t?
On Tue, 26 Jan 2010 20:10:09 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
> Progam jsem zkousel na platforme Win/.NET a Win/MONO a funguji bez
> problemu. Nekoho bych poprosil aby vyzkousel jestli neni nejaky
> problem na Linuxu.
--
Petr Dlouh?
Nem?m zku?enost ... ale nepomohlo by t?eba toto?
http://www.remotesensing.org/libtiff/man/tiffcp.1.html
Honza
2010/1/27 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Hm, tak bohu?el program na Linuxu nefunguje (tedy pod Wine ano).
> D?vodem je neimplementovan? metoda System.Drawing.Image.SaveAdd v Linuxov?
> verzi knihovny GDI+.
> M? n?kdo n?pad, jak by to ?lo jednodu?e obej?t?
>
> On Tue, 26 Jan 2010 20:10:09 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
>
>> Progam jsem zkousel na platforme Win/.NET a Win/MONO a funguji bez
>> problemu. Nekoho bych poprosil aby vyzkousel jestli neni nejaky
>> problem na Linuxu.
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
2010/1/27 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> M? n?kdo n?pad, jak by to ?lo jednodu?e obej?t?
Vyzkousel jsem pouziti tiffcp jak navrhoval Jan Bilak. Na WIN mi to
funguje bez problemu. Stahovat muzete opet z mych stranek [1]. Je to o
neco pomalejsi, nez kdyz mutli-page tiff vytvarim primo v
tile-processor, ale pokud to bude fungovat na LINUXU, tak je to
prijatelna obet. Porad je to totiz rychlejsi, nez puvodni verze.
[1] http://lkabrt.aspone.cz/osm/cuzk-test.zip
--
Lukas
Ahoj,
d?ky - vypad? to, ?e to funguje (tedy musel jsem updatovat tesseract z
verze 2.03 na 2.04).
On Fri, 29 Jan 2010 17:28:48 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
> 2010/1/27 Petr Dlouh? <petr.dlouhy at email.cz>:
>> M? n?kdo n?pad, jak by to ?lo jednodu?e obej?t?
>
> Vyzkousel jsem pouziti tiffcp jak navrhoval Jan Bilak. Na WIN mi to
> funguje bez problemu. Stahovat muzete opet z mych stranek [1]. Je to o
> neco pomalejsi, nez kdyz mutli-page tiff vytvarim primo v
> tile-processor, ale pokud to bude fungovat na LINUXU, tak je to
> prijatelna obet. Porad je to totiz rychlejsi, nez puvodni verze.
>
> [1] http://lkabrt.aspone.cz/osm/cuzk-test.zip
> --
> Lukas
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouh?
On Tue, Jan 26, 2010 at 08:10:09PM +0100, Lukas Kabrt wrote:
zobrazit citaci
> Moje idea dalsiho postupu je takova, ze vysledky vypoctu (CSV a LOG
> soubory) zpracuju, pripadne opravim data na mistech, kde se vyskytnul
> nejaky error a vysledek umistim nekde na web k dalsimu vyuziti pro
> import adres.
uz jsem skoro dopracoval svoje davky, ale nastal maly problem.
v tech cca 80 tile je cca 850 erroru v logach. Mam to nejak
resit, nebo uz si je zkusis udelat znova sam?
Vypada to ze tesseract sem tam nejak spadl nebo neco takoveho
provedl.
Az dodelam poslednich par tilu, tak to cele nejak uploadtnu a na
wiki dam odkaz.
Martin Kupec
zobrazit citaci
> ? ? ? ?uz jsem skoro dopracoval svoje davky, ale nastal maly problem.
>
> ? ? ? ?v tech cca 80 tile je cca 850 erroru v logach. Mam to nejak
> ? ? ? ?resit, nebo uz si je zkusis udelat znova sam?
>
> ? ? ? ?Vypada to ze tesseract sem tam nejak spadl nebo neco takoveho
> ? ? ? ?provedl.
Resit to nijak nemusis, uz jsem si napsal skriptik, ktery projde logy
a mista kde se vyskytnul error zpracuje znova.
--
Lukas
On Tue, Feb 02, 2010 at 10:04:40AM +0100, Lukas Kabrt wrote:
zobrazit citaci
> > ? ? ? ?uz jsem skoro dopracoval svoje davky, ale nastal maly problem.
> >
> > ? ? ? ?v tech cca 80 tile je cca 850 erroru v logach. Mam to nejak
> > ? ? ? ?resit, nebo uz si je zkusis udelat znova sam?
> >
> > ? ? ? ?Vypada to ze tesseract sem tam nejak spadl nebo neco takoveho
> > ? ? ? ?provedl.
>
> Resit to nijak nemusis, uz jsem si napsal skriptik, ktery projde logy
> a mista kde se vyskytnul error zpracuje znova.
Ok super. Asi nejsem sam kdo sem tam ma chybu. Uvazoval jsem
jestli neco takoveho nezbastlit, ale pak me napadlo ze uz to
mozna nekdo udelal.
Moje vysledky poslu nekdky k veceru. Jeste to zpracovava 3 tily,
tak to necham dobehnout a vecer to uploaduju.
Martin
Ahoj,
p?em??lel jsem o tom, jestli by ne?el vyrobit i skript, co projde v?echny adresn? body, kter? nevyhovuj? vzoru ?.e./?.p./bez ?.e./?.p a zpracoval je znovu s vy???m rozli?en?m.
zobrazit citaci
> ------------ P?vodn? zpr?va ------------
> Od: Lukas Kabrt <lukas at kabrt.cz>
> P?edm?t: Re: [Talk-cz] Import adres z katastralni mapy
> Datum: 02.2.2010 10:05:16
> ----------------------------------------
> > ? ? ? ?uz jsem skoro dopracoval svoje davky, ale nastal maly problem.
> >
> > ? ? ? ?v tech cca 80 tile je cca 850 erroru v logach. Mam to nejak
> > ? ? ? ?resit, nebo uz si je zkusis udelat znova sam?
> >
> > ? ? ? ?Vypada to ze tesseract sem tam nejak spadl nebo neco takoveho
> > ? ? ? ?provedl.
>
> Resit to nijak nemusis, uz jsem si napsal skriptik, ktery projde logy
> a mista kde se vyskytnul error zpracuje znova.
> --
> Lukas
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
Petr Dlouh?
petr.dlouhy at email.cz
zobrazit citaci
> p?em??lel jsem o tom, jestli by ne?el vyrobit i skript, co projde v?echny adresn? body, kter? nevyhovuj? vzoru ?.e./?.p./bez ?.e./?.p a zpracoval je znovu s vy???m rozli?en?m.
Koukal jsem kolika pripadu by se to tykalo a pokud za spravne
rozpoznane budeme povazovat i ruzne varianty (ce, c.e, ce., apod.) tak
to odhaduju na cca 200 000 pripadu. To by se asi dalo zvladnout.
Schvalne zkusim neco vytvorit ...
--
Lukas
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
No ja jsem se vcera od kamarada dozvedel, ze v dohledne dobe dostaneme
ctyrXeon s 30GB pameti. Takze az zase nekdo vymysli nejakou takovouhle
ptakovinu, tak procesoru bude dost :)
K
Dne 2.2.2010 22:52, Martin Kupec napsal(a):
zobrazit citaci
> Tak jsem uploadoval na server vysledky, odkaz je na wiki ([1]).
>
> Nevim jak je to se zpracovanim zbylych tilu, ale kdyz mi nekdo neco
> uvolni, tak to klidne jeste spocitam :-). Zjistil jsem ze ten stoj co
> jsem na to zneuzil se nejak moc zbytecne flaka...
>
> [1] http://wiki.openstreetmap.org/wiki/Import_Adres_?R/Prubeh_Zpracovani
>
> Martin Kupec
>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Ahoj,
m??e? kdy?tak ud?lat 10 - 49 a 60 - 69 je?t? jednou? J? to d?lal je?t? se
starou verz? tile-processoru, tak?e chyb? logy.
On Tue, 02 Feb 2010 22:52:06 +0100, Martin Kupec <magon at jkopava.cz> wrote:
zobrazit citaci
> Tak jsem uploadoval na server vysledky, odkaz je na wiki ([1]).
>
> Nevim jak je to se zpracovanim zbylych tilu, ale kdyz mi nekdo neco
> uvolni, tak to klidne jeste spocitam :-). Zjistil jsem ze ten stoj co
> jsem na to zneuzil se nejak moc zbytecne flaka...
>
> [1] http://wiki.openstreetmap.org/wiki/Import_Adres_?R/Prubeh_Zpracovani
>
> Martin Kupec
>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouh?
On Wed, Feb 03, 2010 at 07:39:02AM +0100, Petr Dlouh? wrote:
zobrazit citaci
> Ahoj,
>
> m??e? kdy?tak ud?lat 10 - 49 a 60 - 69 je?t? jednou? J? to d?lal je?t? se
> starou verz? tile-processoru, tak?e chyb? logy.
Ok, pracuje se na tom.
Martin
Ahoj,
tak na Kubajzov? stroji je (po krat?? odst?vce) u? taky v?e spo??tan? a
uploadovan?.
On Tue, 02 Feb 2010 22:52:06 +0100, Martin Kupec <magon at jkopava.cz> wrote:
zobrazit citaci
> Tak jsem uploadoval na server vysledky, odkaz je na wiki ([1]).
>
> Nevim jak je to se zpracovanim zbylych tilu, ale kdyz mi nekdo neco
> uvolni, tak to klidne jeste spocitam :-). Zjistil jsem ze ten stoj co
> jsem na to zneuzil se nejak moc zbytecne flaka...
>
> [1] http://wiki.openstreetmap.org/wiki/Import_Adres_?R/Prubeh_Zpracovani
>
> Martin Kupec
>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouh?
Ahoj,
za?al jsem s imortem adresn?ch bod? v Praze-z?pad, ale zjistil jsem jeden
celkem z?sadn? probl?m.
Zd? se, ?e eviden?n? ??sla jsou o n?co bl?? k te?ce ne? ta popisn? -
d?sledkem je to, ?e pokud je v ??sle ??slice 2, tak se ob?as stane, ?e j?
to rozezn? jako 7. T?ch p??pad? je tolik, ?e d?lat to ru?n? pro celou ?R
by byla nep?edstaviteln? pr?ce (nehled? na to, ?e by se to ?patn?
p?i?adilo) - bylo by tedy dobr? vy?e?it to n?jak automaticky.
Ot?zka je jak probl?m vy?e?it. Asi nejlep?? bude znovu rozpoznat ty
eviden?n? ??sla, ve kter?ch je 7 - byl by to tedy stejn? probl?m jako jsem
u? navrhoval s ??sly, kter? nebyla rozpozn?na v?bec. M?? na to Luk??i
skript, nebo ho m?m vyrobit?
On Wed, 10 Feb 2010 01:48:34 +0100, Petr Dlouh? <petr.dlouhy at email.cz>
wrote:
zobrazit citaci
> Ahoj,
>
> tak na Kubajzov? stroji je (po krat?? odst?vce) u? taky v?e spo??tan? a
> uploadovan?.
>
> On Tue, 02 Feb 2010 22:52:06 +0100, Martin Kupec <magon at jkopava.cz>
> wrote:
>
>> Tak jsem uploadoval na server vysledky, odkaz je na wiki ([1]).
>>
>> Nevim jak je to se zpracovanim zbylych tilu, ale kdyz mi nekdo neco
>> uvolni, tak to klidne jeste spocitam :-). Zjistil jsem ze ten stoj co
>> jsem na to zneuzil se nejak moc zbytecne flaka...
>>
>> [1] http://wiki.openstreetmap.org/wiki/Import_Adres_?R/Prubeh_Zpracovani
>>
>> Martin Kupec
>>
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
--
Petr Dlouh?
Ahoj,
je?t? jsem si ??kal, ?e mo?n? nebylo ?patn? rozpozn?v?n? d?lat na
z?klad? podobnosti vzoru jednotliv?ch ??slic. Kdy? je to psan? jedn?m
fontem, jednou velikost?, v?dy stejn? nato?en? a bez n?jak?ch kaz?
vznikl?m skenov?n?m, tak by tato metoda musela b?t vysoce spolehliv?.
Dokonce podle pozorov?n? jsou znaky zarovnan? na cel? pixely (ale mohu
se pl?st - koukal jsem na to jen letmo).
V?hoda je v tom, ?e je to metoda prakticky zcela spolehliv?. Pokud
text n?co p?ekr?v?, tak to odhal? (neshoduje se s ??dn?m vzorem
??slice/p?smena). Pokud se naopak znak shoduje se vzorem, tak je
prakticky jist?, ?e jde o tento znak. Teoreticky by n?jak? jin? objekt
mohl ud?lat nap?. z p?smene I p?smeno T, ale aby to zcela p?esn?
odpov?dalo vzoru, to je podle mne men?? pravd?podobnost, ne? vyhr?t
prvn? cenu v n?jak? loterii.
Algoritmus rozpozn?v?n? by p?itom byl mysl?m velmi jednodu?e
naprogramovateln?, rychl? a nepot?eboval by n?jak? extern? OCRy. To se
sice m??e zd?t jako zbyte?nost, ale m?lo by to v?znam p?i
aktualizac?ch. Tedy nyn? se cel? import pojal jako jednor?zov? import.
Ale data se budou m?nit a nebylo by od v?ci, kdyby se periodicky na?ly
zm?ny, doplnila nov? ??sla dom? apod.
Zkus?m to ov??it na p??kladu.
Honza
2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Ahoj,
>
> za?al jsem s imortem adresn?ch bod? v Praze-z?pad, ale zjistil jsem jeden
> celkem z?sadn? probl?m.
> Zd? se, ?e eviden?n? ??sla jsou o n?co bl?? k te?ce ne? ta popisn? -
> d?sledkem je to, ?e pokud je v ??sle ??slice 2, tak se ob?as stane, ?e j?
> to rozezn? jako 7. T?ch p??pad? je tolik, ?e d?lat to ru?n? pro celou ?R
> by byla nep?edstaviteln? pr?ce (nehled? na to, ?e by se to ?patn?
> p?i?adilo) - bylo by tedy dobr? vy?e?it to n?jak automaticky.
>
> Ot?zka je jak probl?m vy?e?it. Asi nejlep?? bude znovu rozpoznat ty
> eviden?n? ??sla, ve kter?ch je 7 - byl by to tedy stejn? probl?m jako jsem
> u? navrhoval s ??sly, kter? nebyla rozpozn?na v?bec. M?? na to Luk??i
> skript, nebo ho m?m vyrobit?
>
> On Wed, 10 Feb 2010 01:48:34 +0100, Petr Dlouh? <petr.dlouhy at email.cz>
> wrote:
>
>> Ahoj,
>>
>> tak na Kubajzov? stroji je (po krat?? odst?vce) u? taky v?e spo??tan? a
>> uploadovan?.
>>
>> On Tue, 02 Feb 2010 22:52:06 +0100, Martin Kupec <magon at jkopava.cz>
>> wrote:
>>
>>> Tak jsem uploadoval na server vysledky, odkaz je na wiki ([1]).
>>>
>>> Nevim jak je to se zpracovanim zbylych tilu, ale kdyz mi nekdo neco
>>> uvolni, tak to klidne jeste spocitam :-). Zjistil jsem ze ten stoj co
>>> jsem na to zneuzil se nejak moc zbytecne flaka...
>>>
>>> [1] http://wiki.openstreetmap.org/wiki/Import_Adres_?R/Prubeh_Zpracovani
>>>
>>> ? ? ?Martin Kupec
>>>
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Ahoj,
to by mo?n? fungovalo l?p, ale je ot?zka, jestli to stoj? za tu pr?ci,
kdy? u? m?m funk?n? program.
Ty zm?ny se samoz?ejm? ?asem budou muset ud?lat, tak?e by to ur?it? nebyla
zbyte?n? pr?ce. Zaj?mav? by byl taky n?jak? obecn? diff plugin pro JOSM.
On Thu, 11 Feb 2010 18:29:27 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
> Ahoj,
>
> je?t? jsem si ??kal, ?e mo?n? nebylo ?patn? rozpozn?v?n? d?lat na
> z?klad? podobnosti vzoru jednotliv?ch ??slic. Kdy? je to psan? jedn?m
> fontem, jednou velikost?, v?dy stejn? nato?en? a bez n?jak?ch kaz?
> vznikl?m skenov?n?m, tak by tato metoda musela b?t vysoce spolehliv?.
> Dokonce podle pozorov?n? jsou znaky zarovnan? na cel? pixely (ale mohu
> se pl?st - koukal jsem na to jen letmo).
>
> V?hoda je v tom, ?e je to metoda prakticky zcela spolehliv?. Pokud
> text n?co p?ekr?v?, tak to odhal? (neshoduje se s ??dn?m vzorem
> ??slice/p?smena). Pokud se naopak znak shoduje se vzorem, tak je
> prakticky jist?, ?e jde o tento znak. Teoreticky by n?jak? jin? objekt
> mohl ud?lat nap?. z p?smene I p?smeno T, ale aby to zcela p?esn?
> odpov?dalo vzoru, to je podle mne men?? pravd?podobnost, ne? vyhr?t
> prvn? cenu v n?jak? loterii.
>
> Algoritmus rozpozn?v?n? by p?itom byl mysl?m velmi jednodu?e
> naprogramovateln?, rychl? a nepot?eboval by n?jak? extern? OCRy. To se
> sice m??e zd?t jako zbyte?nost, ale m?lo by to v?znam p?i
> aktualizac?ch. Tedy nyn? se cel? import pojal jako jednor?zov? import.
> Ale data se budou m?nit a nebylo by od v?ci, kdyby se periodicky na?ly
> zm?ny, doplnila nov? ??sla dom? apod.
>
> Zkus?m to ov??it na p??kladu.
>
> Honza
>
>
> 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
>> Ahoj,
>>
>> za?al jsem s imortem adresn?ch bod? v Praze-z?pad, ale zjistil jsem
>> jeden
>> celkem z?sadn? probl?m.
>> Zd? se, ?e eviden?n? ??sla jsou o n?co bl?? k te?ce ne? ta popisn? -
>> d?sledkem je to, ?e pokud je v ??sle ??slice 2, tak se ob?as stane, ?e
>> j?
>> to rozezn? jako 7. T?ch p??pad? je tolik, ?e d?lat to ru?n? pro celou ?R
>> by byla nep?edstaviteln? pr?ce (nehled? na to, ?e by se to ?patn?
>> p?i?adilo) - bylo by tedy dobr? vy?e?it to n?jak automaticky.
>>
>> Ot?zka je jak probl?m vy?e?it. Asi nejlep?? bude znovu rozpoznat ty
>> eviden?n? ??sla, ve kter?ch je 7 - byl by to tedy stejn? probl?m jako
>> jsem
>> u? navrhoval s ??sly, kter? nebyla rozpozn?na v?bec. M?? na to Luk??i
>> skript, nebo ho m?m vyrobit?
>>
>> On Wed, 10 Feb 2010 01:48:34 +0100, Petr Dlouh? <petr.dlouhy at email.cz>
>> wrote:
>>
>>> Ahoj,
>>>
>>> tak na Kubajzov? stroji je (po krat?? odst?vce) u? taky v?e spo??tan? a
>>> uploadovan?.
>>>
>>> On Tue, 02 Feb 2010 22:52:06 +0100, Martin Kupec <magon at jkopava.cz>
>>> wrote:
>>>
>>>> Tak jsem uploadoval na server vysledky, odkaz je na wiki ([1]).
>>>>
>>>> Nevim jak je to se zpracovanim zbylych tilu, ale kdyz mi nekdo neco
>>>> uvolni, tak to klidne jeste spocitam :-). Zjistil jsem ze ten stoj co
>>>> jsem na to zneuzil se nejak moc zbytecne flaka...
>>>>
>>>> [1]
>>>> http://wiki.openstreetmap.org/wiki/Import_Adres_?R/Prubeh_Zpracovani
>>>>
>>>> Martin Kupec
>>>>
>>>>
>>>> _______________________________________________
>>>> Talk-cz mailing list
>>>> Talk-cz at openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>>
>>
>>
>> --
>> Petr Dlouh?
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouh?
Ahoj,
jasn? ... to je dobr? ot?zka. Ale ono by to neznamelalo to cel?
p?ed?lat. Prakticky by to bylo sp??e roz???en? st?vaj?c?ho. Jen m?sto
zavol?n? extern?ho OCR by se zavolalo jedno??elov? "intern? OCR".
Honza
2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Ahoj,
>
> to by mo?n? fungovalo l?p, ale je ot?zka, jestli to stoj? za tu pr?ci,
> kdy? u? m?m funk?n? program.
>
> Ty zm?ny se samoz?ejm? ?asem budou muset ud?lat, tak?e by to ur?it? nebyla
> zbyte?n? pr?ce. Zaj?mav? by byl taky n?jak? obecn? diff plugin pro JOSM.
>
> On Thu, 11 Feb 2010 18:29:27 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
> wrote:
>
>> Ahoj,
>>
>> je?t? jsem si ??kal, ?e mo?n? nebylo ?patn? rozpozn?v?n? d?lat na
>> z?klad? podobnosti vzoru jednotliv?ch ??slic. Kdy? je to psan? jedn?m
>> fontem, jednou velikost?, v?dy stejn? nato?en? a bez n?jak?ch kaz?
>> vznikl?m skenov?n?m, tak by tato metoda musela b?t vysoce spolehliv?.
>> Dokonce podle pozorov?n? jsou znaky zarovnan? na cel? pixely (ale mohu
>> se pl?st - koukal jsem na to jen letmo).
>>
>> V?hoda je v tom, ?e je to metoda prakticky zcela spolehliv?. Pokud
>> text n?co p?ekr?v?, tak to odhal? (neshoduje se s ??dn?m vzorem
>> ??slice/p?smena). Pokud se naopak znak shoduje se vzorem, tak je
>> prakticky jist?, ?e jde o tento znak. Teoreticky by n?jak? jin? objekt
>> mohl ud?lat nap?. z p?smene I p?smeno T, ale aby to zcela p?esn?
>> odpov?dalo vzoru, to je podle mne men?? pravd?podobnost, ne? vyhr?t
>> prvn? cenu v n?jak? loterii.
>>
>> Algoritmus rozpozn?v?n? by p?itom byl mysl?m velmi jednodu?e
>> naprogramovateln?, rychl? a nepot?eboval by n?jak? extern? OCRy. To se
>> sice m??e zd?t jako zbyte?nost, ale m?lo by to v?znam p?i
>> aktualizac?ch. Tedy nyn? se cel? import pojal jako jednor?zov? import.
>> Ale data se budou m?nit a nebylo by od v?ci, kdyby se periodicky na?ly
>> zm?ny, doplnila nov? ??sla dom? apod.
>>
>> Zkus?m to ov??it na p??kladu.
>>
>> Honza
>>
>>
>> 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
>>> Ahoj,
>>>
>>> za?al jsem s imortem adresn?ch bod? v Praze-z?pad, ale zjistil jsem
>>> jeden
>>> celkem z?sadn? probl?m.
>>> Zd? se, ?e eviden?n? ??sla jsou o n?co bl?? k te?ce ne? ta popisn? -
>>> d?sledkem je to, ?e pokud je v ??sle ??slice 2, tak se ob?as stane, ?e
>>> j?
>>> to rozezn? jako 7. T?ch p??pad? je tolik, ?e d?lat to ru?n? pro celou ?R
>>> by byla nep?edstaviteln? pr?ce (nehled? na to, ?e by se to ?patn?
>>> p?i?adilo) - bylo by tedy dobr? vy?e?it to n?jak automaticky.
>>>
>>> Ot?zka je jak probl?m vy?e?it. Asi nejlep?? bude znovu rozpoznat ty
>>> eviden?n? ??sla, ve kter?ch je 7 - byl by to tedy stejn? probl?m jako
>>> jsem
>>> u? navrhoval s ??sly, kter? nebyla rozpozn?na v?bec. M?? na to Luk??i
>>> skript, nebo ho m?m vyrobit?
>>>
>>> On Wed, 10 Feb 2010 01:48:34 +0100, Petr Dlouh? <petr.dlouhy at email.cz>
>>> wrote:
>>>
>>>> Ahoj,
>>>>
>>>> tak na Kubajzov? stroji je (po krat?? odst?vce) u? taky v?e spo??tan? a
>>>> uploadovan?.
>>>>
>>>> On Tue, 02 Feb 2010 22:52:06 +0100, Martin Kupec <magon at jkopava.cz>
>>>> wrote:
>>>>
>>>>> Tak jsem uploadoval na server vysledky, odkaz je na wiki ([1]).
>>>>>
>>>>> Nevim jak je to se zpracovanim zbylych tilu, ale kdyz mi nekdo neco
>>>>> uvolni, tak to klidne jeste spocitam :-). Zjistil jsem ze ten stoj co
>>>>> jsem na to zneuzil se nejak moc zbytecne flaka...
>>>>>
>>>>> [1]
>>>>> http://wiki.openstreetmap.org/wiki/Import_Adres_?R/Prubeh_Zpracovani
>>>>>
>>>>> ? ? ?Martin Kupec
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Talk-cz mailing list
>>>>> Talk-cz at openstreetmap.org
>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>
>>>>
>>>
>>>
>>> --
>>> Petr Dlouh?
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Petr Dlouh? p??e v ?t 11. 02. 2010 v 18:13 +0100:
zobrazit citaci
> za?al jsem s imortem adresn?ch bod? v Praze-z?pad, ale zjistil jsem jeden
> celkem z?sadn? probl?m.
> Zd? se, ?e eviden?n? ??sla jsou o n?co bl?? k te?ce ne? ta popisn? -
> d?sledkem je to, ?e pokud je v ??sle ??slice 2, tak se ob?as stane, ?e j?
> to rozezn? jako 7. T?ch p??pad? je tolik, ?e d?lat to ru?n? pro celou ?R
> by byla nep?edstaviteln? pr?ce (nehled? na to, ?e by se to ?patn?
> p?i?adilo) - bylo by tedy dobr? vy?e?it to n?jak automaticky.
Ne?lo by program nau?it spr?vn? pozn?vat dvojku, kter? splynula
s te?kou?
--
Stanislav Brabec
http://www.penguin.cz/~utx
Nerozum?m. Probl?m o kter?m jsem mluvil je, ?e to pozn? dvojku, kter? byl
u??znut spodek jako sedmi?ku.
On Thu, 11 Feb 2010 19:36:13 +0100, Stanislav Brabec <utx at penguin.cz>
wrote:
zobrazit citaci
> Ne?lo by program nau?it spr?vn? pozn?vat dvojku, kter? splynula
> s te?kou?
--
Petr Dlouh?
Petr Dlouh? p??e v ?t 11. 02. 2010 v 20:15 +0100:
zobrazit citaci
> Nerozum?m. Probl?m o kter?m jsem mluvil je, ?e to pozn? dvojku, kter? byl
> u??znut spodek jako sedmi?ku.
Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat u??znutou
dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
zobrazit citaci
> On Thu, 11 Feb 2010 19:36:13 +0100, Stanislav Brabec <utx at penguin.cz>
> wrote:
>
> > Ne?lo by program nau?it spr?vn? pozn?vat dvojku, kter? splynula
> > s te?kou?
>
>
--
Stanislav Brabec
http://www.penguin.cz/~utx
Ne, o to nejde. Ty ??sla jsou u? rozpoznan?, tak?e sta?? p?ed?lat pouze ta
eviden?n? ??sla (ty jsou posunut? trochu n?? od te?ky, tak?e je tam ta
dvojka u??zl?), ve kter?ch je sedmi?ka. Nen? probl?m v tom, ?e by to ne?lo
u??znout o trochu n??. Probl?m je, ?e u? jsme to ud?lali ?patn?, tak?e by
to bylo dobr? napravit bez toho, abychom museli v?echno p?ed?l?vat.
On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec <utx at penguin.cz>
wrote:
zobrazit citaci
> Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat u??znutou
> dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
--
Petr Dlouh?
Ahoj,
pokusn? implementace je velmi rychl? a m?la by b?t i spolehliv?.
Zkou?el jsem to na 18 v??ezech 4000x4000 px. Celkov? ?as 7.2 s.
Pr?m?rn? ?as zpracov?n? jednoho souboru je 405 ms, pr?m?rn? ?as
zpracov?n? jednoho adresn?ho bodu je 17 ms. To v?e v jednom vl?kn? a
tedy to zat??uje jen jedno j?dro procesoru.
Z?tra to snad dod?l?m do pou?iteln?ho stavu.
Honza
2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Ne, o to nejde. Ty ??sla jsou u? rozpoznan?, tak?e sta?? p?ed?lat pouze ta
> eviden?n? ??sla (ty jsou posunut? trochu n?? od te?ky, tak?e je tam ta
> dvojka u??zl?), ve kter?ch je sedmi?ka. Nen? probl?m v tom, ?e by to ne?lo
> u??znout o trochu n??. Probl?m je, ?e u? jsme to ud?lali ?patn?, tak?e by
> to bylo dobr? napravit bez toho, abychom museli v?echno p?ed?l?vat.
>
> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec <utx at penguin.cz>
> wrote:
>
>> Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat u??znutou
>> dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Ahoj,
zn? to dob?e, jestli by to opravdu neznamenalo p??li? mnoho ?asu, tak by
mo?n? st?lo za to data kv?li t? chyb? p?ed?lat (pokud nav?c zlep?? detekci
u p?ekryv?, nebo d?ky rychlosti umo?n? stahovat dla?dice s v?t??m zoomem,
tak to bude dal?? plus).
On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
> Ahoj,
>
> pokusn? implementace je velmi rychl? a m?la by b?t i spolehliv?.
>
> Zkou?el jsem to na 18 v??ezech 4000x4000 px. Celkov? ?as 7.2 s.
> Pr?m?rn? ?as zpracov?n? jednoho souboru je 405 ms, pr?m?rn? ?as
> zpracov?n? jednoho adresn?ho bodu je 17 ms. To v?e v jednom vl?kn? a
> tedy to zat??uje jen jedno j?dro procesoru.
>
> Z?tra to snad dod?l?m do pou?iteln?ho stavu.
>
> Honza
>
>
> 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
>> Ne, o to nejde. Ty ??sla jsou u? rozpoznan?, tak?e sta?? p?ed?lat pouze
>> ta
>> eviden?n? ??sla (ty jsou posunut? trochu n?? od te?ky, tak?e je tam ta
>> dvojka u??zl?), ve kter?ch je sedmi?ka. Nen? probl?m v tom, ?e by to
>> ne?lo
>> u??znout o trochu n??. Probl?m je, ?e u? jsme to ud?lali ?patn?, tak?e
>> by
>> to bylo dobr? napravit bez toho, abychom museli v?echno p?ed?l?vat.
>>
>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec <utx at penguin.cz>
>> wrote:
>>
>>> Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat u??znutou
>>> dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
>>
>>
>> --
>> Petr Dlouh?
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouh?
Ahoj,
k ?emu v?t?? rozli?en?? Sp??e jsem uva?oval nad dynamick?m rozli?en?m
... tedy stahovat v??ezy nejprve v mal?m rozli?en? a podle toho
detekovat oblasti, kter? obsahuj? adresn? body. A jen tyto ?seky
stahovat ve vy???m (t?eba st?vaj?c?m) rozli?en?. To by mohlo u?et?it
mno?stv? stahovan?ch dat. P?ijde mi, ?e nejpomalej?? bude pr?v?
stahov?n? dla?dic z WMS, tak?e obecn?m zv??en?m rozli?en? by se ?as
prodlou?il.
Mimochodem - nem?te n?kdo sta?en? dla?dice z n?jak? v?t?? oblasti,
kter? byste mohli n?kam hodit zazipovan?, abych to nemusel stahovat z
WMS pro testov?n??
Honza
2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Ahoj,
>
> zn? to dob?e, jestli by to opravdu neznamenalo p??li? mnoho ?asu, tak by
> mo?n? st?lo za to data kv?li t? chyb? p?ed?lat (pokud nav?c zlep?? detekci
> u p?ekryv?, nebo d?ky rychlosti umo?n? stahovat dla?dice s v?t??m zoomem,
> tak to bude dal?? plus).
>
> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
> wrote:
>
>> Ahoj,
>>
>> pokusn? implementace je velmi rychl? a m?la by b?t i spolehliv?.
>>
>> Zkou?el jsem to na 18 v??ezech 4000x4000 px. Celkov? ?as 7.2 s.
>> Pr?m?rn? ?as zpracov?n? jednoho souboru je 405 ms, pr?m?rn? ?as
>> zpracov?n? jednoho adresn?ho bodu je 17 ms. To v?e v jednom vl?kn? a
>> tedy to zat??uje jen jedno j?dro procesoru.
>>
>> Z?tra to snad dod?l?m do pou?iteln?ho stavu.
>>
>> Honza
>>
>>
>> 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
>>> Ne, o to nejde. Ty ??sla jsou u? rozpoznan?, tak?e sta?? p?ed?lat pouze
>>> ta
>>> eviden?n? ??sla (ty jsou posunut? trochu n?? od te?ky, tak?e je tam ta
>>> dvojka u??zl?), ve kter?ch je sedmi?ka. Nen? probl?m v tom, ?e by to
>>> ne?lo
>>> u??znout o trochu n??. Probl?m je, ?e u? jsme to ud?lali ?patn?, tak?e
>>> by
>>> to bylo dobr? napravit bez toho, abychom museli v?echno p?ed?l?vat.
>>>
>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec <utx at penguin.cz>
>>> wrote:
>>>
>>>> Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat u??znutou
>>>> dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
>>>
>>>
>>> --
>>> Petr Dlouh?
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Kv?li p?ekryv?m - ??sla se s rozli?en?m zmen?uj?.
Nev?m, jak moc je tv?j algoritmus dokonal? v detekci p?ekr?vaj?c?ch se
??slic, ale nev???m, ?e dok??e? spolehliv? poznat, kde ??slo skon??.
Samoz?ejm? je to ot?zka n?jak?ho kompromisu, ale v?t?inu ?asu p?edt?m
zabralo po??t?n?.
Mysl?m, ?e ale to dynamick? rozli?en?, kter? navrhuje?, nem? moc cenu,
proto?e ty dla?dice jsou v PNG, tak?e by b?l? plochy nem?ly zab?rat p??li?
mnoho datov?ho objemu. To sam? plat? pro vy??? rozli?en? - zpomalen? m??e
nastat sp?? t?m, ?e je nutn? zpracovat v?t?? mno?stv? obrazov? informace.
On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
> Ahoj,
> k ?emu v?t?? rozli?en?? Sp??e jsem uva?oval nad dynamick?m rozli?en?m
> ... tedy stahovat v??ezy nejprve v mal?m rozli?en? a podle toho
> detekovat oblasti, kter? obsahuj? adresn? body. A jen tyto ?seky
> stahovat ve vy???m (t?eba st?vaj?c?m) rozli?en?. To by mohlo u?et?it
> mno?stv? stahovan?ch dat. P?ijde mi, ?e nejpomalej?? bude pr?v?
> stahov?n? dla?dic z WMS, tak?e obecn?m zv??en?m rozli?en? by se ?as
> prodlou?il.
>
> Mimochodem - nem?te n?kdo sta?en? dla?dice z n?jak? v?t?? oblasti,
> kter? byste mohli n?kam hodit zazipovan?, abych to nemusel stahovat z
> WMS pro testov?n??
>
> Honza
>
>
> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>> Ahoj,
>>
>> zn? to dob?e, jestli by to opravdu neznamenalo p??li? mnoho ?asu, tak by
>> mo?n? st?lo za to data kv?li t? chyb? p?ed?lat (pokud nav?c zlep??
>> detekci
>> u p?ekryv?, nebo d?ky rychlosti umo?n? stahovat dla?dice s v?t??m
>> zoomem,
>> tak to bude dal?? plus).
>>
>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>> wrote:
>>
>>> Ahoj,
>>>
>>> pokusn? implementace je velmi rychl? a m?la by b?t i spolehliv?.
>>>
>>> Zkou?el jsem to na 18 v??ezech 4000x4000 px. Celkov? ?as 7.2 s.
>>> Pr?m?rn? ?as zpracov?n? jednoho souboru je 405 ms, pr?m?rn? ?as
>>> zpracov?n? jednoho adresn?ho bodu je 17 ms. To v?e v jednom vl?kn? a
>>> tedy to zat??uje jen jedno j?dro procesoru.
>>>
>>> Z?tra to snad dod?l?m do pou?iteln?ho stavu.
>>>
>>> Honza
>>>
>>>
>>> 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>> Ne, o to nejde. Ty ??sla jsou u? rozpoznan?, tak?e sta?? p?ed?lat
>>>> pouze
>>>> ta
>>>> eviden?n? ??sla (ty jsou posunut? trochu n?? od te?ky, tak?e je tam ta
>>>> dvojka u??zl?), ve kter?ch je sedmi?ka. Nen? probl?m v tom, ?e by to
>>>> ne?lo
>>>> u??znout o trochu n??. Probl?m je, ?e u? jsme to ud?lali ?patn?, tak?e
>>>> by
>>>> to bylo dobr? napravit bez toho, abychom museli v?echno p?ed?l?vat.
>>>>
>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec <utx at penguin.cz>
>>>> wrote:
>>>>
>>>>> Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat u??znutou
>>>>> dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
>>>>
>>>>
>>>> --
>>>> Petr Dlouh?
>>>>
>>>> _______________________________________________
>>>> Talk-cz mailing list
>>>> Talk-cz at openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>> --
>> Petr Dlouh?
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouh?
Na slu?n? detekci p?ekryv? pr?v? pracuji a mysl?m, ?e rozhodn? bude
v?razn? lep?? ne? byla (to u? je mysl?m te?). Ale stoprocentn?
samoz?ejm? ne - kdy? p?ekryv bude velk?, tak to ur?it? nep?jde.
Ale jinak si mysl?m, ?e generov?n? dla?dic na serveru KN bude n?jakou
dobu trvat - a to, a? je na t? dla?dici 5 bod? nebo t?eba jen jeden. A
tak? jim to bude zat??ovat servery, kdy? se to p?e?ene s rychlost?
stahov?n? (mnoho vl?ken apod.).
Honza
2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Kv?li p?ekryv?m - ??sla se s rozli?en?m zmen?uj?.
> Nev?m, jak moc je tv?j algoritmus dokonal? v detekci p?ekr?vaj?c?ch se
> ??slic, ale nev???m, ?e dok??e? spolehliv? poznat, kde ??slo skon??.
> Samoz?ejm? je to ot?zka n?jak?ho kompromisu, ale v?t?inu ?asu p?edt?m
> zabralo po??t?n?.
>
> Mysl?m, ?e ale to dynamick? rozli?en?, kter? navrhuje?, nem? moc cenu,
> proto?e ty dla?dice jsou v PNG, tak?e by b?l? plochy nem?ly zab?rat p??li?
> mnoho datov?ho objemu. To sam? plat? pro vy??? rozli?en? - zpomalen? m??e
> nastat sp?? t?m, ?e je nutn? zpracovat v?t?? mno?stv? obrazov? informace.
>
> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
> wrote:
>
>> Ahoj,
>> k ?emu v?t?? rozli?en?? Sp??e jsem uva?oval nad dynamick?m rozli?en?m
>> ... tedy stahovat v??ezy nejprve v mal?m rozli?en? a podle toho
>> detekovat oblasti, kter? obsahuj? adresn? body. A jen tyto ?seky
>> stahovat ve vy???m (t?eba st?vaj?c?m) rozli?en?. To by mohlo u?et?it
>> mno?stv? stahovan?ch dat. P?ijde mi, ?e nejpomalej?? bude pr?v?
>> stahov?n? dla?dic z WMS, tak?e obecn?m zv??en?m rozli?en? by se ?as
>> prodlou?il.
>>
>> Mimochodem - nem?te n?kdo sta?en? dla?dice z n?jak? v?t?? oblasti,
>> kter? byste mohli n?kam hodit zazipovan?, abych to nemusel stahovat z
>> WMS pro testov?n??
>>
>> Honza
>>
>>
>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>>> Ahoj,
>>>
>>> zn? to dob?e, jestli by to opravdu neznamenalo p??li? mnoho ?asu, tak by
>>> mo?n? st?lo za to data kv?li t? chyb? p?ed?lat (pokud nav?c zlep??
>>> detekci
>>> u p?ekryv?, nebo d?ky rychlosti umo?n? stahovat dla?dice s v?t??m
>>> zoomem,
>>> tak to bude dal?? plus).
>>>
>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>>> wrote:
>>>
>>>> Ahoj,
>>>>
>>>> pokusn? implementace je velmi rychl? a m?la by b?t i spolehliv?.
>>>>
>>>> Zkou?el jsem to na 18 v??ezech 4000x4000 px. Celkov? ?as 7.2 s.
>>>> Pr?m?rn? ?as zpracov?n? jednoho souboru je 405 ms, pr?m?rn? ?as
>>>> zpracov?n? jednoho adresn?ho bodu je 17 ms. To v?e v jednom vl?kn? a
>>>> tedy to zat??uje jen jedno j?dro procesoru.
>>>>
>>>> Z?tra to snad dod?l?m do pou?iteln?ho stavu.
>>>>
>>>> Honza
>>>>
>>>>
>>>> 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>> Ne, o to nejde. Ty ??sla jsou u? rozpoznan?, tak?e sta?? p?ed?lat
>>>>> pouze
>>>>> ta
>>>>> eviden?n? ??sla (ty jsou posunut? trochu n?? od te?ky, tak?e je tam ta
>>>>> dvojka u??zl?), ve kter?ch je sedmi?ka. Nen? probl?m v tom, ?e by to
>>>>> ne?lo
>>>>> u??znout o trochu n??. Probl?m je, ?e u? jsme to ud?lali ?patn?, tak?e
>>>>> by
>>>>> to bylo dobr? napravit bez toho, abychom museli v?echno p?ed?l?vat.
>>>>>
>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec <utx at penguin.cz>
>>>>> wrote:
>>>>>
>>>>>> Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat u??znutou
>>>>>> dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
>>>>>
>>>>>
>>>>> --
>>>>> Petr Dlouh?
>>>>>
>>>>> _______________________________________________
>>>>> Talk-cz mailing list
>>>>> Talk-cz at openstreetmap.org
>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>
>>>>
>>>> _______________________________________________
>>>> Talk-cz mailing list
>>>> Talk-cz at openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>>
>>> --
>>> Petr Dlouh?
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
K vyzkou?en?:
http://jabi.aspone.cz/osm/OcrBeta1.zip
M? to stejn? ovl?d?n? jako p?vodn? tile-processor, ale nav?c mo?nost logov?n?:
FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv
-log log.txt -all
-log log.txt ... pokud se toto uvede, tak program bude logovat
nerozpoznan? body nebo ty, kter? byly naru?en? p?ekryvem.
Pokud se uvede nav?c -all, tak se budou logovat v?echny body.
Soubor charDef.txt obsahuje definici znak? nebo posloupnosti znak?. Je
to tak? textov? soubor, kter? kdy? zobraz?te fontem s pevnou ???kou,
tak je mysl?m v?znam jasn?. Chyb? tam ??slice 4 posunut? dol? (tedy za
?.o.), proto?e jsem na nic p?i pokusech nenarazil. Soubor mus? b?t p?i
spu?t?n? v aktu?ln?m adres??i.
Honza
2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
zobrazit citaci
> Na slu?n? detekci p?ekryv? pr?v? pracuji a mysl?m, ?e rozhodn? bude
> v?razn? lep?? ne? byla (to u? je mysl?m te?). Ale stoprocentn?
> samoz?ejm? ne - kdy? p?ekryv bude velk?, tak to ur?it? nep?jde.
>
> Ale jinak si mysl?m, ?e generov?n? dla?dic na serveru KN bude n?jakou
> dobu trvat - a to, a? je na t? dla?dici 5 bod? nebo t?eba jen jeden. A
> tak? jim to bude zat??ovat servery, kdy? se to p?e?ene s rychlost?
> stahov?n? (mnoho vl?ken apod.).
>
> Honza
>
>
> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>> Kv?li p?ekryv?m - ??sla se s rozli?en?m zmen?uj?.
>> Nev?m, jak moc je tv?j algoritmus dokonal? v detekci p?ekr?vaj?c?ch se
>> ??slic, ale nev???m, ?e dok??e? spolehliv? poznat, kde ??slo skon??.
>> Samoz?ejm? je to ot?zka n?jak?ho kompromisu, ale v?t?inu ?asu p?edt?m
>> zabralo po??t?n?.
>>
>> Mysl?m, ?e ale to dynamick? rozli?en?, kter? navrhuje?, nem? moc cenu,
>> proto?e ty dla?dice jsou v PNG, tak?e by b?l? plochy nem?ly zab?rat p??li?
>> mnoho datov?ho objemu. To sam? plat? pro vy??? rozli?en? - zpomalen? m??e
>> nastat sp?? t?m, ?e je nutn? zpracovat v?t?? mno?stv? obrazov? informace.
>>
>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>> wrote:
>>
>>> Ahoj,
>>> k ?emu v?t?? rozli?en?? Sp??e jsem uva?oval nad dynamick?m rozli?en?m
>>> ... tedy stahovat v??ezy nejprve v mal?m rozli?en? a podle toho
>>> detekovat oblasti, kter? obsahuj? adresn? body. A jen tyto ?seky
>>> stahovat ve vy???m (t?eba st?vaj?c?m) rozli?en?. To by mohlo u?et?it
>>> mno?stv? stahovan?ch dat. P?ijde mi, ?e nejpomalej?? bude pr?v?
>>> stahov?n? dla?dic z WMS, tak?e obecn?m zv??en?m rozli?en? by se ?as
>>> prodlou?il.
>>>
>>> Mimochodem - nem?te n?kdo sta?en? dla?dice z n?jak? v?t?? oblasti,
>>> kter? byste mohli n?kam hodit zazipovan?, abych to nemusel stahovat z
>>> WMS pro testov?n??
>>>
>>> Honza
>>>
>>>
>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>> Ahoj,
>>>>
>>>> zn? to dob?e, jestli by to opravdu neznamenalo p??li? mnoho ?asu, tak by
>>>> mo?n? st?lo za to data kv?li t? chyb? p?ed?lat (pokud nav?c zlep??
>>>> detekci
>>>> u p?ekryv?, nebo d?ky rychlosti umo?n? stahovat dla?dice s v?t??m
>>>> zoomem,
>>>> tak to bude dal?? plus).
>>>>
>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>>>> wrote:
>>>>
>>>>> Ahoj,
>>>>>
>>>>> pokusn? implementace je velmi rychl? a m?la by b?t i spolehliv?.
>>>>>
>>>>> Zkou?el jsem to na 18 v??ezech 4000x4000 px. Celkov? ?as 7.2 s.
>>>>> Pr?m?rn? ?as zpracov?n? jednoho souboru je 405 ms, pr?m?rn? ?as
>>>>> zpracov?n? jednoho adresn?ho bodu je 17 ms. To v?e v jednom vl?kn? a
>>>>> tedy to zat??uje jen jedno j?dro procesoru.
>>>>>
>>>>> Z?tra to snad dod?l?m do pou?iteln?ho stavu.
>>>>>
>>>>> Honza
>>>>>
>>>>>
>>>>> 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>>> Ne, o to nejde. Ty ??sla jsou u? rozpoznan?, tak?e sta?? p?ed?lat
>>>>>> pouze
>>>>>> ta
>>>>>> eviden?n? ??sla (ty jsou posunut? trochu n?? od te?ky, tak?e je tam ta
>>>>>> dvojka u??zl?), ve kter?ch je sedmi?ka. Nen? probl?m v tom, ?e by to
>>>>>> ne?lo
>>>>>> u??znout o trochu n??. Probl?m je, ?e u? jsme to ud?lali ?patn?, tak?e
>>>>>> by
>>>>>> to bylo dobr? napravit bez toho, abychom museli v?echno p?ed?l?vat.
>>>>>>
>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec <utx at penguin.cz>
>>>>>> wrote:
>>>>>>
>>>>>>> Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat u??znutou
>>>>>>> dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Petr Dlouh?
>>>>>>
>>>>>> _______________________________________________
>>>>>> Talk-cz mailing list
>>>>>> Talk-cz at openstreetmap.org
>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Talk-cz mailing list
>>>>> Talk-cz at openstreetmap.org
>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>
>>>>
>>>> --
>>>> Petr Dlouh?
>>>>
>>>> _______________________________________________
>>>> Talk-cz mailing list
>>>> Talk-cz at openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>> --
>> Petr Dlouh?
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
Doplnil jsem tam chyb?j?c? ??slici 4.
Honza
2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
zobrazit citaci
> K vyzkou?en?:
> http://jabi.aspone.cz/osm/OcrBeta1.zip
>
> M? to stejn? ovl?d?n? jako p?vodn? tile-processor, ale nav?c mo?nost logov?n?:
>
> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv
> -log log.txt -all
>
> -log log.txt ... pokud se toto uvede, tak program bude logovat
> nerozpoznan? body nebo ty, kter? byly naru?en? p?ekryvem.
>
> Pokud se uvede nav?c -all, tak se budou logovat v?echny body.
>
> Soubor charDef.txt obsahuje definici znak? nebo posloupnosti znak?. Je
> to tak? textov? soubor, kter? kdy? zobraz?te fontem s pevnou ???kou,
> tak je mysl?m v?znam jasn?. Chyb? tam ??slice 4 posunut? dol? (tedy za
> ?.o.), proto?e jsem na nic p?i pokusech nenarazil. Soubor mus? b?t p?i
> spu?t?n? v aktu?ln?m adres??i.
>
> Honza
>
>
> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>> Na slu?n? detekci p?ekryv? pr?v? pracuji a mysl?m, ?e rozhodn? bude
>> v?razn? lep?? ne? byla (to u? je mysl?m te?). Ale stoprocentn?
>> samoz?ejm? ne - kdy? p?ekryv bude velk?, tak to ur?it? nep?jde.
>>
>> Ale jinak si mysl?m, ?e generov?n? dla?dic na serveru KN bude n?jakou
>> dobu trvat - a to, a? je na t? dla?dici 5 bod? nebo t?eba jen jeden. A
>> tak? jim to bude zat??ovat servery, kdy? se to p?e?ene s rychlost?
>> stahov?n? (mnoho vl?ken apod.).
>>
>> Honza
>>
>>
>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>>> Kv?li p?ekryv?m - ??sla se s rozli?en?m zmen?uj?.
>>> Nev?m, jak moc je tv?j algoritmus dokonal? v detekci p?ekr?vaj?c?ch se
>>> ??slic, ale nev???m, ?e dok??e? spolehliv? poznat, kde ??slo skon??.
>>> Samoz?ejm? je to ot?zka n?jak?ho kompromisu, ale v?t?inu ?asu p?edt?m
>>> zabralo po??t?n?.
>>>
>>> Mysl?m, ?e ale to dynamick? rozli?en?, kter? navrhuje?, nem? moc cenu,
>>> proto?e ty dla?dice jsou v PNG, tak?e by b?l? plochy nem?ly zab?rat p??li?
>>> mnoho datov?ho objemu. To sam? plat? pro vy??? rozli?en? - zpomalen? m??e
>>> nastat sp?? t?m, ?e je nutn? zpracovat v?t?? mno?stv? obrazov? informace.
>>>
>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>>> wrote:
>>>
>>>> Ahoj,
>>>> k ?emu v?t?? rozli?en?? Sp??e jsem uva?oval nad dynamick?m rozli?en?m
>>>> ... tedy stahovat v??ezy nejprve v mal?m rozli?en? a podle toho
>>>> detekovat oblasti, kter? obsahuj? adresn? body. A jen tyto ?seky
>>>> stahovat ve vy???m (t?eba st?vaj?c?m) rozli?en?. To by mohlo u?et?it
>>>> mno?stv? stahovan?ch dat. P?ijde mi, ?e nejpomalej?? bude pr?v?
>>>> stahov?n? dla?dic z WMS, tak?e obecn?m zv??en?m rozli?en? by se ?as
>>>> prodlou?il.
>>>>
>>>> Mimochodem - nem?te n?kdo sta?en? dla?dice z n?jak? v?t?? oblasti,
>>>> kter? byste mohli n?kam hodit zazipovan?, abych to nemusel stahovat z
>>>> WMS pro testov?n??
>>>>
>>>> Honza
>>>>
>>>>
>>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>> Ahoj,
>>>>>
>>>>> zn? to dob?e, jestli by to opravdu neznamenalo p??li? mnoho ?asu, tak by
>>>>> mo?n? st?lo za to data kv?li t? chyb? p?ed?lat (pokud nav?c zlep??
>>>>> detekci
>>>>> u p?ekryv?, nebo d?ky rychlosti umo?n? stahovat dla?dice s v?t??m
>>>>> zoomem,
>>>>> tak to bude dal?? plus).
>>>>>
>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Ahoj,
>>>>>>
>>>>>> pokusn? implementace je velmi rychl? a m?la by b?t i spolehliv?.
>>>>>>
>>>>>> Zkou?el jsem to na 18 v??ezech 4000x4000 px. Celkov? ?as 7.2 s.
>>>>>> Pr?m?rn? ?as zpracov?n? jednoho souboru je 405 ms, pr?m?rn? ?as
>>>>>> zpracov?n? jednoho adresn?ho bodu je 17 ms. To v?e v jednom vl?kn? a
>>>>>> tedy to zat??uje jen jedno j?dro procesoru.
>>>>>>
>>>>>> Z?tra to snad dod?l?m do pou?iteln?ho stavu.
>>>>>>
>>>>>> Honza
>>>>>>
>>>>>>
>>>>>> 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>>>> Ne, o to nejde. Ty ??sla jsou u? rozpoznan?, tak?e sta?? p?ed?lat
>>>>>>> pouze
>>>>>>> ta
>>>>>>> eviden?n? ??sla (ty jsou posunut? trochu n?? od te?ky, tak?e je tam ta
>>>>>>> dvojka u??zl?), ve kter?ch je sedmi?ka. Nen? probl?m v tom, ?e by to
>>>>>>> ne?lo
>>>>>>> u??znout o trochu n??. Probl?m je, ?e u? jsme to ud?lali ?patn?, tak?e
>>>>>>> by
>>>>>>> to bylo dobr? napravit bez toho, abychom museli v?echno p?ed?l?vat.
>>>>>>>
>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec <utx at penguin.cz>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat u??znutou
>>>>>>>> dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Petr Dlouh?
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Talk-cz mailing list
>>>>>>> Talk-cz at openstreetmap.org
>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Talk-cz mailing list
>>>>>> Talk-cz at openstreetmap.org
>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>
>>>>>
>>>>> --
>>>>> Petr Dlouh?
>>>>>
>>>>> _______________________________________________
>>>>> Talk-cz mailing list
>>>>> Talk-cz at openstreetmap.org
>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>
>>>>
>>>> _______________________________________________
>>>> Talk-cz mailing list
>>>> Talk-cz at openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>>
>>> --
>>> Petr Dlouh?
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>
>
Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy.
Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne.
Ale co tomu vadi, to je ten copyright. Zat?m toti? beru v ?vahu pouze
?ervenou barvu. Jsou 3 mo?nosti jak to ?e?it:
a) stahovat dla?dice s p?ekryvem tak, ?e se bude rozpozn?vat pouze z
t?ch ??st? mapy, kter? copyright nen?. V?hody: Nejlep?? v?sledky.
Nev?hody: Nutnost stahovat v?ce dat z WMS.
b) pova?ovat ?ernou barvu za ?ervenou. V?hody: Nejsou nutn? ?pravy
downloaderu, u rozpozn?va?e jen trivi?ln? zm?na 3 konstant. Nev?hody:
Drobn? zhor?en? rozpozn?v?n? v p??pad? p?ekryvu copyrightu s popiskem
- pokud se to ne?ikovn? tref?, tak bude t?eba ru?n? rozpozn?n?, ale
nemus? to znamenat nic, i kdy? se to tref?.
c) Prov?d?t ru?n? kontrolu v?ech popisk? s p?ekryvem (t?ch m??e b?t hodn?).
Osobn? pova?uji c) za ?patn? ?e?en?. A mezi a) a b) nem?m vyhrazen?
n?zor. Mo?nost a) je sice teoreticky nejlep??, ale b) nemus? m?t
post?ehnuteln? hor?? v?sledky.
Honza
2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
zobrazit citaci
> Doplnil jsem tam chyb?j?c? ??slici 4.
>
> Honza
>
> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>> K vyzkou?en?:
>> http://jabi.aspone.cz/osm/OcrBeta1.zip
>>
>> M? to stejn? ovl?d?n? jako p?vodn? tile-processor, ale nav?c mo?nost logov?n?:
>>
>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv
>> -log log.txt -all
>>
>> -log log.txt ... pokud se toto uvede, tak program bude logovat
>> nerozpoznan? body nebo ty, kter? byly naru?en? p?ekryvem.
>>
>> Pokud se uvede nav?c -all, tak se budou logovat v?echny body.
>>
>> Soubor charDef.txt obsahuje definici znak? nebo posloupnosti znak?. Je
>> to tak? textov? soubor, kter? kdy? zobraz?te fontem s pevnou ???kou,
>> tak je mysl?m v?znam jasn?. Chyb? tam ??slice 4 posunut? dol? (tedy za
>> ?.o.), proto?e jsem na nic p?i pokusech nenarazil. Soubor mus? b?t p?i
>> spu?t?n? v aktu?ln?m adres??i.
>>
>> Honza
>>
>>
>> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>>> Na slu?n? detekci p?ekryv? pr?v? pracuji a mysl?m, ?e rozhodn? bude
>>> v?razn? lep?? ne? byla (to u? je mysl?m te?). Ale stoprocentn?
>>> samoz?ejm? ne - kdy? p?ekryv bude velk?, tak to ur?it? nep?jde.
>>>
>>> Ale jinak si mysl?m, ?e generov?n? dla?dic na serveru KN bude n?jakou
>>> dobu trvat - a to, a? je na t? dla?dici 5 bod? nebo t?eba jen jeden. A
>>> tak? jim to bude zat??ovat servery, kdy? se to p?e?ene s rychlost?
>>> stahov?n? (mnoho vl?ken apod.).
>>>
>>> Honza
>>>
>>>
>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>> Kv?li p?ekryv?m - ??sla se s rozli?en?m zmen?uj?.
>>>> Nev?m, jak moc je tv?j algoritmus dokonal? v detekci p?ekr?vaj?c?ch se
>>>> ??slic, ale nev???m, ?e dok??e? spolehliv? poznat, kde ??slo skon??.
>>>> Samoz?ejm? je to ot?zka n?jak?ho kompromisu, ale v?t?inu ?asu p?edt?m
>>>> zabralo po??t?n?.
>>>>
>>>> Mysl?m, ?e ale to dynamick? rozli?en?, kter? navrhuje?, nem? moc cenu,
>>>> proto?e ty dla?dice jsou v PNG, tak?e by b?l? plochy nem?ly zab?rat p??li?
>>>> mnoho datov?ho objemu. To sam? plat? pro vy??? rozli?en? - zpomalen? m??e
>>>> nastat sp?? t?m, ?e je nutn? zpracovat v?t?? mno?stv? obrazov? informace.
>>>>
>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>>>> wrote:
>>>>
>>>>> Ahoj,
>>>>> k ?emu v?t?? rozli?en?? Sp??e jsem uva?oval nad dynamick?m rozli?en?m
>>>>> ... tedy stahovat v??ezy nejprve v mal?m rozli?en? a podle toho
>>>>> detekovat oblasti, kter? obsahuj? adresn? body. A jen tyto ?seky
>>>>> stahovat ve vy???m (t?eba st?vaj?c?m) rozli?en?. To by mohlo u?et?it
>>>>> mno?stv? stahovan?ch dat. P?ijde mi, ?e nejpomalej?? bude pr?v?
>>>>> stahov?n? dla?dic z WMS, tak?e obecn?m zv??en?m rozli?en? by se ?as
>>>>> prodlou?il.
>>>>>
>>>>> Mimochodem - nem?te n?kdo sta?en? dla?dice z n?jak? v?t?? oblasti,
>>>>> kter? byste mohli n?kam hodit zazipovan?, abych to nemusel stahovat z
>>>>> WMS pro testov?n??
>>>>>
>>>>> Honza
>>>>>
>>>>>
>>>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>>> Ahoj,
>>>>>>
>>>>>> zn? to dob?e, jestli by to opravdu neznamenalo p??li? mnoho ?asu, tak by
>>>>>> mo?n? st?lo za to data kv?li t? chyb? p?ed?lat (pokud nav?c zlep??
>>>>>> detekci
>>>>>> u p?ekryv?, nebo d?ky rychlosti umo?n? stahovat dla?dice s v?t??m
>>>>>> zoomem,
>>>>>> tak to bude dal?? plus).
>>>>>>
>>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Ahoj,
>>>>>>>
>>>>>>> pokusn? implementace je velmi rychl? a m?la by b?t i spolehliv?.
>>>>>>>
>>>>>>> Zkou?el jsem to na 18 v??ezech 4000x4000 px. Celkov? ?as 7.2 s.
>>>>>>> Pr?m?rn? ?as zpracov?n? jednoho souboru je 405 ms, pr?m?rn? ?as
>>>>>>> zpracov?n? jednoho adresn?ho bodu je 17 ms. To v?e v jednom vl?kn? a
>>>>>>> tedy to zat??uje jen jedno j?dro procesoru.
>>>>>>>
>>>>>>> Z?tra to snad dod?l?m do pou?iteln?ho stavu.
>>>>>>>
>>>>>>> Honza
>>>>>>>
>>>>>>>
>>>>>>> 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>>>>> Ne, o to nejde. Ty ??sla jsou u? rozpoznan?, tak?e sta?? p?ed?lat
>>>>>>>> pouze
>>>>>>>> ta
>>>>>>>> eviden?n? ??sla (ty jsou posunut? trochu n?? od te?ky, tak?e je tam ta
>>>>>>>> dvojka u??zl?), ve kter?ch je sedmi?ka. Nen? probl?m v tom, ?e by to
>>>>>>>> ne?lo
>>>>>>>> u??znout o trochu n??. Probl?m je, ?e u? jsme to ud?lali ?patn?, tak?e
>>>>>>>> by
>>>>>>>> to bylo dobr? napravit bez toho, abychom museli v?echno p?ed?l?vat.
>>>>>>>>
>>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec <utx at penguin.cz>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat u??znutou
>>>>>>>>> dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Petr Dlouh?
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Talk-cz mailing list
>>>>>>>> Talk-cz at openstreetmap.org
>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Talk-cz mailing list
>>>>>>> Talk-cz at openstreetmap.org
>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Petr Dlouh?
>>>>>>
>>>>>> _______________________________________________
>>>>>> Talk-cz mailing list
>>>>>> Talk-cz at openstreetmap.org
>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Talk-cz mailing list
>>>>> Talk-cz at openstreetmap.org
>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>
>>>>
>>>> --
>>>> Petr Dlouh?
>>>>
>>>> _______________________________________________
>>>> Talk-cz mailing list
>>>> Talk-cz at openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>
>>>
>>
>
Ahoj,
ten copyright je jen ?pln? naho?e na ka?d? dla?dici, nebo se pletu? Pokud
tomu tak je, tak bych volil mo?nost a), proto?e je to minimum z velikosti
dla?dice, a ty se u? stejn? stahuj? s p?esahem (kv?li tomu, ?e se ??sla
kresl? jen na dla?dici s te?kou).
Jinak jsem se koukal na ten skript, a zd? se to velice dobr?. Mysl?m, ?e
by st?lo za to to p?epo??tat, vzhledem k tomu, ?e je to tak 20x rychlej??,
tak to asi nebude probl?m ud?lat na jednou po??ta?i.
Chyby vid?m n?sleduj?c?:
-N?kter? adresn? body nejsou v?bec detekov?ny, a u n?kter?ch je pr?zdn?
text (p?esto?e jsou daleko od v?eho).
-?asto se objevuje [CHECK] i u bod?, kter? byly detekov?ny spr?vn?. Pokud
je to v p??padech, kdy se ??sla u? skute?n? p?ekr?vaj?, tak OK. Jenom se
pt?m, jestli nen? mo?n? zvolit agresivn?j?? o?ez p?ed detekc? (pozor na
jin? posunut? ?.e. vs ?.p.).
-V p??padech, kdy se objev? [CHECK], tak by asi skript m?l st?hnout ??slo
ve vy???m rozli?en? a detekovat to.
On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
> Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy.
> Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne.
> Ale co tomu vadi, to je ten copyright. Zat?m toti? beru v ?vahu pouze
> ?ervenou barvu. Jsou 3 mo?nosti jak to ?e?it:
>
> a) stahovat dla?dice s p?ekryvem tak, ?e se bude rozpozn?vat pouze z
> t?ch ??st? mapy, kter? copyright nen?. V?hody: Nejlep?? v?sledky.
> Nev?hody: Nutnost stahovat v?ce dat z WMS.
>
> b) pova?ovat ?ernou barvu za ?ervenou. V?hody: Nejsou nutn? ?pravy
> downloaderu, u rozpozn?va?e jen trivi?ln? zm?na 3 konstant. Nev?hody:
> Drobn? zhor?en? rozpozn?v?n? v p??pad? p?ekryvu copyrightu s popiskem
> - pokud se to ne?ikovn? tref?, tak bude t?eba ru?n? rozpozn?n?, ale
> nemus? to znamenat nic, i kdy? se to tref?.
>
> c) Prov?d?t ru?n? kontrolu v?ech popisk? s p?ekryvem (t?ch m??e b?t
> hodn?).
>
> Osobn? pova?uji c) za ?patn? ?e?en?. A mezi a) a b) nem?m vyhrazen?
> n?zor. Mo?nost a) je sice teoreticky nejlep??, ale b) nemus? m?t
> post?ehnuteln? hor?? v?sledky.
>
> Honza
>
>
>
> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>> Doplnil jsem tam chyb?j?c? ??slici 4.
>>
>> Honza
>>
>> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>>> K vyzkou?en?:
>>> http://jabi.aspone.cz/osm/OcrBeta1.zip
>>>
>>> M? to stejn? ovl?d?n? jako p?vodn? tile-processor, ale nav?c mo?nost
>>> logov?n?:
>>>
>>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv
>>> -log log.txt -all
>>>
>>> -log log.txt ... pokud se toto uvede, tak program bude logovat
>>> nerozpoznan? body nebo ty, kter? byly naru?en? p?ekryvem.
>>>
>>> Pokud se uvede nav?c -all, tak se budou logovat v?echny body.
>>>
>>> Soubor charDef.txt obsahuje definici znak? nebo posloupnosti znak?. Je
>>> to tak? textov? soubor, kter? kdy? zobraz?te fontem s pevnou ???kou,
>>> tak je mysl?m v?znam jasn?. Chyb? tam ??slice 4 posunut? dol? (tedy za
>>> ?.o.), proto?e jsem na nic p?i pokusech nenarazil. Soubor mus? b?t p?i
>>> spu?t?n? v aktu?ln?m adres??i.
>>>
>>> Honza
>>>
>>>
>>> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>>>> Na slu?n? detekci p?ekryv? pr?v? pracuji a mysl?m, ?e rozhodn? bude
>>>> v?razn? lep?? ne? byla (to u? je mysl?m te?). Ale stoprocentn?
>>>> samoz?ejm? ne - kdy? p?ekryv bude velk?, tak to ur?it? nep?jde.
>>>>
>>>> Ale jinak si mysl?m, ?e generov?n? dla?dic na serveru KN bude n?jakou
>>>> dobu trvat - a to, a? je na t? dla?dici 5 bod? nebo t?eba jen jeden. A
>>>> tak? jim to bude zat??ovat servery, kdy? se to p?e?ene s rychlost?
>>>> stahov?n? (mnoho vl?ken apod.).
>>>>
>>>> Honza
>>>>
>>>>
>>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>> Kv?li p?ekryv?m - ??sla se s rozli?en?m zmen?uj?.
>>>>> Nev?m, jak moc je tv?j algoritmus dokonal? v detekci p?ekr?vaj?c?ch
>>>>> se
>>>>> ??slic, ale nev???m, ?e dok??e? spolehliv? poznat, kde ??slo skon??.
>>>>> Samoz?ejm? je to ot?zka n?jak?ho kompromisu, ale v?t?inu ?asu p?edt?m
>>>>> zabralo po??t?n?.
>>>>>
>>>>> Mysl?m, ?e ale to dynamick? rozli?en?, kter? navrhuje?, nem? moc
>>>>> cenu,
>>>>> proto?e ty dla?dice jsou v PNG, tak?e by b?l? plochy nem?ly zab?rat
>>>>> p??li?
>>>>> mnoho datov?ho objemu. To sam? plat? pro vy??? rozli?en? - zpomalen?
>>>>> m??e
>>>>> nastat sp?? t?m, ?e je nutn? zpracovat v?t?? mno?stv? obrazov?
>>>>> informace.
>>>>>
>>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak
>>>>> <jan.bilak.osm at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Ahoj,
>>>>>> k ?emu v?t?? rozli?en?? Sp??e jsem uva?oval nad dynamick?m
>>>>>> rozli?en?m
>>>>>> ... tedy stahovat v??ezy nejprve v mal?m rozli?en? a podle toho
>>>>>> detekovat oblasti, kter? obsahuj? adresn? body. A jen tyto ?seky
>>>>>> stahovat ve vy???m (t?eba st?vaj?c?m) rozli?en?. To by mohlo u?et?it
>>>>>> mno?stv? stahovan?ch dat. P?ijde mi, ?e nejpomalej?? bude pr?v?
>>>>>> stahov?n? dla?dic z WMS, tak?e obecn?m zv??en?m rozli?en? by se ?as
>>>>>> prodlou?il.
>>>>>>
>>>>>> Mimochodem - nem?te n?kdo sta?en? dla?dice z n?jak? v?t?? oblasti,
>>>>>> kter? byste mohli n?kam hodit zazipovan?, abych to nemusel stahovat
>>>>>> z
>>>>>> WMS pro testov?n??
>>>>>>
>>>>>> Honza
>>>>>>
>>>>>>
>>>>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>>>> Ahoj,
>>>>>>>
>>>>>>> zn? to dob?e, jestli by to opravdu neznamenalo p??li? mnoho ?asu,
>>>>>>> tak by
>>>>>>> mo?n? st?lo za to data kv?li t? chyb? p?ed?lat (pokud nav?c zlep??
>>>>>>> detekci
>>>>>>> u p?ekryv?, nebo d?ky rychlosti umo?n? stahovat dla?dice s v?t??m
>>>>>>> zoomem,
>>>>>>> tak to bude dal?? plus).
>>>>>>>
>>>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak
>>>>>>> <jan.bilak.osm at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Ahoj,
>>>>>>>>
>>>>>>>> pokusn? implementace je velmi rychl? a m?la by b?t i spolehliv?.
>>>>>>>>
>>>>>>>> Zkou?el jsem to na 18 v??ezech 4000x4000 px. Celkov? ?as 7.2 s.
>>>>>>>> Pr?m?rn? ?as zpracov?n? jednoho souboru je 405 ms, pr?m?rn? ?as
>>>>>>>> zpracov?n? jednoho adresn?ho bodu je 17 ms. To v?e v jednom
>>>>>>>> vl?kn? a
>>>>>>>> tedy to zat??uje jen jedno j?dro procesoru.
>>>>>>>>
>>>>>>>> Z?tra to snad dod?l?m do pou?iteln?ho stavu.
>>>>>>>>
>>>>>>>> Honza
>>>>>>>>
>>>>>>>>
>>>>>>>> 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>>>>>> Ne, o to nejde. Ty ??sla jsou u? rozpoznan?, tak?e sta?? p?ed?lat
>>>>>>>>> pouze
>>>>>>>>> ta
>>>>>>>>> eviden?n? ??sla (ty jsou posunut? trochu n?? od te?ky, tak?e je
>>>>>>>>> tam ta
>>>>>>>>> dvojka u??zl?), ve kter?ch je sedmi?ka. Nen? probl?m v tom, ?e
>>>>>>>>> by to
>>>>>>>>> ne?lo
>>>>>>>>> u??znout o trochu n??. Probl?m je, ?e u? jsme to ud?lali ?patn?,
>>>>>>>>> tak?e
>>>>>>>>> by
>>>>>>>>> to bylo dobr? napravit bez toho, abychom museli v?echno
>>>>>>>>> p?ed?l?vat.
>>>>>>>>>
>>>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec
>>>>>>>>> <utx at penguin.cz>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat
>>>>>>>>>> u??znutou
>>>>>>>>>> dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Petr Dlouh?
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Talk-cz mailing list
>>>>>>>>> Talk-cz at openstreetmap.org
>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Talk-cz mailing list
>>>>>>>> Talk-cz at openstreetmap.org
>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Petr Dlouh?
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Talk-cz mailing list
>>>>>>> Talk-cz at openstreetmap.org
>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Talk-cz mailing list
>>>>>> Talk-cz at openstreetmap.org
>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>
>>>>>
>>>>> --
>>>>> Petr Dlouh?
>>>>>
>>>>> _______________________________________________
>>>>> Talk-cz mailing list
>>>>> Talk-cz at openstreetmap.org
>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouh?
Ahoj,
ten copyright je vlevo naho?e, ale pak i na sou?adnici cca [530,510] px.
Ta detekce bod? ... toho jsem si nev?iml. Jak to kontroluje??
Check ... to zna?? opravdu i nepatrn? p?ekryv. Pokud si to nen? jist?,
tak je tam znak otazn?k a v hranat?ch z?vork?ch seznam mo?nost?. Je?t?
tam d?m jednu kontrolu a m?lo byt o b?t mysl?m 100% spolehliv?, kdy?
tam nebude ??dn? ?erven? bod chyb?t (tedy je t?eba pou??t mo?nost a)
nebo b) vypo??d?n? se s copyrightem).
O?ez p?ed detekc? ned?l?m ... detekce si sama ??d?, kdy skon?it.
Check by nem?lo b?t nic, co by bylo t?eba ru?n? kontrolovat - a? se
vy?e?? ten copyright a p?id?m tam tu jednu drobnou kontrolu. T?ch
mo?nost?, kdy se tam objev? otazn?k (nen? si to jist?) je mysl?m
minimum. Zat?m se mi to nestalo.
Honza
2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Ahoj,
>
> ten copyright je jen ?pln? naho?e na ka?d? dla?dici, nebo se pletu? Pokud
> tomu tak je, tak bych volil mo?nost a), proto?e je to minimum z velikosti
> dla?dice, a ty se u? stejn? stahuj? s p?esahem (kv?li tomu, ?e se ??sla
> kresl? jen na dla?dici s te?kou).
>
> Jinak jsem se koukal na ten skript, a zd? se to velice dobr?. Mysl?m, ?e
> by st?lo za to to p?epo??tat, vzhledem k tomu, ?e je to tak 20x rychlej??,
> tak to asi nebude probl?m ud?lat na jednou po??ta?i.
>
> Chyby vid?m n?sleduj?c?:
>
> -N?kter? adresn? body nejsou v?bec detekov?ny, a u n?kter?ch je pr?zdn?
> text (p?esto?e jsou daleko od v?eho).
> -?asto se objevuje [CHECK] i u bod?, kter? byly detekov?ny spr?vn?. Pokud
> je to v p??padech, kdy se ??sla u? skute?n? p?ekr?vaj?, tak OK. Jenom se
> pt?m, jestli nen? mo?n? zvolit agresivn?j?? o?ez p?ed detekc? (pozor na
> jin? posunut? ?.e. vs ?.p.).
> -V p??padech, kdy se objev? [CHECK], tak by asi skript m?l st?hnout ??slo
> ve vy???m rozli?en? a detekovat to.
>
>
> On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
> wrote:
>
>> Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy.
>> Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne.
>> Ale co tomu vadi, to je ten copyright. Zat?m toti? beru v ?vahu pouze
>> ?ervenou barvu. Jsou 3 mo?nosti jak to ?e?it:
>>
>> a) stahovat dla?dice s p?ekryvem tak, ?e se bude rozpozn?vat pouze z
>> t?ch ??st? mapy, kter? copyright nen?. V?hody: Nejlep?? v?sledky.
>> Nev?hody: Nutnost stahovat v?ce dat z WMS.
>>
>> b) pova?ovat ?ernou barvu za ?ervenou. V?hody: Nejsou nutn? ?pravy
>> downloaderu, u rozpozn?va?e jen trivi?ln? zm?na 3 konstant. Nev?hody:
>> Drobn? zhor?en? rozpozn?v?n? v p??pad? p?ekryvu copyrightu s popiskem
>> - pokud se to ne?ikovn? tref?, tak bude t?eba ru?n? rozpozn?n?, ale
>> nemus? to znamenat nic, i kdy? se to tref?.
>>
>> c) Prov?d?t ru?n? kontrolu v?ech popisk? s p?ekryvem (t?ch m??e b?t
>> hodn?).
>>
>> Osobn? pova?uji c) za ?patn? ?e?en?. A mezi a) a b) nem?m vyhrazen?
>> n?zor. Mo?nost a) je sice teoreticky nejlep??, ale b) nemus? m?t
>> post?ehnuteln? hor?? v?sledky.
>>
>> Honza
>>
>>
>>
>> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>>> Doplnil jsem tam chyb?j?c? ??slici 4.
>>>
>>> Honza
>>>
>>> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>>>> K vyzkou?en?:
>>>> http://jabi.aspone.cz/osm/OcrBeta1.zip
>>>>
>>>> M? to stejn? ovl?d?n? jako p?vodn? tile-processor, ale nav?c mo?nost
>>>> logov?n?:
>>>>
>>>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv
>>>> -log log.txt -all
>>>>
>>>> -log log.txt ... pokud se toto uvede, tak program bude logovat
>>>> nerozpoznan? body nebo ty, kter? byly naru?en? p?ekryvem.
>>>>
>>>> Pokud se uvede nav?c -all, tak se budou logovat v?echny body.
>>>>
>>>> Soubor charDef.txt obsahuje definici znak? nebo posloupnosti znak?. Je
>>>> to tak? textov? soubor, kter? kdy? zobraz?te fontem s pevnou ???kou,
>>>> tak je mysl?m v?znam jasn?. Chyb? tam ??slice 4 posunut? dol? (tedy za
>>>> ?.o.), proto?e jsem na nic p?i pokusech nenarazil. Soubor mus? b?t p?i
>>>> spu?t?n? v aktu?ln?m adres??i.
>>>>
>>>> Honza
>>>>
>>>>
>>>> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>>>>> Na slu?n? detekci p?ekryv? pr?v? pracuji a mysl?m, ?e rozhodn? bude
>>>>> v?razn? lep?? ne? byla (to u? je mysl?m te?). Ale stoprocentn?
>>>>> samoz?ejm? ne - kdy? p?ekryv bude velk?, tak to ur?it? nep?jde.
>>>>>
>>>>> Ale jinak si mysl?m, ?e generov?n? dla?dic na serveru KN bude n?jakou
>>>>> dobu trvat - a to, a? je na t? dla?dici 5 bod? nebo t?eba jen jeden. A
>>>>> tak? jim to bude zat??ovat servery, kdy? se to p?e?ene s rychlost?
>>>>> stahov?n? (mnoho vl?ken apod.).
>>>>>
>>>>> Honza
>>>>>
>>>>>
>>>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>>> Kv?li p?ekryv?m - ??sla se s rozli?en?m zmen?uj?.
>>>>>> Nev?m, jak moc je tv?j algoritmus dokonal? v detekci p?ekr?vaj?c?ch
>>>>>> se
>>>>>> ??slic, ale nev???m, ?e dok??e? spolehliv? poznat, kde ??slo skon??.
>>>>>> Samoz?ejm? je to ot?zka n?jak?ho kompromisu, ale v?t?inu ?asu p?edt?m
>>>>>> zabralo po??t?n?.
>>>>>>
>>>>>> Mysl?m, ?e ale to dynamick? rozli?en?, kter? navrhuje?, nem? moc
>>>>>> cenu,
>>>>>> proto?e ty dla?dice jsou v PNG, tak?e by b?l? plochy nem?ly zab?rat
>>>>>> p??li?
>>>>>> mnoho datov?ho objemu. To sam? plat? pro vy??? rozli?en? - zpomalen?
>>>>>> m??e
>>>>>> nastat sp?? t?m, ?e je nutn? zpracovat v?t?? mno?stv? obrazov?
>>>>>> informace.
>>>>>>
>>>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak
>>>>>> <jan.bilak.osm at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Ahoj,
>>>>>>> k ?emu v?t?? rozli?en?? Sp??e jsem uva?oval nad dynamick?m
>>>>>>> rozli?en?m
>>>>>>> ... tedy stahovat v??ezy nejprve v mal?m rozli?en? a podle toho
>>>>>>> detekovat oblasti, kter? obsahuj? adresn? body. A jen tyto ?seky
>>>>>>> stahovat ve vy???m (t?eba st?vaj?c?m) rozli?en?. To by mohlo u?et?it
>>>>>>> mno?stv? stahovan?ch dat. P?ijde mi, ?e nejpomalej?? bude pr?v?
>>>>>>> stahov?n? dla?dic z WMS, tak?e obecn?m zv??en?m rozli?en? by se ?as
>>>>>>> prodlou?il.
>>>>>>>
>>>>>>> Mimochodem - nem?te n?kdo sta?en? dla?dice z n?jak? v?t?? oblasti,
>>>>>>> kter? byste mohli n?kam hodit zazipovan?, abych to nemusel stahovat
>>>>>>> z
>>>>>>> WMS pro testov?n??
>>>>>>>
>>>>>>> Honza
>>>>>>>
>>>>>>>
>>>>>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>>>>> Ahoj,
>>>>>>>>
>>>>>>>> zn? to dob?e, jestli by to opravdu neznamenalo p??li? mnoho ?asu,
>>>>>>>> tak by
>>>>>>>> mo?n? st?lo za to data kv?li t? chyb? p?ed?lat (pokud nav?c zlep??
>>>>>>>> detekci
>>>>>>>> u p?ekryv?, nebo d?ky rychlosti umo?n? stahovat dla?dice s v?t??m
>>>>>>>> zoomem,
>>>>>>>> tak to bude dal?? plus).
>>>>>>>>
>>>>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak
>>>>>>>> <jan.bilak.osm at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Ahoj,
>>>>>>>>>
>>>>>>>>> pokusn? implementace je velmi rychl? a m?la by b?t i spolehliv?.
>>>>>>>>>
>>>>>>>>> Zkou?el jsem to na 18 v??ezech 4000x4000 px. Celkov? ?as 7.2 s.
>>>>>>>>> Pr?m?rn? ?as zpracov?n? jednoho souboru je 405 ms, pr?m?rn? ?as
>>>>>>>>> zpracov?n? jednoho adresn?ho bodu je 17 ms. To v?e v jednom
>>>>>>>>> vl?kn? a
>>>>>>>>> tedy to zat??uje jen jedno j?dro procesoru.
>>>>>>>>>
>>>>>>>>> Z?tra to snad dod?l?m do pou?iteln?ho stavu.
>>>>>>>>>
>>>>>>>>> Honza
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>>>>>>> Ne, o to nejde. Ty ??sla jsou u? rozpoznan?, tak?e sta?? p?ed?lat
>>>>>>>>>> pouze
>>>>>>>>>> ta
>>>>>>>>>> eviden?n? ??sla (ty jsou posunut? trochu n?? od te?ky, tak?e je
>>>>>>>>>> tam ta
>>>>>>>>>> dvojka u??zl?), ve kter?ch je sedmi?ka. Nen? probl?m v tom, ?e
>>>>>>>>>> by to
>>>>>>>>>> ne?lo
>>>>>>>>>> u??znout o trochu n??. Probl?m je, ?e u? jsme to ud?lali ?patn?,
>>>>>>>>>> tak?e
>>>>>>>>>> by
>>>>>>>>>> to bylo dobr? napravit bez toho, abychom museli v?echno
>>>>>>>>>> p?ed?l?vat.
>>>>>>>>>>
>>>>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec
>>>>>>>>>> <utx at penguin.cz>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat
>>>>>>>>>>> u??znutou
>>>>>>>>>>> dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Petr Dlouh?
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Talk-cz mailing list
>>>>>>>>>> Talk-cz at openstreetmap.org
>>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Talk-cz mailing list
>>>>>>>>> Talk-cz at openstreetmap.org
>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Petr Dlouh?
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Talk-cz mailing list
>>>>>>>> Talk-cz at openstreetmap.org
>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Talk-cz mailing list
>>>>>>> Talk-cz at openstreetmap.org
>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Petr Dlouh?
>>>>>>
>>>>>> _______________________________________________
>>>>>> Talk-cz mailing list
>>>>>> Talk-cz at openstreetmap.org
>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Jinak ... kdy? si povol?? logov?n?, tak se loguje i grafick?
reprezentace toho textu, tak?e tam uvid??, co a jak to rozpozn?v?.
Honza
2010/2/13 Jan Bilak <jan.bilak.osm at gmail.com>:
zobrazit citaci
> Ahoj,
> ten copyright je vlevo naho?e, ale pak i na sou?adnici cca [530,510] px.
>
> Ta detekce bod? ... toho jsem si nev?iml. Jak to kontroluje??
>
> Check ... to zna?? opravdu i nepatrn? p?ekryv. Pokud si to nen? jist?,
> tak je tam znak otazn?k a v hranat?ch z?vork?ch seznam mo?nost?. Je?t?
> tam d?m jednu kontrolu a m?lo byt o b?t mysl?m 100% spolehliv?, kdy?
> tam nebude ??dn? ?erven? bod chyb?t (tedy je t?eba pou??t mo?nost a)
> nebo b) vypo??d?n? se s copyrightem).
>
> O?ez p?ed detekc? ned?l?m ... detekce si sama ??d?, kdy skon?it.
>
> Check by nem?lo b?t nic, co by bylo t?eba ru?n? kontrolovat - a? se
> vy?e?? ten copyright a p?id?m tam tu jednu drobnou kontrolu. T?ch
> mo?nost?, kdy se tam objev? otazn?k (nen? si to jist?) je mysl?m
> minimum. Zat?m se mi to nestalo.
>
> Honza
>
>
> 2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>:
>> Ahoj,
>>
>> ten copyright je jen ?pln? naho?e na ka?d? dla?dici, nebo se pletu? Pokud
>> tomu tak je, tak bych volil mo?nost a), proto?e je to minimum z velikosti
>> dla?dice, a ty se u? stejn? stahuj? s p?esahem (kv?li tomu, ?e se ??sla
>> kresl? jen na dla?dici s te?kou).
>>
>> Jinak jsem se koukal na ten skript, a zd? se to velice dobr?. Mysl?m, ?e
>> by st?lo za to to p?epo??tat, vzhledem k tomu, ?e je to tak 20x rychlej??,
>> tak to asi nebude probl?m ud?lat na jednou po??ta?i.
>>
>> Chyby vid?m n?sleduj?c?:
>>
>> -N?kter? adresn? body nejsou v?bec detekov?ny, a u n?kter?ch je pr?zdn?
>> text (p?esto?e jsou daleko od v?eho).
>> -?asto se objevuje [CHECK] i u bod?, kter? byly detekov?ny spr?vn?. Pokud
>> je to v p??padech, kdy se ??sla u? skute?n? p?ekr?vaj?, tak OK. Jenom se
>> pt?m, jestli nen? mo?n? zvolit agresivn?j?? o?ez p?ed detekc? (pozor na
>> jin? posunut? ?.e. vs ?.p.).
>> -V p??padech, kdy se objev? [CHECK], tak by asi skript m?l st?hnout ??slo
>> ve vy???m rozli?en? a detekovat to.
>>
>>
>> On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>> wrote:
>>
>>> Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy.
>>> Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne.
>>> Ale co tomu vadi, to je ten copyright. Zat?m toti? beru v ?vahu pouze
>>> ?ervenou barvu. Jsou 3 mo?nosti jak to ?e?it:
>>>
>>> a) stahovat dla?dice s p?ekryvem tak, ?e se bude rozpozn?vat pouze z
>>> t?ch ??st? mapy, kter? copyright nen?. V?hody: Nejlep?? v?sledky.
>>> Nev?hody: Nutnost stahovat v?ce dat z WMS.
>>>
>>> b) pova?ovat ?ernou barvu za ?ervenou. V?hody: Nejsou nutn? ?pravy
>>> downloaderu, u rozpozn?va?e jen trivi?ln? zm?na 3 konstant. Nev?hody:
>>> Drobn? zhor?en? rozpozn?v?n? v p??pad? p?ekryvu copyrightu s popiskem
>>> - pokud se to ne?ikovn? tref?, tak bude t?eba ru?n? rozpozn?n?, ale
>>> nemus? to znamenat nic, i kdy? se to tref?.
>>>
>>> c) Prov?d?t ru?n? kontrolu v?ech popisk? s p?ekryvem (t?ch m??e b?t
>>> hodn?).
>>>
>>> Osobn? pova?uji c) za ?patn? ?e?en?. A mezi a) a b) nem?m vyhrazen?
>>> n?zor. Mo?nost a) je sice teoreticky nejlep??, ale b) nemus? m?t
>>> post?ehnuteln? hor?? v?sledky.
>>>
>>> Honza
>>>
>>>
>>>
>>> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>>>> Doplnil jsem tam chyb?j?c? ??slici 4.
>>>>
>>>> Honza
>>>>
>>>> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>>>>> K vyzkou?en?:
>>>>> http://jabi.aspone.cz/osm/OcrBeta1.zip
>>>>>
>>>>> M? to stejn? ovl?d?n? jako p?vodn? tile-processor, ale nav?c mo?nost
>>>>> logov?n?:
>>>>>
>>>>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv
>>>>> -log log.txt -all
>>>>>
>>>>> -log log.txt ... pokud se toto uvede, tak program bude logovat
>>>>> nerozpoznan? body nebo ty, kter? byly naru?en? p?ekryvem.
>>>>>
>>>>> Pokud se uvede nav?c -all, tak se budou logovat v?echny body.
>>>>>
>>>>> Soubor charDef.txt obsahuje definici znak? nebo posloupnosti znak?. Je
>>>>> to tak? textov? soubor, kter? kdy? zobraz?te fontem s pevnou ???kou,
>>>>> tak je mysl?m v?znam jasn?. Chyb? tam ??slice 4 posunut? dol? (tedy za
>>>>> ?.o.), proto?e jsem na nic p?i pokusech nenarazil. Soubor mus? b?t p?i
>>>>> spu?t?n? v aktu?ln?m adres??i.
>>>>>
>>>>> Honza
>>>>>
>>>>>
>>>>> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>>>>>> Na slu?n? detekci p?ekryv? pr?v? pracuji a mysl?m, ?e rozhodn? bude
>>>>>> v?razn? lep?? ne? byla (to u? je mysl?m te?). Ale stoprocentn?
>>>>>> samoz?ejm? ne - kdy? p?ekryv bude velk?, tak to ur?it? nep?jde.
>>>>>>
>>>>>> Ale jinak si mysl?m, ?e generov?n? dla?dic na serveru KN bude n?jakou
>>>>>> dobu trvat - a to, a? je na t? dla?dici 5 bod? nebo t?eba jen jeden. A
>>>>>> tak? jim to bude zat??ovat servery, kdy? se to p?e?ene s rychlost?
>>>>>> stahov?n? (mnoho vl?ken apod.).
>>>>>>
>>>>>> Honza
>>>>>>
>>>>>>
>>>>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>>>> Kv?li p?ekryv?m - ??sla se s rozli?en?m zmen?uj?.
>>>>>>> Nev?m, jak moc je tv?j algoritmus dokonal? v detekci p?ekr?vaj?c?ch
>>>>>>> se
>>>>>>> ??slic, ale nev???m, ?e dok??e? spolehliv? poznat, kde ??slo skon??.
>>>>>>> Samoz?ejm? je to ot?zka n?jak?ho kompromisu, ale v?t?inu ?asu p?edt?m
>>>>>>> zabralo po??t?n?.
>>>>>>>
>>>>>>> Mysl?m, ?e ale to dynamick? rozli?en?, kter? navrhuje?, nem? moc
>>>>>>> cenu,
>>>>>>> proto?e ty dla?dice jsou v PNG, tak?e by b?l? plochy nem?ly zab?rat
>>>>>>> p??li?
>>>>>>> mnoho datov?ho objemu. To sam? plat? pro vy??? rozli?en? - zpomalen?
>>>>>>> m??e
>>>>>>> nastat sp?? t?m, ?e je nutn? zpracovat v?t?? mno?stv? obrazov?
>>>>>>> informace.
>>>>>>>
>>>>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak
>>>>>>> <jan.bilak.osm at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Ahoj,
>>>>>>>> k ?emu v?t?? rozli?en?? Sp??e jsem uva?oval nad dynamick?m
>>>>>>>> rozli?en?m
>>>>>>>> ... tedy stahovat v??ezy nejprve v mal?m rozli?en? a podle toho
>>>>>>>> detekovat oblasti, kter? obsahuj? adresn? body. A jen tyto ?seky
>>>>>>>> stahovat ve vy???m (t?eba st?vaj?c?m) rozli?en?. To by mohlo u?et?it
>>>>>>>> mno?stv? stahovan?ch dat. P?ijde mi, ?e nejpomalej?? bude pr?v?
>>>>>>>> stahov?n? dla?dic z WMS, tak?e obecn?m zv??en?m rozli?en? by se ?as
>>>>>>>> prodlou?il.
>>>>>>>>
>>>>>>>> Mimochodem - nem?te n?kdo sta?en? dla?dice z n?jak? v?t?? oblasti,
>>>>>>>> kter? byste mohli n?kam hodit zazipovan?, abych to nemusel stahovat
>>>>>>>> z
>>>>>>>> WMS pro testov?n??
>>>>>>>>
>>>>>>>> Honza
>>>>>>>>
>>>>>>>>
>>>>>>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>>>>>> Ahoj,
>>>>>>>>>
>>>>>>>>> zn? to dob?e, jestli by to opravdu neznamenalo p??li? mnoho ?asu,
>>>>>>>>> tak by
>>>>>>>>> mo?n? st?lo za to data kv?li t? chyb? p?ed?lat (pokud nav?c zlep??
>>>>>>>>> detekci
>>>>>>>>> u p?ekryv?, nebo d?ky rychlosti umo?n? stahovat dla?dice s v?t??m
>>>>>>>>> zoomem,
>>>>>>>>> tak to bude dal?? plus).
>>>>>>>>>
>>>>>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak
>>>>>>>>> <jan.bilak.osm at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Ahoj,
>>>>>>>>>>
>>>>>>>>>> pokusn? implementace je velmi rychl? a m?la by b?t i spolehliv?.
>>>>>>>>>>
>>>>>>>>>> Zkou?el jsem to na 18 v??ezech 4000x4000 px. Celkov? ?as 7.2 s.
>>>>>>>>>> Pr?m?rn? ?as zpracov?n? jednoho souboru je 405 ms, pr?m?rn? ?as
>>>>>>>>>> zpracov?n? jednoho adresn?ho bodu je 17 ms. To v?e v jednom
>>>>>>>>>> vl?kn? a
>>>>>>>>>> tedy to zat??uje jen jedno j?dro procesoru.
>>>>>>>>>>
>>>>>>>>>> Z?tra to snad dod?l?m do pou?iteln?ho stavu.
>>>>>>>>>>
>>>>>>>>>> Honza
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>>>>>>>> Ne, o to nejde. Ty ??sla jsou u? rozpoznan?, tak?e sta?? p?ed?lat
>>>>>>>>>>> pouze
>>>>>>>>>>> ta
>>>>>>>>>>> eviden?n? ??sla (ty jsou posunut? trochu n?? od te?ky, tak?e je
>>>>>>>>>>> tam ta
>>>>>>>>>>> dvojka u??zl?), ve kter?ch je sedmi?ka. Nen? probl?m v tom, ?e
>>>>>>>>>>> by to
>>>>>>>>>>> ne?lo
>>>>>>>>>>> u??znout o trochu n??. Probl?m je, ?e u? jsme to ud?lali ?patn?,
>>>>>>>>>>> tak?e
>>>>>>>>>>> by
>>>>>>>>>>> to bylo dobr? napravit bez toho, abychom museli v?echno
>>>>>>>>>>> p?ed?l?vat.
>>>>>>>>>>>
>>>>>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec
>>>>>>>>>>> <utx at penguin.cz>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat
>>>>>>>>>>>> u??znutou
>>>>>>>>>>>> dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Petr Dlouh?
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Talk-cz mailing list
>>>>>>>>>>> Talk-cz at openstreetmap.org
>>>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Talk-cz mailing list
>>>>>>>>>> Talk-cz at openstreetmap.org
>>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Petr Dlouh?
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Talk-cz mailing list
>>>>>>>>> Talk-cz at openstreetmap.org
>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Talk-cz mailing list
>>>>>>>> Talk-cz at openstreetmap.org
>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Petr Dlouh?
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Talk-cz mailing list
>>>>>>> Talk-cz at openstreetmap.org
>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>> --
>> Petr Dlouh?
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
Ahoj,
teprv te? jsem si v?iml toho kr?sn?ho logu. O?ez by mohl b?t o 1 pixel
ni??? a o n?co u??? (nev?m ale kolikacifern? je nejdel?? adresa).
Dal?? n?pady na sn??en? mno?stv? [CHECK] jsou:
Pokud adresa za??n? na "bez ?.p./?.e." tak nen? nutn? d?vat [CHECK], ale
sta?? o??znout zbytek ?et?zce (t?m se vy?ad? tak polovina p??pad?).
Pokud je tam nav?c pouze p?r bod? ni???ch ne? ??slice/p?smeno, nemohou ji
tvo?it, a tud?? nen? nutn? d?vat [CHECK], proto?e se tam nemohl p?ipl?st
n?jak? dal?? adresn? bod, kter? by musel za??nat na ? nebo b.
Pro vypo??d?n? s copyrightem existuje je?t? mo?nost d) - pokud si skript nen? jist v?sledkem, tak si st?hne zazoomovan? ??slo, tak?e mu mu?e b?t copyright jedno.
Spolehliv? to nen? hlavn? v m?stech, kde je n?kolik adres v jednom shluku (pom?rn? bl?zko sebe).
Kontroluju to tak, ?e si vygeneruju adresn? body pomoc? Merge skriptu a
otev?u to v JOSM.
PS. Jestli po??d sh?n?? testovac? data, m??u ti poslat celou prahu-z?pad, myslel jsem, ?e u? jsem j? smazal, ale nen? tomu tak.
zobrazit citaci
> ------------ P?vodn? zpr?va ------------
> Od: Petr Dlouh? <petr.dlouhy at email.cz>
> P?edm?t: Re: [Talk-cz] Import adres z katastralni mapy
> Datum: 13.2.2010 00:29:16
> ----------------------------------------
> Ahoj,
>
> ten copyright je jen ?pln? naho?e na ka?d? dla?dici, nebo se pletu? Pokud
> tomu tak je, tak bych volil mo?nost a), proto?e je to minimum z velikosti
> dla?dice, a ty se u? stejn? stahuj? s p?esahem (kv?li tomu, ?e se ??sla
> kresl? jen na dla?dici s te?kou).
>
> Jinak jsem se koukal na ten skript, a zd? se to velice dobr?. Mysl?m, ?e
> by st?lo za to to p?epo??tat, vzhledem k tomu, ?e je to tak 20x rychlej??,
> tak to asi nebude probl?m ud?lat na jednou po??ta?i.
>
> Chyby vid?m n?sleduj?c?:
>
> -N?kter? adresn? body nejsou v?bec detekov?ny, a u n?kter?ch je pr?zdn?
> text (p?esto?e jsou daleko od v?eho).
> -?asto se objevuje [CHECK] i u bod?, kter? byly detekov?ny spr?vn?. Pokud
> je to v p??padech, kdy se ??sla u? skute?n? p?ekr?vaj?, tak OK. Jenom se
> pt?m, jestli nen? mo?n? zvolit agresivn?j?? o?ez p?ed detekc? (pozor na
> jin? posunut? ?.e. vs ?.p.).
> -V p??padech, kdy se objev? [CHECK], tak by asi skript m?l st?hnout ??slo
> ve vy???m rozli?en? a detekovat to.
>
>
> On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
> wrote:
>
> > Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy.
> > Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne.
> > Ale co tomu vadi, to je ten copyright. Zat?m toti? beru v ?vahu pouze
> > ?ervenou barvu. Jsou 3 mo?nosti jak to ?e?it:
> >
> > a) stahovat dla?dice s p?ekryvem tak, ?e se bude rozpozn?vat pouze z
> > t?ch ??st? mapy, kter? copyright nen?. V?hody: Nejlep?? v?sledky.
> > Nev?hody: Nutnost stahovat v?ce dat z WMS.
> >
> > b) pova?ovat ?ernou barvu za ?ervenou. V?hody: Nejsou nutn? ?pravy
> > downloaderu, u rozpozn?va?e jen trivi?ln? zm?na 3 konstant. Nev?hody:
> > Drobn? zhor?en? rozpozn?v?n? v p??pad? p?ekryvu copyrightu s popiskem
> > - pokud se to ne?ikovn? tref?, tak bude t?eba ru?n? rozpozn?n?, ale
> > nemus? to znamenat nic, i kdy? se to tref?.
> >
> > c) Prov?d?t ru?n? kontrolu v?ech popisk? s p?ekryvem (t?ch m??e b?t
> > hodn?).
> >
> > Osobn? pova?uji c) za ?patn? ?e?en?. A mezi a) a b) nem?m vyhrazen?
> > n?zor. Mo?nost a) je sice teoreticky nejlep??, ale b) nemus? m?t
> > post?ehnuteln? hor?? v?sledky.
> >
> > Honza
> >
> >
> >
> > 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
> >> Doplnil jsem tam chyb?j?c? ??slici 4.
> >>
> >> Honza
> >>
> >> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
> >>> K vyzkou?en?:
> >>> http://jabi.aspone.cz/osm/OcrBeta1.zip
> >>>
> >>> M? to stejn? ovl?d?n? jako p?vodn? tile-processor, ale nav?c mo?nost
> >>> logov?n?:
> >>>
> >>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv
> >>> -log log.txt -all
> >>>
> >>> -log log.txt ... pokud se toto uvede, tak program bude logovat
> >>> nerozpoznan? body nebo ty, kter? byly naru?en? p?ekryvem.
> >>>
> >>> Pokud se uvede nav?c -all, tak se budou logovat v?echny body.
> >>>
> >>> Soubor charDef.txt obsahuje definici znak? nebo posloupnosti znak?. Je
> >>> to tak? textov? soubor, kter? kdy? zobraz?te fontem s pevnou ???kou,
> >>> tak je mysl?m v?znam jasn?. Chyb? tam ??slice 4 posunut? dol? (tedy za
> >>> ?.o.), proto?e jsem na nic p?i pokusech nenarazil. Soubor mus? b?t p?i
> >>> spu?t?n? v aktu?ln?m adres??i.
> >>>
> >>> Honza
> >>>
> >>>
> >>> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
> >>>> Na slu?n? detekci p?ekryv? pr?v? pracuji a mysl?m, ?e rozhodn? bude
> >>>> v?razn? lep?? ne? byla (to u? je mysl?m te?). Ale stoprocentn?
> >>>> samoz?ejm? ne - kdy? p?ekryv bude velk?, tak to ur?it? nep?jde.
> >>>>
> >>>> Ale jinak si mysl?m, ?e generov?n? dla?dic na serveru KN bude n?jakou
> >>>> dobu trvat - a to, a? je na t? dla?dici 5 bod? nebo t?eba jen jeden. A
> >>>> tak? jim to bude zat??ovat servery, kdy? se to p?e?ene s rychlost?
> >>>> stahov?n? (mnoho vl?ken apod.).
> >>>>
> >>>> Honza
> >>>>
> >>>>
> >>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
> >>>>> Kv?li p?ekryv?m - ??sla se s rozli?en?m zmen?uj?.
> >>>>> Nev?m, jak moc je tv?j algoritmus dokonal? v detekci p?ekr?vaj?c?ch
> >>>>> se
> >>>>> ??slic, ale nev???m, ?e dok??e? spolehliv? poznat, kde ??slo skon??.
> >>>>> Samoz?ejm? je to ot?zka n?jak?ho kompromisu, ale v?t?inu ?asu p?edt?m
> >>>>> zabralo po??t?n?.
> >>>>>
> >>>>> Mysl?m, ?e ale to dynamick? rozli?en?, kter? navrhuje?, nem? moc
> >>>>> cenu,
> >>>>> proto?e ty dla?dice jsou v PNG, tak?e by b?l? plochy nem?ly zab?rat
> >>>>> p??li?
> >>>>> mnoho datov?ho objemu. To sam? plat? pro vy??? rozli?en? - zpomalen?
> >>>>> m??e
> >>>>> nastat sp?? t?m, ?e je nutn? zpracovat v?t?? mno?stv? obrazov?
> >>>>> informace.
> >>>>>
> >>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak
> >>>>> <jan.bilak.osm at gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Ahoj,
> >>>>>> k ?emu v?t?? rozli?en?? Sp??e jsem uva?oval nad dynamick?m
> >>>>>> rozli?en?m
> >>>>>> ... tedy stahovat v??ezy nejprve v mal?m rozli?en? a podle toho
> >>>>>> detekovat oblasti, kter? obsahuj? adresn? body. A jen tyto ?seky
> >>>>>> stahovat ve vy???m (t?eba st?vaj?c?m) rozli?en?. To by mohlo u?et?it
> >>>>>> mno?stv? stahovan?ch dat. P?ijde mi, ?e nejpomalej?? bude pr?v?
> >>>>>> stahov?n? dla?dic z WMS, tak?e obecn?m zv??en?m rozli?en? by se ?as
> >>>>>> prodlou?il.
> >>>>>>
> >>>>>> Mimochodem - nem?te n?kdo sta?en? dla?dice z n?jak? v?t?? oblasti,
> >>>>>> kter? byste mohli n?kam hodit zazipovan?, abych to nemusel stahovat
> >>>>>> z
> >>>>>> WMS pro testov?n??
> >>>>>>
> >>>>>> Honza
> >>>>>>
> >>>>>>
> >>>>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
> >>>>>>> Ahoj,
> >>>>>>>
> >>>>>>> zn? to dob?e, jestli by to opravdu neznamenalo p??li? mnoho ?asu,
> >>>>>>> tak by
> >>>>>>> mo?n? st?lo za to data kv?li t? chyb? p?ed?lat (pokud nav?c zlep??
> >>>>>>> detekci
> >>>>>>> u p?ekryv?, nebo d?ky rychlosti umo?n? stahovat dla?dice s v?t??m
> >>>>>>> zoomem,
> >>>>>>> tak to bude dal?? plus).
> >>>>>>>
> >>>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak
> >>>>>>> <jan.bilak.osm at gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Ahoj,
> >>>>>>>>
> >>>>>>>> pokusn? implementace je velmi rychl? a m?la by b?t i spolehliv?.
> >>>>>>>>
> >>>>>>>> Zkou?el jsem to na 18 v??ezech 4000x4000 px. Celkov? ?as 7.2 s.
> >>>>>>>> Pr?m?rn? ?as zpracov?n? jednoho souboru je 405 ms, pr?m?rn? ?as
> >>>>>>>> zpracov?n? jednoho adresn?ho bodu je 17 ms. To v?e v jednom
> >>>>>>>> vl?kn? a
> >>>>>>>> tedy to zat??uje jen jedno j?dro procesoru.
> >>>>>>>>
> >>>>>>>> Z?tra to snad dod?l?m do pou?iteln?ho stavu.
> >>>>>>>>
> >>>>>>>> Honza
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
> >>>>>>>>> Ne, o to nejde. Ty ??sla jsou u? rozpoznan?, tak?e sta?? p?ed?lat
> >>>>>>>>> pouze
> >>>>>>>>> ta
> >>>>>>>>> eviden?n? ??sla (ty jsou posunut? trochu n?? od te?ky, tak?e je
> >>>>>>>>> tam ta
> >>>>>>>>> dvojka u??zl?), ve kter?ch je sedmi?ka. Nen? probl?m v tom, ?e
> >>>>>>>>> by to
> >>>>>>>>> ne?lo
> >>>>>>>>> u??znout o trochu n??. Probl?m je, ?e u? jsme to ud?lali ?patn?,
> >>>>>>>>> tak?e
> >>>>>>>>> by
> >>>>>>>>> to bylo dobr? napravit bez toho, abychom museli v?echno
> >>>>>>>>> p?ed?l?vat.
> >>>>>>>>>
> >>>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec
> >>>>>>>>> <utx at penguin.cz>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat
> >>>>>>>>>> u??znutou
> >>>>>>>>>> dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Petr Dlouh?
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Talk-cz mailing list
> >>>>>>>>> Talk-cz at openstreetmap.org
> >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Talk-cz mailing list
> >>>>>>>> Talk-cz at openstreetmap.org
> >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Petr Dlouh?
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Talk-cz mailing list
> >>>>>>> Talk-cz at openstreetmap.org
> >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
> >>>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Talk-cz mailing list
> >>>>>> Talk-cz at openstreetmap.org
> >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Petr Dlouh?
> >>>>>
> >>>>> _______________________________________________
> >>>>> Talk-cz mailing list
> >>>>> Talk-cz at openstreetmap.org
> >>>>> http://lists.openstreetmap.org/listinfo/talk-cz
> >>>>>
> >>>>
> >>>
> >>
> >
> > _______________________________________________
> > Talk-cz mailing list
> > Talk-cz at openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-cz
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
Petr Dlouh?
petr.dlouhy at email.cz
Ty body, kter? nemaj? rozpoznan? popisky, jsou mysl?m p??li? u kraje.
Tedy nyn? tam m?m n?jak? tvrd? limit podle vzd?lenosti bodu od kraje
(tu??m 120px od prav?ho okraje, a cca 20 od horn?ho). Na plo?e, kde to
m? rozpozn?vat, je t?eba se dohodnout. Pokud m?? n?jak? p??pad, kter?
nen? takto bl?zko kraje, tak mi pros?m po?li dla?dici. P?id?m tamk
takov?m bod?m zat?m popisek [out-of-box] do csv souboru.
A ocen?m i zasl?n? dla?dice, kde bod nebyl nalezen v?bec.
Honza
2010/2/13 Jan Bilak <jan.bilak.osm at gmail.com>:
zobrazit citaci
> Jinak ... kdy? si povol?? logov?n?, tak se loguje i grafick?
> reprezentace toho textu, tak?e tam uvid??, co a jak to rozpozn?v?.
>
> Honza
>
>
> 2010/2/13 Jan Bilak <jan.bilak.osm at gmail.com>:
>> Ahoj,
>> ten copyright je vlevo naho?e, ale pak i na sou?adnici cca [530,510] px.
>>
>> Ta detekce bod? ... toho jsem si nev?iml. Jak to kontroluje??
>>
>> Check ... to zna?? opravdu i nepatrn? p?ekryv. Pokud si to nen? jist?,
>> tak je tam znak otazn?k a v hranat?ch z?vork?ch seznam mo?nost?. Je?t?
>> tam d?m jednu kontrolu a m?lo byt o b?t mysl?m 100% spolehliv?, kdy?
>> tam nebude ??dn? ?erven? bod chyb?t (tedy je t?eba pou??t mo?nost a)
>> nebo b) vypo??d?n? se s copyrightem).
>>
>> O?ez p?ed detekc? ned?l?m ... detekce si sama ??d?, kdy skon?it.
>>
>> Check by nem?lo b?t nic, co by bylo t?eba ru?n? kontrolovat - a? se
>> vy?e?? ten copyright a p?id?m tam tu jednu drobnou kontrolu. T?ch
>> mo?nost?, kdy se tam objev? otazn?k (nen? si to jist?) je mysl?m
>> minimum. Zat?m se mi to nestalo.
>>
>> Honza
>>
>>
>> 2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>:
>>> Ahoj,
>>>
>>> ten copyright je jen ?pln? naho?e na ka?d? dla?dici, nebo se pletu? Pokud
>>> tomu tak je, tak bych volil mo?nost a), proto?e je to minimum z velikosti
>>> dla?dice, a ty se u? stejn? stahuj? s p?esahem (kv?li tomu, ?e se ??sla
>>> kresl? jen na dla?dici s te?kou).
>>>
>>> Jinak jsem se koukal na ten skript, a zd? se to velice dobr?. Mysl?m, ?e
>>> by st?lo za to to p?epo??tat, vzhledem k tomu, ?e je to tak 20x rychlej??,
>>> tak to asi nebude probl?m ud?lat na jednou po??ta?i.
>>>
>>> Chyby vid?m n?sleduj?c?:
>>>
>>> -N?kter? adresn? body nejsou v?bec detekov?ny, a u n?kter?ch je pr?zdn?
>>> text (p?esto?e jsou daleko od v?eho).
>>> -?asto se objevuje [CHECK] i u bod?, kter? byly detekov?ny spr?vn?. Pokud
>>> je to v p??padech, kdy se ??sla u? skute?n? p?ekr?vaj?, tak OK. Jenom se
>>> pt?m, jestli nen? mo?n? zvolit agresivn?j?? o?ez p?ed detekc? (pozor na
>>> jin? posunut? ?.e. vs ?.p.).
>>> -V p??padech, kdy se objev? [CHECK], tak by asi skript m?l st?hnout ??slo
>>> ve vy???m rozli?en? a detekovat to.
>>>
>>>
>>> On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>>> wrote:
>>>
>>>> Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy.
>>>> Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne.
>>>> Ale co tomu vadi, to je ten copyright. Zat?m toti? beru v ?vahu pouze
>>>> ?ervenou barvu. Jsou 3 mo?nosti jak to ?e?it:
>>>>
>>>> a) stahovat dla?dice s p?ekryvem tak, ?e se bude rozpozn?vat pouze z
>>>> t?ch ??st? mapy, kter? copyright nen?. V?hody: Nejlep?? v?sledky.
>>>> Nev?hody: Nutnost stahovat v?ce dat z WMS.
>>>>
>>>> b) pova?ovat ?ernou barvu za ?ervenou. V?hody: Nejsou nutn? ?pravy
>>>> downloaderu, u rozpozn?va?e jen trivi?ln? zm?na 3 konstant. Nev?hody:
>>>> Drobn? zhor?en? rozpozn?v?n? v p??pad? p?ekryvu copyrightu s popiskem
>>>> - pokud se to ne?ikovn? tref?, tak bude t?eba ru?n? rozpozn?n?, ale
>>>> nemus? to znamenat nic, i kdy? se to tref?.
>>>>
>>>> c) Prov?d?t ru?n? kontrolu v?ech popisk? s p?ekryvem (t?ch m??e b?t
>>>> hodn?).
>>>>
>>>> Osobn? pova?uji c) za ?patn? ?e?en?. A mezi a) a b) nem?m vyhrazen?
>>>> n?zor. Mo?nost a) je sice teoreticky nejlep??, ale b) nemus? m?t
>>>> post?ehnuteln? hor?? v?sledky.
>>>>
>>>> Honza
>>>>
>>>>
>>>>
>>>> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>>>>> Doplnil jsem tam chyb?j?c? ??slici 4.
>>>>>
>>>>> Honza
>>>>>
>>>>> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>>>>>> K vyzkou?en?:
>>>>>> http://jabi.aspone.cz/osm/OcrBeta1.zip
>>>>>>
>>>>>> M? to stejn? ovl?d?n? jako p?vodn? tile-processor, ale nav?c mo?nost
>>>>>> logov?n?:
>>>>>>
>>>>>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv
>>>>>> -log log.txt -all
>>>>>>
>>>>>> -log log.txt ... pokud se toto uvede, tak program bude logovat
>>>>>> nerozpoznan? body nebo ty, kter? byly naru?en? p?ekryvem.
>>>>>>
>>>>>> Pokud se uvede nav?c -all, tak se budou logovat v?echny body.
>>>>>>
>>>>>> Soubor charDef.txt obsahuje definici znak? nebo posloupnosti znak?. Je
>>>>>> to tak? textov? soubor, kter? kdy? zobraz?te fontem s pevnou ???kou,
>>>>>> tak je mysl?m v?znam jasn?. Chyb? tam ??slice 4 posunut? dol? (tedy za
>>>>>> ?.o.), proto?e jsem na nic p?i pokusech nenarazil. Soubor mus? b?t p?i
>>>>>> spu?t?n? v aktu?ln?m adres??i.
>>>>>>
>>>>>> Honza
>>>>>>
>>>>>>
>>>>>> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>>>>>>> Na slu?n? detekci p?ekryv? pr?v? pracuji a mysl?m, ?e rozhodn? bude
>>>>>>> v?razn? lep?? ne? byla (to u? je mysl?m te?). Ale stoprocentn?
>>>>>>> samoz?ejm? ne - kdy? p?ekryv bude velk?, tak to ur?it? nep?jde.
>>>>>>>
>>>>>>> Ale jinak si mysl?m, ?e generov?n? dla?dic na serveru KN bude n?jakou
>>>>>>> dobu trvat - a to, a? je na t? dla?dici 5 bod? nebo t?eba jen jeden. A
>>>>>>> tak? jim to bude zat??ovat servery, kdy? se to p?e?ene s rychlost?
>>>>>>> stahov?n? (mnoho vl?ken apod.).
>>>>>>>
>>>>>>> Honza
>>>>>>>
>>>>>>>
>>>>>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>>>>> Kv?li p?ekryv?m - ??sla se s rozli?en?m zmen?uj?.
>>>>>>>> Nev?m, jak moc je tv?j algoritmus dokonal? v detekci p?ekr?vaj?c?ch
>>>>>>>> se
>>>>>>>> ??slic, ale nev???m, ?e dok??e? spolehliv? poznat, kde ??slo skon??.
>>>>>>>> Samoz?ejm? je to ot?zka n?jak?ho kompromisu, ale v?t?inu ?asu p?edt?m
>>>>>>>> zabralo po??t?n?.
>>>>>>>>
>>>>>>>> Mysl?m, ?e ale to dynamick? rozli?en?, kter? navrhuje?, nem? moc
>>>>>>>> cenu,
>>>>>>>> proto?e ty dla?dice jsou v PNG, tak?e by b?l? plochy nem?ly zab?rat
>>>>>>>> p??li?
>>>>>>>> mnoho datov?ho objemu. To sam? plat? pro vy??? rozli?en? - zpomalen?
>>>>>>>> m??e
>>>>>>>> nastat sp?? t?m, ?e je nutn? zpracovat v?t?? mno?stv? obrazov?
>>>>>>>> informace.
>>>>>>>>
>>>>>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak
>>>>>>>> <jan.bilak.osm at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Ahoj,
>>>>>>>>> k ?emu v?t?? rozli?en?? Sp??e jsem uva?oval nad dynamick?m
>>>>>>>>> rozli?en?m
>>>>>>>>> ... tedy stahovat v??ezy nejprve v mal?m rozli?en? a podle toho
>>>>>>>>> detekovat oblasti, kter? obsahuj? adresn? body. A jen tyto ?seky
>>>>>>>>> stahovat ve vy???m (t?eba st?vaj?c?m) rozli?en?. To by mohlo u?et?it
>>>>>>>>> mno?stv? stahovan?ch dat. P?ijde mi, ?e nejpomalej?? bude pr?v?
>>>>>>>>> stahov?n? dla?dic z WMS, tak?e obecn?m zv??en?m rozli?en? by se ?as
>>>>>>>>> prodlou?il.
>>>>>>>>>
>>>>>>>>> Mimochodem - nem?te n?kdo sta?en? dla?dice z n?jak? v?t?? oblasti,
>>>>>>>>> kter? byste mohli n?kam hodit zazipovan?, abych to nemusel stahovat
>>>>>>>>> z
>>>>>>>>> WMS pro testov?n??
>>>>>>>>>
>>>>>>>>> Honza
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>>>>>>> Ahoj,
>>>>>>>>>>
>>>>>>>>>> zn? to dob?e, jestli by to opravdu neznamenalo p??li? mnoho ?asu,
>>>>>>>>>> tak by
>>>>>>>>>> mo?n? st?lo za to data kv?li t? chyb? p?ed?lat (pokud nav?c zlep??
>>>>>>>>>> detekci
>>>>>>>>>> u p?ekryv?, nebo d?ky rychlosti umo?n? stahovat dla?dice s v?t??m
>>>>>>>>>> zoomem,
>>>>>>>>>> tak to bude dal?? plus).
>>>>>>>>>>
>>>>>>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak
>>>>>>>>>> <jan.bilak.osm at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Ahoj,
>>>>>>>>>>>
>>>>>>>>>>> pokusn? implementace je velmi rychl? a m?la by b?t i spolehliv?.
>>>>>>>>>>>
>>>>>>>>>>> Zkou?el jsem to na 18 v??ezech 4000x4000 px. Celkov? ?as 7.2 s.
>>>>>>>>>>> Pr?m?rn? ?as zpracov?n? jednoho souboru je 405 ms, pr?m?rn? ?as
>>>>>>>>>>> zpracov?n? jednoho adresn?ho bodu je 17 ms. To v?e v jednom
>>>>>>>>>>> vl?kn? a
>>>>>>>>>>> tedy to zat??uje jen jedno j?dro procesoru.
>>>>>>>>>>>
>>>>>>>>>>> Z?tra to snad dod?l?m do pou?iteln?ho stavu.
>>>>>>>>>>>
>>>>>>>>>>> Honza
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>>>>>>>>>> Ne, o to nejde. Ty ??sla jsou u? rozpoznan?, tak?e sta?? p?ed?lat
>>>>>>>>>>>> pouze
>>>>>>>>>>>> ta
>>>>>>>>>>>> eviden?n? ??sla (ty jsou posunut? trochu n?? od te?ky, tak?e je
>>>>>>>>>>>> tam ta
>>>>>>>>>>>> dvojka u??zl?), ve kter?ch je sedmi?ka. Nen? probl?m v tom, ?e
>>>>>>>>>>>> by to
>>>>>>>>>>>> ne?lo
>>>>>>>>>>>> u??znout o trochu n??. Probl?m je, ?e u? jsme to ud?lali ?patn?,
>>>>>>>>>>>> tak?e
>>>>>>>>>>>> by
>>>>>>>>>>>> to bylo dobr? napravit bez toho, abychom museli v?echno
>>>>>>>>>>>> p?ed?l?vat.
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec
>>>>>>>>>>>> <utx at penguin.cz>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat
>>>>>>>>>>>>> u??znutou
>>>>>>>>>>>>> dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Petr Dlouh?
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Talk-cz mailing list
>>>>>>>>>>>> Talk-cz at openstreetmap.org
>>>>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Talk-cz mailing list
>>>>>>>>>>> Talk-cz at openstreetmap.org
>>>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Petr Dlouh?
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Talk-cz mailing list
>>>>>>>>>> Talk-cz at openstreetmap.org
>>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Talk-cz mailing list
>>>>>>>>> Talk-cz at openstreetmap.org
>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Petr Dlouh?
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Talk-cz mailing list
>>>>>>>> Talk-cz at openstreetmap.org
>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Talk-cz mailing list
>>>> Talk-cz at openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>>
>>> --
>>> Petr Dlouh?
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>
>
O?ez by mohl b?t ni???, ale j? to ka?d? sloupec reprezentuji
16-bitov?m ??slem (16 ??dek) a pak s t?m d?l?m r?zn? bitov? operace.
Tak?e 15 by se mi nehodilo...
Tyhle n?pady jsou dobr?, ale nejsou t?eba. Algoritmus toti? funguje
tak, ?e se sna?? naj?t nap?ed p?esnou shodu. A pokud p?esn? shoda
nen?, tak naj?t v?echny mo?nosti, kter? tam mohou b?t. Pokud je v?ce
mo?nost?, co by tam mohlo b?t, tak to do textu p?id? ?. Pokud jedna
mo?nost, tak ji to bere jako spr?vnou. A pokud ??d? mo?nost, tak to
kon??. Check je jen indikace toho, ?e tam nebyla p?esn? shoda. Otazn?k
je indikace toho, ?e to bylo mnohozna?n?. Zat?m tam tedy chyb? jedna
kontrola, kter? teoreticky m??e zp?sobit chybu bez ot?zn?ku (jen s
checkem). Ale to oprav?m a pravd?podobnost takov? chyby je velmi mal?.
Testovac? data by se mi hodila, pokud m?? kam d?t n?jak? archiv
(klidn? na n?jak? free one-file hosting typu rapidshare - ale ??et tam
nikde nem?m, tak aby to bylo re?ln? st?hnout zdarma).
Honza
2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Ahoj,
>
> teprv te? jsem si v?iml toho kr?sn?ho logu. O?ez by mohl b?t o 1 pixel
> ni??? a o n?co u??? (nev?m ale kolikacifern? je nejdel?? adresa).
> Dal?? n?pady na sn??en? mno?stv? [CHECK] jsou:
> ? ? ? ?Pokud adresa za??n? na "bez ?.p./?.e." tak nen? nutn? d?vat [CHECK], ale
> sta?? o??znout zbytek ?et?zce (t?m se vy?ad? tak polovina p??pad?).
> ? ? ? ?Pokud je tam nav?c pouze p?r bod? ni???ch ne? ??slice/p?smeno, nemohou ji
> tvo?it, a tud?? nen? nutn? d?vat [CHECK], proto?e se tam nemohl p?ipl?st
> n?jak? dal?? adresn? bod, kter? by musel za??nat na ? nebo b.
>
> Pro vypo??d?n? s copyrightem existuje je?t? mo?nost d) - pokud si skript nen? jist v?sledkem, tak si st?hne zazoomovan? ??slo, tak?e mu mu?e b?t copyright jedno.
> Spolehliv? to nen? hlavn? v m?stech, kde je n?kolik adres v jednom shluku (pom?rn? bl?zko sebe).
>
> Kontroluju to tak, ?e si vygeneruju adresn? body pomoc? Merge skriptu a
> otev?u to v JOSM.
>
> PS. Jestli po??d sh?n?? testovac? data, m??u ti poslat celou prahu-z?pad, myslel jsem, ?e u? jsem j? smazal, ale nen? tomu tak.
>
>> ------------ P?vodn? zpr?va ------------
>> Od: Petr Dlouh? <petr.dlouhy at email.cz>
>> P?edm?t: Re: [Talk-cz] Import adres z katastralni mapy
>> Datum: 13.2.2010 00:29:16
>> ----------------------------------------
>> Ahoj,
>>
>> ten copyright je jen ?pln? naho?e na ka?d? dla?dici, nebo se pletu? Pokud
>> tomu tak je, tak bych volil mo?nost a), proto?e je to minimum z velikosti
>> dla?dice, a ty se u? stejn? stahuj? s p?esahem (kv?li tomu, ?e se ??sla
>> kresl? jen na dla?dici s te?kou).
>>
>> Jinak jsem se koukal na ten skript, a zd? se to velice dobr?. Mysl?m, ?e
>> by st?lo za to to p?epo??tat, vzhledem k tomu, ?e je to tak 20x rychlej??,
>> tak to asi nebude probl?m ud?lat na jednou po??ta?i.
>>
>> Chyby vid?m n?sleduj?c?:
>>
>> -N?kter? adresn? body nejsou v?bec detekov?ny, a u n?kter?ch je pr?zdn?
>> text (p?esto?e jsou daleko od v?eho).
>> -?asto se objevuje [CHECK] i u bod?, kter? byly detekov?ny spr?vn?. Pokud
>> je to v p??padech, kdy se ??sla u? skute?n? p?ekr?vaj?, tak OK. Jenom se
>> pt?m, jestli nen? mo?n? zvolit agresivn?j?? o?ez p?ed detekc? (pozor na
>> jin? posunut? ?.e. vs ?.p.).
>> -V p??padech, kdy se objev? [CHECK], tak by asi skript m?l st?hnout ??slo
>> ve vy???m rozli?en? a detekovat to.
>>
>>
>> On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>> wrote:
>>
>> > Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy.
>> > Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne.
>> > Ale co tomu vadi, to je ten copyright. Zat?m toti? beru v ?vahu pouze
>> > ?ervenou barvu. Jsou 3 mo?nosti jak to ?e?it:
>> >
>> > a) stahovat dla?dice s p?ekryvem tak, ?e se bude rozpozn?vat pouze z
>> > t?ch ??st? mapy, kter? copyright nen?. V?hody: Nejlep?? v?sledky.
>> > Nev?hody: Nutnost stahovat v?ce dat z WMS.
>> >
>> > b) pova?ovat ?ernou barvu za ?ervenou. V?hody: Nejsou nutn? ?pravy
>> > downloaderu, u rozpozn?va?e jen trivi?ln? zm?na 3 konstant. Nev?hody:
>> > Drobn? zhor?en? rozpozn?v?n? v p??pad? p?ekryvu copyrightu s popiskem
>> > - pokud se to ne?ikovn? tref?, tak bude t?eba ru?n? rozpozn?n?, ale
>> > nemus? to znamenat nic, i kdy? se to tref?.
>> >
>> > c) Prov?d?t ru?n? kontrolu v?ech popisk? s p?ekryvem (t?ch m??e b?t
>> > hodn?).
>> >
>> > Osobn? pova?uji c) za ?patn? ?e?en?. A mezi a) a b) nem?m vyhrazen?
>> > n?zor. Mo?nost a) je sice teoreticky nejlep??, ale b) nemus? m?t
>> > post?ehnuteln? hor?? v?sledky.
>> >
>> > Honza
>> >
>> >
>> >
>> > 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>> >> Doplnil jsem tam chyb?j?c? ??slici 4.
>> >>
>> >> Honza
>> >>
>> >> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>> >>> K vyzkou?en?:
>> >>> http://jabi.aspone.cz/osm/OcrBeta1.zip
>> >>>
>> >>> M? to stejn? ovl?d?n? jako p?vodn? tile-processor, ale nav?c mo?nost
>> >>> logov?n?:
>> >>>
>> >>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv
>> >>> -log log.txt -all
>> >>>
>> >>> -log log.txt ... pokud se toto uvede, tak program bude logovat
>> >>> nerozpoznan? body nebo ty, kter? byly naru?en? p?ekryvem.
>> >>>
>> >>> Pokud se uvede nav?c -all, tak se budou logovat v?echny body.
>> >>>
>> >>> Soubor charDef.txt obsahuje definici znak? nebo posloupnosti znak?. Je
>> >>> to tak? textov? soubor, kter? kdy? zobraz?te fontem s pevnou ???kou,
>> >>> tak je mysl?m v?znam jasn?. Chyb? tam ??slice 4 posunut? dol? (tedy za
>> >>> ?.o.), proto?e jsem na nic p?i pokusech nenarazil. Soubor mus? b?t p?i
>> >>> spu?t?n? v aktu?ln?m adres??i.
>> >>>
>> >>> Honza
>> >>>
>> >>>
>> >>> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>> >>>> Na slu?n? detekci p?ekryv? pr?v? pracuji a mysl?m, ?e rozhodn? bude
>> >>>> v?razn? lep?? ne? byla (to u? je mysl?m te?). Ale stoprocentn?
>> >>>> samoz?ejm? ne - kdy? p?ekryv bude velk?, tak to ur?it? nep?jde.
>> >>>>
>> >>>> Ale jinak si mysl?m, ?e generov?n? dla?dic na serveru KN bude n?jakou
>> >>>> dobu trvat - a to, a? je na t? dla?dici 5 bod? nebo t?eba jen jeden. A
>> >>>> tak? jim to bude zat??ovat servery, kdy? se to p?e?ene s rychlost?
>> >>>> stahov?n? (mnoho vl?ken apod.).
>> >>>>
>> >>>> Honza
>> >>>>
>> >>>>
>> >>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>> >>>>> Kv?li p?ekryv?m - ??sla se s rozli?en?m zmen?uj?.
>> >>>>> Nev?m, jak moc je tv?j algoritmus dokonal? v detekci p?ekr?vaj?c?ch
>> >>>>> se
>> >>>>> ??slic, ale nev???m, ?e dok??e? spolehliv? poznat, kde ??slo skon??.
>> >>>>> Samoz?ejm? je to ot?zka n?jak?ho kompromisu, ale v?t?inu ?asu p?edt?m
>> >>>>> zabralo po??t?n?.
>> >>>>>
>> >>>>> Mysl?m, ?e ale to dynamick? rozli?en?, kter? navrhuje?, nem? moc
>> >>>>> cenu,
>> >>>>> proto?e ty dla?dice jsou v PNG, tak?e by b?l? plochy nem?ly zab?rat
>> >>>>> p??li?
>> >>>>> mnoho datov?ho objemu. To sam? plat? pro vy??? rozli?en? - zpomalen?
>> >>>>> m??e
>> >>>>> nastat sp?? t?m, ?e je nutn? zpracovat v?t?? mno?stv? obrazov?
>> >>>>> informace.
>> >>>>>
>> >>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak
>> >>>>> <jan.bilak.osm at gmail.com>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Ahoj,
>> >>>>>> k ?emu v?t?? rozli?en?? Sp??e jsem uva?oval nad dynamick?m
>> >>>>>> rozli?en?m
>> >>>>>> ... tedy stahovat v??ezy nejprve v mal?m rozli?en? a podle toho
>> >>>>>> detekovat oblasti, kter? obsahuj? adresn? body. A jen tyto ?seky
>> >>>>>> stahovat ve vy???m (t?eba st?vaj?c?m) rozli?en?. To by mohlo u?et?it
>> >>>>>> mno?stv? stahovan?ch dat. P?ijde mi, ?e nejpomalej?? bude pr?v?
>> >>>>>> stahov?n? dla?dic z WMS, tak?e obecn?m zv??en?m rozli?en? by se ?as
>> >>>>>> prodlou?il.
>> >>>>>>
>> >>>>>> Mimochodem - nem?te n?kdo sta?en? dla?dice z n?jak? v?t?? oblasti,
>> >>>>>> kter? byste mohli n?kam hodit zazipovan?, abych to nemusel stahovat
>> >>>>>> z
>> >>>>>> WMS pro testov?n??
>> >>>>>>
>> >>>>>> Honza
>> >>>>>>
>> >>>>>>
>> >>>>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>> >>>>>>> Ahoj,
>> >>>>>>>
>> >>>>>>> zn? to dob?e, jestli by to opravdu neznamenalo p??li? mnoho ?asu,
>> >>>>>>> tak by
>> >>>>>>> mo?n? st?lo za to data kv?li t? chyb? p?ed?lat (pokud nav?c zlep??
>> >>>>>>> detekci
>> >>>>>>> u p?ekryv?, nebo d?ky rychlosti umo?n? stahovat dla?dice s v?t??m
>> >>>>>>> zoomem,
>> >>>>>>> tak to bude dal?? plus).
>> >>>>>>>
>> >>>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak
>> >>>>>>> <jan.bilak.osm at gmail.com>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> Ahoj,
>> >>>>>>>>
>> >>>>>>>> pokusn? implementace je velmi rychl? a m?la by b?t i spolehliv?.
>> >>>>>>>>
>> >>>>>>>> Zkou?el jsem to na 18 v??ezech 4000x4000 px. Celkov? ?as 7.2 s.
>> >>>>>>>> Pr?m?rn? ?as zpracov?n? jednoho souboru je 405 ms, pr?m?rn? ?as
>> >>>>>>>> zpracov?n? jednoho adresn?ho bodu je 17 ms. To v?e v jednom
>> >>>>>>>> vl?kn? a
>> >>>>>>>> tedy to zat??uje jen jedno j?dro procesoru.
>> >>>>>>>>
>> >>>>>>>> Z?tra to snad dod?l?m do pou?iteln?ho stavu.
>> >>>>>>>>
>> >>>>>>>> Honza
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
>> >>>>>>>>> Ne, o to nejde. Ty ??sla jsou u? rozpoznan?, tak?e sta?? p?ed?lat
>> >>>>>>>>> pouze
>> >>>>>>>>> ta
>> >>>>>>>>> eviden?n? ??sla (ty jsou posunut? trochu n?? od te?ky, tak?e je
>> >>>>>>>>> tam ta
>> >>>>>>>>> dvojka u??zl?), ve kter?ch je sedmi?ka. Nen? probl?m v tom, ?e
>> >>>>>>>>> by to
>> >>>>>>>>> ne?lo
>> >>>>>>>>> u??znout o trochu n??. Probl?m je, ?e u? jsme to ud?lali ?patn?,
>> >>>>>>>>> tak?e
>> >>>>>>>>> by
>> >>>>>>>>> to bylo dobr? napravit bez toho, abychom museli v?echno
>> >>>>>>>>> p?ed?l?vat.
>> >>>>>>>>>
>> >>>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec
>> >>>>>>>>> <utx at penguin.cz>
>> >>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat
>> >>>>>>>>>> u??znutou
>> >>>>>>>>>> dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> --
>> >>>>>>>>> Petr Dlouh?
>> >>>>>>>>>
>> >>>>>>>>> _______________________________________________
>> >>>>>>>>> Talk-cz mailing list
>> >>>>>>>>> Talk-cz at openstreetmap.org
>> >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> _______________________________________________
>> >>>>>>>> Talk-cz mailing list
>> >>>>>>>> Talk-cz at openstreetmap.org
>> >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Petr Dlouh?
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> Talk-cz mailing list
>> >>>>>>> Talk-cz at openstreetmap.org
>> >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>> >>>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> Talk-cz mailing list
>> >>>>>> Talk-cz at openstreetmap.org
>> >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Petr Dlouh?
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> Talk-cz mailing list
>> >>>>> Talk-cz at openstreetmap.org
>> >>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>> > _______________________________________________
>> > Talk-cz mailing list
>> > Talk-cz at openstreetmap.org
>> > http://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>> --
>> Petr Dlouh?
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>>
>
> Petr Dlouh?
> petr.dlouhy at email.cz
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Dal jsem tam betu 2 ... http://jabi.aspone.cz/osm/OcrBeta2.zip
Je v?cevl?knov?, trochu p?epracovan? v?pis do konzole (?asov? odhad do
konce apod.).
+ zapisuje do csv souboru info o tom, ?e bod je moc bl?zko kraje dla?dice.
Honza
2010/2/13 Jan Bilak <jan.bilak.osm at gmail.com>:
zobrazit citaci
> O?ez by mohl b?t ni???, ale j? to ka?d? sloupec reprezentuji
> 16-bitov?m ??slem (16 ??dek) a pak s t?m d?l?m r?zn? bitov? operace.
> Tak?e 15 by se mi nehodilo...
>
> Tyhle n?pady jsou dobr?, ale nejsou t?eba. Algoritmus toti? funguje
> tak, ?e se sna?? naj?t nap?ed p?esnou shodu. A pokud p?esn? shoda
> nen?, tak naj?t v?echny mo?nosti, kter? tam mohou b?t. Pokud je v?ce
> mo?nost?, co by tam mohlo b?t, tak to do textu p?id? ?. Pokud jedna
> mo?nost, tak ji to bere jako spr?vnou. A pokud ??d? mo?nost, tak to
> kon??. Check je jen indikace toho, ?e tam nebyla p?esn? shoda. Otazn?k
> je indikace toho, ?e to bylo mnohozna?n?. Zat?m tam tedy chyb? jedna
> kontrola, kter? teoreticky m??e zp?sobit chybu bez ot?zn?ku (jen s
> checkem). Ale to oprav?m a pravd?podobnost takov? chyby je velmi mal?.
>
> Testovac? data by se mi hodila, pokud m?? kam d?t n?jak? archiv
> (klidn? na n?jak? free one-file hosting typu rapidshare - ale ??et tam
> nikde nem?m, tak aby to bylo re?ln? st?hnout zdarma).
>
> Honza
>
>
> 2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>:
>> Ahoj,
>>
>> teprv te? jsem si v?iml toho kr?sn?ho logu. O?ez by mohl b?t o 1 pixel
>> ni??? a o n?co u??? (nev?m ale kolikacifern? je nejdel?? adresa).
>> Dal?? n?pady na sn??en? mno?stv? [CHECK] jsou:
>> ? ? ? ?Pokud adresa za??n? na "bez ?.p./?.e." tak nen? nutn? d?vat [CHECK], ale
>> sta?? o??znout zbytek ?et?zce (t?m se vy?ad? tak polovina p??pad?).
>> ? ? ? ?Pokud je tam nav?c pouze p?r bod? ni???ch ne? ??slice/p?smeno, nemohou ji
>> tvo?it, a tud?? nen? nutn? d?vat [CHECK], proto?e se tam nemohl p?ipl?st
>> n?jak? dal?? adresn? bod, kter? by musel za??nat na ? nebo b.
>>
>> Pro vypo??d?n? s copyrightem existuje je?t? mo?nost d) - pokud si skript nen? jist v?sledkem, tak si st?hne zazoomovan? ??slo, tak?e mu mu?e b?t copyright jedno.
>> Spolehliv? to nen? hlavn? v m?stech, kde je n?kolik adres v jednom shluku (pom?rn? bl?zko sebe).
>>
>> Kontroluju to tak, ?e si vygeneruju adresn? body pomoc? Merge skriptu a
>> otev?u to v JOSM.
>>
>> PS. Jestli po??d sh?n?? testovac? data, m??u ti poslat celou prahu-z?pad, myslel jsem, ?e u? jsem j? smazal, ale nen? tomu tak.
>>
>>> ------------ P?vodn? zpr?va ------------
>>> Od: Petr Dlouh? <petr.dlouhy at email.cz>
>>> P?edm?t: Re: [Talk-cz] Import adres z katastralni mapy
>>> Datum: 13.2.2010 00:29:16
>>> ----------------------------------------
>>> Ahoj,
>>>
>>> ten copyright je jen ?pln? naho?e na ka?d? dla?dici, nebo se pletu? Pokud
>>> tomu tak je, tak bych volil mo?nost a), proto?e je to minimum z velikosti
>>> dla?dice, a ty se u? stejn? stahuj? s p?esahem (kv?li tomu, ?e se ??sla
>>> kresl? jen na dla?dici s te?kou).
>>>
>>> Jinak jsem se koukal na ten skript, a zd? se to velice dobr?. Mysl?m, ?e
>>> by st?lo za to to p?epo??tat, vzhledem k tomu, ?e je to tak 20x rychlej??,
>>> tak to asi nebude probl?m ud?lat na jednou po??ta?i.
>>>
>>> Chyby vid?m n?sleduj?c?:
>>>
>>> -N?kter? adresn? body nejsou v?bec detekov?ny, a u n?kter?ch je pr?zdn?
>>> text (p?esto?e jsou daleko od v?eho).
>>> -?asto se objevuje [CHECK] i u bod?, kter? byly detekov?ny spr?vn?. Pokud
>>> je to v p??padech, kdy se ??sla u? skute?n? p?ekr?vaj?, tak OK. Jenom se
>>> pt?m, jestli nen? mo?n? zvolit agresivn?j?? o?ez p?ed detekc? (pozor na
>>> jin? posunut? ?.e. vs ?.p.).
>>> -V p??padech, kdy se objev? [CHECK], tak by asi skript m?l st?hnout ??slo
>>> ve vy???m rozli?en? a detekovat to.
>>>
>>>
>>> On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>>> wrote:
>>>
>>> > Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy.
>>> > Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne.
>>> > Ale co tomu vadi, to je ten copyright. Zat?m toti? beru v ?vahu pouze
>>> > ?ervenou barvu. Jsou 3 mo?nosti jak to ?e?it:
>>> >
>>> > a) stahovat dla?dice s p?ekryvem tak, ?e se bude rozpozn?vat pouze z
>>> > t?ch ??st? mapy, kter? copyright nen?. V?hody: Nejlep?? v?sledky.
>>> > Nev?hody: Nutnost stahovat v?ce dat z WMS.
>>> >
>>> > b) pova?ovat ?ernou barvu za ?ervenou. V?hody: Nejsou nutn? ?pravy
>>> > downloaderu, u rozpozn?va?e jen trivi?ln? zm?na 3 konstant. Nev?hody:
>>> > Drobn? zhor?en? rozpozn?v?n? v p??pad? p?ekryvu copyrightu s popiskem
>>> > - pokud se to ne?ikovn? tref?, tak bude t?eba ru?n? rozpozn?n?, ale
>>> > nemus? to znamenat nic, i kdy? se to tref?.
>>> >
>>> > c) Prov?d?t ru?n? kontrolu v?ech popisk? s p?ekryvem (t?ch m??e b?t
>>> > hodn?).
>>> >
>>> > Osobn? pova?uji c) za ?patn? ?e?en?. A mezi a) a b) nem?m vyhrazen?
>>> > n?zor. Mo?nost a) je sice teoreticky nejlep??, ale b) nemus? m?t
>>> > post?ehnuteln? hor?? v?sledky.
>>> >
>>> > Honza
>>> >
>>> >
>>> >
>>> > 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>>> >> Doplnil jsem tam chyb?j?c? ??slici 4.
>>> >>
>>> >> Honza
>>> >>
>>> >> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>>> >>> K vyzkou?en?:
>>> >>> http://jabi.aspone.cz/osm/OcrBeta1.zip
>>> >>>
>>> >>> M? to stejn? ovl?d?n? jako p?vodn? tile-processor, ale nav?c mo?nost
>>> >>> logov?n?:
>>> >>>
>>> >>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv
>>> >>> -log log.txt -all
>>> >>>
>>> >>> -log log.txt ... pokud se toto uvede, tak program bude logovat
>>> >>> nerozpoznan? body nebo ty, kter? byly naru?en? p?ekryvem.
>>> >>>
>>> >>> Pokud se uvede nav?c -all, tak se budou logovat v?echny body.
>>> >>>
>>> >>> Soubor charDef.txt obsahuje definici znak? nebo posloupnosti znak?. Je
>>> >>> to tak? textov? soubor, kter? kdy? zobraz?te fontem s pevnou ???kou,
>>> >>> tak je mysl?m v?znam jasn?. Chyb? tam ??slice 4 posunut? dol? (tedy za
>>> >>> ?.o.), proto?e jsem na nic p?i pokusech nenarazil. Soubor mus? b?t p?i
>>> >>> spu?t?n? v aktu?ln?m adres??i.
>>> >>>
>>> >>> Honza
>>> >>>
>>> >>>
>>> >>> 2010/2/12 Jan Bilak <jan.bilak.osm at gmail.com>:
>>> >>>> Na slu?n? detekci p?ekryv? pr?v? pracuji a mysl?m, ?e rozhodn? bude
>>> >>>> v?razn? lep?? ne? byla (to u? je mysl?m te?). Ale stoprocentn?
>>> >>>> samoz?ejm? ne - kdy? p?ekryv bude velk?, tak to ur?it? nep?jde.
>>> >>>>
>>> >>>> Ale jinak si mysl?m, ?e generov?n? dla?dic na serveru KN bude n?jakou
>>> >>>> dobu trvat - a to, a? je na t? dla?dici 5 bod? nebo t?eba jen jeden. A
>>> >>>> tak? jim to bude zat??ovat servery, kdy? se to p?e?ene s rychlost?
>>> >>>> stahov?n? (mnoho vl?ken apod.).
>>> >>>>
>>> >>>> Honza
>>> >>>>
>>> >>>>
>>> >>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>>> >>>>> Kv?li p?ekryv?m - ??sla se s rozli?en?m zmen?uj?.
>>> >>>>> Nev?m, jak moc je tv?j algoritmus dokonal? v detekci p?ekr?vaj?c?ch
>>> >>>>> se
>>> >>>>> ??slic, ale nev???m, ?e dok??e? spolehliv? poznat, kde ??slo skon??.
>>> >>>>> Samoz?ejm? je to ot?zka n?jak?ho kompromisu, ale v?t?inu ?asu p?edt?m
>>> >>>>> zabralo po??t?n?.
>>> >>>>>
>>> >>>>> Mysl?m, ?e ale to dynamick? rozli?en?, kter? navrhuje?, nem? moc
>>> >>>>> cenu,
>>> >>>>> proto?e ty dla?dice jsou v PNG, tak?e by b?l? plochy nem?ly zab?rat
>>> >>>>> p??li?
>>> >>>>> mnoho datov?ho objemu. To sam? plat? pro vy??? rozli?en? - zpomalen?
>>> >>>>> m??e
>>> >>>>> nastat sp?? t?m, ?e je nutn? zpracovat v?t?? mno?stv? obrazov?
>>> >>>>> informace.
>>> >>>>>
>>> >>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak
>>> >>>>> <jan.bilak.osm at gmail.com>
>>> >>>>> wrote:
>>> >>>>>
>>> >>>>>> Ahoj,
>>> >>>>>> k ?emu v?t?? rozli?en?? Sp??e jsem uva?oval nad dynamick?m
>>> >>>>>> rozli?en?m
>>> >>>>>> ... tedy stahovat v??ezy nejprve v mal?m rozli?en? a podle toho
>>> >>>>>> detekovat oblasti, kter? obsahuj? adresn? body. A jen tyto ?seky
>>> >>>>>> stahovat ve vy???m (t?eba st?vaj?c?m) rozli?en?. To by mohlo u?et?it
>>> >>>>>> mno?stv? stahovan?ch dat. P?ijde mi, ?e nejpomalej?? bude pr?v?
>>> >>>>>> stahov?n? dla?dic z WMS, tak?e obecn?m zv??en?m rozli?en? by se ?as
>>> >>>>>> prodlou?il.
>>> >>>>>>
>>> >>>>>> Mimochodem - nem?te n?kdo sta?en? dla?dice z n?jak? v?t?? oblasti,
>>> >>>>>> kter? byste mohli n?kam hodit zazipovan?, abych to nemusel stahovat
>>> >>>>>> z
>>> >>>>>> WMS pro testov?n??
>>> >>>>>>
>>> >>>>>> Honza
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> 2010/2/12 Petr Dlouh? <petr.dlouhy at email.cz>:
>>> >>>>>>> Ahoj,
>>> >>>>>>>
>>> >>>>>>> zn? to dob?e, jestli by to opravdu neznamenalo p??li? mnoho ?asu,
>>> >>>>>>> tak by
>>> >>>>>>> mo?n? st?lo za to data kv?li t? chyb? p?ed?lat (pokud nav?c zlep??
>>> >>>>>>> detekci
>>> >>>>>>> u p?ekryv?, nebo d?ky rychlosti umo?n? stahovat dla?dice s v?t??m
>>> >>>>>>> zoomem,
>>> >>>>>>> tak to bude dal?? plus).
>>> >>>>>>>
>>> >>>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak
>>> >>>>>>> <jan.bilak.osm at gmail.com>
>>> >>>>>>> wrote:
>>> >>>>>>>
>>> >>>>>>>> Ahoj,
>>> >>>>>>>>
>>> >>>>>>>> pokusn? implementace je velmi rychl? a m?la by b?t i spolehliv?.
>>> >>>>>>>>
>>> >>>>>>>> Zkou?el jsem to na 18 v??ezech 4000x4000 px. Celkov? ?as 7.2 s.
>>> >>>>>>>> Pr?m?rn? ?as zpracov?n? jednoho souboru je 405 ms, pr?m?rn? ?as
>>> >>>>>>>> zpracov?n? jednoho adresn?ho bodu je 17 ms. To v?e v jednom
>>> >>>>>>>> vl?kn? a
>>> >>>>>>>> tedy to zat??uje jen jedno j?dro procesoru.
>>> >>>>>>>>
>>> >>>>>>>> Z?tra to snad dod?l?m do pou?iteln?ho stavu.
>>> >>>>>>>>
>>> >>>>>>>> Honza
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> 2010/2/11 Petr Dlouh? <petr.dlouhy at email.cz>:
>>> >>>>>>>>> Ne, o to nejde. Ty ??sla jsou u? rozpoznan?, tak?e sta?? p?ed?lat
>>> >>>>>>>>> pouze
>>> >>>>>>>>> ta
>>> >>>>>>>>> eviden?n? ??sla (ty jsou posunut? trochu n?? od te?ky, tak?e je
>>> >>>>>>>>> tam ta
>>> >>>>>>>>> dvojka u??zl?), ve kter?ch je sedmi?ka. Nen? probl?m v tom, ?e
>>> >>>>>>>>> by to
>>> >>>>>>>>> ne?lo
>>> >>>>>>>>> u??znout o trochu n??. Probl?m je, ?e u? jsme to ud?lali ?patn?,
>>> >>>>>>>>> tak?e
>>> >>>>>>>>> by
>>> >>>>>>>>> to bylo dobr? napravit bez toho, abychom museli v?echno
>>> >>>>>>>>> p?ed?l?vat.
>>> >>>>>>>>>
>>> >>>>>>>>> On Thu, 11 Feb 2010 20:30:56 +0100, Stanislav Brabec
>>> >>>>>>>>> <utx at penguin.cz>
>>> >>>>>>>>> wrote:
>>> >>>>>>>>>
>>> >>>>>>>>>> Aha, tak to jsme si nerozum?li. Nejde nau?it ho pozn?vat
>>> >>>>>>>>>> u??znutou
>>> >>>>>>>>>> dvojku? Pokud to ov?em nezv??? riziko chyby jinde.
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>> --
>>> >>>>>>>>> Petr Dlouh?
>>> >>>>>>>>>
>>> >>>>>>>>> _______________________________________________
>>> >>>>>>>>> Talk-cz mailing list
>>> >>>>>>>>> Talk-cz at openstreetmap.org
>>> >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>> >>>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> _______________________________________________
>>> >>>>>>>> Talk-cz mailing list
>>> >>>>>>>> Talk-cz at openstreetmap.org
>>> >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> --
>>> >>>>>>> Petr Dlouh?
>>> >>>>>>>
>>> >>>>>>> _______________________________________________
>>> >>>>>>> Talk-cz mailing list
>>> >>>>>>> Talk-cz at openstreetmap.org
>>> >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>> _______________________________________________
>>> >>>>>> Talk-cz mailing list
>>> >>>>>> Talk-cz at openstreetmap.org
>>> >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>> >>>>>
>>> >>>>>
>>> >>>>> --
>>> >>>>> Petr Dlouh?
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> Talk-cz mailing list
>>> >>>>> Talk-cz at openstreetmap.org
>>> >>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>> >>>>>
>>> >>>>
>>> >>>
>>> >>
>>> >
>>> > _______________________________________________
>>> > Talk-cz mailing list
>>> > Talk-cz at openstreetmap.org
>>> > http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>>
>>> --
>>> Petr Dlouh?
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>>
>>>
>>
>> Petr Dlouh?
>> petr.dlouhy at email.cz
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
Ahoj,
teprv te? jsem si v?iml toho kr?sn?ho logu. O?ez by mohl b?t o 1 pixel
ni??? a o n?co u??? (nev?m ale kolikacifern? je nejdel?? adresa).
Dal?? n?pady na sn??en? mno?stv? [CHECK] jsou:
Pokud adresa za??n? na "bez ?.p./?.e." tak nen? nutn? d?vat [CHECK], ale
sta?? o??znout zbytek ?et?zce (t?m se vy?ad? tak polovina p??pad?).
Pokud je tam nav?c pouze p?r bod? ni???ch ne? ??slice/p?smeno, nemohou ji
tvo?it, a tud?? nen? nutn? d?vat [CHECK], proto?e se tam nemohl p?ipl?st
n?jak? dal?? adresn? bod, kter? by musel za??nat na ? nebo b.
Kontroluju to tak, ?e si vygeneruju adresn? body pomoc? Merge skriptu a
otev?u to v JOSM.
PS. Jestli po??d sh?n?? testovac? data, m??u ti poslat celou prahu-z?pad,
myslel jsem, ?e u? jsem j? smazal, ale nen? tomu tak.
On Sat, 13 Feb 2010 00:28:20 +0100, Petr Dlouh? <petr.dlouhy at email.cz>
wrote:
zobrazit citaci
> -?asto se objevuje [CHECK] i u bod?, kter? byly detekov?ny spr?vn?. Pokud
> je to v p??padech, kdy se ??sla u? skute?n? p?ekr?vaj?, tak OK. Jenom se
> pt?m, jestli nen? mo?n? zvolit agresivn?j?? o?ez p?ed detekc? (pozor na
--
Petr Dlouh?
Aha, tak to jsem p?edt?m nepochopil. V tom p??pad? se ale u n?kter?ch "bez
?.p./?.e." detekuj? n?jak? mezery nebo jin? bordel za nimi a mo?n? jsem
vid?l i p??pad, kdy se n?jak? ??slo prodlou?ilo o ??slice, kter? tam
nem?ly b?t (pokus?m se to naj?t).
Dla?dice je na [1], je tam v?c takov?ch bod?, co se nedetekovali.
Testovac? data se pokus?m nahr?t, je toho kolem 200MB.
[1]
http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png
On Sat, 13 Feb 2010 01:10:29 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
> O?ez by mohl b?t ni???, ale j? to ka?d? sloupec reprezentuji
> 16-bitov?m ??slem (16 ??dek) a pak s t?m d?l?m r?zn? bitov? operace.
> Tak?e 15 by se mi nehodilo...
> Tyhle n?pady jsou dobr?, ale nejsou t?eba. Algoritmus toti? funguje
> tak, ?e se sna?? naj?t nap?ed p?esnou shodu. A pokud p?esn? shoda
> nen?, tak naj?t v?echny mo?nosti, kter? tam mohou b?t. Pokud je v?ce
> mo?nost?, co by tam mohlo b?t, tak to do textu p?id? ?. Pokud jedna
> mo?nost, tak ji to bere jako spr?vnou. A pokud ??d? mo?nost, tak to
> kon??. Check je jen indikace toho, ?e tam nebyla p?esn? shoda. Otazn?k
> je indikace toho, ?e to bylo mnohozna?n?. Zat?m tam tedy chyb? jedna
> kontrola, kter? teoreticky m??e zp?sobit chybu bez ot?zn?ku (jen s
> checkem). Ale to oprav?m a pravd?podobnost takov? chyby je velmi mal?.
> Testovac? data by se mi hodila, pokud m?? kam d?t n?jak? archiv
> (klidn? na n?jak? free one-file hosting typu rapidshare - ale ??et tam
> nikde nem?m, tak aby to bylo re?ln? st?hnout zdarma).
> Honza
--
Petr Dlouh?
Ano, to prodlou?en? o n?co bude ?e?it ta kontrola (u? je celkem jedno,
zda prodlou?en? ??sla nebo popisu "bez ?.p./?.e.". Tedy alespo? jsem o
tom p?esv?d?en. Do vypo??d?n? se s copyrightem a p?id?n? t? kontroly
to nen? zcela spolehliv?. M??e to jak zkr?tit ??slo, tak prodlou?it -
teoreticky i mo?n? zm?nit.
D?ky za p??klad i data.
Honza
2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Aha, tak to jsem p?edt?m nepochopil. V tom p??pad? se ale u n?kter?ch "bez
> ?.p./?.e." detekuj? n?jak? mezery nebo jin? bordel za nimi a mo?n? jsem
> vid?l i p??pad, kdy se n?jak? ??slo prodlou?ilo o ??slice, kter? tam
> nem?ly b?t (pokus?m se to naj?t).
>
> Dla?dice je na [1], je tam v?c takov?ch bod?, co se nedetekovali.
> Testovac? data se pokus?m nahr?t, je toho kolem 200MB.
>
> [1]
> http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png
>
> On Sat, 13 Feb 2010 01:10:29 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
> wrote:
>
>> O?ez by mohl b?t ni???, ale j? to ka?d? sloupec reprezentuji
>> 16-bitov?m ??slem (16 ??dek) a pak s t?m d?l?m r?zn? bitov? operace.
>> Tak?e 15 by se mi nehodilo...
>> Tyhle n?pady jsou dobr?, ale nejsou t?eba. Algoritmus toti? funguje
>> tak, ?e se sna?? naj?t nap?ed p?esnou shodu. A pokud p?esn? shoda
>> nen?, tak naj?t v?echny mo?nosti, kter? tam mohou b?t. Pokud je v?ce
>> mo?nost?, co by tam mohlo b?t, tak to do textu p?id? ?. Pokud jedna
>> mo?nost, tak ji to bere jako spr?vnou. A pokud ??d? mo?nost, tak to
>> kon??. Check je jen indikace toho, ?e tam nebyla p?esn? shoda. Otazn?k
>> je indikace toho, ?e to bylo mnohozna?n?. Zat?m tam tedy chyb? jedna
>> kontrola, kter? teoreticky m??e zp?sobit chybu bez ot?zn?ku (jen s
>> checkem). Ale to oprav?m a pravd?podobnost takov? chyby je velmi mal?.
>> Testovac? data by se mi hodila, pokud m?? kam d?t n?jak? archiv
>> (klidn? na n?jak? free one-file hosting typu rapidshare - ale ??et tam
>> nikde nem?m, tak aby to bylo re?ln? st?hnout zdarma).
>> Honza
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Zkou?el jsem tu dla?dici
http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png
a nena?el jsem ??dn? bod, kter? by to nedetekovalo. Nechal jsem si
ud?lat modrou te?ku do p?vodn? bitmapy na ka?d? detekovan? bod ... a
ru?n? kontrolou byly v?echny omod?en? a ??dn? ?erven? nezbyl.
Pros?m o jeden p??pad bodu (??slo popisn?, sou?adnici v pixelech nebo
tak n?co), kter? se ti nedetekoval.
Do csv mi to napsalo 186 ??dek. Tedy to na?lo 186 bod?. Tob? tak??
Honza
2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Aha, tak to jsem p?edt?m nepochopil. V tom p??pad? se ale u n?kter?ch "bez
> ?.p./?.e." detekuj? n?jak? mezery nebo jin? bordel za nimi a mo?n? jsem
> vid?l i p??pad, kdy se n?jak? ??slo prodlou?ilo o ??slice, kter? tam
> nem?ly b?t (pokus?m se to naj?t).
>
> Dla?dice je na [1], je tam v?c takov?ch bod?, co se nedetekovali.
> Testovac? data se pokus?m nahr?t, je toho kolem 200MB.
>
> [1]
> http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png
>
> On Sat, 13 Feb 2010 01:10:29 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
> wrote:
>
>> O?ez by mohl b?t ni???, ale j? to ka?d? sloupec reprezentuji
>> 16-bitov?m ??slem (16 ??dek) a pak s t?m d?l?m r?zn? bitov? operace.
>> Tak?e 15 by se mi nehodilo...
>> Tyhle n?pady jsou dobr?, ale nejsou t?eba. Algoritmus toti? funguje
>> tak, ?e se sna?? naj?t nap?ed p?esnou shodu. A pokud p?esn? shoda
>> nen?, tak naj?t v?echny mo?nosti, kter? tam mohou b?t. Pokud je v?ce
>> mo?nost?, co by tam mohlo b?t, tak to do textu p?id? ?. Pokud jedna
>> mo?nost, tak ji to bere jako spr?vnou. A pokud ??d? mo?nost, tak to
>> kon??. Check je jen indikace toho, ?e tam nebyla p?esn? shoda. Otazn?k
>> je indikace toho, ?e to bylo mnohozna?n?. Zat?m tam tedy chyb? jedna
>> kontrola, kter? teoreticky m??e zp?sobit chybu bez ot?zn?ku (jen s
>> checkem). Ale to oprav?m a pravd?podobnost takov? chyby je velmi mal?.
>> Testovac? data by se mi hodila, pokud m?? kam d?t n?jak? archiv
>> (klidn? na n?jak? free one-file hosting typu rapidshare - ale ??et tam
>> nikde nem?m, tak aby to bylo re?ln? st?hnout zdarma).
>> Honza
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Ahoj,
na?el jsem p??pad, kdy se slila dv? ??sla dohromady (testov?no v bet? 1) -
je to na dla?dici
[1], ??slo 2341.
Nevid?m d?vod, pro? by se vlastn? m?ly ta ??sla prodlu?ovat nebo zkracovat
o dal?? ??slice - pokud se tam p?iplete dal?? adresn? bod ve stejn?m
m?st?, m?lo by se tam p?ipl?st i "?" nebo "b", tak?e by se nem?l p?i Merge
v?bec p?i?adit -> jde to opravit ru?n? (a sta?? tedy minimalizovat po?et
p??pad? na ?nosnou mez). Zkracovat by se snad nem?lo to ??slo nikdy (pokud
skon??me v?as p?ed prav?m okrajem), pokud tam bude velk? zmatek, tak se ve
v?sledku m??e objevit nanejv?? "?". Zm?nit snad tak? ne.
Pos?l?m testovac? data (m?l by to b?t cel? okres Praha-z?pad) na [2].
Zkou?el jsem betu 2, ale m? probl?m s pam?t? - kdy? to generuju na velk?
oblasti, tak po n?jak? dob? spadne na zapln?n? pam?ti. Beta 1 byla v
po??dku.
[1]
http://www.flyshare.cz/stahni/46190/14.2327_50.0796_14.2377_50.0846-budovy.png
[2] http://www.flyshare.cz/stahni/46188/pz.tar.bz2
On Sat, 13 Feb 2010 01:32:41 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
> Ano, to prodlou?en? o n?co bude ?e?it ta kontrola (u? je celkem jedno,
> zda prodlou?en? ??sla nebo popisu "bez ?.p./?.e.". Tedy alespo? jsem o
> tom p?esv?d?en. Do vypo??d?n? se s copyrightem a p?id?n? t? kontroly
> to nen? zcela spolehliv?. M??e to jak zkr?tit ??slo, tak prodlou?it -
> teoreticky i mo?n? zm?nit.
> D?ky za p??klad i data.
> Honza
--
Petr Dlouh?
Ahoj,
186 souhlas?, ty chyb?j?c? body jsou v?dy "bez ?.p./?.e.". Chyb? nap??klad
bod pod ?.p. 1 a 121 na sou?adnic?ch 50,13254; 14,33821.
On Sat, 13 Feb 2010 01:58:07 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
> Zkou?el jsem tu dla?dici
> http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png
> a nena?el jsem ??dn? bod, kter? by to nedetekovalo. Nechal jsem si
> ud?lat modrou te?ku do p?vodn? bitmapy na ka?d? detekovan? bod ... a
> ru?n? kontrolou byly v?echny omod?en? a ??dn? ?erven? nezbyl.
> Pros?m o jeden p??pad bodu (??slo popisn?, sou?adnici v pixelech nebo
> tak n?co), kter? se ti nedetekoval.
> Do csv mi to napsalo 186 ??dek. Tedy to na?lo 186 bod?. Tob? tak??
> Honza
--
Petr Dlouh?
Ahoj,
d?ky, kouknu se na to, kde je probl?m.
Honza
2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Ahoj,
>
> 186 souhlas?, ty chyb?j?c? body jsou v?dy "bez ?.p./?.e.". Chyb? nap??klad
> bod pod ?.p. 1 a 121 na sou?adnic?ch 50,13254; 14,33821.
>
> On Sat, 13 Feb 2010 01:58:07 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
> wrote:
>
>> Zkou?el jsem tu dla?dici
>> http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png
>> a nena?el jsem ??dn? bod, kter? by to nedetekovalo. Nechal jsem si
>> ud?lat modrou te?ku do p?vodn? bitmapy na ka?d? detekovan? bod ... a
>> ru?n? kontrolou byly v?echny omod?en? a ??dn? ?erven? nezbyl.
>> Pros?m o jeden p??pad bodu (??slo popisn?, sou?adnici v pixelech nebo
>> tak n?co), kter? se ti nedetekoval.
>> Do csv mi to napsalo 186 ??dek. Tedy to na?lo 186 bod?. Tob? tak??
>> Honza
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Omlouv?m se. To nen? chyba - Merge nevygeneruje pro "bez ?.p./?.e." ??dn? bod, tak?e je v?echno v po??dku.
zobrazit citaci
> ------------ P?vodn? zpr?va ------------
> Od: Petr Dlouh? <petr.dlouhy at email.cz>
> P?edm?t: Re: [Talk-cz] Import adres z katastralni mapy
> Datum: 13.2.2010 03:02:22
> ----------------------------------------
> Ahoj,
>
> 186 souhlas?, ty chyb?j?c? body jsou v?dy "bez ?.p./?.e.". Chyb? nap??klad
> bod pod ?.p. 1 a 121 na sou?adnic?ch 50,13254; 14,33821.
>
> On Sat, 13 Feb 2010 01:58:07 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
> wrote:
>
OK, nic se nestalo. Hlavn?, ?e se to vyjasnilo.
Honza
2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Omlouv?m se. To nen? chyba - Merge nevygeneruje pro "bez ?.p./?.e." ??dn? bod, tak?e je v?echno v po??dku.
>
>
>> ------------ P?vodn? zpr?va ------------
>> Od: Petr Dlouh? <petr.dlouhy at email.cz>
>> P?edm?t: Re: [Talk-cz] Import adres z katastralni mapy
>> Datum: 13.2.2010 03:02:22
>> ----------------------------------------
>> Ahoj,
>>
>> 186 souhlas?, ty chyb?j?c? body jsou v?dy "bez ?.p./?.e.". Chyb? nap??klad
>> bod pod ?.p. 1 a 121 na sou?adnic?ch 50,13254; 14,33821.
>>
>> On Sat, 13 Feb 2010 01:58:07 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>> wrote:
>>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Jedno upozorn?n? - ta data jsem stahoval na t?ikr?t, a potom to sesypal do
jednoho adres??e (v domn?n?, ?e se p?ekr?vaj?c? dla?dice po?erou, co? se
ale nestalo proto?e nejsou zaokrouhlov?ny stejn?). V adres??i jsou tedy v
p?ekr?vaj?c?ch oblastech shodn? dla?dice akor?t s posunem.
Pokud bys cht?l jednotliv? dla?dice rozd?lit do p?vodn?ch adres???, tak na
[1] jsou seznamy soubor? z jednotliv?ch p?vodn?ch adres???.
[1] http://www.flyshare.cz/stahni/46192/pz.tar.gz
On Sat, 13 Feb 2010 02:07:28 +0100, Petr Dlouh? <petr.dlouhy at email.cz>
wrote:
zobrazit citaci
> Pos?l?m testovac? data (m?l by to b?t cel? okres Praha-z?pad) na [2].
--
Petr Dlouh?
Ahoj.
Dal jsem tam betu 3 ... http://jabi.aspone.cz/osm/OcrBeta3.zip
Pridava drive zminovanou podminku, ktera umoznuje detekovat, zda jde o
jednoznacne rozpoznani nebo je treba rucni kontrola.
Dale meni stavy rozpoznani:
[CHECK] ... je treba rucni kontrola
[OVERLAP] ... byl tam prekryv, ale melo by to byt jednoznacne (spise
pro debug ucely a overeni programu)
Doslo i ke zmene parametru programu:
Command line options are:
-tiles [..] (*) Path to downloaded tiles
-output [..] (*) Output filename
-log [..] Log filename
-all Log all
-overlap Log overlap
-threads [..] Thread count
(*) Required.
Defaultni logovani pri uvedeni souboru logu je takove, ze se loguji
jen CHECK body. Lze zapnout i overlap body nebo vsechny.
Na Monu je asi problem s vicevlaknovym provozem (asi je treba jeste
navic neco zamykat nebo tak neco), tak pribyl argument pro urceni
poctu vlaken. Pri problemech nastavte na hodnotu 1.
A dale cernou barvu povazuji za cervenou. Pokud s tim budou problemy,
lze zvolit variantu s orezem a vetsim prekryvem nebo dynamicke
stahovani zazoomovane oblasti (pracnejsi).
Honza
2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Jedno upozorn?n? - ta data jsem stahoval na t?ikr?t, a potom to sesypal do
> jednoho adres??e (v domn?n?, ?e se p?ekr?vaj?c? dla?dice po?erou, co? se
> ale nestalo proto?e nejsou zaokrouhlov?ny stejn?). V adres??i jsou tedy v
> p?ekr?vaj?c?ch oblastech shodn? dla?dice akor?t s posunem.
>
> Pokud bys cht?l jednotliv? dla?dice rozd?lit do p?vodn?ch adres???, tak na
> [1] jsou seznamy soubor? z jednotliv?ch p?vodn?ch adres???.
>
> [1] http://www.flyshare.cz/stahni/46192/pz.tar.gz
>
> On Sat, 13 Feb 2010 02:07:28 +0100, Petr Dlouh? <petr.dlouhy at email.cz>
> wrote:
>
>> Pos?l?m testovac? data (m?l by to b?t cel? okres Praha-z?pad) na [2].
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Je?t? jsem tam hodil malinko opravenou betu3 (na stejn? m?sto) -
oprava "pad?n?".
Honza
2010/2/13 Jan Bilak <jan.bilak.osm at gmail.com>:
zobrazit citaci
> Ahoj.
>
> Dal jsem tam betu 3 ... http://jabi.aspone.cz/osm/OcrBeta3.zip
>
> Pridava drive zminovanou podminku, ktera umoznuje detekovat, zda jde o
> jednoznacne rozpoznani nebo je treba rucni kontrola.
> Dale meni stavy rozpoznani:
> [CHECK] ... je treba rucni kontrola
> [OVERLAP] ... byl tam prekryv, ale melo by to byt jednoznacne (spise
> pro debug ucely a overeni programu)
>
> Doslo i ke zmene parametru programu:
>
> Command line options are:
> ?-tiles [..] ? ? (*) Path to downloaded tiles
> ?-output [..] ? ?(*) Output filename
> ?-log [..] ? ? ? Log filename
> ?-all ? ? ? ? ? ?Log all
> ?-overlap ? ? ? ?Log overlap
> ?-threads [..] ? Thread count
> (*) Required.
>
> Defaultni logovani pri uvedeni souboru logu je takove, ze se loguji
> jen CHECK body. Lze zapnout i overlap body nebo vsechny.
> Na Monu je asi problem s vicevlaknovym provozem (asi je treba jeste
> navic neco zamykat nebo tak neco), tak pribyl argument pro urceni
> poctu vlaken. Pri problemech nastavte na hodnotu 1.
>
> A dale cernou barvu povazuji za cervenou. Pokud s tim budou problemy,
> lze zvolit variantu s orezem a vetsim prekryvem nebo dynamicke
> stahovani zazoomovane oblasti (pracnejsi).
>
> Honza
>
>
>
> 2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>:
>> Jedno upozorn?n? - ta data jsem stahoval na t?ikr?t, a potom to sesypal do
>> jednoho adres??e (v domn?n?, ?e se p?ekr?vaj?c? dla?dice po?erou, co? se
>> ale nestalo proto?e nejsou zaokrouhlov?ny stejn?). V adres??i jsou tedy v
>> p?ekr?vaj?c?ch oblastech shodn? dla?dice akor?t s posunem.
>>
>> Pokud bys cht?l jednotliv? dla?dice rozd?lit do p?vodn?ch adres???, tak na
>> [1] jsou seznamy soubor? z jednotliv?ch p?vodn?ch adres???.
>>
>> [1] http://www.flyshare.cz/stahni/46192/pz.tar.gz
>>
>> On Sat, 13 Feb 2010 02:07:28 +0100, Petr Dlouh? <petr.dlouhy at email.cz>
>> wrote:
>>
>>> Pos?l?m testovac? data (m?l by to b?t cel? okres Praha-z?pad) na [2].
>>
>>
>> --
>> Petr Dlouh?
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
Ahoj,
je tam st?le ten probl?m s pam?t?. Kdy? jsem zkou?el adres?? pz1, tak to
po n?jak? dob? za?ne n?hle konzumovat velk? mno?stv? pam?ti (zabere mi to
cca 1,7 GB pam?ti + 0,5 GB swapu). Nen? to zp?soben? programem samotn?m
(dlouhou dobu se pam?? t?m?? nezab?r?), ale ani jednotlivou dla?dic?
(b?hem fin?le se st?le je?t? dla?dice m?n?).
On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
> Je?t? jsem tam hodil malinko opravenou betu3 (na stejn? m?sto) -
> oprava "pad?n?".
> Honza
--
Petr Dlouh?
Ahoj,
mne se stalo n?co podobn?ho, kdy? jsem tam nechal v adres??i PNG?ko,
kter? jsem generoval z p?vodn?ch PNG tak, ?e jsem tam dopl?oval modr?
te?ky (kv?li hled?n? toho chyb?j?c?ho bodu, kter? nakonec nechyb?l).
Ale to mi sp??e za?alo stra?n? rychle plnit log.
Pr?v? to zkou??m na t?ch tv?ch datech Prahy ... je?t? nejsem u konce.
Pravda je, ?e m?m 4 GB RAM, tak?e 2,3 GB by mi syst?m mo?n? p?e?il,
kdyby odswapoval v?echno ostatn?.... zkus?m sledovat pam??. Luk?? tam
volal explicitn? Garbage Collector tu??m po zpracov?n? ka?d? dla?dice,
zkus?m to tam p??padn? vr?tit - t?eba pro to m?l dobr? d?vod (j? to
odstranil jako zbyte?n? zdr?uj?c?).
Jinak v?sledky jsou podle mne velmi p?kn? ... asi 9 bod? k ru?n?
kontrole z cca 3000 dla?dic a n?jak?ch 50000 bod?. A to je v Praze,
kde jsou p?ekryvy ?ast?j?? ne? na venkov?.
Honza
2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Ahoj,
>
> je tam st?le ten probl?m s pam?t?. Kdy? jsem zkou?el adres?? pz1, tak to
> po n?jak? dob? za?ne n?hle konzumovat velk? mno?stv? pam?ti (zabere mi to
> cca 1,7 GB pam?ti + ?0,5 GB swapu). Nen? to zp?soben? programem samotn?m
> (dlouhou dobu se pam?? t?m?? nezab?r?), ale ani jednotlivou dla?dic?
> (b?hem fin?le se st?le je?t? dla?dice m?n?).
>
> On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
> wrote:
>
>> Je?t? jsem tam hodil malinko opravenou betu3 (na stejn? m?sto) -
>> oprava "pad?n?".
>> Honza
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
J? mysl?m, ?e by se?ral klidn? i 4 GB - on prost? najednou za?ne ?r?t na
ka?dou dla?dici t?eba 100 MB nav?c (p?ed t?m ale 10 minut po??tal v
po??dku). Samoz?ejm?, ?e kdy? v?echno se?ere, tak ho shod?m, nebo spadne
s?m.
On Sat, 13 Feb 2010 18:54:12 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
> Pr?v? to zkou??m na t?ch tv?ch datech Prahy ... je?t? nejsem u konce.
> Pravda je, ?e m?m 4 GB RAM, tak?e 2,3 GB by mi syst?m mo?n? p?e?il,
> kdyby odswapoval v?echno ostatn?.... zkus?m sledovat pam??. Luk?? tam
> volal explicitn? Garbage Collector tu??m po zpracov?n? ka?d? dla?dice,
> zkus?m to tam p??padn? vr?tit - t?eba pro to m?l dobr? d?vod (j? to
> odstranil jako zbyte?n? zdr?uj?c?).
--
Petr Dlouh?
Dal jsem tam novou verzi beta3 (na stejn? m?sto). M? nav?c parametr
-gc, kter?m lze za??dit zavol?n? Garbace Collectoru po zpracov?n?
ka?d? dla?dice. T?m se v?razn? sn??? pam??ov? n?roky, ale za cenu
n?jak?ho sn??en? rychlosti.
Zkus to pros?m.
Mne to ve Windows ?ere bez -gc spi?kov? tak 650 MB, s -gc tak 250 MB.
To p?i pou?it? dvou vl?ken. Jinak jsem zat?m po zpracov?n? dal??ch
dla?dic z Prahy probl?m nenarazil.
Honza
2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Ahoj,
>
> je tam st?le ten probl?m s pam?t?. Kdy? jsem zkou?el adres?? pz1, tak to
> po n?jak? dob? za?ne n?hle konzumovat velk? mno?stv? pam?ti (zabere mi to
> cca 1,7 GB pam?ti + ?0,5 GB swapu). Nen? to zp?soben? programem samotn?m
> (dlouhou dobu se pam?? t?m?? nezab?r?), ale ani jednotlivou dla?dic?
> (b?hem fin?le se st?le je?t? dla?dice m?n?).
>
> On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
> wrote:
>
>> Je?t? jsem tam hodil malinko opravenou betu3 (na stejn? m?sto) -
>> oprava "pad?n?".
>> Honza
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Projel jsem v?echny dla?dice, kter? jsi mi poslal. Na probl?m jsem
nenarazil. Mo?n? je to specifick? chov?n? Mona - j? to d?l?m pod
.NETem (t?eba v?m, ?e pod Monem mi aplikace v?dycky padala, kdy? jsem
p?istupoval ke konzoli z v?ce vl?ken, zato .NET to automaticky
synchronizoval apod.). Nev?m - t??ko se lad? n?co, co se mi
neprojevuje.
Zdroj?ky jsou tady:
http://jabi.aspone.cz/osm/FindAddressPoints-beta3-src.zip
Pokud by se probl?m nepoda?ilo odstranit, tak je mo?n? to d?lat pod
Windows. Zase tak dlouho to mysl?m netrv?, aby byla t?eba d?lat akce
na zp?sob SETI at home.
Honza
2010/2/13 Jan Bilak <jan.bilak.osm at gmail.com>:
zobrazit citaci
> Dal jsem tam novou verzi beta3 (na stejn? m?sto). M? nav?c parametr
> -gc, kter?m lze za??dit zavol?n? Garbace Collectoru po zpracov?n?
> ka?d? dla?dice. T?m se v?razn? sn??? pam??ov? n?roky, ale za cenu
> n?jak?ho sn??en? rychlosti.
>
> Zkus to pros?m.
>
> Mne to ve Windows ?ere bez -gc spi?kov? tak 650 MB, s -gc tak 250 MB.
> To p?i pou?it? dvou vl?ken. Jinak jsem zat?m po zpracov?n? dal??ch
> dla?dic z Prahy probl?m nenarazil.
>
> Honza
>
>
>
> 2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>:
>> Ahoj,
>>
>> je tam st?le ten probl?m s pam?t?. Kdy? jsem zkou?el adres?? pz1, tak to
>> po n?jak? dob? za?ne n?hle konzumovat velk? mno?stv? pam?ti (zabere mi to
>> cca 1,7 GB pam?ti + ?0,5 GB swapu). Nen? to zp?soben? programem samotn?m
>> (dlouhou dobu se pam?? t?m?? nezab?r?), ale ani jednotlivou dla?dic?
>> (b?hem fin?le se st?le je?t? dla?dice m?n?).
>>
>> On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>> wrote:
>>
>>> Je?t? jsem tam hodil malinko opravenou betu3 (na stejn? m?sto) -
>>> oprava "pad?n?".
>>> Honza
>>
>>
>> --
>> Petr Dlouh?
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
Tady jsou v?sledn? *.csv a logy z tv?ch dat Prahy:
http://www.flyshare.cz/stahni/46207/praha.zip
Zpracov?val jsem to po 5 ??stech - jsou o??slov?ny stejn? *.csv a logy
(stejn? ??sla pat?? k sob?).
Honza
2010/2/13 Jan Bilak <jan.bilak.osm at gmail.com>:
zobrazit citaci
> Projel jsem v?echny dla?dice, kter? jsi mi poslal. Na probl?m jsem
> nenarazil. Mo?n? je to specifick? chov?n? Mona - j? to d?l?m pod
> .NETem (t?eba v?m, ?e pod Monem mi aplikace v?dycky padala, kdy? jsem
> p?istupoval ke konzoli z v?ce vl?ken, zato .NET to automaticky
> synchronizoval apod.). Nev?m - t??ko se lad? n?co, co se mi
> neprojevuje.
>
> Zdroj?ky jsou tady:
> http://jabi.aspone.cz/osm/FindAddressPoints-beta3-src.zip
>
> Pokud by se probl?m nepoda?ilo odstranit, tak je mo?n? to d?lat pod
> Windows. Zase tak dlouho to mysl?m netrv?, aby byla t?eba d?lat akce
> na zp?sob SETI at home.
>
> Honza
>
>
> 2010/2/13 Jan Bilak <jan.bilak.osm at gmail.com>:
>> Dal jsem tam novou verzi beta3 (na stejn? m?sto). M? nav?c parametr
>> -gc, kter?m lze za??dit zavol?n? Garbace Collectoru po zpracov?n?
>> ka?d? dla?dice. T?m se v?razn? sn??? pam??ov? n?roky, ale za cenu
>> n?jak?ho sn??en? rychlosti.
>>
>> Zkus to pros?m.
>>
>> Mne to ve Windows ?ere bez -gc spi?kov? tak 650 MB, s -gc tak 250 MB.
>> To p?i pou?it? dvou vl?ken. Jinak jsem zat?m po zpracov?n? dal??ch
>> dla?dic z Prahy probl?m nenarazil.
>>
>> Honza
>>
>>
>>
>> 2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>:
>>> Ahoj,
>>>
>>> je tam st?le ten probl?m s pam?t?. Kdy? jsem zkou?el adres?? pz1, tak to
>>> po n?jak? dob? za?ne n?hle konzumovat velk? mno?stv? pam?ti (zabere mi to
>>> cca 1,7 GB pam?ti + ?0,5 GB swapu). Nen? to zp?soben? programem samotn?m
>>> (dlouhou dobu se pam?? t?m?? nezab?r?), ale ani jednotlivou dla?dic?
>>> (b?hem fin?le se st?le je?t? dla?dice m?n?).
>>>
>>> On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>>> wrote:
>>>
>>>> Je?t? jsem tam hodil malinko opravenou betu3 (na stejn? m?sto) -
>>>> oprava "pad?n?".
>>>> Honza
>>>
>>>
>>> --
>>> Petr Dlouh?
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>
>
Ahoj,
mas k tomu jeste nejake zasadni postrehy (co je treba upravit)? Tedy
krome toho, ze ti to zacne plnit pamet, protoze to se mi nepodarilo
nasimulovat a ani nemam zadny napad, cim by to mohlo byt.
Honza
2010/2/13 Jan Bilak <jan.bilak.osm at gmail.com>:
zobrazit citaci
> Tady jsou v?sledn? *.csv a logy z tv?ch dat Prahy:
> http://www.flyshare.cz/stahni/46207/praha.zip
>
> Zpracov?val jsem to po 5 ??stech - jsou o??slov?ny stejn? *.csv a logy
> (stejn? ??sla pat?? k sob?).
>
> Honza
>
>
>
> 2010/2/13 Jan Bilak <jan.bilak.osm at gmail.com>:
>> Projel jsem v?echny dla?dice, kter? jsi mi poslal. Na probl?m jsem
>> nenarazil. Mo?n? je to specifick? chov?n? Mona - j? to d?l?m pod
>> .NETem (t?eba v?m, ?e pod Monem mi aplikace v?dycky padala, kdy? jsem
>> p?istupoval ke konzoli z v?ce vl?ken, zato .NET to automaticky
>> synchronizoval apod.). Nev?m - t??ko se lad? n?co, co se mi
>> neprojevuje.
>>
>> Zdroj?ky jsou tady:
>> http://jabi.aspone.cz/osm/FindAddressPoints-beta3-src.zip
>>
>> Pokud by se probl?m nepoda?ilo odstranit, tak je mo?n? to d?lat pod
>> Windows. Zase tak dlouho to mysl?m netrv?, aby byla t?eba d?lat akce
>> na zp?sob SETI at home.
>>
>> Honza
>>
>>
>> 2010/2/13 Jan Bilak <jan.bilak.osm at gmail.com>:
>>> Dal jsem tam novou verzi beta3 (na stejn? m?sto). M? nav?c parametr
>>> -gc, kter?m lze za??dit zavol?n? Garbace Collectoru po zpracov?n?
>>> ka?d? dla?dice. T?m se v?razn? sn??? pam??ov? n?roky, ale za cenu
>>> n?jak?ho sn??en? rychlosti.
>>>
>>> Zkus to pros?m.
>>>
>>> Mne to ve Windows ?ere bez -gc spi?kov? tak 650 MB, s -gc tak 250 MB.
>>> To p?i pou?it? dvou vl?ken. Jinak jsem zat?m po zpracov?n? dal??ch
>>> dla?dic z Prahy probl?m nenarazil.
>>>
>>> Honza
>>>
>>>
>>>
>>> 2010/2/13 Petr Dlouh? <petr.dlouhy at email.cz>:
>>>> Ahoj,
>>>>
>>>> je tam st?le ten probl?m s pam?t?. Kdy? jsem zkou?el adres?? pz1, tak to
>>>> po n?jak? dob? za?ne n?hle konzumovat velk? mno?stv? pam?ti (zabere mi to
>>>> cca 1,7 GB pam?ti + ?0,5 GB swapu). Nen? to zp?soben? programem samotn?m
>>>> (dlouhou dobu se pam?? t?m?? nezab?r?), ale ani jednotlivou dla?dic?
>>>> (b?hem fin?le se st?le je?t? dla?dice m?n?).
>>>>
>>>> On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>>>> wrote:
>>>>
>>>>> Je?t? jsem tam hodil malinko opravenou betu3 (na stejn? m?sto) -
>>>>> oprava "pad?n?".
>>>>> Honza
>>>>
>>>>
>>>> --
>>>> Petr Dlouh?
>>>>
>>>> _______________________________________________
>>>> Talk-cz mailing list
>>>> Talk-cz at openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>
>>>
>>
>
Ahoj,
zat?m jsem se na to zb??n? pod?val. Jedin? chyba, kterou jsem na?el je, ?e
se n?kolikr?t detekovalo [OVERLAP] a ?ada mezer bez jak?hokoliv textu.
Uzl? s [CHECK][OVERLAP] jsem na?el na t?etin? okresu 8, a to je?t? ve
v?ech p??padech krom? jednoho byl ?et?zec spr?vn? (krom? mezer na konci).
Jinak s t?m garbage collectorem to funguje, nezkou?el jsem kolik to
zpomaluje, ale jestli mysl?? ?e se to projev?, tak by ho mo?n? ?lo volat
jen jednou za 100 dla?dic (nebo n?co takov?ho). Asi je v Monu n?jak? chyba
a GC najednou p?estane automaticky fungovat.
On Sun, 14 Feb 2010 18:40:26 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
> Ahoj,
> mas k tomu jeste nejake zasadni postrehy (co je treba upravit)? Tedy
> krome toho, ze ti to zacne plnit pamet, protoze to se mi nepodarilo
> nasimulovat a ani nemam zadny napad, cim by to mohlo byt.
> Honza
--
Petr Dlouh?
Ahoj,
pokud m?? n?kde po ruce csv v?pis (kde jsou sou?adnice t?ch chyb s
mezerami), tam mi jej pros?m po?li. Kouknul bych se, pro? to nast?v? a
co se s t?m d? d?lat. M??e to zp?sobovat i n?jak? m?n? viditeln?
chyby. U t?ch dat Prahy, kter? jsi mne poslal, se toto nestalo.
S t?m GC to volat t?eba po 100 mapk?ch asi nem? smysl, proto?e ka?d?
bitmapa v pam?ti zabere asi 50 MB (4000x4000 px a v RGB 3 byte na
pixel) a k tomu je?t? dal?? pomocn? struktury ... cel? se to mus?
n?sobit po?tem vl?ken ... tedy alokuje se tam velk? mno?stv? pam?ti.
Ale ten rozd?l ?as? nemus? b?t velk?, proto?e i p?i standardn?m
chov?n? se mus? GC volat celkem ?asto.
Honza
2010/2/14 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Ahoj,
>
> zat?m jsem se na to zb??n? pod?val. Jedin? chyba, kterou jsem na?el je, ?e
> se n?kolikr?t detekovalo [OVERLAP] a ?ada mezer bez jak?hokoliv textu.
> Uzl? s [CHECK][OVERLAP] jsem na?el na t?etin? okresu 8, a to je?t? ve
> v?ech p??padech ?krom? jednoho byl ?et?zec spr?vn? (krom? mezer na konci).
>
> Jinak s t?m garbage collectorem to funguje, nezkou?el jsem kolik to
> zpomaluje, ale jestli mysl?? ?e se to projev?, tak by ho mo?n? ?lo volat
> jen jednou za 100 dla?dic (nebo n?co takov?ho). Asi je v Monu n?jak? chyba
> a GC najednou p?estane automaticky fungovat.
>
> On Sun, 14 Feb 2010 18:40:26 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
> wrote:
>
>> Ahoj,
>> mas k tomu jeste nejake zasadni postrehy (co je treba upravit)? Tedy
>> krome toho, ze ti to zacne plnit pamet, protoze to se mi nepodarilo
>> nasimulovat a ani nemam zadny napad, cim by to mohlo byt.
>> Honza
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Ahoj,
pr?v? ?e to nast?v? u t?ch dat z Prahy-z?pad (generoval jsem to ale s?m),
nap??klad:
50.1673801,14.3893938,[OVERLAP]
50.1025125,14.4268763,[OVERLAP]
50.1025113,14.4268763,[OVERLAP]
50.0950088,14.3479638,[OVERLAP]
50.0950088,14.3479650,[OVERLAP]
S t?m GC nen? probl?m, ?e by v?bec nefungoval - probl?m je s t?m, ?e
najednou p?estane fungovat (po del?? dob? bezprobl?mov?ho v?po?tu).
Souhlas?m ale, ?e zapnut? GC asi nem? velk? vliv na v?kon, tak?e to
nemus?? ?e?it.
On Sun, 14 Feb 2010 23:30:56 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
wrote:
zobrazit citaci
> Ahoj,
> pokud m?? n?kde po ruce csv v?pis (kde jsou sou?adnice t?ch chyb s
> mezerami), tam mi jej pros?m po?li. Kouknul bych se, pro? to nast?v? a
> co se s t?m d? d?lat. M??e to zp?sobovat i n?jak? m?n? viditeln?
> chyby. U t?ch dat Prahy, kter? jsi mne poslal, se toto nestalo.
> S t?m GC to volat t?eba po 100 mapk?ch asi nem? smysl, proto?e ka?d?
> bitmapa v pam?ti zabere asi 50 MB (4000x4000 px a v RGB 3 byte na
> pixel) a k tomu je?t? dal?? pomocn? struktury ... cel? se to mus?
> n?sobit po?tem vl?ken ... tedy alokuje se tam velk? mno?stv? pam?ti.
> Ale ten rozd?l ?as? nemus? b?t velk?, proto?e i p?i standardn?m
> chov?n? se mus? GC volat celkem ?asto.
--
Petr Dlouh?
M?? pravdu, hledal jsem to n?jak ?patn? - m?m to v log?ch... Omlouv?m se.
Honza
2010/2/14 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Ahoj,
>
> pr?v? ?e to nast?v? u t?ch dat z Prahy-z?pad (generoval jsem to ale s?m),
> nap??klad:
>
> 50.1673801,14.3893938,[OVERLAP]
> 50.1025125,14.4268763,[OVERLAP]
> 50.1025113,14.4268763,[OVERLAP]
> 50.0950088,14.3479638,[OVERLAP]
> 50.0950088,14.3479650,[OVERLAP]
>
> S t?m GC nen? probl?m, ?e by v?bec nefungoval - probl?m je s t?m, ?e
> najednou p?estane fungovat (po del?? dob? bezprobl?mov?ho v?po?tu).
> Souhlas?m ale, ?e zapnut? GC asi nem? velk? vliv na v?kon, tak?e to
> nemus?? ?e?it.
>
> On Sun, 14 Feb 2010 23:30:56 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
> wrote:
>
>> Ahoj,
>> pokud m?? n?kde po ruce csv v?pis (kde jsou sou?adnice t?ch chyb s
>> mezerami), tam mi jej pros?m po?li. Kouknul bych se, pro? to nast?v? a
>> co se s t?m d? d?lat. M??e to zp?sobovat i n?jak? m?n? viditeln?
>> chyby. U t?ch dat Prahy, kter? jsi mne poslal, se toto nestalo.
>> S t?m GC to volat t?eba po 100 mapk?ch asi nem? smysl, proto?e ka?d?
>> bitmapa v pam?ti zabere asi 50 MB (4000x4000 px a v RGB 3 byte na
>> pixel) a k tomu je?t? dal?? pomocn? struktury ... cel? se to mus?
>> n?sobit po?tem vl?ken ... tedy alokuje se tam velk? mno?stv? pam?ti.
>> Ale ten rozd?l ?as? nemus? b?t velk?, proto?e i p?i standardn?m
>> chov?n? se mus? GC volat celkem ?asto.
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
Ahoj.
Jedn? se o ?patn? detekovan? body. Tedy ona detekovan? te?ka dan?ho
rozm?ru vznikla slit?m popisk? nebo se te?ka zv?t?ila, proto?e se
slila s popiskem. Tedy takov?to body nejsou ve skute?nosti adresn?
body.
Nov? verze beta 4 s drobn?mi ?pravami:
a) takov?to body ozna?uje [CHECK][OVERLAP][NOT POINT] (kv?li mo?nosti
kontroly, pokud se potvrd? spr?vn? funkce programu, tak je m??e
program klidn? zcela vynech?vat)
b) spou?t? vl?kna s men?? prioritou, aby program mohl b??et na pozad?,
ani? by to v?razn? zpomalovalo ostatn? programy
c) vynech?v? pr?zdn? dla?dice 4000x4000 je?t? p?ed rozbalen?m bitmapy
v pam?ti (kontroluje velikost a CRC32 souboru)
d) odd?luje mo?nosti v p??pad? nejednozna?nosti svisl?tkem, tedy m?sto
?[?.p.bez ?.p./?.e.]
je
?[?.p.|bez ?.p./?.e.]
e) v logu form?tuje sou?adnice (lon, lat) stejn? jako v csv kv?li
snadn?m dohled?v?n?
http://jabi.aspone.cz/osm/OcrBeta4.zip
Honza
2010/2/14 Jan Bilak <jan.bilak.osm at gmail.com>:
zobrazit citaci
> M?? pravdu, hledal jsem to n?jak ?patn? - m?m to v log?ch... Omlouv?m se.
>
> Honza
>
>
> 2010/2/14 Petr Dlouh? <petr.dlouhy at email.cz>:
>> Ahoj,
>>
>> pr?v? ?e to nast?v? u t?ch dat z Prahy-z?pad (generoval jsem to ale s?m),
>> nap??klad:
>>
>> 50.1673801,14.3893938,[OVERLAP]
>> 50.1025125,14.4268763,[OVERLAP]
>> 50.1025113,14.4268763,[OVERLAP]
>> 50.0950088,14.3479638,[OVERLAP]
>> 50.0950088,14.3479650,[OVERLAP]
>>
>> S t?m GC nen? probl?m, ?e by v?bec nefungoval - probl?m je s t?m, ?e
>> najednou p?estane fungovat (po del?? dob? bezprobl?mov?ho v?po?tu).
>> Souhlas?m ale, ?e zapnut? GC asi nem? velk? vliv na v?kon, tak?e to
>> nemus?? ?e?it.
>>
>> On Sun, 14 Feb 2010 23:30:56 +0100, Jan Bilak <jan.bilak.osm at gmail.com>
>> wrote:
>>
>>> Ahoj,
>>> pokud m?? n?kde po ruce csv v?pis (kde jsou sou?adnice t?ch chyb s
>>> mezerami), tam mi jej pros?m po?li. Kouknul bych se, pro? to nast?v? a
>>> co se s t?m d? d?lat. M??e to zp?sobovat i n?jak? m?n? viditeln?
>>> chyby. U t?ch dat Prahy, kter? jsi mne poslal, se toto nestalo.
>>> S t?m GC to volat t?eba po 100 mapk?ch asi nem? smysl, proto?e ka?d?
>>> bitmapa v pam?ti zabere asi 50 MB (4000x4000 px a v RGB 3 byte na
>>> pixel) a k tomu je?t? dal?? pomocn? struktury ... cel? se to mus?
>>> n?sobit po?tem vl?ken ... tedy alokuje se tam velk? mno?stv? pam?ti.
>>> Ale ten rozd?l ?as? nemus? b?t velk?, proto?e i p?i standardn?m
>>> chov?n? se mus? GC volat celkem ?asto.
>>
>>
>> --
>> Petr Dlouh?
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
Ahoj,
ja byl ted tyden pryc, proto jsem se do diskuze a reseni problemu nezapojil.
Pokud spravne chapu situaci, tak problem je u c.e., ve kterych je
cislice 2 se obcas stava a obcas se stava, ze se rozpozna jako 7. Jak
jsem z diskuze pochopil, tak Honza Bilak napsal programek, ktery vezme
celou dlazdici a provede OCR jinym zpusobem.
Ja mam pripravene skripty na docisteni vysledku (slouceni dat z
dlazdic, vymazani duplicit zpusobenych prekryvem dlazdic, vyfiltorvani
bodu ktere neodpovidaji vzoru c.p., c.e., bez cp./c.e a jejich stazeni
ve vyssim rozliseni a znovuprovedeni OCR - vyreseni prokryvajicich se
napisu)
Vysledky po stazeni detailu a znovuprovedeni OCR jsou celkem dobre. Na
datech, co byla spocitana minuly tyden (cca 2/3 republiky) je po
znovuprovedeni OCR jen 1050 adresnich bodu, ktere neodpovidaji
zadanemu vzoru.
Myslim, ze by bylo zbytecne zpracovavat celou CR znovu. Z dat si muzu
vytahnout c.e., ktera obsahuji cislici 7, stahnout si detail ve vyssim
rozliceni a ten misto terreractem zpracovat algoritmem od Honzy.
--
Lukas
Ahoj,
algoritmus po Honzov?ch ?prav?ch pracuje v?razn? rychleji a dok??e
detekovat p?ekr?vaj?c? se ??sla s t?m?? 100% ?sp??nost? (na rozs?hl?m
?zem? jsou to jednotky chyb). Vzhledem k tomu, ?e je to mo?n? zpracovat za
n?kolik dn? na jednom PC, tak bych ?ekl, ?e se to p?ed?lat vyplat?.
On Mon, 15 Feb 2010 09:44:58 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
zobrazit citaci
> Ahoj,
>
> ja byl ted tyden pryc, proto jsem se do diskuze a reseni problemu
> nezapojil.
>
> Pokud spravne chapu situaci, tak problem je u c.e., ve kterych je
> cislice 2 se obcas stava a obcas se stava, ze se rozpozna jako 7. Jak
> jsem z diskuze pochopil, tak Honza Bilak napsal programek, ktery vezme
> celou dlazdici a provede OCR jinym zpusobem.
>
> Ja mam pripravene skripty na docisteni vysledku (slouceni dat z
> dlazdic, vymazani duplicit zpusobenych prekryvem dlazdic, vyfiltorvani
> bodu ktere neodpovidaji vzoru c.p., c.e., bez cp./c.e a jejich stazeni
> ve vyssim rozliseni a znovuprovedeni OCR - vyreseni prokryvajicich se
> napisu)
>
> Vysledky po stazeni detailu a znovuprovedeni OCR jsou celkem dobre. Na
> datech, co byla spocitana minuly tyden (cca 2/3 republiky) je po
> znovuprovedeni OCR jen 1050 adresnich bodu, ktere neodpovidaji
> zadanemu vzoru.
>
> Myslim, ze by bylo zbytecne zpracovavat celou CR znovu. Z dat si muzu
> vytahnout c.e., ktera obsahuji cislici 7, stahnout si detail ve vyssim
> rozliceni a ten misto terreractem zpracovat algoritmem od Honzy.
> --
> Lukas
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouh?
Ahoj,
nezkousel jsem porovnavat vysledky z tesseractu a meho rozpoznavani
vzoru, ale myslim, ze by to slo snadno. Staci nejaka data, ktera byla
zpracovana tesseractem, zpracovat take timto. Oba csv soubory seradit
a pouzit nejaky klasicky diff.
Obecne mam obavu, ze tesseract se muze splest a rozpoznat cislo
spatne, i kdyz vysledek rozpoznani odpovida vzoru. Zato muj OCR na
miru detektuje pripady, kdy si neni jisty, a loguje je, aby je bylo
mozne rucne zkontrolovat. Pritom je jich dostatecne maly pocet na to,
aby rucni kontrola byla proveditelna. Pokud v programu neni chyba (coz
nevylucuji), tak by program nemel popisek rozpoznat spatne, aniz by
jej oznacil, ze si neni jisty.
To byl hlavni cil, proc jsem OCR delal - zajisteni spolehlivosti.
Zvyseni rychlosti bylo druhorade, i kdyz je to prijemne.
Honza
2010/2/15 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Ahoj,
>
> algoritmus po Honzov?ch ?prav?ch pracuje v?razn? rychleji a dok??e
> detekovat p?ekr?vaj?c? se ??sla s t?m?? 100% ?sp??nost? (na rozs?hl?m
> ?zem? jsou to jednotky chyb). Vzhledem k tomu, ?e je to mo?n? zpracovat za
> n?kolik dn? na jednom PC, tak bych ?ekl, ?e se to p?ed?lat vyplat?.
>
> On Mon, 15 Feb 2010 09:44:58 +0100, Lukas Kabrt <lukas at kabrt.cz> wrote:
>
>> Ahoj,
>>
>> ja byl ted tyden pryc, proto jsem se do diskuze a reseni problemu
>> nezapojil.
>>
>> Pokud spravne chapu situaci, tak problem je u c.e., ve kterych je
>> cislice 2 se obcas stava a obcas se stava, ze se rozpozna jako 7. Jak
>> jsem z diskuze pochopil, tak Honza Bilak napsal programek, ktery vezme
>> celou dlazdici a provede OCR jinym zpusobem.
>>
>> Ja mam pripravene skripty na docisteni vysledku (slouceni dat z
>> dlazdic, vymazani duplicit zpusobenych prekryvem dlazdic, vyfiltorvani
>> bodu ktere neodpovidaji vzoru c.p., c.e., bez cp./c.e a jejich stazeni
>> ve vyssim rozliseni a znovuprovedeni OCR - vyreseni prokryvajicich se
>> napisu)
>>
>> Vysledky po stazeni detailu a znovuprovedeni OCR jsou celkem dobre. Na
>> datech, co byla ?spocitana minuly tyden (cca 2/3 republiky) je po
>> znovuprovedeni OCR jen 1050 adresnich bodu, ktere neodpovidaji
>> zadanemu vzoru.
>>
>> Myslim, ze by bylo zbytecne zpracovavat celou CR znovu. Z dat si muzu
>> vytahnout c.e., ktera obsahuji cislici 7, stahnout si detail ve vyssim
>> rozliceni a ten misto terreractem zpracovat algoritmem od Honzy.
>> --
>> Lukas
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
> --
> Petr Dlouh?
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
zobrazit citaci
> Obecne mam obavu, ze tesseract se muze splest a rozpoznat cislo
> spatne, i kdyz vysledek rozpoznani odpovida vzoru. Zato muj OCR na
> miru detektuje pripady, kdy si neni jisty, a loguje je, aby je bylo
> mozne rucne zkontrolovat. Pritom je jich dostatecne maly pocet na to,
> aby rucni kontrola byla proveditelna. Pokud v programu neni chyba (coz
> nevylucuji), tak by program nemel popisek rozpoznat spatne, aniz by
> jej oznacil, ze si neni jisty.
Tak ja jsem zkusil porovnat vysledky puvodniho a tveho programu.
Puvodni program skutecne dela chyby u budov s c.e., mimo zminovaneho
problemu 2/7 jeste obcas dochazi k zamene 6/8. U budov s c.p. jsou ve
vetsine pripadu stejne. Narazil jsem na par rozdilu, ktere tvuj
program oznacuje jako [CHECK].
Takze, i kdyz uz je vse spocitane, tak asi mate pravdu, ze by stalo za
to rozpoznani udelat znovu. Mrzi me to, netusil jsem ze tesseract si s
tim neporadi a pri testovani jsem si tohohle problemu nevsimnul.
BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program pracuje.
--
Lukas
Princip pr?ce Honzova programu se d? jednodu?e poznat z logov?ch soubor?.
Zdroj?ky by asi bylo nejlep?? nahr?t na <http://svn.openstreetmap.org/applications/utils/>, abychom se s nimi p?i p???t?m importu zase setkali, a aby se jimi mohli inspirovat i ostatn?.
zobrazit citaci
> ------------ P?vodn? zpr?va ------------
> Od: Lukas Kabrt <lukas at kabrt.cz>
> P?edm?t: Re: [Talk-cz] Import adres z katastralni mapy
> Datum: 17.2.2010 15:38:57
> ----------------------------------------
zobrazit citaci
> BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program pracuje.
>
> --
> Lukas
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
Petr Dlouh?
petr.dlouhy at email.cz
Ahoj,
odkaz na zdroj?ky jsem do t?to konference u? zas?lal (na betu 3) - o
p?r p??sp?vk? v??e jej najde?. Beta 4 upravovala jen drobnosti. Je?t?
zdroj?ky trochu uprav?m (po form?ln? str?nce - refaktoring, koment??e,
...) ... a pak, kdy? vymysl?te vhodn? m?sto na SVN, tak tam nahraju.
Obecn? si ale mysl?m, ?e je vhodn? d?lat tyto utility jako class
library (v p??pad? .NETu) s n?jak?m rozumn?m interfacem, aby je bylo
mo?n? za?l??ovat do celku. Tedy m?sto dlouh?ho postupu, co spou?t?t v
jak?m po?ad?, tak pak m?t utilitku s p??jemn?m rozhran?m (a? ji?
konzolov?m nebo GUI), kter? tohle v?echno za??d?. A p?itom jednotliv?
??sti ?e?en? jako vym?niteln? a nahraditeln? jinou implementac?.
Jinak m?m velk? pochybnosti o tom, ?e se budou dostate?n? ?asto data
aktualizovat. U? to nebude m?t takov? ten "wow" efekt, kdy na map?ch
p?ibude mnoho dat a tak se do toho nikomu nebude moc cht?t, kdy? to
bude slo?it?.
Honza
2010/2/17 Petr Dlouh? <petr.dlouhy at email.cz>:
zobrazit citaci
> Princip pr?ce Honzova programu se d? jednodu?e poznat z logov?ch soubor?.
>
> Zdroj?ky by asi bylo nejlep?? nahr?t na <http://svn.openstreetmap.org/applications/utils/>, abychom se s nimi p?i p???t?m importu zase setkali, a aby se jimi mohli inspirovat i ostatn?.
>
>
>> ------------ P?vodn? zpr?va ------------
>> Od: Lukas Kabrt <lukas at kabrt.cz>
>> P?edm?t: Re: [Talk-cz] Import adres z katastralni mapy
>> Datum: 17.2.2010 15:38:57
>> ----------------------------------------
>
>> BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program pracuje.
>>
>> --
>> Lukas
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>>
>
> Petr Dlouh?
> petr.dlouhy at email.cz
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
A mimochodem nejde o m?j program ... je to upraven? ten tv?j.
Honza
2010/2/17 Jan Bilak <jan.bilak.osm at gmail.com>:
zobrazit citaci
> Ahoj,
>
> odkaz na zdroj?ky jsem do t?to konference u? zas?lal (na betu 3) - o
> p?r p??sp?vk? v??e jej najde?. Beta 4 upravovala jen drobnosti. Je?t?
> zdroj?ky trochu uprav?m (po form?ln? str?nce - refaktoring, koment??e,
> ...) ... a pak, kdy? vymysl?te vhodn? m?sto na SVN, tak tam nahraju.
>
> Obecn? si ale mysl?m, ?e je vhodn? d?lat tyto utility jako class
> library (v p??pad? .NETu) s n?jak?m rozumn?m interfacem, aby je bylo
> mo?n? za?l??ovat do celku. Tedy m?sto dlouh?ho postupu, co spou?t?t v
> jak?m po?ad?, tak pak m?t utilitku s p??jemn?m rozhran?m (a? ji?
> konzolov?m nebo GUI), kter? tohle v?echno za??d?. A p?itom jednotliv?
> ??sti ?e?en? jako vym?niteln? a nahraditeln? jinou implementac?.
>
> Jinak m?m velk? pochybnosti o tom, ?e se budou dostate?n? ?asto data
> aktualizovat. U? to nebude m?t takov? ten "wow" efekt, kdy na map?ch
> p?ibude mnoho dat a tak se do toho nikomu nebude moc cht?t, kdy? to
> bude slo?it?.
>
> Honza
>
>
> 2010/2/17 Petr Dlouh? <petr.dlouhy at email.cz>:
>> Princip pr?ce Honzova programu se d? jednodu?e poznat z logov?ch soubor?.
>>
>> Zdroj?ky by asi bylo nejlep?? nahr?t na <http://svn.openstreetmap.org/applications/utils/>, abychom se s nimi p?i p???t?m importu zase setkali, a aby se jimi mohli inspirovat i ostatn?.
>>
>>
>>> ------------ P?vodn? zpr?va ------------
>>> Od: Lukas Kabrt <lukas at kabrt.cz>
>>> P?edm?t: Re: [Talk-cz] Import adres z katastralni mapy
>>> Datum: 17.2.2010 15:38:57
>>> ----------------------------------------
>>
>>> BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program pracuje.
>>>
>>> --
>>> Lukas
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>>
>>>
>>
>> Petr Dlouh?
>> petr.dlouhy at email.cz
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
Ne? to n?jak uprav?m ... tak zat?m je?t? p?ikl?d?m beta4 zdroj?ky pro z?jemce:
http://jabi.aspone.cz/osm/FindAddressPoints-beta4-src.zip
Honza
2010/2/17 Jan Bilak <jan.bilak.osm at gmail.com>:
zobrazit citaci
> A mimochodem nejde o m?j program ... je to upraven? ten tv?j.
>
> Honza
>
>
> 2010/2/17 Jan Bilak <jan.bilak.osm at gmail.com>:
>> Ahoj,
>>
>> odkaz na zdroj?ky jsem do t?to konference u? zas?lal (na betu 3) - o
>> p?r p??sp?vk? v??e jej najde?. Beta 4 upravovala jen drobnosti. Je?t?
>> zdroj?ky trochu uprav?m (po form?ln? str?nce - refaktoring, koment??e,
>> ...) ... a pak, kdy? vymysl?te vhodn? m?sto na SVN, tak tam nahraju.
>>
>> Obecn? si ale mysl?m, ?e je vhodn? d?lat tyto utility jako class
>> library (v p??pad? .NETu) s n?jak?m rozumn?m interfacem, aby je bylo
>> mo?n? za?l??ovat do celku. Tedy m?sto dlouh?ho postupu, co spou?t?t v
>> jak?m po?ad?, tak pak m?t utilitku s p??jemn?m rozhran?m (a? ji?
>> konzolov?m nebo GUI), kter? tohle v?echno za??d?. A p?itom jednotliv?
>> ??sti ?e?en? jako vym?niteln? a nahraditeln? jinou implementac?.
>>
>> Jinak m?m velk? pochybnosti o tom, ?e se budou dostate?n? ?asto data
>> aktualizovat. U? to nebude m?t takov? ten "wow" efekt, kdy na map?ch
>> p?ibude mnoho dat a tak se do toho nikomu nebude moc cht?t, kdy? to
>> bude slo?it?.
>>
>> Honza
>>
>>
>> 2010/2/17 Petr Dlouh? <petr.dlouhy at email.cz>:
>>> Princip pr?ce Honzova programu se d? jednodu?e poznat z logov?ch soubor?.
>>>
>>> Zdroj?ky by asi bylo nejlep?? nahr?t na <http://svn.openstreetmap.org/applications/utils/>, abychom se s nimi p?i p???t?m importu zase setkali, a aby se jimi mohli inspirovat i ostatn?.
>>>
>>>
>>>> ------------ P?vodn? zpr?va ------------
>>>> Od: Lukas Kabrt <lukas at kabrt.cz>
>>>> P?edm?t: Re: [Talk-cz] Import adres z katastralni mapy
>>>> Datum: 17.2.2010 15:38:57
>>>> ----------------------------------------
>>>
>>>> BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program pracuje.
>>>>
>>>> --
>>>> Lukas
>>>>
>>>> _______________________________________________
>>>> Talk-cz mailing list
>>>> Talk-cz at openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>
>>>>
>>>>
>>>
>>> Petr Dlouh?
>>> petr.dlouhy at email.cz
>>>
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>
>
Ahoj,
par informac?, co je nov?ho ohledn? importu adres.
Znovu jsem provedl OCR s vylep?en?m programem. V?sledek je na [1]
Vylep?il jsem program merge-cuzk-db [2]
- lep?? detekce probl?m? (duplicity)
- mo?nost zpracov?n? v?ce *.map soubor? najednou
- rychlej?? zpracov?n? osm a xml soubor? (bez probl?m? lze pou??vat
soubor s hranicemi k.?. pro celou ?R)
- zm?na ozna?en? nekonzistentn?ch dat (tag note m?sto tagu fixme) -
podle toho co jsem koukal, tak fixme se pou??v? pro z?va?n?j??
pronl?my
Na wiki [3] je p?r bod? k nov? verzi programu. Postupn? tam budu
p?id?vat odkazy na zip soubory s daty pro jednotliv? okresy (archiv
obsahuje map soubory, soubor s polohami budov a v?sledkem ocr, osm
soubory pro obce, kde je p?edpoklad, ?e map soubor je spr?vn?). V
sou?asn? dob? jsou na wiki odkazy na prvn?ch 5 soubor?.
Pokud se n?kdo pust?te do importu, tak pros?m data aspo? zb??n?
zkontrolujte - jestli jsem neud?lal n?jakou chyby, kter? jsem si
nev?imnul. V?c o??, v?c vid? :-)
[1] lkabrt.aspone.cz/osm/cz.zip
[2] http://osm.kabrt.cz/home/adresy.zip?attredirects=0&d=1
[3] http://wiki.openstreetmap.org/wiki/Import_Adres_?R#P.C5.99ehled_import.C5.AF
--
Lukas
Cht?l jsem se na to pod?vat, ale chce to po m? .NET Framework 4.0.3...
N?jak si nejsem jist?, kterou z t?ch mnoha verz? co MS nab?z? m?m
nainstalovat a po p?edcho?zch zku?enostech, kdy mi instalace .NET 3.5
rozhasila n?kter? v?ci se mi do toho ani moc nechce.
M??e? d?t podrobn?j?? n?vod, p??padn? link na spr?vnou verzi?
J&D
2010/2/23 Lukas Kabrt <lukas at kabrt.cz>:
zobrazit citaci
> Ahoj,
>
> par informac?, co je nov?ho ohledn? importu adres.
>
> Znovu jsem provedl OCR s vylep?en?m programem. V?sledek je na [1]
>
> Vylep?il jsem program merge-cuzk-db [2]
> - lep?? detekce probl?m? (duplicity)
> - mo?nost zpracov?n? v?ce *.map soubor? najednou
> - rychlej?? zpracov?n? osm a xml soubor? (bez probl?m? lze pou??vat
> soubor s hranicemi k.?. pro celou ?R)
>
> - zm?na ozna?en? nekonzistentn?ch dat (tag note m?sto tagu fixme) -
> podle toho co jsem koukal, tak fixme se pou??v? pro z?va?n?j??
> pronl?my
>
> Na wiki [3] je p?r bod? k nov? verzi programu. Postupn? tam budu
> p?id?vat odkazy na zip soubory s daty pro jednotliv? okresy (archiv
> obsahuje map soubory, soubor s polohami budov a v?sledkem ocr, osm
> soubory pro obce, kde je p?edpoklad, ?e map soubor je spr?vn?). V
> sou?asn? dob? jsou na wiki odkazy na prvn?ch 5 soubor?.
>
> Pokud se n?kdo pust?te do importu, tak pros?m data aspo? zb??n?
> zkontrolujte - jestli jsem neud?lal n?jakou chyby, kter? jsem si
> nev?imnul. V?c o??, v?c vid? :-)
>
> [1] lkabrt.aspone.cz/osm/cz.zip
> [2] http://osm.kabrt.cz/home/adresy.zip?attredirects=0&d=1
> [3] http://wiki.openstreetmap.org/wiki/Import_Adres_?R#P.C5.99ehled_import.C5.AF
> --
> Lukas
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
--
--
Ing. Jan Dud?k
2010/2/23 Jan Dud?k <jan.dudik at gmail.com>:
zobrazit citaci
> Cht?l jsem se na to pod?vat, ale chce to po m? .NET Framework 4.0.3...
> N?jak si nejsem jist?, kterou z t?ch mnoha verz? co MS nab?z? m?m
> nainstalovat a po p?edcho?zch zku?enostech, kdy mi instalace .NET 3.5
> rozhasila n?kter? v?ci se mi do toho ani moc nechce.
> M??e? d?t podrobn?j?? n?vod, p??padn? link na spr?vnou verzi?
.NET Framework 4.0 bych ur?it? b??n?m u?ivatel?m nedoporu?oval
instalovat, zat?m to nen? fin?ln? verze a zad?l?te si na mo?n?
probl?my, a? budete instalovat ostrou verzi (mluv?m z vlastn?
zku?enosti s aktualizac? z Beta 1 na Beta 2?).
-- Petr Kadlec / Mormegil
Dne 23. ?nora 2010 9:56 Petr Kadlec <petr.kadlec at gmail.com> napsal(a):
zobrazit citaci
> 2010/2/23 Jan Dud?k <jan.dudik at gmail.com>:
>> Cht?l jsem se na to pod?vat, ale chce to po m? .NET Framework 4.0.3...
>> N?jak si nejsem jist?, kterou z t?ch mnoha verz? co MS nab?z? m?m
>> nainstalovat a po p?edcho?zch zku?enostech, kdy mi instalace .NET 3.5
>> rozhasila n?kter? v?ci se mi do toho ani moc nechce.
>> M??e? d?t podrobn?j?? n?vod, p??padn? link na spr?vnou verzi?
>
> .NET Framework 4.0 bych ur?it? b??n?m u?ivatel?m nedoporu?oval
> instalovat, zat?m to nen? fin?ln? verze a zad?l?te si na mo?n?
> probl?my, a? budete instalovat ostrou verzi (mluv?m z vlastn?
> zku?enosti s aktualizac? z Beta 1 na Beta 2?).
>
> -- Petr Kadlec / Mormegil
Tek?e dotaz zn?, zda lze tuto pr?ci ud?lat i jinak, s dostupn?mi
prost?edky (JOSM, Java, NET <4)
J&D
zobrazit citaci
> Cht?l jsem se na to pod?vat, ale chce to po m? .NET Framework 4.0.3...
> N?jak si nejsem jist?, kterou z t?ch mnoha verz? co MS nab?z? m?m
> nainstalovat a po p?edcho?zch zku?enostech, kdy mi instalace .NET 3.5
> rozhasila n?kter? v?ci se mi do toho ani moc nechce.
> M??e? d?t podrobn?j?? n?vod, p??padn? link na spr?vnou verzi?
Za .NET framework 4 se omlouv?m, pou??v?m Beta verzi nov?ho Visual
Studia a ta m? defaultn? nastaven? pou?it? .NET frameworku 4, n?jak
jsem si to neuv?domil.
Tady [1] program zkompilov?n pro verzi 3.5.
[1] http://sites.google.com/a/kabrt.cz/osm/home/adresy.zip?attredirects=0&d=1
--
Lukas
Je?t? jeden dotaz:
Ve sta?en?m souboru (Beroun) u? jsou v?echny v?stupy ud?lan?, pro? je
tedy t?eba zprovoz?ovat program?
tam, kde jsou konflikty mi program spadne.
BTW, co ten import ktastr?ln?ch ?zem?? soubor existuje, pro? nen?
z?rove? nahr?n?
J&D
2010/2/23 Lukas Kabrt <lukas at kabrt.cz>:
zobrazit citaci
>> Cht?l jsem se na to pod?vat, ale chce to po m? .NET Framework 4.0.3...
>> N?jak si nejsem jist?, kterou z t?ch mnoha verz? co MS nab?z? m?m
>> nainstalovat a po p?edcho?zch zku?enostech, kdy mi instalace .NET 3.5
>> rozhasila n?kter? v?ci se mi do toho ani moc nechce.
>> M??e? d?t podrobn?j?? n?vod, p??padn? link na spr?vnou verzi?
>
> Za .NET framework 4 se omlouv?m, pou??v?m Beta verzi nov?ho Visual
> Studia a ta m? defaultn? nastaven? pou?it? .NET frameworku 4, n?jak
> jsem si to neuv?domil.
>
> Tady [1] program zkompilov?n pro verzi 3.5.
>
> [1] http://sites.google.com/a/kabrt.cz/osm/home/adresy.zip?attredirects=0&d=1
> --
> Lukas
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
--
--
Ing. Jan Dud?k
zobrazit citaci
> Ve sta?en?m souboru (Beroun) u? jsou v?echny v?stupy ud?lan?, pro? je
> tedy t?eba zprovoz?ovat program?
V?stupy jsou ud?lan? pro m?sta, kde se poda?il automaticky vytvo?it
*.map soubor. U dal??ch (n?zev souboru za??n? podtr??tkem) je n?jak?
nejasnost v *.map souboru. Je pot?eba map soubor upravit a vygenerovat
osm soubory - proto je pot?eba zprovoznit program.
zobrazit citaci
> tam, kde jsou konflikty mi program spadne.
M??u se zeptat co vyp??e za chybu? (spustit p?es p??kazov? ??dek, pak
z?stane chyba na obrazovace)
zobrazit citaci
> BTW, co ten import ktastr?ln?ch ?zem?? soubor existuje, pro? nen?
> z?rove? nahr?n?
Nahr?n nen?, proto?e to je?t? nikdo neud?lal :-)
A nahr?vat ho sou?asn? s adresami mi nep?ijde jako ??astn? n?pad - je
nutn? vy?e?it konflikty s existuj?c?mi daty, napojen? na existuj?c?
relace apod.
--
Lukas« zpět na výpis měsíce