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
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),
/24 Petr Dlouhý petr.dlo...@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@gmail.com
wrote:
Ahoj, udělal jsem si utilitku pro vyjmutí
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 lu...@kabrt.cz:
V kroku 3
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@gmail.com
wrote:
A hlavně mým cílem je, aby celý proces byl
/mapa.jsp?budId=207400obrprvId=184459
Honza
2010/1/24 Jan Bilak jan.bilak@gmail.com:
Já nemyslel GUI v tom smyslu, že tam bude 5 tlačítek a ty budou
spouštět tyhle skripty. Ale co je třeba dělat?
Pro adresní body:
- vybrat území, které mne zajímá (zajímavá informace zde bude, co už
je hotové
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@gmail.com
wrote:
Veškeré údaje na internetových stránkách ČSÚ
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
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@gmail.com:
Já myslím, že hodně času
Ahoj,
existuje něco hotového, čím lze dávkově zjednodušovat polygony v *.osm
souborech (nebo v něčem dávkově převeditelném)? Konkrétně zkouším
pracovat na trasování budov z katastrální mapy, ale budovy zatím mám
složené z příliš mnoha bodů (něco už jsem osekal, ale pořád to není
dostatečné). 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í
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
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
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.dlo...@email.cz:
Hm, tak bohužel program na Linuxu nefunguje (tedy pod Wine ano).
Důvodem je neimplementovaná metoda System.Drawing.Image.SaveAdd v Linuxové
taková potíž..
Každopádně supr!
Zdravím,
Pavel Zbytovský
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 nemá smysl automaticky trasovat
@openstreetmap.org
Právě, ono takovej merkaartor je super věc, JOSM je jak složitý, tak
prostě ovladatelný. :/ Ale asi by mě to donutilo přejít, to zas jo.
2010/1/27 Jan Bilak jan.bilak@gmail.com:
Ahoj,
uvažoval jsem podobně ... zatím tedy o JOSM a API pro pluginy moc
nevím. A v Javě jsem něco
, mě se lehce škubne, jen při
velkém počtu bodů a linek (a to nemám zdaleka oslnivý hardware). Ale
API nemá (zatím).
2010/1/28 Jan Bilak jan.bilak@gmail.com:
Na Merkaator jsem zběžně koukal a nějak mne zatím nepřesvědčil. A to
ani možnostmi (to jsem ani moc nečekal), ani rychlostí (to jsem
(to vrátí XML se stejnými daty)
Naopak, pokud kliknete v JOSM na nějaký bod nástrojem Tracer, tak v
okénku serveru uvidíte, co tam přišlo za požadavek...
Honza
2010/1/29 Jan Bilak jan.bilak@gmail.com:
Zdravím pánové,
prosím o vyzkoušení první betaverze traceru budov z katastrálních map
u programu, kterej bych někdy měl použít být nemůže.
To vidím jen já, jak je to nešikovnej program?
Zlatej Merkaartor, uvítal bych tak i možnost klikat v nějakém okně
samostatně. Jo a mimochodem, je to jen u mě, nebo víc lidem u v. 2561
nefunguje czechadress?
J.
2010/1/29 Jan Bilak
/applications/editors/josm/plugins/00_README
On Mon, 01 Feb 2010 04:28:58 +0100, Jan Bilak jan.bilak@gmail.com
wrote:
Na commitnutí do ofic. SVN by to potřebovalo:
a) formálně doladit (po stránkách struktury adresářů, build skriptů,
informace o licenci, ...)
b) získat přístup do SVN
c) zpřehlednit
stáhnout.
Původní zpráva
Od: Jan Bilak jan.bilak@gmail.com
Předmět: Re: [Talk-cz] Tracer na rozpoznání budov z katastr. map
Datum: 02.2.2010 16:33:31
Ahoj,
jj, ohledně spojování ... máme na to stejný názor. Ohledně
.
Honza
2010/2/2 Jan Bilak jan.bilak@gmail.com:
Díky za nápady, úpravu ... a omlouvám se za chybu v URL a chybějící
ikonky ... tyhle tvoje jsou ale myslím hezčí.
Správně je:
http://jabi.aspone.cz/osm/TraceServerBeta2-src.zip
(tedy bez r)
Honza
2010/2/2 Petr Dlouhý petr.dlo
posílám první drobnou opravu - změnu pluginu z nástroje na editační
mód. Tato změna odstraňuje mnoho problémů, které předchozí chování
způsobovalo.
Ikony si neposlal, takže jsem musel použít náhradní.
Původní zpráva
Od: Jan Bilak jan.bilak@gmail.com
Předmět
stejně to samo fungovat zatím
nebude.
Honza
2010/2/4 Jan Bilak jan.bilak@gmail.com:
Ahoj,
díky. Zrovna dělám na úpravách, které se trochu překrývají ... snažil
jsem se to rozhodit do tříd a metod, okomentovat a vůbec trochu
zkulturnit, napojovat jen na budovy, ... No nevadí. Zkusím
pluginu. Obecně netuším, jak s verzemi
funguje - tedy vůči jaké revizi zdrojáků JOSM se má plugin kompilovat.
Stáhnul jsem nějakou z počátku prosince, ale tak odhadem, protože
nevím, jakou přesnou revizi použít.
Honza
2010/2/4 Jan Bilak jan.bilak@gmail.com:
Díky, jak jednoduché :)
Honza
Ahoj. Je to tak. Ve Windows je vyžadován .NET Framework (tuším verze
2.0+, 3.5 stačí určitě). Je celkem pravděpodobné, že .NET Framework už
v počítači máš, pokud máš Windows. Ve Vistách a Windows 7 je přímo
(tedy ve Vistách ve verzi 3.0). V XPčkách není, ale vyžaduje jej hodně
programů a tedy se
Spřežky se tuším nazývají ty čáry, které naznačují vztah dvou ploch,
které jsou oddělené čarou. Tedy je to taková čára ve tvaru písmene
s, která vede z jedné plochy do druhé.
Honza
2010/2/4 Petr Dlouhý petr.dlo...@email.cz:
O integraci serveru už jsme psali, ale jsou podstatnější věci.
Nevím,
Ahoj,
ten tracker se snažil to čáru posouvat na střed čáry (tedy nejprve
obtáhnul vnitřní hranu, pak zkoušel detekovat tlouštky čar a čáru
posouvat). Ale moc mu to nešlo. Mám rozpracovanou úpravu, která to
myslím trochu zlepší. Chybu to občas udělá, ale je to myslím lepší.
Zazněl tady nápad -
, že se to
chová stále rozumně. Když tam ale je, tak to občas nespojí něco, co by
spojit mohlo.
On Sat, 06 Feb 2010 18:25:00 +0100, Jan Bilak jan.bilak@gmail.com
wrote:
Ahoj,
ten tracker se snažil to čáru posouvat na střed čáry (tedy nejprve
obtáhnul vnitřní hranu, pak zkoušel detekovat
Experimentální verze TraceServeru - jen pro toho, kdo to chce vyzkoušet:
http://jabi.aspone.cz/www/osm/TraceServerBeta3.zip
(nenahrazuje betu 2 - tohle občas padá apod.)
Honza
2010/2/6 Jan Bilak jan.bilak@gmail.com:
Ahoj,
ano - se změnou balíku nemám problém. Jde mi to jak zkompilovat, tak
. Budu se
snažit to dál sledovat.
On Sat, 06 Feb 2010 19:21:13 +0100, Jan Bilak jan.bilak@gmail.com
wrote:
Experimentální verze TraceServeru - jen pro toho, kdo to chce vyzkoušet:
http://jabi.aspone.cz/www/osm/TraceServerBeta3.zip
(nenahrazuje betu 2 - tohle občas padá apod.)
Honza
Ahoj,
zkoušel jsem použít algoritmus pro ztenčování od Jiřího Parkana (díky
za něj). Rychlost je velmi dobrá. Problém je, že je poněkud agresivní
a pokud k čáře přiléhá něco tlustšího, tak to dělá ošklivé věci. V
příloze je trochu extrémní ukázka, ale dělá to často obdobnou věc i u
klasické čáry.
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@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
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@gmail.com
wrote:
Ahoj,
k čemu větší rozlišení? Spíše jsem
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@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
Pokud vím, tak v současné době nikoli. Ani nevím, jak by to vlastně
mělo dělat. Zda vytvořit jeden obrys přes všechny části nebo více
obrysů a přes to relaci? A jak to pak tagovat?
Honza
2010/2/12 Zdeněk Pražák zpra...@seznam.cz:
Nainstaloval jsem si tracer a chtěl bych se zeptat, zda se v
Doplnil jsem tam chybějící číslici 4.
Honza
2010/2/12 Jan Bilak jan.bilak@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
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@gmail.com:
Doplnil jsem tam chybějící číslici 4.
Honza
2010/2/12 Jan Bilak jan.bilak@gmail.com:
K vyzkoušení:
http://jabi.aspone.cz/osm/OcrBeta1.zip
, 12 Feb 2010 22:05:40 +0100, Jan Bilak jan.bilak@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
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@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
, Jan Bilak jan.bilak@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
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@gmail.com:
Ořez by mohl být
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
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@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é
: 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
Ahoj,
popravdě mne zatím nenapadá nějaký vhodný algoritmus, který by na to
šel aplikovat. Ani jsem moc neprocházel katastrální mapu, takže nevím,
jak na jiných místech vypadá.
Pro slučky bych si dovedl představit něco, co bude detekovat dvě čáry,
které se skoro dotýkají, jsou téměř rovnoběžné a
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
://www.openstreetmap.org/?lat=50.03166lon=14.49917zoom=17
ale jestli jinak v Praze stačí stáhnout nějakou oblast, ve které domy
chybí, a většinou se trefíš.
On Sat, 13 Feb 2010 16:31:49 +0100, Jan Bilak jan.bilak@gmail.com
wrote:
Můžeš poslat nějakou souřadnici, kde je typická ukázka těchto tenkých
čar
Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) -
oprava padání.
Honza
2010/2/13 Jan Bilak jan.bilak@gmail.com:
Ahoj.
Dal jsem tam betu 3 ... http://jabi.aspone.cz/osm/OcrBeta3.zip
Pridava drive zminovanou podminku, ktera umoznuje detekovat, zda jde o
jednoznacne
stále ještě dlaždice mění).
On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak jan.bilak@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
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@gmail.com
wrote
, Jan Bilak jan.bilak@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@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@gmail.com:
Projel jsem všechny dlaždice, které jsi mi
Ahoj,
kdyz nepouzivam zadnou fotomapu, tak pouzivam kn neinvertovanou a s
citelnosti nemam problem. Invertovana je citelna take, ale tohle mi
vyhovuje vice (asi otazka zvyku). To vse s defaultnim barevnych
schematem. S jinym barevnych schematek bude citelnost uplne jina.
Idealni by bylo z WMS
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@gmail.com:
Tady jsou výsledná *.csv a logy z tvých
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
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@gmail.com:
A mimochodem nejde o můj program ... je to upravený ten tvůj.
Honza
2010/2/17 Jan Bilak jan.bilak
Zdravím,
je to moc pěkné. Dovedu si živě představit, že třeba orientační mapka
typu jak se dostat do ... by byla tímto způsobem provedená a
vypadala velmi efektně.
Měřítko ... v izometrickém pohledu prostě bude mapka zkreslená, s tím
nic nenaděláš. Když to nějak roztáhneš, tak už to není
. Takže každý si bude
moci vyrenderovat co chce.
Ale zatím je to příliš v raném stádiu.
Aleš Janda
On 17.2.2010 20:52, Jan Bilak napsal/a:
Zdravím,
je to moc pěkné. Dovedu si živě představit, že třeba orientační mapka
typu jak se dostat do ... by byla tímto způsobem provedená a
vypadala velmi
Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede
cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne?
Honza
Dne 23. února 2010 21:44 Tomas Kolda ko...@web2net.cz napsal(a):
A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM
uploadne si
.
idle timeout)
Coz vysvetluje proc data zustaly. Ja to pochopil, ze je changeset jen kvuli
lepsi identifikaci pro reverty ne jako transakce. Na transakci je pouzit ten
diff upload.
No aspon vime jak se to asi ma priste delat.
Tomas
jzvc napsal(a):
Dne 23.2.2010 21:55, Jan Bilak napsal
Sice nevím, o co jde, ale podle pořadí mailů a rozsahů to vypadá na:
11 - 20 ... Jan Dudík
21 - 30 ... Zdeněk Pražák
31 - 35 ... Jiří Parkan
Honza
2010/2/24 Martin Kupec ma...@jkopava.cz:
On Wed, Feb 24, 2010 at 08:56:25PM +0100, Zdeněk Pražák wrote:
Beru tedy 11 - 20
Koukam ze o to
ploch (trojúhelníků) k
rendrování, to je otázka. Přecijen pixelů výsledného obrázku je řádově
více. Ale myslím, že to stojí zato.
A případně lze řešit pomalost distribuovaným výpočtem.
Honza
2010/2/25 Jan Bilak jan.bilak@gmail.com:
Ahoj,
tohle by opravdu obecně nefungovalo ... i u
Ahoj,
tohle by opravdu obecně nefungovalo ... i u obdélníku by to bylo
divné. Ale mohlo by to jít jinak... nebo nějak obdobně. Rozhodně je to
relativně snadno algoritmicky řešitelné i u nekonvexních a
nepravoúhlých polygonů.
Honza
Dne 24. února 2010 22:37 Aleš Janda openstreet...@kyblsoft.cz
Ahoj,
přidal jsem podporu nějakého nastavení TraceServeru:
http://jabi.aspone.cz/osm/TraceServerBeta5.zip
Zároveň podporuje pluginy pro předzpracování bitmapy i filtraci bodů
(asi nejproblematičtější část trasování).
Konfigurační soubor je ve formátu XML a definuje dvě pipelines
(bitmapFilters
Ahoj,
díky za reakci ... zítra (nebo možná ještě teď večer) se kouknu, v čem
je problém. Mimochodem zkoušíš to na Windows nebo pod Monem?
Honza
Dne 28. února 2010 2:21 MP singular...@gmail.com napsal(a):
On 27/02/2010, Jan Bilak jan.bilak@gmail.com wrote:
Ahoj,
přidal jsem podporu
Ahoj,
omlouvám se za chyby ... opravenou verzi jsem dal na stejné místo.
Honza
2010/2/28 Jan Bilak jan.bilak@gmail.com:
Ahoj,
díky za reakci ... zítra (nebo možná ještě teď večer) se kouknu, v čem
je problém. Mimochodem zkoušíš to na Windows nebo pod Monem?
Honza
Dne 28. února
Zdroják SmallHoleRemover filtru vypadá takto:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Osm.Kn.Trace.Server.Trace.Interfaces;
namespace SmallHoleRemover
{
[BitmapFilter(SmallHoleRemover)]
public class SmallHoleRemover : IBitmapFilter
:
Ahoj,
zkoušel jsem tu novou verzi, která opravdu funguje zase o dost lépe.
Zdá se ale, že to na tenkých čarách stále moc nefunguje - většinou to
stejně projde nějakou mezerou.
Dá se někde nastavit, jak velkou mezeru to zacelí?
On Mon, 01 Mar 2010 13:32:21 +0100, Jan Bilak jan.bilak
IndexOutOfRangeException.
On Mon, 01 Mar 2010 18:13:33 +0100, Jan Bilak jan.bilak@gmail.com
wrote:
Ahoj,
to se divím, že funguje o dost lépe, protože tam prakticky žádné změny
v tomto směru nejsou. Změny se týkají možnosti nastavení a pluginů
(filtrů). Pravda je, že jeden ukázkový primitivní filtr
Ahoj,
dostal jsem typ na reseni renderovani strech...
Knihovna:
http://www.cgal.org/Manual/3.2/doc_html/cgal_manual/Straight_skeleton_2/Chapter_main.html
Popis algoritmu:
http://web.natur.cuni.cz/~bayertom/Adk/adk7.pdf
Honza
2010/3/28 hanoj eha...@gmail.com:
Podle pravidel fotbalu má hřiště
A tady je ještě Java applet, který to názorně a interaktivně ukazuje:
http://www.sable.mcgill.ca/~dbelan2/roofs/roofs.html
Honza
2010/3/28 Jan Bilak jan.bilak@gmail.com:
Ahoj,
dostal jsem typ na reseni renderovani strech...
Knihovna:
http://www.cgal.org/Manual/3.2/doc_html/cgal_manual
Zdravím,
zkoušel jsem tracer se starým JOSM 2561 na jedné oblasti a trasoval v
pohodě - stahované mapy vypadaly obdobně jako dříve. Za jakých
podmínek to nefunguje? Záleží na oblasti nebo na něčem jiném?
Honza
2010/7/14 hanoj eha...@gmail.com:
IMHO Tracer ma WMS nastaveno URL natvrdo. Problem
Ahoj,
urcite ... jen, co se k tomu dostanu (asi pred vikend).
Honza
Dne 1. září 2010 10:54 hanoj eha...@gmail.com napsal(a):
Ahoj Honzo,
dnes doslo ke zmene nastaveni KM na WMS CUZK.
Bylo by mozno upravit tracer na novy stav pripadne rovnou nechat
moznost si nastavit zdrojovy server v
vědět ... snad jsem nevzal nějakou starou verzi ...
dělal jsem to dost na rychlo.
http://jabi.aspone.cz/osm/TraceServerBeta7-src.zip
Honza
2010/9/6 Zdeněk Pražák zpra...@seznam.cz:
Dne 2. 9. 2010 Jan Bilak napsal:
Ahoj,
urcite ... jen, co se k tomu dostanu (asi pred vikend).
Honza
Dne 1
Ahoj,
díky za úpravy. Na SVNko OSM to samozřejmě klidně dejte - bude to
nejlepší. Jen pak prosím sem do maillistu napište na to odkaz, kde se
to dá najít.
Honza
2010/9/7 hanoj eha...@gmail.com:
binarka
http://openstreetmap.cz/tracer/tracer7patched.tar.gz
*** supr funguje to, na CZ:wiki
Ahoj. Stiskni START. Zvol položku Spustit a napiš:
cmd.exe
a stiskni ENTER
napiš
CD C:\Users\Zdeněk Pražák\osmosis
(vcetne uvozozovek) a stiskni ENTER. Nyní se ti zobrazí:
C:\Users\Zdeněk Pražák\osmosis
napiš
osmosis.bat
a stiskni ENTER.
Ale co to bude dělat, to nevím. Osmosis jsem nikdy
komerčně použít (tím se
vyřeší to, že třeba data z nějakého důvodu zahodíš nebo předáš někomu
jinému pro dopracování, než se uploadnou do OSM).
Pokud v tom vidíte nějaký problém, řekněte. Třeba je to blbost.
Honza
Dne 8. září 2010 22:33 MP singular...@gmail.com napsal(a):
On 2010-09-07, Jan
openstreet...@kyblsoft.cz napsal(a):
Ahoj,
tak přesně takovouhle licenci jsem chtěl taky pro svůj program, jenže pak se
stává nesvobodným, viz
http://www.abclinuxu.cz/poradna/programovani/show/297980
Nakonec jsem to vyřešil GPLv3.
Aleš Janda
Dne 8.9.2010 22:54, Jan Bilak napsal/a:
Ahoj,
v
svobodný
sotware, tak github, sourceforge a podobné využít nepůjdou.
Zřídit SVN nebo GIT server není problém, můžu udělat u mě (tam co teď běží
izometrická mapa apod.).
Kdyžtak mi napište.
Aleš Janda
Dne 9.9.2010 01:50, MP napsal/a:
On 2010-09-08, Jan Bilak wrote:
Hmmm, tak pokud je jediný
několik lidí (včetně mne) u sebe. Když mi vyjde
čas, večer to tam založím.
Honza
2010/9/9 Jan Bilak jan.bilak@gmail.com:
Ještě mne napadnul codeplex.com ... který poskytuje dobré zázemí a pro
.NET projekty je jak dělaný. Licence jsem tam tuším viděl všelijaké,
ale třeba se pletu.
Honza
Ahoj,
myslím, že by se těch témat našlo o dost více, ale jde spíše o to, co
by tě bavilo dělat (nemyslím konkrétně, to bys pak téma nehledala),
ale druh práce (hromadné zpracování dat, algoritmické úlohy,
desktopové aplikace, klientskou část webové aplikace, serverové
aplikace, propojování
Ahoj,
máš nějakou konkrétní potřebu tam začlenit nějakou GPL knihovnu, pro
kterou není alternativa pod jinou vhodnou licencí?
Honza
Dne 16. září 2010 8:01 Pavel Machek pa...@ucw.cz napsal(a):
On Wed 2010-09-08 22:54:21, Jan Bilak wrote:
Ahoj,
v licencích se moc neorientuji. Představoval
Ahoj,
souhlasím. Hranice mají tu výhodu, že je lze dobře vykreslovat na
mapě. Z stromového/svazového (dále budu psát jen o stromu, i když
možná by šlo obecně o svaz kvůli městským částem a částem obcí apod.)
by se pro vykreslení musela hranice vždy počítat - jinak si nedovedu
představit nějaké
není.
Doplňovat tam celý strom mi ale přijde trochu zbytečné.
On Thu, 30 Sep 2010 16:16:59 +0200, Jan Bilak jan.bilak@gmail.com
wrote:
Ahoj,
souhlasím. Hranice mají tu výhodu, že je lze dobře vykreslovat na
mapě. Z stromového/svazového (dále budu psát jen o stromu, i když
možná by šlo
Problem je, ze toto neni adresa. Ve vetsine obci, ktere maji i sve
casti, je urcujici adresa ulice + cp + obec + psc. Z psc se da (pokud je
spravne) urcit cast obce. Cast obce (tu oficialni) spousta lidi ani
nezna. Klidne muzu uvest konkretni priklad, v Teplicich je cast Trnovany
a cast
Zdravím,
situaci ohledně změny licence jsem nesledoval a i když nemám žádný
podstatný podíl na editacích v OSM, rád bych si udělal obrázek o tom,
o co jde, a nějak se rozhodnul. Můžete mi prosím někdo stručně
vysvětlit, v čem jsou zásadní rozdíly mezi licencemi? Jaký je hlavní
důvod změny
Díky. Ale ještě z toho shrnutí nerozumím, jak to tedy podle nové
licence bude v tom modelovém případě:
Pokud někdo vaše data používá pro mapu s několika vrstvami v knize,
co všechno má být pod CC-BY-SA? Jen vrstva OpenStreetMap a její
úpravy? Celá mapa včetně nesouvisejících vrstev a značek? Celá
Řekněme, že by se opravdu někdo našel a data začal prodávat. Kdo by je
ale koupil, kdy je může získat zdarma přímo z OSM? Jistě - někdo by se
najít mohl, ale nevidím v tom žádné podstatné riziko. Obdobně
vydělávat lze např. i prodejem GPL software, ale kdo GPL software
kupoval, když jej může mít
Zdravím,
omlouvám, že se nyní projektu nevěnuji (nedostatek času). VerticalSkip
tuším bylo kvůli odříznutí nějakého copyrightu, který by dělal při
rozpoznávání problémy v případě, že by někdo kliknul na místo, kde se
zrovna nacházel. Nevím, zda se tam pořád nebo už tam není. Pokud tam
je, že tak
Zdravím,
mám několik dotazů:
1) Změna licence má nějaké klady a nějaké zápory. Mezi zápory jistě
patří ztráta dat z OSM map. To je celkem podstatný zápor. Otázka tedy
zní, jaké jsou ty konkrétní podstatné klady, které mají převážit
zápory?
2) Změnou licence nedojde ze ztrátě dat obecně, ale ke
nejake servery na ktere bychom mohli neco
umistit...
K
Dne 2.2.2012 14:32, Pavel Machek napsal(a):
On Tue 2011-12-20 22:35:12, Jan Bilak wrote:
Zdravím.
Problém vidím v bodě 3. Třeba máš lepší zdroje, spoustu kamarádů
pilotů, ale nějak moc nevěřím tomu, že by se toho podařilo dostatek
Ahoj,
předem se omlouvám, pokud budu psát nesmysly - moc o tom nevím.
Chápu to správně tak, že data budou licenčně použitelné pro OSM, budou
obsahovat např. adresní body, obrysy budov, ulice apod., vše zdarma ve
formě veřejné dostupné aplikace na bázi XML/SOAP? A nyní data ještě
dostupná nejsou,
Díky. Nevíte o nějakých knihovnách (.NET, Java, JavaScript, C, C++,
...) pro transformaci pomocí toho S-JTSK gridu? Nebo, pokud nejsou
přímo knihovny, ve kterých opensource programech s vhodnou licencí by
tato transformace šla najít?
Honza
Dne 22. června 2012 22:12 Martin Kokeš
/gwiki/S-JTSK-Grid, cokoliv co používá GDAL/PROJ4.
MK
- Original Message -
From: Jan Bilak
[mailto:jan.bilak@gmail.com]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Sat, 23 Jun 2012 04:45:21
+0200
Subject: Re: [Talk-cz] Data RUIAN - výměnný formát
ulevilo ZP a jeho tabletu při obkreslování
zemědělské půdy ;-)...).
Jelikož se všude používá nativně Křovák, je nutná zpřesněná transformace
pomocí S-JTSK gridu.
MK
- Original Message -
From: Jan Bilak
[mailto:jan.bilak.osm@gmail.**com jan.bilak@gmail.com]
To: OpenStreetMap Czech
.
Honza
Dne 24. června 2012 17:55 Jan Bilak jan.bilak@gmail.com napsal(a):
Zdravím,
díky za info, ještě mám dotazy. Budou průběžně vydávané změnové soubory
(popis formátu jsem tam viděl) nebo jen kompletní snapshoty? S jak častou
aktualizací dat se počítá (jednou denně, ...)?
Honza
Dne
Ahoj,
s importem adresních bodů získaných z teček na mapě bych se teď moc
nezatěžoval, protože v brzké době se doufám podaří provést import z
RUIAN, což být měl být kvalitnější zdroj (viz probíhající diskuse o
RUIAN) - tedy úplný, denně aktualizovaný, přesnější, s menším rizikem
chyby, lehčeji
Ahoj,
jak vypadá ideální zápis adresního bodu v OSM XML? Koukal jsem se do
snapshotu OSM dat ČR a zápisy nemají jednotný formát. Např.:
node id=296674495 lat=48.9631350 lon=14.5119948 version=2
changeset=1965423 user=Radomír Černoch uid=51295
timestamp=2009-07-28T14:56:31Z
1 - 100 z 116 matches
Mail list logo
