Spíše jen něco jako klasický webserver. TileCache mi přijde pro tento účel
příliš složitá věc, která řeší generování v případě, že dlaždice není v
cache apod. Dlaždice zřejmě budou samostatné jpg (příp. png/gif) soubory v
nějaké adresářové struktuře, aby jich nebylo mnoho v jednom adresáři. A
Ahoj,
můžeš, prosím, uvést praktické výhody oproti Vespucci OSM Editoru:
https://play.google.com/store/apps/details?id=de.blau.android
Honza
Dne 16. září 2013 21:43 Vojtěch Kalčík vo...@kalcik.cz napsal(a):
Ahoj,
jako diplomku jsem dělal open source program TerrainGIS pro mapování v
Možná tam maluje nějaký historický stav. Nějaký Palouš v obci bydlel,
vyhořel tam i nějaký mlýn... (http://www.dbranna.cz/hiszaj.htm).
Honza
Dne 7. dubna 2013 2:18 LM_1 flukas.robot+...@gmail.com napsal(a):
Mnohokrát se probíralo, že spousta uživatelů - nováčků neví, že opravdu
upravují
Ahoj,
jak ten bot rychlý? Aneb za jak dlouho by zpracoval (pokusně) celou ČR
- tedy vygeneroval log?
Můžeš udělat histogram vzdáleností spárovaných bodů?
Honza
Dne 6. srpna 2012 4:54 Mirek Dlask dlas...@gmail.com napsal(a):
Je otázka, zda nejsou v RÚIAN adresní body domů bez č.p. , asi tam
Zdravím,
metainformace o tom, že se něco nemá importovat z RUIAN, protože je to
tam špatně, by podle mě chtělo mít přímo v OSM. A to včetně informace
o tom, odkud konkrétně ta spolehlivější informace pochází.
Honza
PS: Doplňování čp. podle čísla na popelnici nemusí být moc spolehlivé,
protože
Ahoj,
teď z toho nechápu, zda si aplikaci představuješ jen jako evidenční
nebo zda aplikace má provádět vlastní import (resp. s ním výrazně
pomáhat).
Tedy za zásadní považuji porovnání současných OSM dat s daty RUIAN a
následné provedení změn (posuny stávajících bodů, opravy tagů,
zachování
složitější.
Obecně čistě ručního importu se celkem obávám. Dat je vetší než malé množství.
Honza
Dne 27. července 2012 13:41 Miroslav Šulc fordf...@fordfrog.com napsal(a):
Dne 27.7.2012 13:20, Jan Bilak napsal(a):
Ahoj,
teď z toho nechápu, zda si aplikaci představuješ jen jako evidenční
nebo
O konvencích tagování toho moc nevím, ale co na to jít od jinud?
Tedy dávat silnicím tagy, které mají jasný význam. Tedy např. tag,
který bude říkat třídu silnice, tag, který bude říkat počet pruhů
apod. Takové ty neurčité tagy, podle který ale třeba renderer kreslí
mapy, by pak bylo možné
Tohle je podle mě vlastnost JOSM, takto se mi to chovalo vždy u všech zdrojů.
Honza
Dne 19. července 2012 20:09 Miroslav Šulc fordf...@fordfrog.com napsal(a):
jinak jsem zjistil, že pokud si přiblížím mapu a až pak si načtu tu wms
vrstvu, tak se mi načte detailnější. bohužel ale při zoomování
Obkreslovat by podle mě bylo licenčně špatně. Ale používat to pro
informaci o tom, co je třeba v mapě doplnit, podle mě licenčně špatně
není. Vlastní kreslení by pak muselo probíhat podle jiného zdroje.
Honza
Dne 18. července 2012 18:43 Jan Breuer jan.bre...@jaybee.cz napsal(a):
Taky bych to
Ahoj, to mě také zaráží. V takovém případě by snad mělo smysl použít
poslední licenčně použitelnou verzi, případně selektivně odstranit licenčně
problematické tagy apod.
Honza
Dne 16.7.2012 18:04 Jakub Sykora kub...@kbx.cz napsal(a):
Docela me zarazi, ze tam dojde ke smazani veci, ktere jsem
Zdravím,
nemohu si pomoci, ale souhlasím s hanojem a jsem přesvědčen, tak
dlaždicování je správná cesta. Marushka je opravdu strašně pomalá -
generování výřezu 10 sekund není nic výjimečného - naštěstí s ní
nepracuji. Ono tedy nahlížení do katastru je také velmi pomalé (4 až 5
sekund běžně) -
Subject: Re: [Talk-cz] Data RUIAN - výměnný
formát
On Sat 2012-06-23 04:45:21, Jan Bilak wrote:
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
Ahoj,
Trochu sem se prohrab temi samply, a me by se libilo nevyrabet adresni
body ale priradit adresy budovam, neb ta vazba v tech datech je. Bod
bych vyrobil jen tam, kde budova neni (a je tam definovana adresa).
Co se tyce ulic, tam to asi s jejich presnosti nebude zadna slava -
použitého nástroje.
Jsou
tři (polo)automatické způsoby importu, a nakonec pak ruční zadání.
On Tue 26-06-12 04:14:04, Jan Bilak wrote:
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
Ahoj,
koukám, že tu budou i různé rozdíly mezi adresami z registru a z OSM,
i když v OSM mají v tagu uveden kód adresy registru (tedy mělo by se
jednat o stejnou adresu a asi import z UIR-ADR):
Pár rozdílů z Prahy (pokud jsem neudělal chybu):
http://jabi.aspone.cz/osm/temp/praha-rozdily.pdf
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
/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,
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š
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
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
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,
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
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
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
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
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
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
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,
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
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,
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
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,
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
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,
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
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
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
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
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,
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
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
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
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.
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
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,
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
/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
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
, 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
1 - 100 of 116 matches
Mail list logo