« 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>
518
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 at 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>
614
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 at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

10.3.2009 09:58:36 (#7)
gravatar

Karel Volný

<kavol at seznam.cz>
518
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>
518
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>
614
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 at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

11.3.2009 11:50:05 (#12)
gravatar

Karel Volný

<kavol at seznam.cz>
518
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 at 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 at 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>
518
Dne st 11. b?ezna 2009 Tom?? Tich? napsal(a): zobrazit citaci
> 2009/3/11 Karel Voln? <kavol at 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 at seznam.cz>: zobrazit citaci
> Dne st 11. b?ezna 2009 Tom?? Tich? napsal(a): >> 2009/3/11 Karel Voln? <kavol at 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>
614
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 at 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 at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

11.3.2009 04:24:43 (#18)
gravatar

Kubajz

<kubajz at kbx.cz>
614
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 at seznam.cz>: > >> Dne st 11. b?ezna 2009 Tom?? Tich? napsal(a): >> >>> 2009/3/11 Karel Voln? <kavol at 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>
518
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 at 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 at openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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