Re: [Talk-cz] Prusanky
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
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&lon=14.683021&z=14&show=0&w=1024&h=768&dp_num=5&d0p0lat=49.994546&d0p0lon=14.683021&d0p1lat=51.458600&d0p1lon=7.013417&d0p2lat=51.450690&d0p2lon=7.012910&d0p3lat=51.458850&d0p3lon=7.007020&d0p4lat=51.458600&d0p4lon=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
http://openaerialmap.org/Main_Page Sent via BlackBerry -Original Message- From: Petr Balíček Date: Tue, 20 Dec 2011 22:12:33 To: Reply-To: OpenStreetMap Czech Republic 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
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
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] UIR - cisla popisne a orientacni
Ondrej Novy napsal(a): > Ahoj, > > On Thu, Nov 27, 2008 at 09:54:27AM +0100, Kubajz wrote: >> Podle obecne uznavanych pravidel se vzdy adresuje cislo popisne, >> popripade evidencni nebo nahradni(to je u takovych tech zvlastnich typu >> budov jako provizornich). Pokud existuji obe, tak je mozne orientacni >> vypustit (nebot budova je urcena jednoznacne) nebo psat zasadne ve tvaru >> POPISNE / ORIENTACNI. Pokud to nekdo napise obracene, tak je to trotl. >> Adresovat pouze orientacni bych taky nedoporucoval - koneckoncu se totiz >> muze stat, ze v jedne ulici nejenze budou stejna s popisnym, ale muzou >> tam byt orientacni i dve stejna (rohove baraky casto patri do vsech ulic >> a mohou tak mit vice orientacnich cisel). >> Cisla orientacni, jak nazev napovida slouzi pro orientaci postaka v >> terenu a s jednoznacnym urcenim budovy nemaji nic spolecneho - postak se >> jukne za lomitko a vi ve ktere casti ulice ma hledat, ale kdyz tam >> dojde, tak se musi podivat, jestli sedi c.p. > > to ovsem potvrzuje to, ze c.p. by melo byt housenumber v OSM a c.o. > alternatenumber. A v tom pripade si priasadim konvenci, dle ktere by housenumber bylo bud cislo popisne, nebo "ev.č. 8", abych konecne mohl zakreslit i svuj dum ;-) -- 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
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] Silniční databanka
Petr Dlouhý napsal(a): > On Thu, 30 Oct 2008 20:41:33 +0100, Jiri Klement <[EMAIL PROTECTED]> > wrote: > > Díky. > Vypadá to, že aktuální databanka začala obsahovat i písmena u některých > silnic. V OSM je ale použit formát 23617a (který je použit i na mapě), > kdežto v databance je to 23617 A. Měli bychom se shodnout, který je lepší > a pak předělat buď ten skript, aby to automaticky změnil, a nebo OSM. Prestoze je to "odchylka od standardu", klonim se k variante bez mezery. -- 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
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
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
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.15321&lon=16.81535&zoom=17&layers=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
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
Martin Kokeš napsal(a): > Petr Nejedly napsal(a): >> 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 >> > > Já jsem se dival v ArcExploreru na ty vodní nádrže a rozhodně nelze > říct, že by tam byly nějaké zbytečné "louže". Proto navrhuju stejně jako > u břehových linií případnou korekci (odstranění zbytečných nodů) nechat > na ručním zpracování. No ja jsem se mezitim mrknul i na A01 (osy vsech toku) a to bylo bratru 5M bodu a vsechno siroko daleko (cela republika) modre. A kdyz jsem se koukal zblizka na horni tok moravy (od pramene po obec Horni Morava, cili asi 8km), bylo tam spousta potucku ;-) -- 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
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] UIR
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=, 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] Možnost využití dat Povodí La be
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://lis
Re: [Talk-cz] Máme půlku silnic!
Petr Dlouhý napsal(a): > On Tue, 14 Oct 2008 11:55:06 +0200, Petr Schonmann <[EMAIL PROTECTED]> wrote: > > Tak pro začátek jsem udělal tohle: > http://wiki.openstreetmap.org/index.php/Image:Czech_roads_chart.svg Asi by to chtelo vyfitrovat (vynechat) ty rozbity dumpy, ta dubnova dira tam vypada fakt divne... > (nevím, proč to ta Wikipedie vykreslila tak kostrbatě, v svg je to OK) Protoze si predrenderuje mensi (640x480) preview (jako PNG) a to teprve, na rozkliknuti, robrazi to skutecne svg. Coz stale neodpovida na otazku, proc je to preview jinak velike, nez na kolik ho to wiki nastavi (800x600) Jo a nez jsem to dopsal, dira zmizela ;-) -- 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
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] Máme půlku silnic!
Petr Dlouhý napsal(a): > On Tue, 14 Oct 2008 11:55:06 +0200, Petr Schonmann <[EMAIL PROTECTED]> wrote: > > Tak pro začátek jsem udělal tohle: > http://wiki.openstreetmap.org/index.php/Image:Czech_roads_chart.svg > (nevím, proč to ta Wikipedie vykreslila tak kostrbatě, v svg je to OK) Protoze preview http://wiki.openstreetmap.org/images/thumb/d/db/Czech_roads_chart.svg/640px-Czech_roads_chart.svg.png je 640x480 a v html ho wiki nastavuje na 800x600 Samotne svg, po rozkliknuti, je OK. -- 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] Značení dálničního sjezdu
hanoj napsal(a): >> 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 > *** Jako svuj referencni mam tento na D1, ale jsou tam (asi) pouzity > relace, takze se popisky nevykresluji korektne > http://www.informationfreeway.org/?lat=49.16544749482366&lon=16.543158638867887&zoom=15&layers=BF000F Ano, je tam relace a moc nedava smysl. Uz jenom proto, ze nema nastaveny typ. Chapu, ze je tam proto, aby rekla, ze vsechny ty "krizovatky" jsou jeden sjezd, ale to se da odvodit z ref. > jeste jeden podobny nedoznaceny je tady na D2: > http://www.informationfreeway.org/?lat=48.96877268798984&lon=16.521143072042083&zoom=16&layers=BF000F > > >> 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.14819&lon=14.22193&zoom=16&layers=B000FTF > *** motorway_exit je tag se Status: Abandoned > http://wiki.openstreetmap.org/index.php/Proposed_features/Motorway_Exit Sorry, samozrejme jsem myslel motorway_link. Slo mi o to, kdyz se silnice jen napojuje, nema plne krizeni. Ale to je vcelku nepodstatny detail... > >> 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. > *** toto je imho spravne reseni na stykovy bod > highway=motorway_junction + ref + name > > rampy a pripojovaci pruhy = motorway_link > komunikace nizsi tridy od mista spolecneho vedeni = primary(napr.) > > snad je to tak ok OK. Leckde je pomoci ref, popr. i name znacen prave ten motorway_link. Mam peclive zapsane vsechny sjezdy z D1, D2 i kus R7, tak to chci obejit a udelat spravne... -- 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
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] OT: Logovani na WM5.0 GPSce
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
[Talk-cz] Značení dálničního sjezdu
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.14819&lon=14.22193&zoom=16&layers=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
Re: [Talk-cz] Vizualizace aktivity v OSM
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] Vizualizace aktivity v OSM
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] Je OSM routovatelna nebo neni?
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?
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.)
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.0724&lon=14.42395&zoom=17&layers=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 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ů
Tomáš Tichý napsal(a): > - Jediné č.p. může mít přiřazeno více č.o. No to bude tím, že č.p. popisuje OBJEKT (dům), zatímco č.o. ADRESU (vchod) ne? (Vsadil bych se, že paneláky budou mít natruc víc č.p.) -- 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ů
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: > > > > > > > > > > > > > > > > > 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] Import skript z uir_adr (fwd)
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ů
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
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] Číslování domů
Pavel Machek napsal(a): > On Wed 2008-08-27 00:03:25, Pavel Machek wrote: >> Ahoj! >> >> 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... >>> Zkuste tohle: ... 19800 je zrovna cerny most, tam X/Y jsou. >>> >>> A ted... ma nekdo jednoduchy navod jak zkonvertovat s-jtsk do wgs84? >> mam ;-). Bohuzel je v pascalu. >> >> V jakym formatu ma byt vystup? Predpokladam ze .osm soubor pro >> josm... kde je we wikine popsany format adresniho bodu / muze mi nekdo >> par adresnich bodu poslat? (Jsem na *hodne* pomaly lince :-(). > > Opravte me... mel by to byt bod s > > place_numbers=$CISDOM_HOD $CISOR_HOD > postal_code=$PSC > is_in=$NAME > > ($NAME je jmeno ulice) > Pavel dle http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers/Karlsruhe_Schema to ma byt (typicky) bod: Jen na to napasovat dvoji cislovani (popisne vs. orientacni) a nezapomenout na $CISOR_PIS Jeste bych pridal protoze se bude _fakt dost_ hodit pro updaty (neb z definice UIR_ADR je ADRESA_KOD v case nemenna a diff nam oznami i zruseni adresy) Naopak davat tam PSC a jmeno obce mi prijde divne, prilis velka redundance. Kdyz na to prijde, tak by se tam daly dodatecne pridat pres uir_adr:ADRESA_KOD :-) -- 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ů
Pavel Machek napsal(a): > Ahoj! > > 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... >> Zkuste tohle: ... 19800 je zrovna cerny most, tam X/Y jsou. Super, aspon ze tak. >> A ted... ma nekdo jednoduchy navod jak zkonvertovat s-jtsk do wgs84? S tim uz si poradim. Po te me peripetii s rozvodimi mi zbyla plne funkcni konverzni rutina v jave. > mam ;-). Bohuzel je v pascalu. > > V jakym formatu ma byt vystup? Predpokladam ze .osm soubor pro > josm... kde je we wikine popsany format adresniho bodu / muze mi nekdo > par adresnich bodu poslat? (Jsem na *hodne* pomaly lince :-(). Chceme to uploadovat en-block opravdu jako cisla domu? (Teda ne ze bych byl proti, ale bude to komicke, mit cisla domu v Horni Dolni a nemit mezi nima tu ulici) Ja jsem si primarne chtel vyrobit pomocnou vrstvu z niz bych mohl opisovat* jmena ulic, kdyz ted mapova prohlizecka UIR_ADR neni na: http://mapy2.oksystem.cz/mapy2/mpsv2.html Nebo je jeste nekde jinde mapova prohlizecka jako byla tam? (viz free_map2osm) *) Aby bylo jasno, jmena ulic jsem nikdy neopisoval z te mapy, ale z rozkliknutych zlutych bodu na ni. -- 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ů
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] Tagovani cesty
Pavel Machek napsal(a): >> No to jsem tam samozrejme dal, ale cekal jsem na nejake eso ve stylu >> horse=leash > > Aha, a kdyz je tam "cyklisto ved kolo" tak se napise bicycle=leash? ;-) > > Uz jsem uvazoval o tagu horse=unsuitable (pro veci jako je tohle, > ruzny cesty posypany sutrakama, a podobne, kde se projit da ale jaksi > to neni ono). Pro me je podstatne co bys tam chtel mit ty. Ja tam na koni nepojedu, ale kdyz tam dam, ze horse=yes a ty tam pricvalas, realne hrozi, ze kone otocis smerem na mistni zastupitelstvo. No a kdyz dam horse=no, zase prozmenu nedojedes na Vochtanku, kde by pro tveho kone meli plny servis a lepsi pristupova prava. http://www.openstreetmap.org/?lat=50.0778&lon=16.31197&zoom=16&layers=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] Tagovani cesty
Pavel Machek napsal(a): > On Mon 2008-08-25 23:15:21, Petr Nejedly wrote: >> Na tohle jsem natrefil v Potstejne: >> http://shell.sh.cvut.cz/~nenik/Pod_Lipami_znacka.jpg >> :-) > > No, za tohle se strili obecni zastupitelstvo, ne? Stejne bys v te kolone mamin s kocarky dost tezko klickoval ;-) >> Ted babo rad, jak to mam otagovat > > highway=residential? No to jsem tam samozrejme dal, ale cekal jsem na nejake eso ve stylu horse=leash Ale mel bych tam asi pridat prinejmensim: motorcycle=destination motorcar=destination -- 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
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] Číslování domů
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
Re: [Talk-cz] Duplikovane lesy
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] import lesů - díry a mýtiny v Mapniku
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 lesu -- nezjednodusili jsme to trochu moc?
BH napsal(a): > Aha ... tak kdyz jsem mrknul na unglueplugin.jar tak jsem tam nasel tohle: > > -- citace -- > > I have taken my business elsewhere as I was told on the mailing lists. > Goodbye and be miserable. Hmm, nemyslim si, ze zrovna na Henryho byl nekdo osklivy. Uz vubec ne ve spojeni s unglue pluginem. Teda pokud si nevzal osobne muj prepis proti josm-ng API (vyrazne jednodussi kod, ale to je probem josm, ne ungluepluginu... > Holt autoupdate ... muzete nekdo nekam hodit funkcni verzi? Google > nachazi akorat tuhle zmrsenou ... http://shell.sh.cvut.cz/~nenik/unglueplugin.jar -- 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?
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.(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] import lesů - díry a mýtiny v Mapniku
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] sdileni nodu
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] Import lesu -- nezjednodusili jsme to trochu moc?
BH napsal(a): > Na druhou stranu, u tech podrobnych dat pokud je napr hranice se > silnici, tak je tam presna, zatimco u zjednodusenych uz ne - a tam, > kde les sdili hranici s necim jinym (silnice, zastavba, rybnik, ...) > obvykle ta nepresnost vadi nejvic. Kdyz uz jsme u toho (a ja to tu uz jednou zminoval, Pavel byl proti), tak ta hranice by dle best practices (viz wiki:ProjectCzechia) skutecne mela byt sloucena. I na Pavlovu vytku, ze se s tim pak v JOSM dost spatne pracuje uz mam odpoved: UngluePlugin. Takze pro les podel silnice zvesela merguju nody -- 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: Re: Fwd: Re: mapové podklad y ČHMÚ
Karel Volný napsal(a): > zdravím, > > přišla mi odpověď, vidím, že CC nebylo zachováno, tak přeposílám ... Teda vy jste mi dali zabrat... Cetl jsem to jen na pul oka, klinu na URL, je tam neco ke stazeni a tyka se to vody. Sup s tim na disk, rozbalit. Aha, shapefile, o tom uz jsem mnohokrat slysel, ale nikdy nepracoval, co by se s tim tak dalo delat? Hmm, format je podle popisu jednoduchy, to naparsuju. Aha, ty souranice jsou v S-JSTK, to si fakt asi budu muset toho Hrdinu nastudovat... Hele, da se to opsat z toho kusu divokeho PHP[1] kodu na netu... Co mi to z toho leze za souradnice? Aha, ono to je v radianech Ale fakt, co mi to z toho leze za souradnice? 66.3 44.1? No to je pakarna... Zkusime prevodnik na hodinach[2], jestli jsem ty vzorce nerozbil. Eee, to samy... Proc jsou vsechny ty cisla v .shp zaporny, vzdyt jsem nekde cetl, ze to Krovak to cely nacpal do jednoho kvadrantu Hmm, kdyz otocim znamenko, stale me to strka nekam do zapadniho Nemecka Jeste ze mam ty hodiny, tam se to snadno zkousi, otocit znamenka, prohodit osy a bod sedi nekde na hranicich s Polskem. Sice to podle dbf ma byt labe a to prameni o 100m dal, ale vypada to slibne... Otevru to v josm-ng, na josm by to bylo velke... COZE!? To je mapa rozvodnic a nee potoku a rek!? A tak mam na disku nadhernou mapu rozvodnic ve formatu OSM Utesuji se tim, ze ta kostra shp parseru, jakoz i transformace S-JSTK -> WGS84 se muze co nevidet hodit... [1] http://au23.troja.mff.cuni.cz/~mira/sh/db_trans.tar.gz [2] http://au23.troja.mff.cuni.cz/~mira/sh/sh.php?type=trans2 -- 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
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] pokusny import lesu
Tomas Kolda napsal(a): > Tuto sekci si tedy zatim beru na starost a po opraveni hrubych chyb pujdu na > dalsi. Vymyslel jste tedy nekdo postup? Mozna by vice lidi ladovalo > rychleji, ale ja bych to delal nejmene mesic (3 hodky denne je pro me asi > maximum). Vice lidi laduje rychleji, uz jenom proto, ze si pro sebe utrhnou vetsi cast (vic kousku) sdileneho zdroje (OSM databaze), ale take proto, ze kazdy ma cas jine 3 hodiny ;-) Beru si za ukol 015 a cpu to tam... -- 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)
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
Tomas Kolda napsal(a): > Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM formatu. > Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? Zrusit > zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? Kazdy by > si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na 23), > vycistit ho a pak uploadnout. No ty cesticky me taky napadly... Vychazi to na cca 2000 zelenych fleku na soubor, to by se dalo rucne zlehka proklepnout ... -- 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
Kubajz napsal(a): > 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... > Onehda jsem se to pokousel zbuildovat a nejak mi to neslo... Hmm, chce to mit pobliz nainstalovane NetBeans a jednou to v nich otevrit. Budu muset ten build script predelat... -- 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
Tomas Kolda napsal(a): >> 3) co je to za format MXF? > > To je muj format, ktery pouzivam. Nekdy by to mela byt navigace... Aktualne > jsem si zaregistroval degu.cz (jako OSMak degu...) Je to v podstate OSM s > prostorovym indexem, R/W moznosti a velmi dobrou komprimaci. Nic > standardniho... > Jak na to tak koukam, stale resime podobne problemy (josm-ng a viewer). Pro ladeni josm-ng pouzivam takovy jednoduchy binarni format (nema index), ktery (bez dalsi komprese) je jen o trochu vetsi nez .osm.bz2 a po gzip kompresi je dokonce mensi, a hlavne, ktery nactu 10x rychleji nez parsovat to XMLko. A je ekvivalentem toho "extended" .osm formatu, cili obsahuje vsechny informace, vcetne action=add, modified flagu a podobne. Opravdu MXF pokryva komplet data z OSM? To by me zajimalo. Ja v soucasne dobe prostorovy index a detail level resim v RAM, ale API DataSetu mam trochu pripravene na to, ze by sam mohl resit index. Checkbox "quality rendering" planuju uz od te doby, co jsem antialiasing natvrdo vypnul ;-) Ted mam rozdelane multistyly - vic malovacich pravidel pro jednu entitu, skladane podle ruznych tagu, jako ze napriklad ulice s tramvaji tam ma ty cary obe, kulatak je malovany podle typu silnice, ale zaroven zelene vyplneny a 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] pokusny import lesu
Pavel Machek napsal(a): > Ahoj! > 2) a co na to JOSM, jaka bude jeho pouzitelnost v nejakem mensi oblasti (napr. okres)? >>> Tak to si nejsem jisty. Pri nacteni vetsi oblasti ma JOSM docela problemy. >>> Kdyby se to dalo v JOSM nejak filtrovat, bylo by to asi lepsi. >> *** Nez to uploadnem, mela by existovat jistota, ze budeme schopni >> efektivne data v CR dale editovat napric platformami. Pokud tato >> jistota (metoda) nebude, tak bych si nehazel klacky pod nohy. Touha >> pracovat s ctvercem o hrane 20km neni az tak neprirozena. > > Vzhledem k tomu ze jsem cely ten import nahral do josm najednou, tak s Opravdu? Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a vysledny dataset zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, pocitac funel a funel a stale nebylo hotovo. Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. BTW: josm-ng nahral vpohode, celou CR vyrendroval za ~300ms a moje lokalni, necommitnuta verze maluje i diry v multipolygonech... -- 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
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
Pavel Machek napsal(a): > Jo... urcite by bylo dobry pridat nejaky znacky... landuse=forest, > source=uhul... a asi i neco k bodum. Waye maji landuse=forest spravne nastavene, source nebo nejaky jiny identifikator tohoto uploadu by nebyl od veci, ale rozhodne bych netagoval nody, je to drahe a zbytecne -- 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
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
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.49457&lon=8.2033&zoom=16&layers=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
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] pokusny import lesu
[EMAIL PROTECTED] napsal(a): > V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po > ctvercich. Je to asi dane tim, ze pak data pouzivam do me "navigace" a > kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky > preprocesing vubec. Kdyz uz tady vsichni odhalujeme svoji agendu :-) tak pro srovnani, nejvetsi polygon v nemecku je les o ~4000 nodech, 30x60km. Neprijde mi to zas tak strasne. A rozhodne bych byl nerad, kdyby se umele rezalo na kusy mensi nez 2-3km. To je zase moje agenda ;-) Pro vysvetleni, pri zobrazovani velkych zoomu v JOSMng filtruju objekty pod 3px (catecne na urovni datovych struktur, zbytek pred renderovanim). A ty 2-3km je tak akorat, aby pohled na celou republiku byl jeste stale zeleny ;-) -- 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í
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] Kniha o GPS/Mapování
Michal Kovar napsal(a): > Ale rec neni o vylepsovani JOSM. Proc ne? Kdyz uz josm-ng, tak aby to bylo pouzitelny. > Rec je o otevrenosti pro jine formaty. Jak, jine formaty? Ve finale je stejne potreba ty data namapovat na OSM model* (body, jejich sekvence, atributy), a pokud puvodni data vychazela z OSM, tak cestou o ty atributy neprijit. *) coz je znacne omezeny vektorovy format. -- 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í
Jachym Cepicky napsal(a): > souhlasim, ze josm je silenej, autori zrejme neslyseli nic o zadnym > GISu, a nebo zadnej nevideli Kdyz uz jsme u toho, co je pro vas, profiky, referencni GIS? Abych mel predstavu, jak by se to melo chovat... -- 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
Tomas Kolda napsal(a): > Takze pre alpha je zde: > > http://www.web2net.cz/osm/dist.zip > > Zatim to neumi nazvy cehokoliv (v databazi jiz jsou), zoom maximalne > 1:10 (ostatni nejsou vygenerovany) a je tam naprosto zakladni > nastaveni barvicek. Nejsou vsechny dle OSM, ale tak jak se to libi mne. > Hlavne highways jsou uplne jinak. Pri nejvetsim zoomu (<1:1) jsou > cervene videt features, ktere nemaji nastaveny vzhled (barvy apod.). Je > tam videt i ta chyba s Berounkou... Vratil bych se k tomuhle. Jak velky dataset zvladnete a jak by byla velka ta databaze pod tim. Germany.osm (7.5M nodes, 1M ways)? Planet.osm (>200M nodes, 20M ways)? Do josm-ng jsem udelal mirnou opravu smerem k moznosti prace s jeste vetsimi datasety - vyclenil jsem z DataSetu implementaci storage a od ni pozaduju zhruba nasledujici API: getNode(long) getWay(long) getRelation(long) getPrimitives(Bounds, DeailLevel) implementaci getPrimitives(Bounds, DetailLevel) zrejme mate (vicevrstvy spatial index), zbytek je vcelku trivialni (pridavny jednorozmerny index). Ja zatim na tuhle datovou strukturu nemam cas :-) tak vse drzim v pameti, coz se pro czechia.osm stale da -- 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
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
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
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.04047&lon=14.40705&zoom=17&layers=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
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
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] import lesu
BH napsal(a): >> 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 > > Takhle podrobna data (t.j. rozdeleni dle typu lesa by vyuzili nejspis > jen lesnici (ti si to ale budou spise tahat rovnou z UHULu) a pak lidi > vyrabejici mapy na orientacni beh - jenze jednak ti si to muzou > stahnout z UHULu sami, jednak stejne musi do lesa aby zmapovali > "kazdicky sutr v lese" :) IMHO pouze ty obalove krivky budou asi > stacit :) > >> Opravdu chceme mit podrobnejsi mapu lesu nez treba silnic? > > Spravnym resenim tohoto "problemu" neni zjednoduseni mapy lesu, ale > zlepseni mapy silnic :) Zajiste. Doplnit silnicni sit osobne povazuju za primarni. RSD export spolu s funkcnim UHUlem je pro dany ucel uzasny nastroj. > 12M OSM primitiv neni zas tolik :) Cela czechia.osm ma zatim stale <1M primitiv... > Samozrejme je otazkou, odkud ty budovy > sehnat ... zatim asi jedina realna moznost je kreslit je rucne podle > UHULu nebo Yahoo. Oslovit katastr? Rucne podle jejich WMS by slo mnohem lepe nez dle UHULu, ale katastr ma ty data urcite i nejak vektorove. Alespon co jsem zanasel svuj dum do katastru, daval jsem jim dost presna data v Krovakovi ;-) > >> Jake jeste datasety obdobne rozsahlosti by se chtely importovat? > > Vodstvo? Silnice 3. tridy? Hranice okresu/kraju/atd? Cyklostezky? > Turisticke trasy? Cokoliv zajimaveho, co kdo vyhrabe s licenci > umoznujici import a ma to rozumnou velikost :) Ulicni sit? Nekdo tu chtel prokladat polygony mezi body z uir_adr a tim generovat hint. Nejaky pokrok? -- 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
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] JOSM-NG
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] Lokalizace JOSM
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
Re: [Talk-cz] Lokalizace JOSM
BikerOnly napsal(a): > A jeste jedna vec, > > jak napojit na posledni bod silnice tak, aby se to nedostalo pod jeden > tag? Cili udelat novou way zacinajici ve vybranem bode: pri kresleni prvniho segmentu podrz alt (viz status bar) > Urcite vite o cem mluvim? Nebo jestli to jde nejak otocit smer sipky? Klavesa "R" (Tools -> reverse way) -- 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
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] tagovani a renderovani
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
[Talk-cz] CUZK - licence
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] Porovnani silnic v OSM a RSD
Kubajz napsal(a): > Tady je trochu problem s pojmenovavanim. Po D5ce vede daleko vice tras, > nez jak by se dala pojmenovat. Mam pocit, ze po ni vedou dve Exx. > Takovych silnic je v CR i mimo CR vicero. > > Ref by tedy mela byt spis relace, ale vzhledem k tomu, ze relace jsou > zatim v plenkach, tak to neni moc aktualni. Co je spatneho na: ref=D5 int_ref=E60,E65 Jak myslite, ze by mela prace s relacema rozumne vypadat z hlediska uzivatele? Myslim, ze relace prinaseji tolik semantiky, ze podchyceni alespon casti z ni bude nutne pro rozumne pouzitelne UI. -- 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
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 > > Jsou tam jak soubory se vsemi silnicemi, tak soubory kde jsou pouze > silnice, ktere chybi v osm. Skoda jen, ze ta silnicni sit nesdili nody. Kdyz se nekde napojuje silnice X na silnici Y, tak na Y sice ve spojeni lezi node, ale silnice X konci svym vlastnim nodem o stejnych souradnicich. Teda nevim, jestli bych to v xslt umel zunifikovat, ale dalo by se to kdyztak prohnat i proceduralnim filtrem - ta transformace neni slozita ne? Ono by se totiz i podle tech primych spojnic krizovatka-krizovatka, kdyz budou spravne propojene, dalo navigovat :-) -- 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
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: -- 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
BH napsal(a): > Tak jsem zkusil not-in-osm/czechia.osm otevrit v OSMProcessoru a > hodilo to tohle: > > Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException > at storage.Storage$1.getHashCode(Storage.java:291) Opraveno (ve zdrojacich v SVN). V generovanych osm datech neni timestamp a parser nepobral ten null. -- 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]
Michal Grézl napsal(a): > ted to zkousim na 1.3ghz masine s 700mb ram, klasickej mappaint v > josmu se tady neda vubec pouzit, zapnu si ho jenom nachvili, kdyz > potrebuju neco najit treba, a to na datech o velikosti okolo 3mb a > tady v tom otevru 90mb fajl bez vetsich problemu a muzu si to cele > prohlizet:) FYI: Zdrojaky jsou v centralnim SVN, takze kdo se chce podivat: http://svn.openstreetmap.org/applications/editors/josm-ng/ Build: $ svn co http://svn.openstreetmap.org/applications/editors/josm-ng $ cd josm-ng $ ant run (Chce to javu 1.5 a ant 1.6.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]
BH napsal(a): > No, s velikosti pisma by si slo jeste asi pohrat (renderovat nazvy > hotelu vetsim pismem nez nazvy stanic metra mi neprijde zrovna > idealni) ... zavisi to na elemstyles.xml, nebo je to nekde natvrdo? Aktualni verze ma: int size = (scale > maxScale/2) ? 7 : (scale > maxScale/4) ? 12 : 24; Cili pouzita velikost fontu zavisi i na stylu, ale samozrejme by to chtelo mit ruzne maximalni velikosti pro ruzne typy objektu, cili podle stylu. Jen jsem chtel pro zacatek pouzit stavajici format stylu. > Jinak vim ze je to testovaci verze, ale hodilo by se kdyby to umelo > brat parametry z commandline (parametr = soubor k nahrani), at nemusim > davat porad file->open a pak ten soubor hledat na disku (kdyby si to > aspon zapamatovalo naposledy pouzity adresar ) To by chtelo. Ostatne, posledni uprava pred poslanim byla JFileChooser pro otevirani, do te doby File->Open rovnou oteviral hardcoded soubor. Ostatne, File->Open GPX to dela porad... > Rozhodne to ale jinak vypada dobre. Jde/pujde nastavovat taky hranice > mizeni nodu eventuelne jejich velikost pro node s tagy/bez tagu? Rozhodne to bude prinejmensim urcovat styl. > (trefovat se v JOSM nepresnou mysi do 3pixelovych mrnousu taky neni > nekdy to pravy orechovy :)) Citliva je kruhova oblast 10px kolem stredu node, tak jake trefovani? OK, resit co vse bude parametrizovatelne je ted velmi predcasne. Ted jde predevsim o validaci architektury. Az budou zdrojaky na osm.org, muzes si ty kosticky udelat jak velky chces ;-) -- 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]
[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\0download>java -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]
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] import UIR-ZSJ a pouzitelnost UIR-ADR (dlouhe)
hanoj napsal(a): > Pokud jsem to dobre pochopil, tak tvoje uprava umi predzpracovat velkou > datovou sadu a nasledne ji pred vykreslovanim efektivne redukovat na > zobrazene okno + odpovidajici detaily meritku. DataSet jako takovy jsem zatim optimalizoval jen na spotrebu pameti. Ale oddelil jsem vizualizacni vrstvu, ktera uz o tech datech neco vi - cachuje promitnute souradnice a platny styl. Rychle filtrovani (selekce) je zatim trivialni jen na subset podle jedne osy (popr. jen tagovane nody), pak se filtruje iterativne do skutecneho vyrezu. To je dulezite pro rychle vykresleni nodu (snadne kresleni, ale obrovsky pocet). To same pro selekci (zkuste si v puvodnim josm s czechia.osm jen vybrat node, trva to 100-300ms na silnem stroji). Redukce vykreslovanych detailu se uz pak deje nazivo pri kresleni cest (tech neni tolik, ale >1px siroke renderovani je dost drahe), a to tak, ze: 1. Cesty pod 1px se nemaluji. 2. transformuje se bbox cesty na obrazovku, pokud je mensi nez 5 pixelu, maluje se jen primy segment mezi zacatkem a koncem (cili pod 5px mizi kulataky) 3. dynamicky se vynechavaji nody, ktere jsou blize nez 5px od minuleho nodu (krom posledniho). Zubata cesta se tim narovna. Pokud je jen klikata, rozdil bude minimalni ;-) 4. pri malem zoomu se snizuje sirka na 1px - rendrovani takovych linek je vyrazne levnejsi Navic veskera matematika kolem malovani a selekce je celociselna. Kubajz napsal(a): > Michal Grézl napsal(a): >> No faktem je, ze ti patlalove, co ted bastli josm, nikdy v zivote >> nevideli vektorovy editor a nejsou schopni udelat ani rozumne >> ovladani, a chtit po nic nejakou zmenu vykreslovaciho jadra je asi >> trosku moc. Asi stejne prejdu na merkaator:) >> >> > Takhle bych to nerekl. Ja si vazim kazde prace na tom editoru. Od > zacatku udelal velky kus prace a neni mozne jim zazlyvat, ze to nedelaji > 100% dobre. V dobe, kdy zacali s vyvojem, tak asi malokdo tusil, na jak > velkych datasetech to pobezi. A pokud nekdo jako Petr do toho vidi a Tak jako tak projekt nekolikrat zmenil "majitele" a riznout do toho radikalne neni uplne jednoduche z duvodu mnozstvi stavajici funkcionality a pluginu. A co se tyce velkych datasetu, uprimne receno mam to stesti, ze je cechy jsou jeste tak malo zmapovane. germany.osm obsahuje 10x tolik dat a vsech jeho 4.5M nodu neudrzim v rozumnem mnozstvi pameti. I na to bych ale nasel v novem modelu odpoved, otazka je jestli je to use case. > optimalizuje to, tak je to super. Patlaly bych je nazval az v pripade, > kdy by odmitli tyto zmeny do trunku. To bych pak mozna pouzil i silnejsi > vyrazivo... Bohuzel nejde o zmeny, ale o cleanroom implementaci. Pred tim nez jsem zacal tenhle experiment tak takovy typ zmeny v datovych strukturach zamitli (nekomu jinemu,a ne prilis stastne udelanou, ja jsem byl v projektu prilis novy na to, abych si mohl dovolit takovou zmenu sam navrhnout, prestoze jsem o jeji nutnosti vedel od zacatku). Mozna je presvedci vysledky, i kdyz velky dataset stejne neni primarni use case. Zatim se ale mail do josm-dev s .jarem zasekl u moderatora :-) Tak jako tak dokazu nektere optimalizace na mappaint aplikovat. Lepsi rozdeleni dat a vizualizace by si pral i owner projeku a poslouchatelnost na modelu bych dokazal vynutit i bez (tolik v JOSM chybejici) encapsulace (diky tomu, ze kolega Bloch ty collections navrhl docela dobre). Ale bez prechodu z ChangeCommand na primy zapis do DataSetu s automatickym vytvarenim UndoableEditu bych jen tezko po vsech certech honil kde ktery Command pohnul s nodem ve ktere ceste a ja musim prepocitat bbox (popr zmenil atributy a ja musim prepocitat styl)... -- 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] Cestina bez diakritiky
Pavel Machek napsal(a): > No, to by nebylo tak tezky, ale kdyz nejak oedituju .osm, jak ho > dostanu zpet na server? No to je desne jednoduchy, udelas to JOSM plugin pro "checked upload" a ten pred kazdym uploadem provede download daneho elementu a porovna to na konflikt. Pokud konflikt bude, oznaci, zbytek proste uploadne. Tim se dostavas na race window radove sekundy, skutecne transakce nejsou, ale stale by slo (s rizikem dalsi race) udelat download, upload, download history, pri detekci vlozene zmeny rollback. Trochu problemem pro takovy masivni upload asi bude posledni dobou tragicka rychlost API. Nevite o nejakem prave probihajicim masivnim importu nebo necem podobnem, co by to tak brzdilo? Vcera jsem kousicek Kladna uploadoval snad pul hodiny -- 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
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] JOSM mirne zrychlen
Jakub Sykora napsal(a): > Jen tak pro zajimavost - jaka je slozitost noveho algoritmu? Tak tedy presneji. Mejme dataset obsahujici N nodu (>500.000 pro czechia.osm) a stehneme neco ze serveru (M nodu, M je typicky mezi 5 a 50 tisici). Slozitost puvodniho algoritmu (pokud zanedbame lokalne vytvorene objekty, kterych bude typicky malo) byla O(MxN), Slozitost meho algoritmu byla O(M) (plus nejaky ten nepovedeny hash, ale id Nodu je dobry zaklad pro hash), predpokladam, ze i oficialni novy algoritmus je O(M), ale prilis jsem ho nezkoumal. > Diky, > > K > > Petr Nejedly wrote: >> Pro czechia.osm muzete zkusit posledni JOSM (r493). >> Vypnete sipky a mappaint. >> U me maluje full view asi 15x rychleji (do seundy) a pri priblizeni >> je vicemene interaktivni (<300ms) >> Mel by mit i zrychleny merge (cizim patchem, i kdyz i toto jsem mel >> pripravene), takze kdyz nad priblizenim czechia.osm date download, >> nemusite chodit uplne na kafe (predtim byl algoritmus O(N^2), >> coz je pro N>50 ponekud tragikomicke). >> > -- 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] UHUL - presnost zamereni
Jak presne je fotomapa UHULu zamerena? I.e. jak daleko muze byt objekt (cesta) na fotce od skutecne polohy? V JOSM, stahovano pri "200m" priblizeni, za pouziti Mercaator projekce, popr. za pouziti EPSG:4326? -- 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] JOSM mirne zrychlen
Pro czechia.osm muzete zkusit posledni JOSM (r493). Vypnete sipky a mappaint. U me maluje full view asi 15x rychleji (do seundy) a pri priblizeni je vicemene interaktivni (<300ms) Mel by mit i zrychleny merge (cizim patchem, i kdyz i toto jsem mel pripravene), takze kdyz nad priblizenim czechia.osm date download, nemusite chodit uplne na kafe (predtim byl algoritmus O(N^2), coz je pro N>50 ponekud tragikomicke). -- 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] Pretagovani uhul.mapy.cz na správn ý tvar
noone02 napsal(a): > Presne tak, zkousel jsem si jak to bude vypadat po vyrendrovani ... > jedno je skola building=yes a druhe jako pozemek skoly ... > Diky moc, nestalo by mozna za zvazeni smaznuti celeho tveho uploadu z > urciteho data ? Urcite musi byt OSM nejak chranena proti vandalismu tzn > by to nejak mohlo jit ... delal jsem tam toho opravdu hodne ... jeste > asi bude docela velkej problem u Chodova ve Vřesové :( OSM je podlozena databazi s historii. Ja vim presne kterych 804 elementu jsem vcera editoval, od nich jsem si (po tom nestastnem uploadu) stahnul historii a manualne overil, ze jsem nic nerozbil. Vsechny elementy, kde mi JOSM spatne rezolvoval konflikt (6 kousku, tedy >1% :-) ) jsem opravil, teda krom #6540880, u te to je slozitejsi. Kdbych umel provest rollback (coz neumim a nevim, jestli to ta databaze nejak rozumne vystrkuje), provedl bych ho a postup upravil na: Otevrit czechia.osm Vybrat vsechny elementy urcene pro upravu Provest update po rozumnych ctvercich obsahujicich vybrane elementy Provest zmenu Provest upload. Stale, OSM databaze nenabizi transakce, takze i tak bych mohl neco malo prace rozbit... -- 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] Vytvoreni CZ mutaci na wiki abych je mohl prelozit
Kubajz napsal(a): > Petr Nejedly napsal(a): >> Hmm, tak way#5347511 uz jsem opravil. >> Merge konfliktu prevzalo i lokalni nodes. >> Zajimave je, ze jsem vychzel z dumpu 12-7-2007, ale ta ztracena zmena byla >> uz z 5.12.2007, viz: >> http://api.openstreetmap.org/api/0.5/way/5347511/history >> >> > Skoda, ze jsi chvili nepockal. Dnesni dump uz je asi hotovej... Jo skoda. To jsem si dal Way#10721948,5006297,5347511 a 8783677 uz jsem taky opravil. #5906917 byla mezitim smazana, tak jsem ji taky smazal Jen #6540880 jsem zatim nezrekonstruoval, nektere nody byly mezitim smazany. U #14463850 byl konflikt zajimavejsi. 4.12. NoOne pridal name/amenity (ZŠ Luby/school), 7.12. ty tagy odmazal a ja je pri zmene zpet nepridal, protoze o tom nic nevim a on jako autor se mohl prve splest. -- 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] Vytvoreni CZ mutaci na wiki abych je mohl prelozit
Petr Nejedly napsal(a): > noone02 napsal(a): >> Prosim nekoho znalejsiho o pretagovani mnou spatne vytvorenych >> source=mapy.uhul.cz na korektni tvar source=UHUL:ortofoto jestli je to >> mozne. > > Tak mi drzte palce at je to OK ;-) Hmm, tak way#5347511 uz jsem opravil. Merge konfliktu prevzalo i lokalni nodes. Zajimave je, ze jsem vychzel z dumpu 12-7-2007, ale ta ztracena zmena byla uz z 5.12.2007, viz: http://api.openstreetmap.org/api/0.5/way/5347511/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
Re: [Talk-cz] Vytvoreni CZ mutaci na wiki abych je mohl prelozit
noone02 napsal(a):
> Prosim nekoho znalejsiho o pretagovani mnou spatne vytvorenych
> source=mapy.uhul.cz na korektni tvar source=UHUL:ortofoto jestli je to
> mozne.
Tak mi drzte palce at je to OK ;-)
Prave jsem upravil vsechny elementy s source=mapy.uhul.cz na
source=UHUL:ortofoto
Vcelku divokym zpusobem, ale zamyslenym tak, aby nic nerozbil.
Postup:
Otevrit posledni snapshot czechia.osm
Vybrat(source:mapy.uhul.cz)
Zoom to selection bylo prilis velke, takze po rozumnych ctvercich: {
Zoom na cast zmen (je to dobre videt pri select(modified))
Download ze serveru
vyresit konflikty (byly jen ruzne popridavane tagy) - z lokalu brat jen
source tag
}
Upload
Cele to bylo asi na 10 minut. Tech 10 minut je take pripadne kolizni okenko,
takze pokud nekdo poslednich ~20 minut modifikoval cokoliv s tagem
source=mapy.uhul.cz),
tak ma zmeny asi prepsane.
Takhle by podle me mel fungovat checked upload, jen s tim, ze by provedl update
pro kazdy jednotlivy element jeste pred uploadem a kolize by vynechaval a
poznamenal.
--
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] UHUL WFS import
[EMAIL PROTECTED] napsal(a): > Ahoj, > prave jsem si nahral a vypada to moc pekne: > http://kubajz.kbx.cz/junk/uhul/output/x603388_x1159320_x593388_x1149320.xml.gz Hmm, kdyz maji dva polygony polecnou hranu (coz je bezny pripad na rozhranni dvou druhu lesa), jsou nody duplikovany (kazdy polygon ma na hrane vlastni nody). Chtelo by to ty nody reusovat. Mimo jine se tim zmensi mnozstvi dat v databazi > > coz pokryva asi 1/6 mesta Brna. > Tento jeden XML ma 7MB, takze po jeho natazeni uz nejde s JOSM rozumne > pracovat, na hloupych 10km ctverecnich. Ani s vypnutym mappaintem a vypnutymi sipkami? Muj upraveny JOSM to nahral bez zakolisani a bez mappaintu zoomuju i panuju v realnem case. Ale pravda, je to stale jen jeden ctverec, ne vsechna data. Snad se pred vanocema dostanu k navrzeni a obhajeni zmen v trunku JOSM. Zatim jsem nedelal nic tak kontroverzniho... (Hehe, az budu chtit maintainerum vysvetlit, ze ta enkapsulace a striktne privatni fieldy maji neco do sebe, to teprve pujde do tuheho...) > Pocitac je to Pent Dual 2,8GHZ/2GB ram + JAVA 1.6win. > > Ted je opet otazka jak dal: > > * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety? JOSM vzdy bude mit sve limity. Do editoru se precijen trochu hure implementuje kvadraturni strom, nez do vieweru. > * generalizujeme data tak, aby slo dale pracovat a tento vystup nechame na > jindy/na jine pouziti mimo hlavni vrstvu JOSM? > * vytvorime tematicke vrstvy v JOSM, tak abych treba si nestahoval/vypnul > zobr. lesu, ci zjednodusil vykreslovani se zoomem? Umi snad OSM jako takove tematicke vrstvy? Pravda, do JOSM by sel dopsat importni filtr, co by to prorezal. -- 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
hanoj napsal(a): > >> *) smazat name=_$ref u naimpotrovanych cest z HELP SERVICE s.r.o. > *** proti tomu nikdo nic nema, nemylim-li se... > >>> * pouzivani "name" u zel. trati a silnic typu "cesta z Klanovic do >>> Cicenic", mi prijde nevypovidajici a v ruznych mapovych interpretaci >>> obtezujici. >> Ok, ale bylo by mozny je prekonvertovat na note= pro snazsi orentaci v >> josm? > *** to je dobre reseni... Dobre, takze zkusim posbirat ty namety v wiki. Pak bych zkusil stvorit plugin do JOSM pro safe upload (pokud neexistuje), ktery by pred uploadem kazdeho elementu (nebo skupiny) provedl download podle ID a merge-rezoluci konfliktu. >>> * ted me napadlo nejak si pohrat s UIR-ADR a prevest stavebni objekty s >>> cislem popisnym/orientacnim (body) na polygony, mohlo by z toho neco >>> zajimaveho vypadnout. Zkusim si s tim pohrat. Jake polygony? Jsou snad v UIR-ADR pudorysy objektu? -- 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] UHUL WFS import
Jakub Sykora napsal(a): > Ahoj, > > To by nemela byt chyba, ale vlastnost. Ty diry by mely jit protismeru > hod. rucicek a obrys jako takovy po smeru, cimz by melo byt zaruceno > korektni renderovani. Myslel jsem, ze "spravne"(tm) se derave polygony tvori pomoci relace multipolygon s inner/outer way. viz relace#3033: a jeji korektni renderovani: http://openstreetmap.org/?lat=50.051056&lon=14.365452&zoom=18&layers=B0F Neco je zmineno tez na: http://wiki.openstreetmap.org/index.php/Relations/Multipolygon -- 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
