> 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. >> > > 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.

> 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

> > 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 > > *** 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 realitou > >> Limit 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 realitou >> >> >>> Limit 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

> 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 > >> realitou > >> > >>> Limit 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? >

> 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=

> 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íme >> >> > je 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

> 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 > > Michal Grézl napsal(a):