nazdar, doba je zla, je krize, nejsou prachy, meni se licence a k tomu vsemu api verze 0.6. podle popisu bude mit jednu srandovni vlastnost, tou je limit 2000 bodu na way (http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6#New_Limits).Nase lesy tento limit hrave prekracuji. Nasledek bude mozna nemoznost editace lesnich polygonu po prechodu na 0.6. Resenim je rozkouskovat lesy na casti mensi nez 2000 nodu, napriklad podel silnic, nebo umele nekde uprostred tak aby to nebylo videt.
nazdar, doba je zla, je krize, nejsou prachy, meni se licence a k tomu vsemu api verze 0.6. podle popisu bude mit jednu srandovni vlastnost, tou je limit 2000 bodu na way (http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6#New_Limits). Nase lesy tento limit hrave prekracuji. Nasledek bude mozna nemoznost editace lesnich polygonu po prechodu na 0.6. Resenim je rozkouskovat lesy na casti mensi nez 2000 nodu, napriklad podel silnic, nebo umele nekde uprostred tak aby to nebylo videt.
Resenim je rozkouskovat lesy na casti mensi nez 2000 nodu, napriklad podel silnic, nebo umele nekde uprostred tak aby to nebylo videt.
Resenim je rozkouskovat lesy na casti mensi nez 2000 nodu, napriklad podel silnic, nebo umele nekde uprostred tak aby to nebylo videt.
Resenim je rozkouskovat lesy na casti mensi nez 2000 nodu, napriklad podel silnic, nebo umele nekde uprostred tak aby to nebylo videt.Nesmysl, stačí tu hranici lesa rozkouskovat na neuzavřené cesty a spojit je multipolygon relací. Umělé spojnice uzavírající polygon uprostřed lesa nedělejte!!! Tady je ukázka jak na to: http://www.openstreetmap.org/browse/relation/24849
Resenim je rozkouskovat lesy na casti mensi nez 2000 nodu, napriklad podel silnic, nebo umele nekde uprostred tak aby to nebylo videt.Nesmysl, stačí tu hranici lesa rozkouskovat na neuzavřené cesty a spojit je multipolygon relací. Umělé spojnice uzavírající polygon uprostřed lesa nedělejte!!! Tady je ukázka jak na to: http://www.openstreetmap.org/browse/relation/24849
Upozorňuji, že podobný limit se bude týkat počtu členů relace.
Nesmysl, stačí tu hranici lesa rozkouskovat na neuzavřené cesty a spojit je multipolygon relací. Umělé spojnice uzavírající polygon uprostřed lesa nedělejte!!! Tady je ukázka jak na to: http://www.openstreetmap.org/browse/relation/24849
Asi je to nejjednodussi reseni, nicmene male lesy sou lepsi nez velke. Umele je tristit je blbost, to je fakt. Nicmene neco se udelat musi.
Upozorňuji, že podobný limit se bude týkat počtu členů relace.
Nesmysl, stačí tu hranici lesa rozkouskovat na neuzavřené cesty a spojit je multipolygon relací. Umělé spojnice uzavírající polygon uprostřed lesa nedělejte!!! Tady je ukázka jak na to: http://www.openstreetmap.org/browse/relation/24849
Asi je to nejjednodussi reseni, nicmene male lesy sou lepsi nez velke. Umele je tristit je blbost, to je fakt. Nicmene neco se udelat musi.
Upozorňuji, že podobný limit se bude týkat počtu členů relace.
Dne čt 5. března 2009 Michal Grézl napsal(a):nazdar, doba je zla, je krize, nejsou prachy, meni se licence a k tomu vsemu api verze 0.6. podle popisu bude mit jednu srandovni vlastnost, tou je limit 2000 bodu na way (http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6#New_Limits). Nase lesy tento limit hrave prekracuji. Nasledek bude mozna nemoznost editace lesnich polygonu po prechodu na 0.6. Resenim je rozkouskovat lesy na casti mensi nez 2000 nodu, napriklad podel silnic, nebo umele nekde uprostred tak aby to nebylo videt.ok, tohle mě tedy silně nahlodává podpořit variantu forknutí ... K. _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
To jsou ale preci dve uplne odlisne veci - licence a API 0.6.
Limit 2000 bodu je IMO spravny,
ale nemel by se vztahovat na jiz nahrana data a jejich editaci a pripadne hromadne importy - mel by spis byt zabudovan v editorech nez primo v importnim skriptu. Delat fork OSM kuvli takoveto hovadine je uz uplne mimo, protoze za cvhili bychom nemeli ani cim editovat... K
To jsou ale preci dve uplne odlisne veci - licence a API 0.6.
Limit 2000 bodu je IMO spravny,
ale nemel by se vztahovat na jiz nahrana data a jejich editaci a pripadne hromadne importy - mel by spis byt zabudovan v editorech nez primo v importnim skriptu. Delat fork OSM kuvli takoveto hovadine je uz uplne mimo, protoze za cvhili bychom nemeli ani cim editovat... K
Karel Volný napsal(a):Dne čt 5. března 2009 Michal Grézl napsal(a):nazdar, doba je zla, je krize, nejsou prachy, meni se licence a k tomu vsemu api verze 0.6. podle popisu bude mit jednu srandovni vlastnost, tou je limit 2000 bodu na way (http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6#New_Limits) . Nase lesy tento limit hrave prekracuji. Nasledek bude mozna nemoznost editace lesnich polygonu po prechodu na 0.6. Resenim je rozkouskovat lesy na casti mensi nez 2000 nodu, napriklad podel silnic, nebo umele nekde uprostred tak aby to nebylo videt.ok, tohle mě tedy silně nahlodává podpořit variantu forknutí ... K.
To jsou ale preci dve uplne odlisne veci - licence a API 0.6.to záleží na úhlu pohledu ... díváš-li se na to čistě technicky, ano, ale v širším kontextu to souvisí: začnou-li vývojáři dělat změny, které se lidem jeví jako problematické, může to značit ztrátu kontaktu s realitou
Limit 2000 bodu je IMO spravny,nechápu proč; když jsem koukal na wiki, zdůvodněn nebyl ... přijde mi zvrhlé, když je někde nějaká dlouhá linie, tak ji dělit a vymýšlet nad tím relaci, která to zase spojí, jen protože se od zeleného stolu stanovil nějaký limit
To jsou ale preci dve uplne odlisne veci - licence a API 0.6.to záleží na úhlu pohledu ... díváš-li se na to čistě technicky, ano, ale v širším kontextu to souvisí: začnou-li vývojáři dělat změny, které se lidem jeví jako problematické, může to značit ztrátu kontaktu s realitou
Limit 2000 bodu je IMO spravny,nechápu proč; když jsem koukal na wiki, zdůvodněn nebyl ... přijde mi zvrhlé, když je někde nějaká dlouhá linie, tak ji dělit a vymýšlet nad tím relaci, která to zase spojí, jen protože se od zeleného stolu stanovil nějaký limit
To jsou ale preci dve uplne odlisne veci - licence a API 0.6.to záleží na úhlu pohledu ... díváš-li se na to čistě technicky, ano, ale v širším kontextu to souvisí: začnou-li vývojáři dělat změny, které se lidem jeví jako problematické, může to značit ztrátu kontaktu s realitou*** Mne se jevi vyvoj OSM (a historie API tomu nasvedcuje) hodne prekotny, navic postaveny na zelene louce. OSM bude nyni i __napriste__ takove zmeny podstupovat, protoze nikdo napocatku asi netusil k cemu (mnozstvi, zaber, cil) to povede a to co tusil nemusel vhodne odhadnout. Tim nechci rici, ze lide, podstata celeho projektu, meli sejit ze zretele. Zmeny budou nutne, podivejte se na projekt http://www.poi.cz/, ten jak licencne, technologicky zakrnel, ma pramale moznosti rozvoje.
Limit 2000 bodu je IMO spravny,nechápu proč; když jsem koukal na wiki, zdůvodněn nebyl ... přijde mi zvrhlé, když je někde nějaká dlouhá linie, tak ji dělit a vymýšlet nad tím relaci, která to zase spojí, jen protože se od zeleného stolu stanovil nějaký limit*** aniz bych videl do hloubky pricin a duvod nastavene hranice, jiste se pracuje lepe s homogennim datasetem o velikosti 1-x nodu, (vykreslovani, stazeni bbox). Bezne se tak i v komercnich datasetech pracuje (pokud to topologie umoznuje), neni to nic zvrhleho. Nestastna je mozna implementace OSM relaci.
To jsou ale preci dve uplne odlisne veci - licence a API 0.6.to záleží na úhlu pohledu ... díváš-li se na to čistě technicky, ano, ale v širším kontextu to souvisí: začnou-li vývojáři dělat změny, které se lidem jeví jako problematické, může to značit ztrátu kontaktu s realitou*** Mne se jevi vyvoj OSM (a historie API tomu nasvedcuje) hodne prekotny, navic postaveny na zelene louce. OSM bude nyni i __napriste__ takove zmeny podstupovat, protoze nikdo napocatku asi netusil k cemu (mnozstvi, zaber, cil) to povede a to co tusil nemusel vhodne odhadnout. Tim nechci rici, ze lide, podstata celeho projektu, meli sejit ze zretele. Zmeny budou nutne, podivejte se na projekt http://www.poi.cz/, ten jak licencne, technologicky zakrnel, ma pramale moznosti rozvoje.
Limit 2000 bodu je IMO spravny,nechápu proč; když jsem koukal na wiki, zdůvodněn nebyl ... přijde mi zvrhlé, když je někde nějaká dlouhá linie, tak ji dělit a vymýšlet nad tím relaci, která to zase spojí, jen protože se od zeleného stolu stanovil nějaký limit*** aniz bych videl do hloubky pricin a duvod nastavene hranice, jiste se pracuje lepe s homogennim datasetem o velikosti 1-x nodu, (vykreslovani, stazeni bbox). Bezne se tak i v komercnich datasetech pracuje (pokud to topologie umoznuje), neni to nic zvrhleho. Nestastna je mozna implementace OSM relaci.
to záleží na úhlu pohledu ... díváš-li se na to čistě technicky, ano, ale v širším kontextu to souvisí: začnou-li vývojáři dělat změny, které se lidem jeví jako problematické, může to značit ztrátu kontaktu s realitouLimit 2000 bodu je IMO spravny,
to záleží na úhlu pohledu ... díváš-li se na to čistě technicky, ano, ale v širším kontextu to souvisí: začnou-li vývojáři dělat změny, které se lidem jeví jako problematické, může to značit ztrátu kontaktu s realitouLimit 2000 bodu je IMO spravny,
to záleží na úhlu pohledu ... díváš-li se na to čistě technicky, ano, ale v širším kontextu to souvisí: začnou-li vývojáři dělat změny, které se lidem jeví jako problematické, může to značit ztrátu kontaktu s realitouLimit 2000 bodu je IMO spravny,Je to "umely" limit, ktery by tam byt mozna nemusel, ale je tam kvuli vykonu serveru a zatezi databaze. Pokazde, kdyz nekdo v takhle dlouhe ceste zmeni maly kus, nebo nejak opravi tagy, tak se nahrava cela cesta znovu na server (ano, tady by slo vylepsit API o moznost nahrani jenom tagu s tim, ze "nody se ponechaj"). No a pokud si nekdo u takhle dlouhe way, ktera se mnohokrat v minulosti upravovala vyrada historii, tak by dostal XML o mnoha desitkach MB (teoreticky, ale pry ho driv utne nejaky limit nebo timeout). Cili pokud se tyhle problemy nejak vyresi, tak by se ten limit mohl v budoucnu zvysit nebo mozna i zrusit. Martin _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Me osobne se ten limit libi prave z tohoto duvodu. Na sumave, kdyz posunu v hranici lesa, tak zbytecne odesilam nekolik MB dat a trva to dost dlouho. Nebo je uzasne, kdyz si stahnu vesnici a stahne se mi k tomu cele Labe. Nez zjistim, kde je ta vesnice, co jsem vlastne chtel...
Limit je to mozna umely, ale na druhou stranu i chrani OSM pred primitivnim DoS utokem - je zajimave, ze dosud nikoho nenapadlo zkusit nahrat nekonecne dlouhou cestu do OSM. K
Me osobne se ten limit libi prave z tohoto duvodu. Na sumave, kdyz posunu v hranici lesa, tak zbytecne odesilam nekolik MB dat a trva to dost dlouho. Nebo je uzasne, kdyz si stahnu vesnici a stahne se mi k tomu cele Labe. Nez zjistim, kde je ta vesnice, co jsem vlastne chtel...
Limit je to mozna umely, ale na druhou stranu i chrani OSM pred primitivnim DoS utokem - je zajimave, ze dosud nikoho nenapadlo zkusit nahrat nekonecne dlouhou cestu do OSM. K
MP napsal(a):to záleží na úhlu pohledu ... díváš-li se na to čistě technicky, ano, ale v širším kontextu to souvisí: začnou-li vývojáři dělat změny, které se lidem jeví jako problematické, může to značit ztrátu kontaktu s realitouLimit 2000 bodu je IMO spravny,Je to "umely" limit, ktery by tam byt mozna nemusel, ale je tam kvuli vykonu serveru a zatezi databaze. Pokazde, kdyz nekdo v takhle dlouhe ceste zmeni maly kus, nebo nejak opravi tagy, tak se nahrava cela cesta znovu na server (ano, tady by slo vylepsit API o moznost nahrani jenom tagu s tim, ze "nody se ponechaj"). No a pokud si nekdo u takhle dlouhe way, ktera se mnohokrat v minulosti upravovala vyrada historii, tak by dostal XML o mnoha desitkach MB (teoreticky, ale pry ho driv utne nejaky limit nebo timeout). Cili pokud se tyhle problemy nejak vyresi, tak by se ten limit mohl v budoucnu zvysit nebo mozna i zrusit. Martin
Me osobne se ten limit libi prave z tohoto duvodu. Na sumave, kdyz posunu v hranici lesa, tak zbytecne odesilam nekolik MB dat a trva to dost dlouho. Nebo je uzasne, kdyz si stahnu vesnici a stahne se mi k tomu cele Labe. Nez zjistim, kde je ta vesnice, co jsem vlastne chtel...uff, takže místo toho, aby se to pořádně vyřešilo (viz níže, možnost komunikovat pouze změny, nikoliv všechna data), budeme raději tleskat hloupému workaroundu?
Me osobne se ten limit libi prave z tohoto duvodu. Na sumave, kdyz posunu v hranici lesa, tak zbytecne odesilam nekolik MB dat a trva to dost dlouho. Nebo je uzasne, kdyz si stahnu vesnici a stahne se mi k tomu cele Labe. Nez zjistim, kde je ta vesnice, co jsem vlastne chtel...uff, takže místo toho, aby se to pořádně vyřešilo (viz níže, možnost komunikovat pouze změny, nikoliv všechna data), budeme raději tleskat hloupému workaroundu?
Me osobne se ten limit libi prave z tohoto duvodu. Na sumave, kdyz posunu v hranici lesa, tak zbytecne odesilam nekolik MB dat a trva to dost dlouho. Nebo je uzasne, kdyz si stahnu vesnici a stahne se mi k tomu cele Labe. Nez zjistim, kde je ta vesnice, co jsem vlastne chtel...uff, takže místo toho, aby se to pořádně vyřešilo (viz níže, možnost komunikovat pouze změny, nikoliv všechna data), budeme raději tleskat hloupému workaroundu?
Me osobne se ten limit libi prave z tohoto duvodu. Na sumave, kdyz posunu v hranici lesa, tak zbytecne odesilam nekolik MB dat a trva to dost dlouho. Nebo je uzasne, kdyz si stahnu vesnici a stahne se mi k tomu cele Labe. Nez zjistim, kde je ta vesnice, co jsem vlastne chtel...uff, takže místo toho, aby se to pořádně vyřešilo (viz níže, možnost komunikovat pouze změny, nikoliv všechna data), budeme raději tleskat hloupému workaroundu?
2009/3/11 Karel Volný <kavol na seznam.cz>:Me osobne se ten limit libi prave z tohoto duvodu. Na sumave, kdyz posunu v hranici lesa, tak zbytecne odesilam nekolik MB dat a trva to dost dlouho. Nebo je uzasne, kdyz si stahnu vesnici a stahne se mi k tomu cele Labe. Nez zjistim, kde je ta vesnice, co jsem vlastne chtel...uff, takže místo toho, aby se to pořádně vyřešilo (viz níže, možnost komunikovat pouze změny, nikoliv všechna data), budeme raději tleskat hloupému workaroundu?A co "DoS" na uživatele? Není nad to, když se při editaci jedné hospody stáhne tisíc kilometrů čtverečních lesa. Nebo když hledáte nějakého člena relace v pěti tisících položkách. A zkuste si někdy používat něco takového třeba na GPRS připojení. Eventuelní řešení stahovat pouze část cesty/relace považuji za potenciálně velmi nebezpečné.
Vylepšit datový model tak, aby byl pro člověka lépe uchopitelný nepovažuji za "hloupý workaround". Dlouhé cesty elegantně řeší relace. Rozsáhlé relace elegantně řeší relace relací. Doufejme, že se zavedením limitů bude větší motivace k vylepšení podpory relací v OSM nástrojích. =TT=
2009/3/11 Karel Volný <kavol na seznam.cz>:Me osobne se ten limit libi prave z tohoto duvodu. Na sumave, kdyz posunu v hranici lesa, tak zbytecne odesilam nekolik MB dat a trva to dost dlouho. Nebo je uzasne, kdyz si stahnu vesnici a stahne se mi k tomu cele Labe. Nez zjistim, kde je ta vesnice, co jsem vlastne chtel...uff, takže místo toho, aby se to pořádně vyřešilo (viz níže, možnost komunikovat pouze změny, nikoliv všechna data), budeme raději tleskat hloupému workaroundu?A co "DoS" na uživatele? Není nad to, když se při editaci jedné hospody stáhne tisíc kilometrů čtverečních lesa. Nebo když hledáte nějakého člena relace v pěti tisících položkách. A zkuste si někdy používat něco takového třeba na GPRS připojení. Eventuelní řešení stahovat pouze část cesty/relace považuji za potenciálně velmi nebezpečné.
Vylepšit datový model tak, aby byl pro člověka lépe uchopitelný nepovažuji za "hloupý workaround". Dlouhé cesty elegantně řeší relace. Rozsáhlé relace elegantně řeší relace relací. Doufejme, že se zavedením limitů bude větší motivace k vylepšení podpory relací v OSM nástrojích. =TT=
2009/3/11 Karel Volný <kavol na seznam.cz>:Me osobne se ten limit libi prave z tohoto duvodu. Na sumave, kdyz posunu v hranici lesa, tak zbytecne odesilam nekolik MB dat a trva to dost dlouho. Nebo je uzasne, kdyz si stahnu vesnici a stahne se mi k tomu cele Labe. Nez zjistim, kde je ta vesnice, co jsem vlastne chtel...uff, takže místo toho, aby se to pořádně vyřešilo (viz níže, možnost komunikovat pouze změny, nikoliv všechna data), budeme raději tleskat hloupému workaroundu?A co "DoS" na uživatele? Není nad to, když se při editaci jedné hospody stáhne tisíc kilometrů čtverečních lesa. Nebo když hledáte nějakého člena relace v pěti tisících položkách. A zkuste si někdy používat něco takového třeba na GPRS připojení. Eventuelní řešení stahovat pouze část cesty/relace považuji za potenciálně velmi nebezpečné.huh, to nechápu ... když je nebezpečné stáhnout pouze část relace, tak jak si pomůžu, když budu stahovat relaci o 2*2000 bodů místo jedné linie o 4000 bodech?Vylepšit datový model tak, aby byl pro člověka lépe uchopitelný nepovažuji za "hloupý workaround". Dlouhé cesty elegantně řeší relace. Rozsáhlé relace elegantně řeší relace relací. Doufejme, že se zavedením limitů bude větší motivace k vylepšení podpory relací v OSM nástrojích. =TT=a relace relací relací a relace relací relací relací ... - no jistě, těch 640 KB taky elegantně řešil DOS4/GW a další, že ... já nevím, nemotám se kolem projektu dlouho, a furt mi něco nefunguje, takže do toho až tak nehrabu, tož mi dík nezkušenosti asi něco uchází, ale ... tak nějak jsem myslel, že relace byly míněny jako způsob, jak z fyzických objektů zkonstruovat nějaké logické celky, nikoliv proto, aby se nějaký fyzický objekt mohl nakrájet jako salám, a pak silou vůle, eh, tedy relace, zase slepil dohromady a řeklo se, že to má být jako celá štangle salámu a ty řezy mezi kolečky jako nevidíme
Dne st 11. března 2009 Tomáš Tichý napsal(a):2009/3/11 Karel Volný <kavol na seznam.cz>:Me osobne se ten limit libi prave z tohoto duvodu. Na sumave, kdyz posunu v hranici lesa, tak zbytecne odesilam nekolik MB dat a trva to dost dlouho. Nebo je uzasne, kdyz si stahnu vesnici a stahne se mi k tomu cele Labe. Nez zjistim, kde je ta vesnice, co jsem vlastne chtel...uff, takže místo toho, aby se to pořádně vyřešilo (viz níže, možnost komunikovat pouze změny, nikoliv všechna data), budeme raději tleskat hloupému workaroundu?A co "DoS" na uživatele? Není nad to, když se při editaci jedné hospody stáhne tisíc kilometrů čtverečních lesa. Nebo když hledáte nějakého člena relace v pěti tisících položkách. A zkuste si někdy používat něco takového třeba na GPRS připojení. Eventuelní řešení stahovat pouze část cesty/relace považuji za potenciálně velmi nebezpečné.huh, to nechápu ... když je nebezpečné stáhnout pouze část relace, tak jak si pomůžu, když budu stahovat relaci o 2*2000 bodů místo jedné linie o 4000 bodech?Vylepšit datový model tak, aby byl pro člověka lépe uchopitelný nepovažuji za "hloupý workaround". Dlouhé cesty elegantně řeší relace. Rozsáhlé relace elegantně řeší relace relací. Doufejme, že se zavedením limitů bude větší motivace k vylepšení podpory relací v OSM nástrojích. =TT=a relace relací relací a relace relací relací relací ... - no jistě, těch 640 KB taky elegantně řešil DOS4/GW a další, že ... já nevím, nemotám se kolem projektu dlouho, a furt mi něco nefunguje, takže do toho až tak nehrabu, tož mi dík nezkušenosti asi něco uchází, ale ... tak nějak jsem myslel, že relace byly míněny jako způsob, jak z fyzických objektů zkonstruovat nějaké logické celky, nikoliv proto, aby se nějaký fyzický objekt mohl nakrájet jako salám, a pak silou vůle, eh, tedy relace, zase slepil dohromady a řeklo se, že to má být jako celá štangle salámu a ty řezy mezi kolečky jako nevidíme
Dne st 11. března 2009 Tomáš Tichý napsal(a):2009/3/11 Karel Volný <kavol na seznam.cz>:Me osobne se ten limit libi prave z tohoto duvodu. Na sumave, kdyz posunu v hranici lesa, tak zbytecne odesilam nekolik MB dat a trva to dost dlouho. Nebo je uzasne, kdyz si stahnu vesnici a stahne se mi k tomu cele Labe. Nez zjistim, kde je ta vesnice, co jsem vlastne chtel...uff, takže místo toho, aby se to pořádně vyřešilo (viz níže, možnost komunikovat pouze změny, nikoliv všechna data), budeme raději tleskat hloupému workaroundu?A co "DoS" na uživatele? Není nad to, když se při editaci jedné hospody stáhne tisíc kilometrů čtverečních lesa. Nebo když hledáte nějakého člena relace v pěti tisících položkách. A zkuste si někdy používat něco takového třeba na GPRS připojení. Eventuelní řešení stahovat pouze část cesty/relace považuji za potenciálně velmi nebezpečné.huh, to nechápu ... když je nebezpečné stáhnout pouze část relace, tak jak si pomůžu, když budu stahovat relaci o 2*2000 bodů místo jedné linie o 4000 bodech?Vylepšit datový model tak, aby byl pro člověka lépe uchopitelný nepovažuji za "hloupý workaround". Dlouhé cesty elegantně řeší relace. Rozsáhlé relace elegantně řeší relace relací. Doufejme, že se zavedením limitů bude větší motivace k vylepšení podpory relací v OSM nástrojích. =TT=a relace relací relací a relace relací relací relací ... - no jistě, těch 640 KB taky elegantně řešil DOS4/GW a další, že ... já nevím, nemotám se kolem projektu dlouho, a furt mi něco nefunguje, takže do toho až tak nehrabu, tož mi dík nezkušenosti asi něco uchází, ale ... tak nějak jsem myslel, že relace byly míněny jako způsob, jak z fyzických objektů zkonstruovat nějaké logické celky, nikoliv proto, aby se nějaký fyzický objekt mohl nakrájet jako salám, a pak silou vůle, eh, tedy relace, zase slepil dohromady a řeklo se, že to má být jako celá štangle salámu a ty řezy mezi kolečky jako nevidíme K. _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
2009/3/11 Karel Volný <kavol na seznam.cz>:Dne st 11. března 2009 Tomáš Tichý napsal(a):2009/3/11 Karel Volný <kavol na seznam.cz>:Me osobne se ten limit libi prave z tohoto duvodu. Na sumave, kdyz posunu v hranici lesa, tak zbytecne odesilam nekolik MB dat a trva to dost dlouho. Nebo je uzasne, kdyz si stahnu vesnici a stahne se mi k tomu cele Labe. Nez zjistim, kde je ta vesnice, co jsem vlastne chtel...uff, takže místo toho, aby se to pořádně vyřešilo (viz níže, možnost komunikovat pouze změny, nikoliv všechna data), budeme raději tleskat hloupému workaroundu?A co "DoS" na uživatele? Není nad to, když se při editaci jedné hospody stáhne tisíc kilometrů čtverečních lesa. Nebo když hledáte nějakého člena relace v pěti tisících položkách. A zkuste si někdy používat něco takového třeba na GPRS připojení. Eventuelní řešení stahovat pouze část cesty/relace považuji za potenciálně velmi nebezpečné.huh, to nechápu ... když je nebezpečné stáhnout pouze část relace, tak jak si pomůžu, když budu stahovat relaci o 2*2000 bodů místo jedné linie o 4000 bodech?Vylepšit datový model tak, aby byl pro člověka lépe uchopitelný nepovažuji za "hloupý workaround". Dlouhé cesty elegantně řeší relace. Rozsáhlé relace elegantně řeší relace relací. Doufejme, že se zavedením limitů bude větší motivace k vylepšení podpory relací v OSM nástrojích. =TT=a relace relací relací a relace relací relací relací ... - no jistě, těch 640 KB taky elegantně řešil DOS4/GW a další, že ... já nevím, nemotám se kolem projektu dlouho, a furt mi něco nefunguje, takže do toho až tak nehrabu, tož mi dík nezkušenosti asi něco uchází, ale ... tak nějak jsem myslel, že relace byly míněny jako způsob, jak z fyzických objektů zkonstruovat nějaké logické celky, nikoliv proto, aby se nějaký fyzický objekt mohl nakrájet jako salám, a pak silou vůle, eh, tedy relace, zase slepil dohromady a řeklo se, že to má být jako celá štangle salámu a ty řezy mezi kolečky jako nevidímeje to cele postavene na hlavu totiz. nejdrive tady byly segmenty, ale to bylo malo tak nad segmenty nekdo vyrobil virtualni zapouzrovaci bazmek a nazval ho way, pak rozhodl ze segmenty ee a zrusil je, jenze tim padem vznikla potreba virtualniho zapouzdrovaciho bazmeku nad ways, a tak vznikla relace, budme radi ze nezrusili way:) relace nad relaci je jen logicky dusledek vymysleni kravin. Casem se zcela urcite dockame zase nejakych novych skvelych vymozenosti, aspon se mame na co tesit!:)
Zkusim se zeptat - mela by byt statni hranice CR jedna cela neprerusovana uzavrena way? Odpovedi jsou dve a rekl bych, ze se neshodneme napric uzivatelskym forem... Jako u vseho je hodne pro a hodne proti. K
Zkusim se zeptat - mela by byt statni hranice CR jedna cela neprerusovana uzavrena way? Odpovedi jsou dve a rekl bych, ze se neshodneme napric uzivatelskym forem... Jako u vseho je hodne pro a hodne proti. K
Karel Volný napsal(a):Dne st 11. března 2009 Tomáš Tichý napsal(a):2009/3/11 Karel Volný <kavol na seznam.cz>:Me osobne se ten limit libi prave z tohoto duvodu. Na sumave, kdyz posunu v hranici lesa, tak zbytecne odesilam nekolik MB dat a trva to dost dlouho. Nebo je uzasne, kdyz si stahnu vesnici a stahne se mi k tomu cele Labe. Nez zjistim, kde je ta vesnice, co jsem vlastne chtel...uff, takže místo toho, aby se to pořádně vyřešilo (viz níže, možnost komunikovat pouze změny, nikoliv všechna data), budeme raději tleskat hloupému workaroundu?A co "DoS" na uživatele? Není nad to, když se při editaci jedné hospody stáhne tisíc kilometrů čtverečních lesa. Nebo když hledáte nějakého člena relace v pěti tisících položkách. A zkuste si někdy používat něco takového třeba na GPRS připojení. Eventuelní řešení stahovat pouze část cesty/relace považuji za potenciálně velmi nebezpečné.huh, to nechápu ... když je nebezpečné stáhnout pouze část relace, tak jak si pomůžu, když budu stahovat relaci o 2*2000 bodů místo jedné linie o 4000 bodech?Vylepšit datový model tak, aby byl pro člověka lépe uchopitelný nepovažuji za "hloupý workaround". Dlouhé cesty elegantně řeší relace. Rozsáhlé relace elegantně řeší relace relací. Doufejme, že se zavedením limitů bude větší motivace k vylepšení podpory relací v OSM nástrojích. =TT=a relace relací relací a relace relací relací relací ... - no jistě, těch 640 KB taky elegantně řešil DOS4/GW a další, že ... já nevím, nemotám se kolem projektu dlouho, a furt mi něco nefunguje, takže do toho až tak nehrabu, tož mi dík nezkušenosti asi něco uchází, ale ... tak nějak jsem myslel, že relace byly míněny jako způsob, jak z fyzických objektů zkonstruovat nějaké logické celky, nikoliv proto, aby se nějaký fyzický objekt mohl nakrájet jako salám, a pak silou vůle, eh, tedy relace, zase slepil dohromady a řeklo se, že to má být jako celá štangle salámu a ty řezy mezi kolečky jako nevidíme K. _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz_______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Michale, jako prispevatele OSM si Te vazim, ale uznej, ze reptanim se toho moc nespravi. Mas nejaky jiny lepsi konstruktivni navrh? K
Michale, jako prispevatele OSM si Te vazim, ale uznej, ze reptanim se toho moc nespravi. Mas nejaky jiny lepsi konstruktivni navrh? K Michal Grézl napsal(a):
Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.