« zpět na výpis měsíce |

[Talk-cz] limit 2000bodu

Vlákno 5.3. - 11.3.2009, počet zpráv: 20


5.3.2009 04:25:07 (#1)
gravatar

Michal Grézl

<michal.grezl at gmail.com>
231
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. -- Michal GrĂŠzl http://walley.org

5.3.2009 04:36:01 (#2)
gravatar

Karel Volný

<kavol at seznam.cz>
550
Dne čt 5. března 2009 Michal Grézl napsal(a): zobrazit citaci
> 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.

5.3.2009 05:14:04 (#3)
gravatar

Tomáš Tichý

<t.tichy at post.cz>
150 4809
zobrazit citaci
>> 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. =TT=

5.3.2009 05:36:24 (#4)
gravatar

Michal Grézl

<michal.grezl at gmail.com>
231
2009/3/5 TomĂĄĹĄ TichĂ˝ <t.tichy na post.cz>: zobrazit citaci
>>> 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
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. zobrazit citaci
> Upozorňuji, že podobný limit se bude týkat počtu členů relace. >
-- Michal GrĂŠzl http://walley.org

5.3.2009 06:32:51 (#5)
gravatar

MP

<singularita at gmail.com>
306
zobrazit citaci
>> 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
Tohle nebude problem, vnejsi hranice se proste jen rozdeli na segmenty po max. 2000 uzlech (no, dal bych tam tak 1800, at je rezerva na pripadne male upravy bez nutnosti dalsiho deleni), vsem vnejsim segmentum se nacha role=outer v multipolygonu a az renderery korektne implementuji "advanced multipolygons" tak zase mame krasne lesy kde vnejsi polygon ma treba 5000 bodu. Jen to interne bude ulozene jako tri samostane cesty. Nevidel bych v tom problem a budou i snazsi upravy, kdyz zmenim maly usek nekde na okraji, tak nenahravam zpet na server vsech 5000 bodu, ale jen tu mensi cast kde jsem delal zmeny (proto se to hlavne delalo, kvuli zatezi serveru). zobrazit citaci
> 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.
Umele ne, ale pokud nekde na vhodnem miste vede nejaka vhodna hranice (napr. silnice skrze les) tak to rozriznout podel ni. Na http://tools.geofabrik.de/osmi/ je takovy kontrolni nastroj, co zobrazuje cesty nad 1000 bodu (cili prisnejsi limit odkdy to varuje), lesu nad limit 2000 je v CR jen par. Navic po zavedeni nezmizi z DB, jen je nepujde ulozit pokud budou mit pres 2000 nodu, takze je bude potreba rozkouskovat nez pujdou normalne editovat. zobrazit citaci
>> Upozorňuji, že podobný limit se bude týkat počtu členů relace.
Tusim 1000 nebo 2000 clenu. Problem by mohl byt u veledlouhych cest, ale tam by se pak slo navazat na dalsi/predchozi useky cesty treba pridanim relace do te relace s roli napr. next_part/previous_part nebo tak neco. Martin

8.3.2009 09:38:42 (#6)
gravatar

Kubajz

<kubajz at kbx.cz>
616
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): zobrazit citaci
> 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 >

10.3.2009 09:58:36 (#7)
gravatar

Karel Volný

<kavol at seznam.cz>
550
Dne ne 8. března 2009 Kubajz napsal(a): zobrazit citaci
> 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 zobrazit citaci
> 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 zobrazit citaci
> 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
viz výše - aneb stokrát nic umořilo vola K. zobrazit citaci
> > 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.

10.3.2009 11:52:14 (#8)
gravatar

hanoj

<ehanoj at gmail.com>
713
zobrazit citaci
>> 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. zobrazit citaci
>> 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. hanoj

10.3.2009 12:45:56 (#9)
gravatar

Karel Volný

<kavol at seznam.cz>
550
zobrazit citaci
> >> 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.
tož, je jasné, že nikdo nemá křišťálovou kouli a postavit základy projektu tak, aby nevyžadovaly změny, je takřka nemožné někdy je dokonce vhodné dělat změny dosti zásadní, které zahodí spoustu předchozí práce, aby se nešťastné řešení netáhlo do budoucna jako koule na noze, ale nikoli překotné, z bláta do louže (což je jak na mě působí současný stav přefiltrovaný zdejší diskusí lidí v OSM technicky zdatnějších) zobrazit citaci
> >> 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.
nevím, co je nebo není běžné v komerční sféře, ale mě to tak nějak připomíná "640 KB RAM musí stačit každému ..." (anebo "pojďme počítat čas v sekundách od 1.1.1970, 32bit integer musí stačit ...") K.

10.3.2009 01:41:21 (#10)
gravatar

MP

<singularita at gmail.com>
306
zobrazit citaci
> 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

11.3.2009 08:10:13 (#11)
gravatar

Kubajz

<kubajz at kbx.cz>
616
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): zobrazit citaci
>> 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 >

11.3.2009 11:50:05 (#12)
gravatar

Karel Volný

<kavol at seznam.cz>
550
zobrazit citaci
> 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? zobrazit citaci
> 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
před nekonečnou cestou by chránil i limit o několik řádů vyšší, který by neomezoval v současnosti existující validní data před klasickým DoS útokem žádný takový limit neochrání, prostě se místo jednoho požadavku na nekonečno bodů pošle "nekonečno" požadavků na jeden bod K. zobrazit citaci
> 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

11.3.2009 12:00:16 (#13)
gravatar

MP

<singularita at gmail.com>
306
2009/3/11 Karel VolnĂ˝ <kavol na seznam.cz>: zobrazit citaci
> >> 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?
Neco takoveho se planuje (diff uploads), ale znamena to zmeny v API (do api 0.6 uz se to nestihne, tak snad 0.7), takze predpokladam, ze tenhle limit je (snad :) docasny. I kdyz, editace tagu bez posilani nodu by snad slo i ted, proste by editor misto seznamu nodu poslal specialni tag <keep-old-nodes/> a bylo by :) Martin

11.3.2009 02:00:00 (#14)
gravatar

Tomáš Tichý

<t.tichy at post.cz>
150 4809
2009/3/11 Karel VolnĂ˝ <kavol na seznam.cz>: zobrazit citaci
> >> 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=

11.3.2009 03:37:13 (#15)
gravatar

Karel Volný

<kavol at seznam.cz>
550
Dne st 11. března 2009 Tomáš Tichý napsal(a): zobrazit citaci
> 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? zobrazit citaci
> 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.

11.3.2009 03:52:32 (#16)
gravatar

Michal Grézl

<michal.grezl at gmail.com>
231
2009/3/11 Karel VolnĂ˝ <kavol na seznam.cz>: zobrazit citaci
> 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!:) -- Michal GrĂŠzl http://walley.org

11.3.2009 04:23:34 (#17)
gravatar

Kubajz

<kubajz at kbx.cz>
616
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): zobrazit citaci
> 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 >

11.3.2009 04:24:43 (#18)
gravatar

Kubajz

<kubajz at kbx.cz>
616
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): zobrazit citaci
> 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!:) > >

11.3.2009 04:43:38 (#19)
gravatar

Karel Volný

<kavol at seznam.cz>
550
Dne st 11. března 2009 Kubajz napsal(a): zobrazit citaci
> 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
hm, já jsem pro tu druhou, pokud ta první je "ano" :-) nicméně dělicí body by měly vycházet z geopolitické struktury, tj. trojmezí, případně ve zvrhlejší podobě body návaznosti jednotlivých cest, hřebenů, střednic toků a dalších linií, kterými je hranice vymezena, ale zcela určitě nikoliv podle počtu bodů v jedné way ... u limitu vytvořeného uměle bez návaznosti na velikost objektů, kterých se týká, holt žádné "pro" nevidím zabránění "DoS" tím, že zatímco dříve jsem si bral celý salám, teď si *musím* vzít polovinu, nemůžu si vzít celý, když chci celý, je pořád řešení vcelku na nic pro toho, koho zajímá jen jedno kolečko salámu, kvůli kterému si ovšem musí vzít celou půlku a zase tu půlku vrátit K. zobrazit citaci
> 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

11.3.2009 06:01:48 (#20)
gravatar

Michal Grézl

<michal.grezl at gmail.com>
231
2009/3/11 Kubajz <kubajz na kbx.cz>: zobrazit citaci
> 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):
Rozdelit velke polygony na mensi, coz momentalne delam. Rozdelit samozrejme i relace, coz taky delam. -- Michal GrĂŠzl http://walley.org

« zpět na výpis měsíce