Proč ne ref? Dá se snad využít nějak jinak?
To bude asi ten spravny atribut.
Řekl bych, že všechna území, která v mapě jsou (možná s výjimkou hranic s
Německem) jsou méně přesná, a je tedy je možné smazat (pokud tedy nejsou
nějak vázána na další objekty). Možná by ale bylo dobré zkopírovat
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
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
...
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
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
Ahoj,
dělal jsem na programu, který by dokázal rozumně trasovat budovy z
digit. map katastru. Ty ruční čmáranice ze skenů mnoha let starých map
myslím nemá smysl automaticky trasovat. Zkoušel jsem to pomocí potrace
apod. ... ale nějak mi to nedopadalo moc dobře, takže jsem se rozhodl
pro vlastní
No dokonalý! Super práce, určitě bych nechtěl integraci do JOSM, ne
každý s ním pracuje.
J.
2010/1/26 Jan Bilak jan.bilak@gmail.com:
Ahoj,
dělal jsem na programu, který by dokázal rozumně trasovat budovy z
digit. map katastru. Ty ruční čmáranice ze skenů mnoha let starých map
myslím
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
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
Já bych naopak integraci do JOSM velmi ocenil, nemusel bych pak
všechno procházet dvakrát a vše by bylo vidět pěkně v kontextu už
existujících dat. Nicméně udělat to neumím, programátor nejsem.
2010/1/26 Frettie fret...@gmail.com:
No dokonalý! Super práce, určitě bych nechtěl integraci do JOSM,
Teď mě vlastně napdalo, že ref by mělo spíš znamenat NUTS, protože to je
univerzálnější číslo. Tedy jestli mají katastrální území NUTS.
On Tue, 26 Jan 2010 10:11:41 +0100, Lukas Kabrt lu...@kabrt.cz wrote:
To bude asi ten spravny atribut.
--
Petr Dlouhý
Díky za synchronizaci postupu.
On Tue, 26 Jan 2010 20:10:09 +0100, Lukas Kabrt lu...@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.
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
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
Ok, když jsi schopný to kontrolovat v JOSM, tak není problém. Ale
nezapomeň, že toho bude spousta.
Honza
2010/1/26 Lukas Kabrt lu...@kabrt.cz:
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
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
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 lu...@kabrt.cz wrote:
To mas pravdu, asi jsem blbe identifikoval pricinu. Pravy duvod
2010/1/26 Jiri Parkan jpar...@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
18 matches
Mail list logo
