Re: [Talk-cz] Prusanky

[Petr Nejedly]

  Hmm, to sedí, potvrzuji že u Predínských mají točenou zmrzlinu!Tučňáky tentokráte netřeba... --PetrSent from my BlackBerry PRIVFrom: mky...@email.czSent: June 13, 2017 11:03 AMTo: talk-cz@openstreetmap.orgReply-to: talk-cz@openstreetmap.orgSubject: Re: [Talk-cz] Prusanky  Dne 2.6.2017 v 12:22 Marián Kyral
  napsal(a):

  
-- Původní e-mail --
Od: Pavel Machek 
Komu: OpenStreetMap Czech Republic

Datum: 2. 6. 2017 11:37:54
Předmět: Re: [Talk-cz] Prusanky
  
  
  On Wed 2017-05-31 06:51:35,
Petr Schönmann wrote:

> Ahoj, zkusil jsem poslat mail do školy. Uvidíme jestli se
pan učitel ozve.

> 
> Dobrý den,

> píši jménem české komunity openstreetmap (*3). Jedná se
"mapovou wikipedii"

> kde každý může upravovat mapová data.

> Zřejmě máte to štěstí že nějaký váš kantor vzdělává žáky v
tomto směru.

> Potud vše v pořádku. Nicméně poměrně často řešíme (*1) že
se v okolí

> Prušánek objevují podivné editace. Jméno školy například
blázinec a

> podobně. No znáte děti :)


...a jestli se tato nestastna situace bude opakovat i pristi
rok,

dorazi k vam parta nastvanych tucnaku, a opravi realitu tak, aby

odpovidala mape. No znate tucnaky, udelat ze skoly blazinec pro
ne

nebude problem :-).

  
  
  
  Ty máš nějaké v záloze? :-D
  
  
  

Tak to vypadá, že dnes byla další hodina…
… a zdá se, že Smurficka to chytlo a editoval i z domu:
http://www.openstreetmap.org/user/Smurficek/history#map=14/48.8424/16.9754


Marián


  Marián
  


  

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Url pro mapu i se znackama

[Petr Nejedly]

Asi je to rozbitý:

Fatal error: Uncaught Error: Call to undefined function tileValid() in 
/home/ojw/public_html/StaticMap/map.php.inc:276 Stack trace: #0 
/home/ojw/public_html/StaticMap/map.php.inc(36): cacheableTile(8858.2406001778, 
5554.9341235273, '14', Array) #1 
/home/ojw/public_html/StaticMap/index.php(318): doMap('49.994546', '14.683021', 
'14', '1024', '768', 'mapnik', 'jpg', true, Array) #2 {main} thrown in 
/home/ojw/public_html/StaticMap/map.php.inc on line 276

--
Petr

  Original Message  
From: pa...@ucw.cz
Sent: November 18, 2016 2:05 PM
To: talk-cz@openstreetmap.org
Reply-to: talk-cz@openstreetmap.org
Subject: [Talk-cz] Url pro mapu i se znackama

Ahoj!

Chtel bych neco jako "zobraz mapu kolem 50, 14, na 50.1, 14.1 dej
znacku, na 50.2, 14.2 dej dalsi znacku"

Driv fungovalo

http://ojw.dev.openstreetmap.org/StaticMap/?lat=49.994546=14.683021=14=0=1024=768_num=5=49.994546=14.683021=51.458600=7.013417=51.450690=7.012910=51.458850=7.007020=51.458600=7.013417

ale tam se mi uz par tydnu nezobrazi mapa... Delam neco spatne? Je
nejaka podobna sluzba ktera funguje?

Dik,
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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM ortofoto

[Petr Nejedly]

http://openaerialmap.org/Main_Page

Sent via BlackBerry

-Original Message-
From: Petr Balíček pbali...@seznam.cz
Date: Tue, 20 Dec 2011 22:12:33 
To: talk-cz@openstreetmap.org
Reply-To: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Subject: [Talk-cz] OSM ortofoto

Zdravim,

jeden z posledních vážných důvodů, proč používat nesvobodný mapy od Seznamu, 
Gúglu, atd. je, že OSM chybí vrstva s leteckou mapou. Tak mě napadlo, proč si 
ji taky nevyrobit? Hodila by se třeba i k odvozování dat do OSM (Na 
„obkreslování“ by to asi nebylo.).

Bylo by k tomu potřeba:

1) Přístup k serveru, kam by se nahrávaly dlaždice.

2) Software, kterej by uměl transformovat letecký fotky do souřadnic podle 3+ 
naklikaných bodů, jejichž polohu známe, rozřezat na dlaždice a poslat na 
server. Napsat takovej program by byl asi největší kámen úrazu, ale možná se 
někdo schopnej najde.

3) Spousta leteckejch fotek, ale myslim, že by se jich podařilo nashromáždit 
překvapivě dost - stačilo by se poptat kamarádů a známejch, oni by se určitě 
rádi vzdali autorských práv.

4) Mravenčí práce, trochu si s tim pohrát.

Zkoušel sem si takhle vyrobit pár dlaždic jen tak ručně v GIMPu nástrojem 
„perspektiva“ a výsledek je docela slušnej (Samozřejmě, že je to takhle moc 
pracný a ne zrovna přesný). 
Sám se do takovýho projektu nepustim, protože na to nemam potřebný zázemí a 
znalosti, ale samozřejmě bych se taky rád přičinil.
Přišlo mi to prostě jako dobrej nápad, třeba se toho někdo chytne, možná by to 
bylo pěkný téma na bakalářku...

Mělo by něco takovýho smysl nebo je to úplně zcestná myšlenka?

PB


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Tip na citlivou GPS

[Petr Nejedly]

Martin Kokeš napsal(a):
 hanoj napsal(a):
 a k cemu je tam tech 66 kanalu?

 zdravi

 hanoj
   
 LOL. Já nepsal, že jsem konstruktér toho čipu. Místo na 
 talk-cz@openstreetmap.org jsi měl psát na serv...@mediatek.com. Možná, 
 že předností toho čipu není čím víc kanálů, tím víc Adidas (i když za 
 pár let se to může třeba hodit, až nám budou možná lítat nad hlavama 
 GIOVy), ale citlivost a spotřeba energie.

No ja sice take nejsem konstrukter toho chipu a me znalosti GPS systemu jsou 
omezene, ale soudil bych, ze na kazdy satelit nasadi vic kanalu s ruznym fazovym
posunem a tim rychleji/lepe dosahne locku.

Po pameti, nemusi byt presne/spravne:
Ono totiz GPS signal se ani tak neprijima jako spis tusi. Ostatne jak
chcete prijimat cosi, co je 30dB pod urovni sumu? Takze takovy kanal GPSky
funguje tak, ze si generuje tu pseudonaodnou sekvenci s urcitym posunem
a zkousi ji korelovat s tim prijatym sumem. A pokud se s tim posunem trefi,
tak najde statisticky vyznamnou korelaci. Normalne by jeden kanal pro jeden
satelit (kazdy mi jinou sekvenci) postupne skousel ruzne posuny, az by se 
trefil. Takhle muze prohledavany rozsahu posunu rozdelit mezi vice kanalu.

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] UIR - cisla popisne a orientacni

[Petr Nejedly]

Karel Volný napsal(a):
 ...
 chapu to dobre tak, ze
 dum ma CO:
 * housenumber=CO
 * alternatenumber=CP

 dum nema CO:
 * housenumber=CP

 dum nema CP:
 * housenumber=EC

 pokud to chapu dobre, tak +1 za tuhle variantu :).
 
 hm, a patřičné nástroje budou mít v základní výbavě křišťálovou kouli, aby 
 dokázali vyvěštit, cože to v tom aktuálním housenumber vlastně je?

Hmm, co tak:
  dum ma CO:
  * housenumber=CP
  * alternatenumber=CO
 
  dum nema CO:
  * housenumber=CP
 
  dum nema CP:
  * housenumber=ev.č.EC

Resp. (pokud už jste někdy vůbec psali na adresu na evidenčním čísle) jak
tedy uvádíte takovou adresu? Já teda dost často píšu jen 8e, ale když
mi na zásilce hodně záleží (nebo mi ji má přivézt nějaký méně spolehlivý
dopravce, tak aby nemohl držkovat, když už neumí zavolat), uvedu celé ev.č.8

Tak jako tak je potřeba naučit renderer dobře renderovat a hlavně vyhledávač 
dobře hledat...

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] dotaz na označení naučné stez ky

[Petr Nejedly]

Zdeněk Pražák napsal(a):
 Chtěl bych se zeptat, zda jsem označil dobře naučnou stezku pomocí tagu 
 kct_green s hodnotou learning
 Pražák

Ano, tak ze to znaci, viz:
http://www.informationfreeway.org/api/0.5/way[kct_green=learning]


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Možnost využití dat Povodí La be

[Petr Nejedly]

Tomas Kolda napsal(a):
 Ano to s tim routovanim pravda je. Je to tim, ze graf (vrcholy a hrany) 
 urcuji way, kde vrchol je pocatecni a koncovy nodeID. To jsou prave ty 
 krizovatky. Kdyz je spojis do jedne way napr. u Tckove krizovatky tak 
 pak bude ta treti slepa, protoze nema navaznou way, ktera zacina stenym 
 nodeID jako ona konci Orientace u jednosmerne hrany se urcuje stejne 
 jako u graficke mapy (oneway). Proto se nesmi spojovat napric krizovatkou.
 
 Slo by to v pripade, ze nekdo kdo dela routovani bude kontrolovat kazdy 
 nodeID v way a kdyz uvidi, ze je obsazen koncovy z jine cesty tak tam 
 umele udela krizovatku. To je ale velika nevyhoda, protoze ty nemuzes 
 implicitne predpokladat krizovatku pro kazdy sdileny nod. Proto se to 
 dela explicitne tim sekanim.

Uff, fakt nekdo videl navigaci nad OSM, ktera by mela problem s prubeznou
silnici? I ten gpsmid do mobilu si, krome grafu pro renderovani grafiky
predpocita i separatni routovaci graf, ktery obsahuje prave jen ty krizovatky
(nalezene automaticky i na tech prubeznych krizovatkach) a zadne mezilehle nody
(protoze proc by routovaci algoritmus melo zajimat, krome prirazene ceny 
spojnice,
kudy se dana cesta krouti).

Naopak, kdyz bych si predstavil mapu New Yorku, ve ktere by kazdy ten 200yardovy
usek ulice mezi dvema avenue mela byt separatni way, asi bych se opupinkoval
pri predstave, ze jsem udelal typo v nazvu jedne ulice.

Zaver: Spojujte ulice, spojujte silnice. Jedine, co vam v tom muze zabranit
jsou odlisne parametry segmentu (bridge, speed limit), kde by OSM uzila mirne
hierarchicky model (tohle je way II/601 a sklada se z techto casti). Ale to 
vlastne
pouzivaji napriklad cyklisti s relacema, ze?

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Možnost využití dat Povodí La be

[Petr Nejedly]

Tomas Kolda napsal(a):
 Ahoj,
 
 takze jsem dodelal import. Dost me zdrzel prevod souradnic, ale melo by 
 to byt ok. Pro zvedave k presnosti posilam vysek databaze v okoli 
 prehrady. Zatim je tam jen waterway a vzdy river, ale nazvy uz tam 
 jsou.Polygony a brehy jeste dodelavam.
 
 Podivejte na super prehnanou presnost u nekterych potucku, presne jak 
 jsem rikal.
 
 http://www.web2net.cz/osm/dibavod.zip

Mohl bys, prosim, zkusit udelat kousek na hornim toku Moravy?
Mapoval jsem ho podle ortofoto, ale nakonec jsem to doladil podle katastru,
a muj pokusny import DIBAVODu mel stejny tvar krivek, ale byl o par (desitek) 
metru mimo
http://www.openstreetmap.org/?lat=50.15321lon=16.81535zoom=17layers=B000FTF

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Možnost využití dat Povodí La be

[Petr Nejedly]

Tomas Kolda napsal(a):
 Vecer neco poslu. Ja vybral oblast kde jsou polygony, linie i riverbank. 
 Kdyz posles bounding rect udelam oblast na morave. Hlavne at to neni moc 
 velike...
Na porovnani by stacil ten kousek, co jsem psal, cili:
[50.152,16.813,50.154,16.817]


 Jinak kdyz to dam do JOSMu a pak stahnu okoli, tak ta oblast co jsem 
 posilal sedi skoro presne...

Pravda, Kocába sedi na katastrální mapu fakt na milimetr.

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Možnost využití dat Povodí La be

[Petr Nejedly]

Tomas Kolda napsal(a):
 V tom pripade se pouziva to co jsem psal v druhem odstavci (sekani ways 
 pomoci algoritmu, jenz urcuje zda tam krizovatka je ci neni). Komercni 
 navigacni data napr. multinet jsou skutecne rozsekana po castech (format 
 GDF).
Ano, ale to uz je zajiste exportni format jejich databaze, ne?

 Jestli je to v OSM takto zavedene, tak proc ne. Asi tento zpusob 
 zpracovani zavedli, protoze je tak kreslena vetsina silnic. Osobne bych 
 volil druhou variantu, ale na to uz je pozde...

Druhou variantu volit nemuzes ani kdyby jsi byl na zacatku projektu, protoze
to nedokazes udrzet a lidi by zbytecne delali chyby (a chyby na prvni pohled
neviditelne). Jediny zpusob, jak jim v tom zabranit, by bylo zcela zakazat
sdileni bodu uprostred way. To by vsak bylo velmi restriktivni a znemoznovalo
nektera jina soucasna vyuziti (napr. sdileni hranice mezi ruznymi landuse).

 T
 
 Petr Nejedly napsal(a):
 Uff, fakt nekdo videl navigaci nad OSM, ktera by mela problem s prubeznou
 silnici? I ten gpsmid do mobilu si, krome grafu pro renderovani grafiky
 predpocita i separatni routovaci graf, ktery obsahuje prave jen ty krizovatky
 (nalezene automaticky i na tech prubeznych krizovatkach) a zadne mezilehle 
 nody
 (protoze proc by routovaci algoritmus melo zajimat, krome prirazene ceny 
 spojnice,
 kudy se dana cesta krouti).

 Naopak, kdyz bych si predstavil mapu New Yorku, ve ktere by kazdy ten 
 200yardovy
 usek ulice mezi dvema avenue mela byt separatni way, asi bych se opupinkoval
 pri predstave, ze jsem udelal typo v nazvu jedne ulice.

 Zaver: Spojujte ulice, spojujte silnice. Jedine, co vam v tom muze zabranit
 jsou odlisne parametry segmentu (bridge, speed limit), kde by OSM uzila mirne
 hierarchicky model (tohle je way II/601 a sklada se z techto casti). Ale to 
 vlastne
 pouzivaji napriklad cyklisti s relacema, ze?

   
 
 
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Možnost využití dat Povodí La be

[Petr Nejedly]

Tomas Kolda napsal(a):
 V tom pripade jdu na to. Dibavod obsahuje celou CR s neuveritelnou 
 podrobnosti. Problem bude vyfiltrovani dat, protoze obsahuji snad i 
 louze :) Bude potreba udelat nejakou simplifikaci a pridani jen toku, 
 ktere maji alespon nazev. No to se muzeme domluvit. Zkusim udelat vzorek 
 rek, vodnich nadrzi a obrysu brehu (riverbank) v nejake oblasti.

Tak jsem v ramci treningu skouknul DIBAVOD-A16 (brehove linie toku *)
a to da zhruba 1M bodu, 18MB v .osm.bz2

*) neobsahuje vodni nadrze ani linie tenkych toku, tu jsou v jinych
datovych souborech, viz: http://www.vuv.cz/oddeleni-gis/index.php?id=27

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Možnost využití dat Povodí La be

[Petr Nejedly]

Tomas Kolda napsal(a):
 Klidne se toho ujmu, jaky source tomu chcete priradit?

Že by source=pla:dibavod?
Nicméně: V případě tisku si zpracovatel vyhrazuje uvedení copyrightu na 
vytištěném
listu takto: (c) Zpracováno s použitím dat Povodí Labe, státní podnik

Toto je podmínka, kterou těžko v OSM splníme. To by chtělo vyjasnit.

Zdroj: http://www.pla.cz/planet/ram.aspx?id=21

 
 T
 
 Martin Kokeš napsal(a):
 Nedalo mi to a zeptal jsem se Povodí Labe na možnost využití jejich dat 
 (osy vodních toků) ve formátu SHP, která poskytují na svých stránkách ke 
 stažení a dostalo se mi kladné odpovědi od p. Staňka, správce jejich GIS 
 i s doporučením. Ujmul by se prosím někdo importu?

 Martin Kokeš
 (shr3k)
 ---
 Dobrý den,

 filosofie našeho podniku je založena na principu, že data by měl 
 poskytovat ten, který dané mapové objekty spravuje
 a to pokud možno zdarma.

 To je i odpovědí na Váš dotaz.
 Na našich stránkách poskytujeme osy vodních toků, cizí i ty, které 
 spravujeme (cca 300 os vodohospodářsky významných toků z cca 20.000 
 všech os toků a meliorací na území našech Podniku = cca 1/5 ČR). Ty co 
 spravujeme i aktualizujeme, a ty ostatní budou postupně aktualizovat 
 jejich správci (Lesy ČR, Státní meliorační správa, Vojenské újezdy, ...)
 Centrálně tak existuje 5 databází na 5 podnicích Povodí, které dohromady 
 pokrývají toky celé ČR.

 Co se týká IDéček, bylo na úrovni MZe odsouhlaseno, že bude používán 
 jednoznačný číselný bezvýznamový identifikátor vodního IDVT, který již 
 dnes naše databáze obsahují.
 V případném využití doporučujeme tento IDVT udržovat a přes něj provádět 
 jakékoli aktualizace nebo vazby. Tento IDVT přebírá postupně i ČÚZK do 
 ZaBaGeD.

 Offline data poskytujeme (cca 1x ročně) na našich stránkách: 
 http://www.pla.cz/planet/ram.aspx?id=21 v SHP formátu
 a do budoucna uvažujeme o zřízení WMS či WFS online přístupů do naší 
 centrální databáze.

 Zároveň naše data a data, která jsme oprávněni využít i pro internetové 
 presentace jsou veřejně dostupná
 přes GIS aplikaci http://www.pla.cz/gis/ , kde je vyžadován ActiveX 
 prvek MapGuide od firmy AutoDESK.

 Závěrem si dovolím konstaovat, že každý podnik Povodí řeší presentaci a 
 poskytování svých dat individuálně.
 Přesto jsou vybraná data (převážně legislativně určená), která se 
 zveřejňují jednotně a ty jsou pak přístupná přes porál Ministerstva 
 zemědělství (MZe) a Životního prostředí (MŽP)
 http://www.voda.gov.cz/portal/cz/

 S pozdravem



 Pavel Staněk, správce GIS
 __
 Povodí Labe, státní podnik
 Víta Nejedlého 951
 500 03 Hradec Králové
 tel. : +420 495 088 633
 e-mail : [EMAIL PROTECTED]
 http://www.pla.cz/
 ---
 Dobrý den,

 chtěl jsem se zeptat, zda by bylo možné použít některá mapová díla
 státního podniku Povodí Labe pro účely projektu OpenStreetMap. Zejména
 pak osy vodních toků, vodní nádrže, ale i případně i další vhodné
 objekty ve správě Povodí Labe (jezy atd.). Nekomerční projekt
 OpenStreetMap má za cíl vytvoření svobodných a licencemi nezatížených
 map, volně použitelných v otevřeném formátu pro všechny uživatele. V
 současné době to vypadá tak, že přispěvatelé buď mapují území na základě
 záznamů svých GPS zařízení, nebo odvozují mapy ze zdrojů, které toto
 umožňují (převážně ortofotomapy ÚHUL, případně katastru nemovitostí ČÚZK).

 Více informací k uvedenému projektu naleznete zde:

 http://www.openstreetmap.org/ případně http://www.informationfreeway.org/
 a
 http://wiki.openstreetmap.org/index.php/Cz:Main_Page
 http://wiki.openstreetmap.org/index.php/WikiProject_Czechia

 Myslím, že česká komunita, mapující naši republiku v projektu
 OpenStreetMap, by uvítala jakákoliv, případně i mírně generalizovaná
 (znepřesněná) data, případně jakoukoliv formu licence k jejich použití
 nebo vytvoření odvozeného mapového díla. Věříme, že tato a ostatní data
 z projektu by byla v budoucnu dobře použitelná i pro Vaše zaměstnance
 (podklady pro plány, prezentace, plánování či navigaci atp.), neboť je
 lze exportovat přímo z centrálního úložiště v mnoha dostupných formátech
 (mj. pro Garmin GPS atp.).

 Děkuji za jakoukoliv odpověď, s pozdravem

 Martin Kokeš
 Dašická 1253
 53003 Pardubice
 tel. 777 136 677




 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz
   
 
 
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] UIR

[Petr Nejedly]

Ondrej Novy napsal(a):
 Ahoj,
 
 ma nekdo v planu casem (nebo se tak jiz deje?) importovat rozdilove soubory
 UIRu? Predpokladam, ze postupne souradnice adres pridavaji.

Predpokladas vcelku spatne :-)
No, od roku 2004 uz bylo updatovano (pridany souradnice) par tisic adres,
vsehovsudy ve dvou vanocnich importech.
Nicmene vse je pro updaty pripravene, neb cizi primarni klic jsme do OSM
prenesli (v tomto pripade uir_adr:ADRESA_KOD).

 Jak chcete pozdeji resit to, ze nektere body budou zkorigovany dle uhulu ci
 gps?

Uz tady probehl proposal ve smyslu verified=date, coz ovsem nepokryva pripad,
kdy oficialni data jsou tvrdohlave nespravna (napr. pravni vs. skutecny stav 
veci).


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Kvalita zákresu silnic I. a II. t řídy

[Petr Nejedly]

Martin Kokeš napsal(a):
 Nevím, jaký na to máte názor vy, ale snažím se při mapování III. třídy i měst 
 upravovat i silnice I. třídy, protože kvalita jejich zanesení do mapy je 
 hrozná. Vynikne to zejména tam, kde je k dispozici vektorová katastrová mapa.

Samozrejme. Taky je upravuju.

 Holt práce kvapná, málo platná... ;-)
S timto ovsem nemohu souhlasit. Velka cast silnic I. a II. tridy pochazi z 
importu
darovane baze (http://www.bnhelp.cz/), a presto, ze cesty jsou misty i o desitky
metru jinde, tato data nam velmi pomohla.

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OT: Logovani na WM5.0 GPSce

[Petr Nejedly]

Za prve oprava, je to CE5.0 GPSce, ne plne WinMobile, cili puvodne zadne
PDAcko, ale cistokrevna GPSka. Tolik tedy k nastaveni. V aplikaci se nic
takoveho nastavit neda, zdroj NMEA pujde tak maximalne nastavit kreativni
editaci konfiguraku, a cosi jako Control Panel, pristupny s hackem to ma
take vcelku omezene.
No nic, budu vic googlovat, uz vim co.

Stanislav Brabec napsal(a):
 Petr Nejedly píše v Pá 10. 10. 2008 v 00:39 +0200:
 Krom sve oblibene logovaci GPSky (QStarz Q1000) mam ted jeste i navigaci
 (Mio Moov 360U). Ta sama od sebe neloguje. Logovat na ni umim (mirne 
 hacknuta),
 jenze kdyz bezi logger, nefunguje navigace.

 Neda se to nejak priohnout aby to logovalo porad (na SD je mista...) ale 
 nejak
 umoznilo te vestavene aplikaci pristup ke GPS?
 
 Prý to jde to i obráceně - přiohnout QStarz Q1000, aby logovala a
 zároveň navigovala a umožnila stahovat logy přes BT. Pod názvem resistor

O tu Q1000 vubec nejde. Ta mi zaroven loguje i posila NMEA pres BT uz od 
vyrobce,
od toho ma dva mody: LOGuj a NAViguj (a loguj). Tu ssebou vozim ja.
Navigaci ssebou vozi manzelka a je ji, vzhledem k jejimu vcelku kreativnimu 
rizeni
a castym rozlicnym destinacim, lito, ze taky nemuze logovat.


 hack se to dá najít na webu. QStart Q1000P už to umí od výrobce.
 
 V podstatě jde o to, že Q1000 nemá propojen Tx na BT modulu s Rx na GPS
 modulu.

To je hezke, rikal jsem si, ze to tak nejak bude, ale nikdy me netrapilo,
ze nemuzu stahovat logy bezdratove. Pripojim - nabiji a stahuje.
Ale kdyz tam ten odpor pridam, nebudu muset modul vyndavat z auta, kde bude
stale na nabijecce
Dekuji za podnět

 
 Má to jednu bezpečnostní implikaci, o které výrobce u Q1000P taktně
 mlčí... Já raději také, neb chytrým dojde sama.

Asi stejnou, jako kdyz svuj archiv logu natlacim na OSM

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] Značení dálničního sjezdu

[Petr Nejedly]

Jak má vypadat kompletně otagovaný sjezd z dálnice?
Neprilis detailne to popisuje
http://wiki.openstreetmap.org/index.php/WikiProject_Czechia/roads_tagging#Motorway_exit

Co se topologie tyce, obcas se s (tusim) Pavlem hadame, co je jeste primary
a co uz motorway_exit:
http://www.openstreetmap.org/?lat=50.14819lon=14.22193zoom=16layers=B000FTF

co se name tyce, videl jsem ho pouzit na way nebo na spolecnem node highway
a highway_exit. Co je lepsi?

Take jsem nasel stycny node otagovany jako highway=motorway_junction a vzhledem
k tomu, ze JOSM na to ma ikonku, tak je to asi take tak zamyslene, i kdyz mi to
prijde mirne redundantni.

Jak tedy?
-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] OT: Logovani na WM5.0 GPSce

[Petr Nejedly]

Krom sve oblibene logovaci GPSky (QStarz Q1000) mam ted jeste i navigaci
(Mio Moov 360U). Ta sama od sebe neloguje. Logovat na ni umim (mirne hacknuta),
jenze kdyz bezi logger, nefunguje navigace.

Neda se to nejak priohnout aby to logovalo porad (na SD je mista...) ale nejak
umoznilo te vestavene aplikaci pristup ke GPS?
Nikdy jsem se timhle OS (WM5.0, ostatne ani poslednimi nekolika inkarnacemi
jeho desktopove verze) prilis nezabyval, takze nevim, jak to v tom
s devices chodi, ale predstavoval bych si, ze se pred vestavenou aplikaci
spusti cosi, co udela tee na GPS device a pak spusti ten zbytek.

To pred a zbytek bych zvladnul, jen s tim tee si nevim rady.
Neresil jste nekdo podobny problem?

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Vizualizace aktivity v OSM

[Petr Nejedly]

Tomas Kolda napsal(a):
 Ahoj, 
 
 je to hezky, ale nechapu 2 veci. 
 
 Proc je potreba mit vsechny nody v pameti? Dve moznosti:
 1. Vykresli se cela cesta i kdyz se v ni hybne treba jen jednim nodem? To 
 bych mozna takto nezeslozitoval... Jak to vypada kdyz se kresli jen 
 modifikace nodu? Kdyz se totiz pridava way, tak by se rozsvitila, pokud se 
 jen upravi geometrie, rozsviti se skutecne jen ten nod. Chapu, ze by to 
 svitilo mnohem mene, ale asi by vice odrazelo realitu. Nevyhoda: Neviditelne 
 pracne zpresnovani tagu a uprava ways... 
 
 2. Prochazet osm.xml 2x. V prvnim prubehu si poznamenat idcka nodu, ktere 
 nalezi zmenenym ways a jez se maji vykreslit. V druhem uz probihat identicky 
 jako u 1 s tim, ze se vykresli navic i ty s timestamp. Pokud budou kolizni 
 vykreslit tou svetlejsi barvou. V teto variante budou mezivysledky asi dost 
 male (vse se ihned kresli a pamatuji se jen IDcka nodu ze zmenenych ways), 
 ale pro poradnou paranoiu se da pouzit sqlite jako zasobarna IDcek. 
 
 Nejhezci by bylo pri prvnim pruchodu udelat mezisoubor s nodama (napr. 
 ID\tabLAT\tLON), ktery bude zarucene sesortovany podle ID a ten pak jenom 
 mergovat se sesortovanym mezivysledkem nodu zmenenych ways (sort | uniq). 
 Pak je pametova naroznost nulova pro libovolnou velikost dat. Pokud to 
 vypada slozite tak z duvodu me snizene schopnosti se vyjadrovat :) 

Nadherna prace, zlaty merge sort (sort -m)
Ale vyrobit ten druhy sesortovany soubor taky nebude zadarmo
Tak jako tak, world ma kolem 300M nodu, to se da pro tenhle ucel stale
zpracovat v gigu RAM (kdyz si clovek sikovne pohraje s bity).

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Vizualizace aktivity v OSM

[Petr Nejedly]

BH napsal(a):
 U nodu skladuju jako klic ID (zatim se do 32bitu vejde :) a jako
 hodnotu prepocitane souradnice v obrazku (coz se narozdil od 2x double
 vejde s prehledem do 32 bitu).
Tak jsem to myslel...

 Teoreticky min. 8 bajtu/nod, ale je to
... ale tady se rozchazime ;-)

 nejaky overhead u pouzitych datovych struktur. Takze udelat to pro
 planet by asi slo po mensi optimalizaci i na 4gb ram (neco sezere i
 vystupni obrazek, ktery by mel byt pro planet asi velky, aby bylo neco
 videt)
 Moc bitu se uz usetrit neda, pro cely planet a vetsi obrazky se to u
 obou k tem 32 bitm celkem dost blizi (takze 300M nodes=min 2.4gb ram)

Vzhledem k tomu, ze set ID je vcelku huste populovany (pokud se bavime
o celem world), nema smysl IDcka drzet a hashovat. ID je samo nejlepsim
hashem, nody jsou pak jen jednoduchym polem 32bit hodnot prepocitanych 
souradnic.
Co node, to jeden int. Chci node 227321453, sahnu na [227321453].
Spotreba 1.2GB RAM.

Ale je to hack tak na rok, dva, pak uz zase tech nodu asi bude moc

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Je OSM routovatelna nebo neni?

[Petr Nejedly]

Karel Volný napsal(a):
 *** tak si je vytahnu z cele planet. Me se moc nelibi, ze se tagem ma
 resit neco, co uz v geografickych datech je nebo ma byt.
 Teorie rika:
 1. vytvor z linie hranic polygon
 2. kdo je uvnitr polygonu je nas!

 Prece nebudeme davat kazde benzince a adrese a lesu pricpavat CZ, EU?
 
 kontrolní dotaz - co říká teorie o objektech ležících na hranici (dvojí 
 příslušnost), anebo o objektech cizích států v daném státě (tuším třeba 
 ambasády a vojenské základny, nebo to je všechno poctivě obkresleno státními 
 hranicemi?)

Moje teorie se ridi pripadovymi studiemi, a takovy pripad pak bude uzivatel
hledajici americkou ambasadu _v Cechach_ (nikoli v Americe), stejne jako
pomnik Jana Amose Komenskeho v Holandsku, nikoli v Cechach.

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Je OSM routovatelna nebo neni?

[Petr Nejedly]

Michal Grézl napsal(a):
 2008/9/29 Jakub Sykora [EMAIL PROTECTED]:
 Jsem pro pridani is_in Czechia, protoze Czech Republic je s mezerou a
 strasne dlouhy...

 K
 ja bych byl pro pridani is_in=ceska republika (s hackama a velkejma
 pismenama jak to ma byt:) Hlavne proto ze se tak nas stat jmenuje.

Ja osobne jsem pro aby zrovna toto aplikace dopocitavaly podle boundary,
ale to bych asi chtel moc.

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] přidávání dat do uir_adr a cu zk:km (např. amenity apod.)

[Petr Nejedly]

BH napsal(a):
 Chtěl jsem se zeptat, zdali je dobrý nápad přidávat tagy do bodů
  importovaných z uir_adr nebo cuzk:km. Např. je-li celé číslo popisné
  hospoda, přidat amenity=pub přímo do bodu z uir_adr databáze, má-li
  budova jméno, přidat to do cuzk:km vrstvy.
 
 Nemyslím si, že by to bylo dobré, blbě by se pak řešilo případné
 automatické opravování dat pomocí změnových souborů z uir-adr. Možná
 ten bod ještě hodit o nějaký malý kus vedle (třeba když má ta hospoda
 vchod jinde než dům kde je), ať validator v JOSM neřve nad
 duplicitními body.

Naopak, dal bych to do toho bodu.
Updaty si s tim poradi, neb ADRESA_KOD je unikatni i v case. Muze byt
dane budove pridelene jine cislo, muze byt dana adresa zrusena, ale urcite
nebude bod recyklovan pro jiny ucel. Pokud na adrese e hospoda, vsechny updaty
budou platne prave pro tu hospodu.

 
  A také, zdali je dobré editovat nekonzistence nebo chyby, např. když je
  značka s číslem popisným na ulici před budovou, jako např. Kateřinská 2:
  
 http://www.openstreetmap.org/?lat=50.0724lon=14.42395zoom=17layers=0B00FTF
 
 To asi jo ... pokud by se dělal automatický update dle změn v uir-adr,
 tak by to asi šlo implementovat tak, že pokud se v uir-adr souřadnice
 nezmění, updater s bodem hýbat nebude (prostě opraví jen to co se
 změnilo).

Tak tak.

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import uir-adr

[Petr Nejedly]

Petr Dlouhý napsal(a):
 Dobrý den,
 
 chtěl bych se zeptat, co vlastně chybí, aby bylo možné importovat adresní  
 body z uir-adr. Zdálo se mi, že skripty fungovaly již dobře, a že  
 importovaná data by pomohla především při pojmenovávání a kontrole  
 pojmenování ulic.

No myslim, ze uz jen zbyva pekne poprosit Tomase, kdyz to ma zpracovane
i s updaty, aby z toho vyrobil to OSMko, ktere pak nekdo s mirne patchnutym
JOSM a zeleznymi nervy cele najednou narve na server...


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Číslování domů

[Petr Nejedly]

hanoj napsal(a):
 Nemam na to to cist cele, kazdopadne:
 1) mapovy server MPSV je tady
 http://mapy.mpsv.cz:8080/mapy2/mpsv2.html
OK, opravil jsem wiki: 
http://wiki.openstreetmap.org/index.php/WikiProject_Czechia/free_map2osm#N.C3.A1zvy_ulic_a_.C4.8D.C3.ADsla_stavebn.C3.ADch_objekt.C5.AF

 
 2) pro transforamce pouzivejte gdal, nebo proj (cs2cs)
 Spravnost algoritmu lze snadno overit na nejakem bodu z kampane DOPNULL

Coz o to, algoritmus mam spravne (opsany) i ja. Ale az budete overovat ten 
svuj,
neleknete se, kdyz vam to pro body DOPNUL utece o par centimetru: as designed.

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import skript z uir_adr (fwd)

[Petr Nejedly]

Pavel Machek napsal(a):
 Spechat se neda, pocitace jsou pomaly; ta konverze by mela trvat 10+ hodin...

O to nejde. Jeste jsme se nedomluvili jak to ma vypadat a ty si tu hazis
outer joinama nad CSV v bashi ;-)
Stejne to nakonec nejlepe provede Tomas Kolda (vid ;-)) protoze uz ma v databazi
i ty 3+ roky updatu a u nej ten outer join pobezi asi tak 130ms.

 Na pochlapeni UIR_ADR bych moc nespolehal.

Hmm, pravda, vsechny updaty dohromady daji necelych 24 tisic nove dodanych
souradnic existujicich adres a vseho vsudy 9 (devet) novych adres ktere
maji i souradnice.
Takze z hlediska souradnic jsou relevantni jen updaty 442, 497, 606, 607 a 6

 
   jestli a jak se to tam nacpe. I kdyz si myslim ze ty data by tam byt v
   OSM mely. Dost to pomuze, jak pri mapovani, tak pri navigaci.

 Mely by tam byt urcite. Dulezite je doladit v jakem formatu a hlavne
 nasetupovat proces pro updaty! (Precijen si nechceme zaneradit OSM
 nejakymi 10%, ktere by nam pak vyrazneji komplikovali dodani tech
 zbylych 90%...
 
 Ten ADRESA_KOD by mel pro updaty stacit, ne?

Ano

 Anyway, tady je dalsi vzorek, mel by byt oznacen podle debaty na
 tady, takze pokud jsem neco udelal blbe, reknete...

Udelal. Vychazis ze 4 roky starych dat. Viz prvni odstavec.
(Tim nechci nijak krotit tvoji kreativitu, jen ji mirne nasmerovat.
Pokud to mergovani updatu taky napises v Bashi, jsi borec ;-)
Teda ne ze by to neslo...)

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Číslování domů

[Petr Nejedly]

BH napsal(a):
 Cislo popisne ma kazdy dum, pak nektere stavby maji misto cisla
 popisneho cislo evidencni (tech moc neni, predpokladam ze to budou
 nejspis ruzne skleniky, garaze apod. kam se stejne posta nedorucuje

No dovol. Ja mam v cisle evidencnim trvale bydliste a posta mi chodi!
(BTW Oficialne: Stavba pro individualni rekreaci)
V UIR_ADR (resp. ve zmenovych zaznamech) ma muj dum zaznam jak pro
objekt (prave s tim pridelenim evidencniho cisla), tak pro adresni bod
(kde pro zmenu neni prideleno cislo zadne).

Protoze je to zajimavy pripad, davam do placu i ID:
OBJEKT_KOD=25677641, ADRESA_KOD=26178257, zmenovy soubor 00475

 ). Cislo popisne je pro danou vesnici/mesto, respektive mestskou
 cast jedinecne.
 Ve mestech a asi i ve vetsich vesnicich pak maji i cisla orientacni (u ulic).
 
 Asi bych to udelal, ze pokud ma dum jen cislo popisne nebo evidencni,
 tak bych ho dal do housenumber, pokud ma i orientacni tak do
 housenumber cislo ve formatu orientacni/popisne. Mozna pak do
 dalsiho tagu dat informace o tom, jake cislo a v jakem formatu tam je
 (to by chtelo pak i nejak dohodnout presny hodnoty) - tim bude hned
 jasny jaky cislo a v jakym formatu tam teda je :)
 
 Priklad:
 
 node id=1
   tag k=addr:housenumber v=10 /
   tag k=addr:housenumberformat v=cislo popisne /
 /node
 
 node id=2
   tag k=addr:housenumber v=45/3010 /
   tag k=addr:housenumberformat v=cislo orientacni/cislo popisne /
 /node
 
 node id=3
   tag k=addr:housenumber v=617 /
   tag k=addr:housenumberformat v=cislo evidencni /
 /node
 
 Alternativne mozna jeste pridat dalsi specialni tagy pro , takze by
 pak vzniklo neco jako:
 
 addr:housenumber=45/3010
 addr:cislo_popisne=3010
 addr:cislo_orientacni=45
 
 Ale v tom uz je zase redundance, coz se mi moc nelibi ...
 
  V poslední době jsem napsal nadprůměrné množství dopisů a hledal
  spoustu adres (oproti mému obvyklému ročnímu průměru 0) a všude kde
  mají dvojí číslování jsem se setkal buď s adresou s lomítkem nebo jen
  s číslem popisným.
  Ovšem teď jsem trochu zapátral a řešení s lomítkem taky není
  samospasitelné, protože jsem narazil i na to, že je adresa bývá
  udávána jak č.p./č.o. tak  někdy i obráceně č.o./č.p.  Je v tom děsnej
  bordel :-(
  Jen pro info, náš konkurent mapy.cz najde Ulice č.p., Ulice č.o. a
  Ulice č.p./č.o. ale  nenajde Ulice č.o/č.p.

  Každopádně bych dával do housenumber minimálně č.p., protože jinak v
  tom budem mít bordel na vesnicích. A taky se to dá snadno opisovat z
  ČÚZKu :-)
 
 Ve mestech je IMHO vetsinou zase dulezitejsi to orientacni  takze
 to tam bude chtit nacpat obe.
 
 Martin
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Číslování domů

[Petr Nejedly]

BH napsal(a):
   http://git.wz.cz/uir-adr-cd.zip
  
   cca 420 Mb


 Nemuzu si pomoct, ale ten server ma nejaky mentalni problem.
  Kazdych par (kilo az mega) bajtu zabiji spojeni. Alespon ze umi retry
 
 Holt freehosting ... bohuzel nikde jinde momentalne 400Mb volneho
 mista nemam (nebo ne tam, kam by se dalo dostat z webu )
 
 Pokud nekdo vi o lepsim ulozisti tak reknete a ja to tam muzu nahrat 

Ja myslim, ze je to tak jako tak jedno.
Jsou tam 5x ta sama data (v ruznych formatech), a nakonec jsou stejne
na 2 veci. To nejdulezitejsi tam totiz ponekud chybi - souradnice.
Tabulka ADRESA pro ne sice sloupecky ma, ale pro vsechna data co jsem
videl byla ta policka prazdna...

Ma nekdo jinou zkusenost?

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import skript z uir_adr

[Petr Nejedly]

Pavel Machek napsal(a):
 Ahoj!
 
 je v priloze...
 
 Bohuzel tak jak je napsanej zvlada jen asi tak 2 adresy za sekundu
 :-(. grep ,19800, ho omezuje na jedno PSC, to asi dava smysl vyhodit
 nebo nahradit Vasim oblibenym PSC.

Nespěchejmež...

BH napsal(a):
  No, nejdriv bych to radsi prozkoumal, zjistil o kolik to nafoukne
  data, jak je to kvalitni, odlkadil to a pak teprve se rozhodoval

Vzhledem k tomu, ze geotagovanych je zatim jen cca 10% adres, jedna se
o cca 300.000 nodu, nafouknuti CR o ~20%. Pokud se UIR_ADR pochlapi
a da to dohromady cele, narostla by nam CR o 200%. Pak bysme dosahli
paradoxniho stavu vicemene kompletni site silnic prvnich a druhych
trid a ulicni site, ale bez vetsiny silnic 3. tridy ;-)

  jestli a jak se to tam nacpe. I kdyz si myslim ze ty data by tam byt v
  OSM mely. Dost to pomuze, jak pri mapovani, tak pri navigaci.

Mely by tam byt urcite. Dulezite je doladit v jakem formatu a hlavne
nasetupovat proces pro updaty! (Precijen si nechceme zaneradit OSM
nejakymi 10%, ktere by nam pak vyrazneji komplikovali dodani tech
zbylych 90%...


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Duplikovane lesy

[Petr Nejedly]

Michal Kovar napsal(a):
 To on najde - slo mi o nejakou globalni akci - ale vzhledem k tomu, ze  
 mezi nactenim lesu a jejich vycistenim se muze ledascos zvrtnout. Nu  
 coz, asi to bude nejjednodussi...

No, ono je to na vic mistech. Ja jsem vcera cistil okoli Steti,
ale moc daleko jsem nesel...

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Číslování domů

[Petr Nejedly]

BH napsal(a):
 Konecne se mi povedlo to uploadnout 
 
 http://git.wz.cz/uir-adr-cd.zip
 
 cca 420 Mb

Nemuzu si pomoct, ale ten server ma nejaky mentalni problem.
Kazdych par (kilo az mega) bajtu zabiji spojeni. Alespon ze umi retry

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] Tagovani cesty

[Petr Nejedly]

Na tohle jsem natrefil v Potstejne:
http://shell.sh.cvut.cz/~nenik/Pod_Lipami_znacka.jpg
:-)

Ted babo rad, jak to mam otagovat

Kdyz uz jsme u toho tagovani, taguje se horni tok (to jest od pramene)
vyznamne reky jako stream, nebo rovnou jako river?
Moravu jsem od pramene zakreslil coby river, ale vyrenderovane mi to prislo
vcelku drsne...

A kdyz uz jsem tam byl, i ten Kralicky sneznik jsem posunul tam, kde jsem
ho nasel (ostatne i podle wikipedie mel byt o tech 100m jinde).
Ale reknu vam, silnice, to se to mapuje, kdyz clovek nemusi po svych a deti
jsou v autosedacce a ne na zadech

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import lesů - díry a mýtiny v Mapniku

[Petr Nejedly]

Tomas Kolda napsal(a):
 Asi bych to umel opravit. Napada nekoho jak dostanu vsechny lesy co jsou na 
 uzemi CR? Pote uz staci udelat modifikace na prislusny smer. Rucne bych to 
 nedelal. 

Mozna by stacilo:
http://osmxapi.hypercube.telascience.org/api/0.5/*[source=uhul:wms]

a nebo mozna:
http://www.informationfreeway.org/api/0.5/relation[type=multipolygon][bbox=12.4,48.5,19,51.1]

Skoda ze ty multipoly relace nedostaly source tag, pak by to bylo jeste 
jednodussi...

 Muzu vzit czechia, ale nevim co se dela pri vysekavani na hranicich... 
 Chtelo by to vsechny lesy s dostatecnym bound boxem pro CR a tagem uhul... 

No a ta druha podminka vicemene implikuje tu prvni...

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import lesů - díry a mýtiny v Mapniku

[Petr Nejedly]

Tomáš Tichý napsal(a):

 Mohu to zde pokusně ověřit otočením, a za týden uvidím, ale na otočení
 všech děr v lesích by to poté chtělo někoho zkušenějšího.


 
 Uz jsem to zkousel minuly tyden a po otoceni se tuto stredu ty diry objevily.
 Ma nekdo predstavu kolik tech der je, nebude to rychlejsi pootacet rucne?

V mem segmentu jich bylo pres 200, extrapolace na 5000 pro CR by mohla 
odpovidat...


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import lesu -- nezjednodusili jsme to trochu moc?

[Petr Nejedly]

BH napsal(a):
 Tak zrovna ungule plugin nefunguje:
 
 org.openstreetmap.josm.plugins.PluginException: An error occoured in plugin 
 ungl
 ueplugin
  
 Caused by: java.io.IOException: e:\josm\JOSM\plugins\unglueplugin.jar 
 contains n
 o manifest.
 at 
 org.openstreetmap.josm.plugins.PluginInformation.init(PluginInforma
 tion.java:70)
 ... 34 more
 
 Zdrojaky ani autora pluginu jsem nenasel, takze asi smula 

Me funguje, zdrojaky jsou primo v pluginovem jaru


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] sdileni nodu

[Petr Nejedly]

Pavel Machek napsal(a):
 Ahoj!
 
 ...jinak validator plugin z josm na to rve, takze to asi nebude dobry
 napad...
 
   Pavel

http://wiki.openstreetmap.org/index.php/WikiProject_Czechia/Editing_Standards_and_Conventions#Topologie

Predpokldadal jsem, ze to bude preklad z anglickeho 
Editing_Standards_and_Conventions,
ale neni. Jinak se, zda se, o problemu globalne mlci.
Tak jako tak, souhlasim, ze toto se to melo resit plosne a ne na ceskem 
pisecku...

Co se validatoru tyce, dany stav neoznacuje ani jako warning, u me to ukazuje 
jen
info ikonku ze cesta sdili nody (s area) pod polozkou other.

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] pokusny import lesu

[Petr Nejedly]

Jiri Klement napsal(a):
 Ja jsem zrovna douplodoval, takze beru posledni dve - 28 a 29.

Vy jste teda rychlici. Jestlipak jste se na to po sobe aspon trochu podivali?
Ja tu svoji 015 (co byla na serveru na to tata) stale jeste ucesavam...
Mel jsem tam nejake prekryvy se stavajicimi lesy a taky rusim diry na silnici,
coz je v JOSM docela pakarna*. Take se nabizi uzasna moznost domalovat ty 
silnice,
co v databazi chybi, ale je na ne tunel v lese - takovou silnici podle 
ortofoto
nenamalujete.

Kdyz uz jsme u toho, jak byste resili silnici na kraji lesa?
Zatim jsem to nedelal, ale primo to krici po tom, aby way a prilehly les
sdilely nody


*) sloucit dva polygony:
- vybrat dva stycne body na prvnim polygonu, split way, smazat jednu way
- vybrat dva stycne body na druhem polygonu, split way, smazat jednu way
- bud domalovat dve propojovaci waye nebo zmergovat stycne body
- join way - spojit dva vysledne skoropolygony
- celou dobu davat pozor na relace
Neumi to nekdo lepe?

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] josm-ng (was Re: pokusny import lesu)

[Petr Nejedly]

Pavel Machek napsal(a):
 On Tue 2008-08-05 21:53:58, Pavel Machek wrote:
 Ahoj!

 No ja jsem se taky nedockal zobrazeni v JOSM... Je nekde k dostani 
 JOSM-ng v jaru? 
 http://shell.sh.cvut.cz/~nenik/josmng.html
 Ted jsem to zkousel a je tam jeste ten styl, co doprostred lesniho 
 polygonu
 namaluje stromecek, coz ted pri pohledu na CR vypada vskutku
 zabavne...
 Da se to pustit nejak jinak nez pres web browser? Link na .jar by byl
 uzitecny, javu v browseru rozjetou nemam :-(.
 
 ...jinak pouzivat alt-clicky neni na linuxu mozny, zere je window
 manager :-(.
MUJ fvwm2 je nezere. OK, point taken, nicmene pouzitelne modifikatory
a klavesove zkratky na linuxu jsou pole znacne zaminovane, budu si na to
muset dat pozor. Zvlaste proto, ze ani na linuxaka nejsem reprezentativni
vzorek.

Tak jako tak chci to malovani nodu predelat, drzet pul hodiny Alt pri oklikavani
Lipna je kravina, ze? Prvni node nejakym gestem, pak skryty mod jinak modeless 
UI
az do Esc by mohlo byt pruchodne, ale jak uz tu zaznelo, rad bych se napred 
podival
na opravdovy GIS.

  Jinak je to znatellne rychlejsi nez josm, a kresli to
 hezky... pekne.

Dik. A to uz ted (lokalne) umim i tu tramvaj pres residential, k tomu sipecky v 
jednosmerkach
a jeste stylovatelne malovani pro ruzne zoomy. Jo a ta vystavena verze jeste 
neumela multipolygony...
http://shell.sh.cvut.cz/~nenik/josmng-multistyle.png

  Mozna bych od nejakeho zoomu schoval ikonky lesu a parkovist...
... viz vyse.

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] pokusny import lesu

[Petr Nejedly]

Jiri Klement napsal(a):
 No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze
 rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je
 cela uprostred lesa.

 At se propadnu do zapadniho nemecka*, jestli jsou ty renderery takhle spatne 
 napsany.
 
 Myslim ze osmarender to opravdu neresi. Proste renderuje najednou
 dostatecne velkou dlazdici (+ stahuje o dost vetsi oblast nez chce
 renderovat) a doufa, ze vetsi les nebude.
 
 Na druhou stranu, OSMAPI takhle spatne napsany je
 Jak se tohle da resit? Napada me sestavit z ways polygon a u kazdeho
 polygonu ulozit jeho bounding box. Ale uz jenom vytvareni polygonu
 bude problem, protoze way muze byt jak hranice polygonu tak jenom
 cara, v zavislosti na tom, jake ma tagy.

Ty uvozokvky mely byt spis kolem toho spatne, ale ono je to jeste horsi
nez jsem myslel. OSMAPI dokonce nevrati nic ani v pripade, ze pozadam o bbox
protnuty cestou, jejiz vsechny nody jsou vne toho bboxu.


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] pokusny import lesu

[Petr Nejedly]

Pavel Machek napsal(a):
 Ahoj!
 
 tak dnes jeste jednou. Udelal jsem generalizaci na 20metru + odstraneni 
 ostrych vycnelku (30stupnu a rozvor max. 50metru). Minimalni plochu jsem 
 urcil na 60x60metru. 

 Jine varianty byly moc bodu... Takto je to:
 2.567 multipolygonu
 75.940 polygonu
 1.747.590 nodu 

 Mne se to opticky zda hezci nez to predesle. Zkuste ohodnotit. Nyni jiz 
 zkompilovane pomoci MINGW, takze snad bez problemu. 

 http://www.web2net.cz/osm/viewer_080804.zip 
 
 Byl by .osm.bz2?
 
 Pak bych potreboval poradit jakym zpusobem uploadovat takove mnozstvi dat. 
 Ma OSM transakce? Mam zaruceno, ze jedna davka, pokud spadne spojeni se 
 rollbackne? Mate nejake zkusenosti, nastroje apod? Staci velky OSM rozdelit 
 po polygonech a pak necim uploadnout? Bude to takto bezpecnejsi? 
 
 Ja jsem silnice importoval normalne josm-kem.

Coz m.j. znamena generovat zaporna ID.

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] pokusny import lesu

[Petr Nejedly]

Pavel Machek napsal(a):
 Ahoj!
 
 Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali
 body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal
 podel tech dlazdic (duvody uz jsem psal minule - treba takove
 krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na
 kousek ulice v Beroune).
 Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak
 to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze
 je area obrovska pokus se sklada z 10 bodu Podle dlazdic Ti naopak
 budou vznika usekle vycnelky z tilu...
 
 No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze
 rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je
 cela uprostred lesa.
 

At se propadnu do zapadniho nemecka*, jestli jsou ty renderery takhle spatne 
napsany.
Na druhou stranu, OSMAPI takhle spatne napsany je

*) http://www.openstreetmap.org/?lat=48.49457lon=8.2033zoom=16layers=B00TTF
-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Duplicitni body

[Petr Nejedly]

Michal Kovar napsal(a):
 Toho jsem se bal - tak jsem to radsi cely smaznul a holt to udelam po  
 kouskach...btw jak mam v JOSM smazat cestu jednim kliknutim? Kdyz chci  
 smazat cestu, tak mi po ni zustanou body...

Co tak pouzit JOSM mene nez pul roku stary?
Soucasny JOSM implicitne maze vsechny nepouzite nody, pro smazani way bez node
podrz Alt, pro smazani jen jednoho segmentu Shift.

Take se da v select modu dragem vybrat vice objektu a ty pak smazat najednou...

Pak je jeste moznost, ze josm u cestu smazal i s jejimi definicnimi body
a ty zbyle jsou ty duplicitni
-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] Kniha o GPS/Mapování

[Petr Nejedly]

Jachym Cepicky napsal(a):

 Jak je to s JOSM-ng ? Kdy to bude JOSM a kde se to dá stáhnout?

Zatim na tom delam sam. Uprimne, jeste neni dost zajimavy aby pritahl
dalsi uzivatele. Pracuji prevazne na enginu a frameworku, takze to jeste
neni pouzitelny pro praci (nemam napr. tagovaci UI).

Design goals (bez poradi):
Snizena spotreba pameti
Vysoka rychlost
Spolehlivy a transparentni undo system
Snadno pouzitelne API datasetu
  - snadne psani featur
Pouzitelnost
Duraz na workflow
Verne renderovani (vcetne relaci)

Kdy to bude (JOSM)?
Bude to pouzitelne ve chvili kdy pridam tagovaci UI a WMS plugin.
JOSM to ale bude az ve chvili, kdy to bude prilis dobre na to, aby
se to dalo prehlizet, nehlede na architektonicke neshody s JOSM teamem.
Tak jako tak, cas mam omezeny a deti tri ;-)

Kde se to da stahnout?
Zatim jen jako zdrojaky v openstreetmap SVN, pravidelne buildy
zatim nevyrabim. OK, postnul jsem aktualni verzi jako webstart na:
http://shell.sh.cvut.cz/~nenik/josmng.html

Kde jsem:
Engine dokaze na 2GB RAM stroji komplet natahnout a svizne zobrazovat
i editovat dataset velikosti nemecka (germany.osm, 8M entit).
Undo se stara samo o sebe.

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] mobilni xhtml browser s podporou gps - nazor, pomoc

[Petr Nejedly]

BH napsal(a):

 jednosmerce v jeji casti). Mozna by to slo vyresit nejakym docasnym
 tagem (k=street_name_sign v=jmeno_ulice) ktery by pak clovek doma
 smaznul a priradil to jmeno k patricne way

Ze bych si jako vecer stahnul ze serveru a dal search(user=nenik, 
street_name_sign=*) :-)


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] Plochy vod v OSM

[Petr Nejedly]

Jiri Jakes napsal(a):
 [EMAIL PROTECTED] dist % wine viewer.exe
 [EMAIL PROTECTED] dist %

No dobre, po ACCEPT_KEYWORDS='~x86' emerge wine
uz mi to taky funguje, i kdyz to nebyla uplne pointa...

Renderuje to zajimave, nicmene prilis si toho nedela z multipolygonu
ani z vrstev. Mimourovnove krizovatky maluje asi jako mapnik (cili napred
vsechny outline, pak vsechny vnitrky), jen jeste mene prehledne kvuli tem 
vrstvam.
Dale se mi zda, ze to nezvladne soubeh slinice a tramvaje
(highway=*/railway=tram na jedne way)

Datova struktura bude pekna, vse ve 2MB, ale zda se, ze komprimovane.
Zkousel jsem v josm-ng jak by slapalo hifi renderovani a dokazu renderovat
v realnem case (cili srovnatelne s josm-ng bez hifi) v podobne kvalite a resim
i vrstvy. Viz: http://stoupa.sh.cvut.cz/~nenik/josm-ng-hifi.png

Hodill by se rozumny, mezi systemy sdilitelny popis renderovaciho stylu
(zatim pouzivam mappainti + neco hardcoduju). Osmarendererova XSL transfromace
neni, opakuji neni, takovym rozumnym popisem ;-)
Pak bychom se mohli lepe bavit o implementaci renderovani.

Coz mi pripomina, ze pro rozumne renderovani mimourovnovych krizovatek
(jako ta na screenshotu*) potrebuje i pro osmarenderer mirne prizpusobit
styl editace. Napojeni sjezdu z mostu je potreba udelat na stejne vrstve
jako je most (obecne, krizovatky by mely mit vsechny cesty ve stejne layer),
jinak se vyrenderuje okraj vyssi silnice a napojeni nevypada napojene,
viz: http://www.openstreetmap.org/?lat=50.04047lon=14.40705zoom=17layers=0BFT

*) screenshot se renderoval z mirne upraveneho czechia.osm a ty skrty na 
sjezdech
ted uz renderuju lepe...

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] Plochy vod v OSM

[Petr Nejedly]

Tomas Kolda napsal(a):
 Nemam na vyvoj moc casu, takze asi 4 mesice jsem vyvijel jen datovou 
 zakladnu (komprimace, spatial indexy, konverze dat apod.). Posledni asi 
 3 tydny delam na grafice, takze tam jsou mouchy presne co pisete. 
 Optimalizace na grafice je nulova, proto mate asi tu javu rychlejsi. 

Nemyslim, ze mam tu javu rychlejsi. Mam josm-ng rychlejsi nez josm,
dostatecne rychly pro beznou editaci datasetu velikosti czechia.osm,
ale prerendrovani celoobrazovkoveho pohledu na Prahu pri nejnevhodnejsim
zoomu jsou stale nejake stovky ms.
Ale pisu editor a musim se rozumne vejit do pameti aniz bych
stazena data poskodil (pro viewer bych napr. zahodil nody mimo krizovatky,
pro editor je musim udrzovat vsechny kvuli tomu jednomu tagu (created_by)
a kvuli IDcku). Zatim jsem se nevrhal ani do skutecnych indexu,
josm-ng ma jen sesortovane nody podle jedne osy a hlida bboxy cest.
To staci pro vyrazne rychlejsi renderovani velkych datasetu nez zvlada
josm a luxusni editovani pri rozumnem zoomu.

 Jinak ale myslim, ze 6MB v pameti by se s Javou dosahovalo tezko. Jsem 
Ani smykem. 500k nodu x 16B souradnice + 8B ID je samo o sobe 12MB
a to jeste ani nejsou vsechny informace z OSM. Ale to neni problem javy,
tolik tech dat proste je a editor je musi udrzet. A OSM APIv0.6 to muze
udelat jeste horsi.

 Javista tak prosim nekamenovat za mou poznamku :), ale treba se mylim. 
 zlib komprimaci na komplet data jsem zkousel, ale vychazi asi o 80% 
 vetsi soubor.
Takze data nejsou komprimovana? V tom 2MB souboru jsem nenasel zadne texty.

 Jinak jak jsem psal. Filozofie programu je miniaturni aplikace, ktera by 
 mela bezet na embedded zarizenich (WinCE apod.) a poskytovat sluzby jako 
 napr. iGO. Pro OSMaky tam budou featury jako automaticke logovani, 
 separace casti tracku, ktery jeste neni v mapach, warningy casti tracku, 
 ktere se hodne lisi od mapy (silnice je zakreslena s chybou). Bude to 
 freeware, ale otevirat kod se mi zatim nechce. Konfigurace apod. budou 
 formou easy textaku, jak je to ted.
[...]
 Ted se jdu teda vrhnout na ty diry a zlevel, at si nedelam ostudu. 
 Proste jsem se na ten brzky release nemel nechat ukecat :-)

Ale mel. Muj komentar neberte jako kritiku, ale spis jako motivaci.
Resime spolecne problemy, komunikace neni nikdy na skodu.
Josm-ng zatim take nemaluje diry a nebude uplne snadne je dodelat tak,
aby spravne reagovaly na editaci (zmenim nejakou relaci a tim se zmeni
renderovani nejake way. Nebo jeste hure, zmenim nejakou way (tu vnitrni)
a zmeni se mi renderovani jine way (te vnejsi)).

Vpodstate budu muset vymyslet obecne renderovani relaci, napr. kvuli
relacnimu znaceni turistickych cest.

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] Plochy vod v OSM

[Petr Nejedly]

Tomas Kolda napsal(a):
 Takze pre alpha je zde:
 
 http://www.web2net.cz/osm/dist.zip

[EMAIL PROTECTED] ~/dist $ wine viewer.exe
wine: Unhandled page fault on read access to 0x0040 at address 0x40acc8 (thr
ead 0009), starting debugger...
Unhandled exception: page fault on read access to 0x0040 in 32-bit code (0x0
040acc8).
Register dump:
  CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
  EIP:0040acc8 ESP:006ef860 EBP:006efa58 EFLAGS:00210246(   - 00  -RIZP1)
  EAX: EBX: ECX:00144600 EDX:0011d630
  ESI:006efad0 EDI:00010024
Stack dump:
0x006ef860:  006ef8ec 7ee88ff4 006ef8b8 7ef850ab
0x006ef870:  7ed48ee4  006ef8c8 7e86c285
0x006ef880:  7ffdc0cc 7efe3ff4 006ef898 7ef85068
0x006ef890:  7ed48ee4 7ee88ff4 006ef8e8 7ee605fe
0x006ef8a0:  7ed48ee0 006efad0 006ef8f8 7ed11de5
0x006ef8b0:  7ed40ff4 006efad0 006ef8f8 7ed11f82
Backtrace:
=1 0x0040acc8 in viewer (+0xacc8) (0x006efa58)
   2 0x0040f846 in viewer (+0xf846) (0x006efb28)
   3 0x7eb78c2a WINPROC_wrapper+0x1a() in user32 (0x006efb58)
   4 0x7eb79308 WINPROC_wrapper+0x6f8() in user32 (0x006efba8)
   5 0x7eb7f646 WINPROC_call_window+0xe4() in user32 (0x006efbf8)
   6 0x7eb3dc01 in user32 (+0x8dc01) (0x006efc58)
   7 0x7eb40132 in user32 (+0x90132) (0x006efca8)
   8 0x7eb40532 SendMessageW+0x54() in user32 (0x006efcf8)
   9 0x7eb4bfa8 in user32 (+0x9bfa8) (0x006efd28)
   10 0x7eb4ca05 RedrawWindow+0x38d() in user32 (0x006efd98)
   11 0x7eb4cad0 UpdateWindow+0x35() in user32 (0x006efdb8)
   12 0x0040f47f in viewer (+0xf47f) (0x006efdf8)
   13 0x0040f514 in viewer (+0xf514) (0x006efe38)
   14 0x00486b28 in viewer (+0x86b28) (0x006efeb8)
   15 0x0040124b in viewer (+0x124b) (0x006efee8)
   16 0x004012b8 in viewer (+0x12b8) (0x006efef8)
   17 0x7ee44a87 in kernel32 (+0x64a87) (0x006effe8)
   18 0xb7e70c7b wine_switch_to_stack+0x17() in libwine.so.1 (0x)
[...]

:-)

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] import lesu

[Petr Nejedly]

Michal Kovar napsal(a):
 Ono by mozna stalo za to zamyslet se nad moznosti, ze by OSM umel nejakym  
 zpusobem uzivateli rict, jak stara jsou data, na ktera se diva. To neplati  
 jen o stromech, ale i o silnicich a zastavbe - bylo by to uzitecny. Pak  
 bychom nemuseli resit, kdo co udrzuje, ale do neznama bychom sli s tim, ze  
 na danou oblast uz nikdo 5 let nehrabnul a pocitali bychom s tim, ze tam  
 muze byt neco jinak.

OSM to svym zpusobem umi - kazdy prvek ma ulozeno cas posledni editace.
To vsak samozrejme vice ci mene neodpovida casu porizeni dat.

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] JOSM-NG

[Petr Nejedly]

Petr Schonmann napsal(a):
 Ahoj,
 padle zde zmínka o josm-ng, kde se dá stáhnout *.jar, popř lze nějak 
 zkompilovat pro windows ?

JOSM-NG je muj pokus o zefektivneni datovych struktur a renderovani
v JOSM tak, aby se v nem v realnem case dal editovat dataset velikosti
czechia.osm

Starsi build se da spustit webstartem primo z:
http://stoupa.sh.cvut.cz/~nenik/josmng.html

Mapovat se v nem jeste neda - chybi tag editor, save a server I/O

Mam na JOSM-NG relativne malo casu (posledni mesic jsem nemel zadny,
az vcera vecer nejakou hodinku) a zatim se nikdo nepridal, nicmene
JOSM skupina o NG vi. Rozdily v implementaci dat a pristupu k implementaci
undo vsak neumoznuji snadne sdileni kodu mezi implementacemi.

Zdrojaky: http://svn.openstreetmap.org/applications/editors/josm-ng/
Licence: GPLv2+

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] import lesu

[Petr Nejedly]

Kubajz napsal(a):
 Soucasny skript nezohlednuje duplicitu bodu a zavede klidne dva stejne.
 Indexaci jsem mel namysli to, ze se bude drzet tabulka bodu (index) v
 pameti po celou dobu zpracovani lesu a bude se napred zkoumat, zda bod
 uz v indexu neni, nez se vybleje do .osm souboru.
 
 K
 
 Jachym Cepicky napsal(a):
 Indexace bodu, co to je?

 Coz takhle generalizace?

... by rozhodne byla na miste.
Ony sice renderery vyrabeji mapu az do 30cm/px, ale mapovat
okraje lesa s detaily v jednotkach metru nema moc smysl, obzvlaste
kdyz jde o drobne rozliseni uvnitr souvisleho lesniho porostu.
Zachovanim pouze obalovych krivek lesa by se velikost datasetu
redukovala nejmene o 90% a to uz by pomalu davalo smysl importovat.

Soucasny export UHULu ma ~30M nodu, po odstraneni duplicit jich bude
~15M, po redukci vnitrku se dostaneme radove na 1M. To je porad
2x tolik nez vsech ostatnich nodu v cele CR, ale dovedu si to uz predstavit.

Musime si pak ale polozit otazku co a jak podrobne v te mape chceme mit.
Popr. se opravdu zacit vazneji bavit o tematickych vrstvach v OSM.org

Opravdu chceme mit podrobnejsi mapu lesu nez treba silnic?

Patri do mapy treba vsechny budovy? (2M domu - 12M OSM primitiv,
potencialni import z katastru, pokud by licence povolila)
Ostatni mapy ty budovy maji (bitmapove), viz nahodne:
http://www.mapy.cz/[EMAIL PROTECTED]@[EMAIL PROTECTED]

Jake jeste datasety obdobne rozsahlosti by se chtely importovat?



 j

 Dne 15. květen 2008 9:29 Kubajz [EMAIL PROTECTED] napsal(a):
   
 Ahoj,

 kvuli hustemu nedostatku casu jsem na to nemel vubec cas a vykaslal jsem
 se na to. Podivam se, jak se zmenila situace na UHULu (pokud vubec) a
 predelam ten importer tak, aby generoval spravna data pro OSM vcetne
 relaci a indexace bodu, abychom jich tam nemeli miliardu ale jenom pul
 miliardy.

 K

 Pavel Machek napsal(a):
 
 Ahoj!

 ...pokrocil nejak? Myslim ze by bylo pekne uploadnout aspon huste
 zmapovane oblasti -- treba lesy v Praze...

 Takhle je mapovat prazsky lesy/parky dost demotivujici -- k dispozici
 jsou nejspis lepsi data -- ale pravdepodobne ani ty lepsi data
 nebudou dokonaly... bylo by fajn je tam mit at se daj opravovat chyby
 etc...

   Pavel

   
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

 


   
 
 
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] tagovani a renderovani

[Petr Nejedly]

BikerOnly napsal(a):
 Jo toho jsem si bohuzel vsiml, az kdyz jsem vlezl do souboru.
 
 a co s tim pak dale?

V JOSM je tlacitko upload (hned vedle download. Tam ke napada, stahnul jsi
napred okolni data? Takze si projistotu projdeme cely postup:)

1) Spustim JOSM
2) Otevru gpx soubor
3) Nazoomuju na rozumnou oblast pro editaci (rekneme pravitko vlevo nahore
ma mene nez 2km) - pokud mam data z rozsahlejsiho uzemi.
4) Download from OSM - to stahne aktualni data pro prave zobrazenou oblast
5) Domaluju co mam navic, patricne to otaguju
6) Upload to OSM - tim svuj vytvor zvecnim v OSM databazi.


Pokud mas namalovano a ulozeno do .osm souboru, tak doporucuji pred uploadem
merge s aktualnimi daty (obzvlaste pokud jsi maloval bez predchoziho stazeni
dat pro oblast):
1) Spustim JOSM
2) Otevru osm soubor - JOSM se sam nazoomuje na moje data
4) Download from OSM - probehne lokalni merge mych dat s OSM,
pozor, nedela to zadne chytrostiky jako napojovani cest, jen to hlida
konfliktni upravy existujicich OSM prvku. bez predchoziho stazeni z OSM
zadny konflikt nenastane.
5) Inspekce vytvoru
6) Upload to OSM

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] Lokalizace JOSM

[Petr Nejedly]

BikerOnly napsal(a):
 Jen pro overeni, kdyz zameruji ulici, staci tyto tri tagy:
 - highway residential
 - created_by Jaaa
ne.
created_by je automaticky generovany editorem (JOSM tam,
kupodivu, da JOSM ;-)
Uzivatel ktery danou entitu vyrobil/modifikoval je zaznamenan
automaticky jako vlastnost primitiva, nikoliv tag.
Viz napr (nahodne zadane ID ;-)
http://api.openstreetmap.org/api/0.5/node/27134521

 - name ... nazev ulice?

BTW: Obcas se hodi overit, jestli nahodou ta hlavni ulice neni spis
silnice 3. a vyssi tridy, viz:
http://wiki.openstreetmap.org/index.php/WikiProject_Czechia/free_map2osm#Silni.C4.8Dn.C3.AD_a_d.C3.A1lni.C4.8Dn.C3.AD_s.C3.AD.C5.A5_.C5.98SD
V takovem pripade pridavam
ref=cislo silnice
source:ref=rsd_cr


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] Lokalizace JOSM

[Petr Nejedly]

BikerOnly napsal(a):
 A dotaz, pokud to zakreslim jako ulici a nejaky znalejsi clovek zjisti 
 ze to je silnice III. tridy, da se to dodatecne predelat? A autor je 
Samozrejme. Vsechny tagy jsou editovatelne i mazatelne.

 kdo? Ten kdo to opravil nebo kdo to zakreslil
Databaze uklada jako autora toho, kdo primitiv naposledy upravil.
Ale nejakou dobu uz se v databazi udrzuje i historie, viz:
http://api.openstreetmap.org/api/0.5/way/13993660/history

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

[Talk-cz] CUZK - licence

[Petr Nejedly]

Zkousel jsem katastralni mapu CUZK a (navzdory komentari ve wiki) sedela 
perfektne
na cesty mapovane drive dle GPS logu, takze projekce se mi zda byt OK.

Stalo by za to vyjasnit licenci, nebot z duvodu zdroje je nadeje, ze by licence
byla pristupna a hlavne protoze se jedna o data dost presna...

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] Mapa silnic podle RSD

[Petr Nejedly]

Jiri Klement napsal(a):
 Zdravim,
 
 Napsal jsem xslt transformace pro prevod silnic v databance rsd do
 osm. Nemam samozrejme v umyslu to importovat, je to spis mysleno jako
 podklad pri kresleni silnic.
 
 Je to ke stazeni tady:
 http://home.zcu.cz/~jklement/osmrsd.zip

Vypada to moc pekne a dokonce to i odpovida tem silnicim treti tridy
co jsem z RSD opisoval ;-)

Ted jeste to jako layer hezky poznat a renderovat ho slabe na pozadi
velmi sirokou carou i se jmenem.

No, JOSMove pojeti stylu neumi vice pravidel ale v NG bych chtel umet
alespon nejaky ten AND, alespon ve smyslu:
rule
   condition k=created_by v=rsdToOsm.xsl/
   condition k=highway v=tertiary/
   line width=20 colour=#809bc040 annotate=yes/
/rule


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] OSMProcessor.jar [update]

[Petr Nejedly]

[EMAIL PROTECTED] napsal(a):
 Zkus http://stoupa.sh.cvut.cz/~nenik/OSMProcessor.jar
 Je to update co umi elemstyles.xml a ma pribalene ikonky
 z JOSM i puvodni standardni styl. Renderuje tedy vse co JOSM
 s par odchylkami:
 *** nemohu to spustit ani na Linuxu ani na WinXP:
 
 c:\Data\0downloadjava -version
 java version 1.5.0_06
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
 Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)

Novejsi verze na http://stoupa.sh.cvut.cz/~nenik/OSMProcessor.jar funguje
i na JDK1.5


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] OSMProcessor.jar [update]

[Petr Nejedly]

Pavel Machek napsal(a):
 Zni to pekne, ale nepustim to.

Zkus http://stoupa.sh.cvut.cz/~nenik/OSMProcessor.jar
Je to update co umi elemstyles.xml a ma pribalene ikonky
z JOSM i puvodni standardni styl. Renderuje tedy vse co JOSM
s par odchylkami:
1. Zmenil jsem sirku highway=residential na 1 (byla 2)
2. Renderer uplatnuje maxScale pravidlo (JOSM nee)
3. Zatim nepocitam realwidth, takze dalnice je 3px i zblizka

[2] zpusobuje (pri oddaleni) nejvetsi rozdily v renderovani
a take je nejvetsim problemem. Jeho ignorace JOSMem zpusobila,
ze je max_scale ve stylu vetsinou nerozumny. Ale aspon je videt,
ze to neco dela. Kdo by si s tim chtel pohrat[*], necht vezme v uvahu,
ze cislo v elemstyles.xml (jar:styles/standard/elemstyles.xml) je pred
porovnanim se zoom faktorem (tim cislem co pri prerendrovani vidite
v konzoli) vydelen 10. Zoom faktor je pocet jednotek na pixel, pricemz
v nasich zemepisnych sirkach a za pouziti mercatora vychazi jednotka cca
na 17cm. Minimalni zoom factor je 6 - 1m/px, ale je to mozne jeste trochu
zpresnit.

 (Zminoval jsem ze java je neuveritelnej krap?
To zminujes vzdy a nasledujici otazky jsou recnicke, tak na to zapomeneme, OK?

[*] Hrat?
$ jar -xf OSMProcessor.jar styles
$ vi styles/standard/elemstyles.xml
$ java -Xmx256m -classpath .:OSMProcessor.jar josmng.ui.Main
Ale stale jsou v kodu nejaka implicitni omezeni zoomu (napr promenliva
velikost textu a jeho zmizeni nad z=5000)
Ale pokud by nekdo navrhnul rozumne maxscale, rekneme v meritku 1px/cm,
rozhodne se neztrati.

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] Ceska slippymap

[Petr Nejedly]

Kubajz napsal(a):
 Ahoj,
 
 dnes se mi za pomoci mapniku a OpenLayers podarilo rozbehnout mapu na
 
 http://kubajz.kbx.cz/junk/openlayers.html
 
 renderuje se tam pouze vyrez pro CR, a to z dat, ktera jsou v
 czechia.osm.bz2
 
 Ma to smysl?

Uprimne, dokud neni generovani czechia.osm dostatecne stabilni tak ani moc nee.
To by ta mapa vetsinou obsahovala jen mesta a zadne cesty ;-)

Ale kdyz uz to jede, popoladil bych barvy. Silnice treti tridy nejsou na tom
modrem pozadi moc videt (pokud se nepriblizim dostatecne).

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] Podzimni uklid

[Petr Nejedly]

Michal Grézl napsal(a):
 On Nov 26, 2007 3:33 PM, Michal Grézl [EMAIL PROTECTED] wrote:
 On Nov 26, 2007 3:20 PM, Petr Nejedly [EMAIL PROTECTED] wrote:
 Michal Grézl napsal(a):

 On Nov 25, 2007 9:43 PM, Petr Nejedly [EMAIL PROTECTED] wrote:
 Michal Grézl napsal(a):
 Jinak jedno masochisticke reseni jak opravit ty restrictions=cosi je
 nahrat do josm danou oblast nechat si najit vsechno s danym tagem,
 najit to do selection a pak napravo v current selection provest
 patricne opravy, tedy prepsani tech vadnych tagu. Funguje to bezvadne,
 a jestli pujde do josm nahrat cela cr, muze se to udelat naraz.
 Celou CR v (upravenem) JOSM sice mam, ale jeho Find neni zdaleka tak
 mocny, jak by bylo potreba i na takovou trivialitu. Nebo mi neco unika?
 find josmu je docela hodne mocny a na takovouhle trivialitu bohate
 staci, zkousel sem to ted zrovna nad prahou, a offline mi to bezvadne
 funguje, za asi 5s sem pridal ke vsemu co v sobe ma
 restrictions=cokoliv oneway=yes. Jeste to prozkoumam, ale zkuste to,
 No prave. Je to jen jednoduche textove porovnani s cimkoliv.
 Nechci restrictions=cokoliv, chci restrictions=(.*,|)oneway(,.*|)
 Nezabere ani replace-select(restrictions), and-select(oneway),
 to mi stale muze vybrat objekt s oneway=true a restrictions=neco jineho.
 V tomto konkretnim pripade bych si mozna vystacil (jake jine restrictions
 se vlastne drive pouzivaly?), ale obecne by to hledani slo zlepsit...

 zadej restriction:oneway to najde tagy restriction=oneway, zbytek
 kde je napsano neco navic to je holt smula, nicmene asi by nebyl
 problem dodelat nebo napsat request na dodelani hledani regexpama.
 Je k tomu na wiki (asi josm) navod jak to pouzit, nejake info se
 zobrazi i v bubline po najeti na inputbox

 
 blizsi info tady, ovsem jestli si nejak zasadne nerozumime tak se omlouvam:)

Rozmime si dobre, to je presne to Nebo mi neco unika?

 http://wiki.openstreetmap.org/index.php/JOSM_search_function
Unikal mi tento help. Zkousel jsem hledat s key=value, to nezafungovalo,
a ani ten dialog na prvni pohled nenaznacoval, ze by se za nim
skryval tak mocny jazyk.

Dekuji za nakopnuti spravnym smerem.

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] Podzimni uklid

[Petr Nejedly]

Michal Grézl napsal(a):
 Jinak jedno masochisticke reseni jak opravit ty restrictions=cosi je
 nahrat do josm danou oblast nechat si najit vsechno s danym tagem,
 najit to do selection a pak napravo v current selection provest
 patricne opravy, tedy prepsani tech vadnych tagu. Funguje to bezvadne,
 a jestli pujde do josm nahrat cela cr, muze se to udelat naraz.

Celou CR v (upravenem) JOSM sice mam, ale jeho Find neni zdaleka tak
mocny, jak by bylo potreba i na takovou trivialitu. Nebo mi neco unika?

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

[Talk-cz] czechia.osm v JOSM

[Petr Nejedly]

FYI: Pujde to!

JOSM neni prilis staven na rozsahle datasety (cimz czechia.osm bezesporu je),
nicmene da se priohnout, aby se v nem dalo pouzitelne pracovat i s mnozstvim
dat, ktere czechia.osm v soucasne dobe predstavuje.

Pocatecni pozorovani:
V normalnim modu neni schopen vykreslit celou CR (jakakoliv operace trva
desitky sekund), prace s velkym priblizenim je na hranici pouzitelnosti.

V mappaint modu si mnohem lepe poradi s celou CR (uz jen jednotky sekund),
bohuzel potrebuje jednotky sekund i pri velkem priblizeni.

Prvni upravy (zatim jen normalni mod):
Vypnute malovani sipek vyrazne urychli celou CR.

Overene patche:
*) prepis malovaciho filtru z Point2D a rectangle.intersects(Line2D) na Point
a rectangle.intersects(rectangle) vyrazne zrychli praci v priblizeni.

*) filtrovani segmentu promitnutych do bodu (rectangle(0,0)) vyrazne zrychli
celou CR (jsou videt jen node, ale i tak se clovek dobre orientuje).

Sam ted takto upraveny a nastaveny JOSM provozuji a jsem schopen s nim
vcelku normalne pracovat (pravda Core2Duo @2.4GHz, ale druhe jadro se flaka).

Abych nezapomel, z duvodu spotreby pameti jsem musel zvetsit heap (-Xmx256m)
pridat unifikaci (ne internovani, ale jako by to bylo) stringu (260MB-170MB)
a nahradit tag HashMapy vlastni implementaci Mapy - pole a linearni prochazeni,
coz pri 6 zaznamech neni problem (170MB-106MB)

Dalsi moznosti:
*) Filtrovat cele way dle bboxu
*) Prejit na celociselnou aritmetiku

Az to jeste trochu popoladim a doprofiluju, submitnu patche...


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

Re: [Talk-cz] Intro a par otazek

[Petr Nejedly]

Pavel Machek wrote:
 Ahoj!
 
Pred par dny jsem zacal mapovat a nashromazdilo se mi par nejasnosti, tak jsem
tu a ptam se ;-)

Vetsina z vas me asi nezna, takze kratke intro:
Bydlim u Kladna, mapuji co kde projedu (Mam QStarz Q1000, coz je prima vecicka
- mala, citliva, staci zapnout a sama loguje, a na tlacitko dela znacky). Rad
jezdim po silnicich 3ti tridy (hlavne tak ne prilis daleko od spojnice Kladno
- Steti). Velmi dobre ovladam Javu, takze mam take v planu ponekud zrychlit a
zefektivnit JOSM (zezacatku to pujde snado, uz jsem zacal posilat
patche).
 
 
 Kdo prida funkcni delete point from way bude muj osobni hrdina :-).

Myslis takovy delete, kdy way zustane funkcni a nerozdelena, jen z ni ubyde
jeden node (narovna kousek cesty), tak to se mi asi deje tak jak ma.
Vcera se mi to ale stalo nejak jinak, takze dnes jsem zacal inspekci zdrojaku
a nasel jakousi zminku o Altu... Nicmene mi node mizel bez rozbiti cesty
i bez Altu...

PS: Pokud by nekdo mel Q1000 (nebo jinou logujici GPS s MTK32) a chtel by to
provozovat pod Linuxem, napsal jsem si na to appku (Ma i mapping mod -
vyfiltrovani nekvalitnich bodu z logu). Jen jsem ji jeste nemel cas 
publikovat
 
 
 Mam GPSku zvanou openmoko, data padaj v NMEA. Aplikace na mazani
 spatnych bodu by se hodila...

Um, nody filtruju podle fixu (GPS loguje binarne,ja to stahuju, parsuju
(, zobrazuju v tabulce) a pak ukladam jednim z nekolika formatteru,
napr. GPX) a podle PDOP. GPSka totiz loguje i kdyz nema signal, pote
chvili loguje kdyz spis tusi kde je, nez ze by vedela a pak uz je to
dobre ;-) Takze pokud v NMEA mas GPGGA message (jako ze asi ano), daji
se body podle PDOP snadno vyfiltrovat, ale nevim, jestli je to to,
cos mel na mysli?
BTW: jak moc GPS-logujici neo zere baterky?

-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

[Talk-cz] Intro a par otazek

[Petr Nejedly]

Zdravim,

Pred par dny jsem zacal mapovat a nashromazdilo se mi par nejasnosti, tak jsem
tu a ptam se ;-)

Vetsina z vas me asi nezna, takze kratke intro:
Bydlim u Kladna, mapuji co kde projedu (Mam QStarz Q1000, coz je prima vecicka
- mala, citliva, staci zapnout a sama loguje, a na tlacitko dela znacky). Rad
jezdim po silnicich 3ti tridy (hlavne tak ne prilis daleko od spojnice Kladno
- Steti). Velmi dobre ovladam Javu, takze mam take v planu ponekud zrychlit a
zefektivnit JOSM (zezacatku to pujde snado, uz jsem zacal posilat patche).

Prace viz napr (a sirsi okoli):
http://www.openstreetmap.org/?lat=50.13678lon=14.16782zoom=17layers=0BF

A ted ty dotazy:
*) V me obci je mnoho ulic jen sterkovych (delala se kanalizace a ulice se
jeste nespravovaly). Zatim jsem je mapoval jako track/2, ale tracktype byl
deprekovan a na mape to take nevypada hezky. Pokud je to ulice, mam to teda
delat jako residential?

*) Obcas projedu neco, co je naimportovano z HELP SERVICE . Opetovny import se
asi nepredpoklada, takze s tim muzu hybat (pokud mam detailnejsi/presnejsi
data)? A kdyz uz treba usek komplet predelam, muzu smazat zdroj?
A s tim souvisi:

*) Jak presne/detailne je rozumne mapovat? Pokud je nekde rovny usek, udelam
ho dlouhy, ale kdyz se cesta vlni (a to se ty treti tridy rady), lamu to i po
15m. Je to pak sice hezci a presnejsi, ale vic dat...

*) A jeste jedna souvisejici: po importu nachazim nejake duplicity (ta sama
silnice, oklikana drive, casto hodne nahrubo treba podle fotomapy) Mazat bez
milosti?

*) Volne lozene body bez tagu mazat?

*) Kdyz pojmenovavam fan-out ulice z vesnic, zakoncuju je (splitem) na
hranici obce. Nedavalo by smysl (v kontextu Ceske Republiky) pouzivat
node(tag(highway,city_limit))? Pri navigaci to ma vyznam (spousta navigacnich
systemu hlasi 50ku) a kdyz nevim jmeno ulice, alespon tam mam znacku, nez to
zjistim. Hranice obci si za jizdy zaznamenavam zminenym tlacitkem.

To je snad pro dnesek vse :-)


PS: Pokud by nekdo mel Q1000 (nebo jinou logujici GPS s MTK32) a chtel by to
provozovat pod Linuxem, napsal jsem si na to appku (Ma i mapping mod -
vyfiltrovani nekvalitnich bodu z logu). Jen jsem ji jeste nemel cas 
publikovat


-- 
Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz