Re: [Talk-cz] Možnost využití dat Povodí Labe
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. Jinak sdidelni nazvu pres vsechny cesty by mohlo jit udelat pres pojmenovanou relaci, ne? Nikdy jsem to nedelal, ale mozna se to tak v OSM dela... T Petr Dlouhý napsal(a): On Fri, 24 Oct 2008 07:14:14 +0200, Tomas Kolda [EMAIL PROTECTED] wrote: Automaticky jsem na silnicích nic nespojoval. Používal jsem to při vytváření toho grafu (aby se vymazal bod, pokud je ta silnice někde uprostřed přerušená). Ručně jsem ovšem některé silnice spojoval, protože mi to tak připadá lepší (možá si ale neuvědomuji nějakou zradu). Silnice pocházející z importu jsou toti přerušené v místě neexistující křižovatky, což má za následek, že když si toho někdo nevšimne a udělá křižovatku kousek vedle, tak je pak to přerušení kousek za křižovatkou. Další výhoda je, že pokud je nutné změnit tag, tak to stačí udělat na míň místech, a pokud je nutné mít rozdílný tag pro část té waye, tak to bude pravděpodobně stejně nutné přerušit. Opravdu je to s tím routováním pravda? Vždyť většina silnic není na (všech) křižovatkách přerušená. Jestli ale má spojování nějakou zásadní nevýhodu, tak s tím přestanu. Jaka by mela byt vyhoda spojovani? Vzdyt nechceme polygony a cary o rozmerech nekolika kilometru U silnic to ma navic za nasledek, ze se pak neda routovat. Co jsi spojoval na silnicich? Nebo to detekuje krizovatku o dvou hranach a vice nespojuje? T ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] porovnavani map
2008/10/24 Jachym Cepicky [EMAIL PROTECTED]: A ještě by to chtělo, aby ty mapy měly synchronní pohyb :-D no jestli vis jak to udelat tak porad, jeste sem nezjistil jak udelat nakej ondrag callback:), ja prozatim jen kopiroval examply a generoval api klice. Rozhodne to jeste poupravim. ale jinak zajímavá stránka! j -- Michal Grézl http://walley.org ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] porovnavani map
nevím jak u ostatních api, ale u OpenLayers
map.events.register(zoomend,map,zoomAllMaps);
no a pak už něco jako
function zoomAllMaps(e) {
for (var i = 0; i apis.length; i++) {
apis[i].zoomToExtent(this.getExtent());
}
};
nebo tak nějak podobně
j
Dne 24. říjen 2008 8:07 Michal Grézl [EMAIL PROTECTED] napsal(a):
2008/10/24 Jachym Cepicky [EMAIL PROTECTED]:
A ještě by to chtělo, aby ty mapy měly synchronní pohyb :-D
no jestli vis jak to udelat tak porad, jeste sem nezjistil jak udelat
nakej ondrag callback:), ja prozatim jen kopiroval examply a generoval
api klice. Rozhodne to jeste poupravim.
ale jinak zajímavá stránka!
j
--
Michal Grézl
http://walley.org
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Možnost využití dat Povodí Labe
On Fri, 24 Oct 2008 08:02:20 +0200, Tomas Kolda [EMAIL PROTECTED] wrote: A které routování s tím nefunguje? Zkoušel jsem yournavigation.org (který vychází z gosmore), a nevadí mu to. Tuhle cestu http://www.yournavigation.org/?flat=50.099556flon=14.380929tlat=50.102068tlon=14.374784v=motorcarfast=1layer=mapnik to našlo přestože ty silnice nejsou ani na jedné křižovatce přerušené. 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. Řekl bych, že pro název nebo ref se relace nehodí, tam by šlo spíš použít hledání, ale asi ne každý o tom ví (a nevím, jak je to v Potlachu). Například u cyklostezek, naopak považuji osobně relaci za jedinou správnou, protože kromě jednoduchého opravování tagu na umožňuje (v novém JOSMu) nechat si stáhnout všechny objekty, které v ní jsou. Jinak sdidelni nazvu pres vsechny cesty by mohlo jit udelat pres pojmenovanou relaci, ne? Nikdy jsem to nedelal, ale mozna se to tak v OSM dela... T Petr Dlouhý napsal(a): On Fri, 24 Oct 2008 07:14:14 +0200, Tomas Kolda [EMAIL PROTECTED] wrote: Automaticky jsem na silnicích nic nespojoval. Používal jsem to při vytváření toho grafu (aby se vymazal bod, pokud je ta silnice někde uprostřed přerušená). Ručně jsem ovšem některé silnice spojoval, protože mi to tak připadá lepší (možá si ale neuvědomuji nějakou zradu). Silnice pocházející z importu jsou toti přerušené v místě neexistující křižovatky, což má za následek, že když si toho někdo nevšimne a udělá křižovatku kousek vedle, tak je pak to přerušení kousek za křižovatkou. Další výhoda je, že pokud je nutné změnit tag, tak to stačí udělat na míň místech, a pokud je nutné mít rozdílný tag pro část té waye, tak to bude pravděpodobně stejně nutné přerušit. Opravdu je to s tím routováním pravda? Vždyť většina silnic není na (všech) křižovatkách přerušená. Jestli ale má spojování nějakou zásadní nevýhodu, tak s tím přestanu. Jaka by mela byt vyhoda spojovani? Vzdyt nechceme polygony a cary o rozmerech nekolika kilometru U silnic to ma navic za nasledek, ze se pak neda routovat. Co jsi spojoval na silnicich? Nebo to detekuje krizovatku o dvou hranach a vice nespojuje? T -- Petr Dlouhý ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] porovnavani map
2008/10/24 Jachym Cepicky [EMAIL PROTECTED]: nevím jak u ostatních api, ale u OpenLayers map.events.register(zoomend,map,zoomAllMaps); uz sem to nasel eventy zoomend a moveend, pridam to tam. dik za nakopnuti:) -- Michal Grézl http://walley.org ___ 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
Tomas Kolda napsal(a): Ahoj, takze jsem dodelal import. Dost me zdrzel prevod souradnic, ale melo by to byt ok. Pro zvedave k presnosti posilam vysek databaze v okoli prehrady. Zatim je tam jen waterway a vzdy river, ale nazvy uz tam jsou.Polygony a brehy jeste dodelavam. Podivejte na super prehnanou presnost u nekterych potucku, presne jak jsem rikal. http://www.web2net.cz/osm/dibavod.zip Mohl bys, prosim, zkusit udelat kousek na hornim toku Moravy? Mapoval jsem ho podle ortofoto, ale nakonec jsem to doladil podle katastru, a muj pokusny import DIBAVODu mel stejny tvar krivek, ale byl o par (desitek) metru mimo http://www.openstreetmap.org/?lat=50.15321lon=16.81535zoom=17layers=B000FTF -- Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Možnost využití dat Povodí Lab e
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). 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... 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
Re: [Talk-cz] Možnost využití dat Povodí Lab e
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... Jinak kdyz to dam do JOSMu a pak stahnu okoli, tak ta oblast co jsem posilal sedi skoro presne... T Petr Nejedly napsal(a): Tomas Kolda napsal(a): Ahoj, takze jsem dodelal import. Dost me zdrzel prevod souradnic, ale melo by to byt ok. Pro zvedave k presnosti posilam vysek databaze v okoli prehrady. Zatim je tam jen waterway a vzdy river, ale nazvy uz tam jsou.Polygony a brehy jeste dodelavam. Podivejte na super prehnanou presnost u nekterych potucku, presne jak jsem rikal. http://www.web2net.cz/osm/dibavod.zip Mohl bys, prosim, zkusit udelat kousek na hornim toku Moravy? Mapoval jsem ho podle ortofoto, ale nakonec jsem to doladil podle katastru, a muj pokusny import DIBAVODu mel stejny tvar krivek, ale byl o par (desitek) metru mimo http://www.openstreetmap.org/?lat=50.15321lon=16.81535zoom=17layers=B000FTF ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Možnost využití dat Povodí Labe
Ahoj, On Fri, Oct 24, 2008 at 09:48:37AM +0200, Tomas Kolda wrote: 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). 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... ber to tak, ze z aktualni varianty do tve varianty se to da kdykoliv zkonvertovat 'online' (napr. pri buildovani routovacich dat - tak to dela Garmin - ma ulozeny cary jako spojnice + routovaci graf zvlast, mimo jine proto v Garminu nefunguje aktualne routovani nad OSM :). Obracene to jde hur (nemuzu jen tak spojovat automaticky veci). -- S pozdravem/Best regards Ondrej Novy Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] ICQ: 115-674-713 Tel/Cell: +420 777 963 207 ___ 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í Lab e
Ja to delam presne obracene, pro grafiku spojuji entity se stejnymi atributy a navigacni data beru tak jak jsou. Proste to pro OSM upravim... A stejne tak se to bude muset udelat pro Garmin, jak rikas. A timto bych uzavrel tenhle offtopic :) T Ondrej Novy napsal(a): Ahoj, On Fri, Oct 24, 2008 at 09:48:37AM +0200, Tomas Kolda wrote: 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). 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... ber to tak, ze z aktualni varianty do tve varianty se to da kdykoliv zkonvertovat 'online' (napr. pri buildovani routovacich dat - tak to dela Garmin - ma ulozeny cary jako spojnice + routovaci graf zvlast, mimo jine proto v Garminu nefunguje aktualne routovani nad OSM :). Obracene to jde hur (nemuzu jen tak spojovat automaticky veci). ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Možnost využití dat Povodí Labe
Já bych ho změnil spátky na intopic tím, že bych zopakoval požadavek na spojení těch řek na úseky o nějaké rozumné délce (například po 30Km). Myslím, že se s tím pak bude líp pracovat a zmenší se tím velikost výsledného souboru. Původní zpráva Od: Tomas Kolda [EMAIL PROTECTED] Předmět: Re: [Talk-cz] Možnost využití dat Povodí Labe Datum: 24.10.2008 10:10:10 Ja to delam presne obracene, pro grafiku spojuji entity se stejnymi atributy a navigacni data beru tak jak jsou. Proste to pro OSM upravim... A stejne tak se to bude muset udelat pro Garmin, jak rikas. A timto bych uzavrel tenhle offtopic :) T Ondrej Novy napsal(a): Petr Dlouhý [EMAIL PROTECTED] ___ 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í Labe
Tyto data jsou dabavod, coz neni povodi Labe. Melo by se to nejak ridit asi tim zakonem, jak bylo zminovano v tomto threadu. T Martin Vidner napsal(a): Petr Nejedly uz psal, ale asi to zapadlo: 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 http://www.pla.cz/planet/ram.aspx?id=21 2008/10/24 Tomas Kolda [EMAIL PROTECTED]: PS: Jeste poprosim nekoho komu neprijdou zakony dost sifrovane at nezavisle potvrdi tu moznost pouziti. Ja se v pravni hantyrce neorientuji... Jen abysme to pak cele nemuseli revertovat. ___ 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] Možnost využití dat Povodí Labe
Petr Nejedly uz psal, ale asi to zapadlo: 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 http://www.pla.cz/planet/ram.aspx?id=21 2008/10/24 Tomas Kolda [EMAIL PROTECTED]: PS: Jeste poprosim nekoho komu neprijdou zakony dost sifrovane at nezavisle potvrdi tu moznost pouziti. Ja se v pravni hantyrce neorientuji... Jen abysme to pak cele nemuseli revertovat. ___ 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
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. Pak je to nedostatecne routovani. Nebudeme prece sekat hlavni tridu na malinkate kousky kvuli kazde odbocce. Pro nektere aplikace (napr. mapnik) je zase naopak lepsi mit silnice v rozumne mire co nejvice spojene, protoze ty na kazdy usek cpou extra jmeno. Nekteri lidi to rozsekavaji, nekteri to zase spojiji (osobne spojuji useky silnic druhe tridy tak, aby byly rozseknuty jen krizovatkami s druhou tridou, jinak by bylo fura mrnavych useku) IMHO nedostatecny algoritmus u navigace a ne neco co by se melo opravovat v OSM. V nejhorsim se to da rozsekat takhle automaticky a predradit jako predzpracovani pri generovani pro takovehle chybne navigace a rozhodne bych to nedelal rucne v OSM. Jinak sdidelni nazvu pres vsechny cesty by mohlo jit udelat pres pojmenovanou relaci, ne? Nikdy jsem to nedelal, ale mozna se to tak v OSM dela... Nic takovyho jsem v OSM nevidel. V praxi clovek musi pojmenovat vsechny kousky. Martin ___ 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
2008/10/24 Petr Dlouhý [EMAIL PROTECTED]: Já bych ho změnil spátky na intopic tím, že bych zopakoval požadavek na spojení těch řek na úseky o nějaké rozumné délce (například po 30Km). Myslím, že se s tím pak bude líp pracovat a zmenší se tím velikost výsledného souboru. Kolik bude tech 30 km zhruba bodu? Drzel bych se maxima tak kolem 500-1500 bodu na usek (at to je km kolik chce :), kdyz je toho vic a clovek chce opravit kratky usek reky, tak jednak to dlouho stahuje a po oprave uploaduje, jednak je vyssi riziko konfliktu kdyz dva lidi opravujou tu samou reku na jinych mistech. Martin ___ 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
BH píše v Pá 24. 10. 2008 v 14:41 +0200: Jinak sdidelni nazvu pres vsechny cesty by mohlo jit udelat pres pojmenovanou relaci, ne? Nikdy jsem to nedelal, ale mozna se to tak v OSM dela... Nic takovyho jsem v OSM nevidel. V praxi clovek musi pojmenovat vsechny kousky. Je to proposed feature. Ještě jsem nezkoušel, zda to mapnik a osmarender umí. http://wiki.openstreetmap.org/index.php/Relations/Proposed/Collected_Ways nebo obrácený přístup http://wiki.openstreetmap.org/index.php/Relations/Proposed/Segmented_Tag a zčásti podobný http://wiki.openstreetmap.org/index.php/Relations/Proposed/Composite_Tag -- Stanislav Brabec http://www.penguin.cz/~utx ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
