On Wed, Sep 30, 2009 at 11:33:14AM +0000, Valent Turkovic wrote: > On Tue, 29 Sep 2009 00:14:22 +0200, Matija Nalis wrote: > > BTW ima i proposal za takve paralelne staze: > > http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group > > Paralelne staze su mi jako odbojna ideja. Vidio sam neki grad u njemackoj
A cuj, omogucavaju najvecu fleksibilnost i ne zahtjevaju da se ista mijenja u postojecim rendererima i editorima. Ne postoji drugi nacin za hrpu stvari da definiras ono sto hoces i da to imas *SADA* (ili u bilo kojoj bliskoj buducnosti). lane_group bi trebao *pomoci* u upravo da smanji odbojnost multiple wayova tamo gdje to moze (npr. JOSM plugin koji mrda cijelu lane grupu dok pomices njen centar i sl) > gdje su zabrijali na paralelne staze i to je katastrofa za kasnije > editiranje. Toliko linija bude da se vise nikako ne mozes snaci, te zbog > visestruke kolicine podataka vise se opterecuju serveri pri uploadu i > downloadu, te mozes ucitati manju povrsinu za uredjivanje. Ne mislim da su performanse servera ono na sto se treba koncentrirati za unosenje podataka (jos manje nego sto kazu da to nisu niti trenutne mogucnosti nekon od renderera, kao Mapnik ili Osmarender). U suprotnom bi trebalo zagovarati sto manje unosenje "manje bitnih" podataka. Problem je da je ono sto je tebi manje bitno, nekom drugom vise bitno. Recimo meni uopce nisu bitno gdje su koje ceste za motorna vozila ali zelim znati gdje su dobre birtije, servisi za bicikl, biciklisticke staze i parkovi i klupe te izvori vode i WCi u njima. A evo bas sam gledao na bestofosm.org su neki bjelorusi mapirali zasebno svako drvo u parku! Totalno cool! A ako te brinu performanse servera doniraj koji euro pa ce se to poboljsati samo od sebe :) I/ili uzmi kod renderera pa ga poboljsaj da bude brzi. > Zbog svega toga mi se vise svidja ideja pametnijih tagova i pametnijih > rendera, a da podaci ne dupliraju ako nije bas izrazito nuzno. I meni, ali to nije moguce trenutno sa zamisljenim tagovima. To je problem ogranicavanja na "ciste" key=value parove. Ono sto treba je globalno prihvacena (i tu nastaje problem :) i implementirana razradjenija tehnika (koja trenutno je tehnicki dopusteni podskup, ali bez koncenzusa i implementacije je beskorisno), npr "key:subkey:subkey:subkey:....=value" Trenutno se takav "kludge" koristi za stvari tipa "key:jezik=value", npr. "name:it=Zagabria". Ono sto bi se moglo prosiriti je napraviti nesto tipa: (nisu pravi podaci, ali radi ilustracije) name=Vukovarska avenija highway=tertiary oneway=yes surface=asphalt parallel:l1:highway=cycleway parallel:l1:surface=concrete parallel:l1:access=official parallel:l2:highway=footway parallel:r1:highway=path parallel:r1:suface=grass parallel:r1:dog=leashed gdje l1/l2/l3/... i r1/r2/r3/... su (u ovisnosti na smjer waya) s lijeve i desne strane istog. Mozda bi ":" trebalo zamijeniti nekim drugim, posto je ":" vec overloaded za jezik i sl. U svakom slucaju trebala bi izmjene renderera (i editora!) da svaki "parallel:" tag izparsiraju nakon glavnom i renderaju kao da je bio posebni way. Alternativna sintaksa (mozda bolja?) bi mogla biti: name=Vukovarska avenija highway=tertiary oneway=yes surface=asphalt highway/1=cycleway surface/1=concrete access/1=official highway/2=footway highway/-1=path suface/-1=grass dog/-1=leashed Nesto takvo na generalnom nivou (mora biti na generalnom, jer mora funkcionirati za SVE tagove. Ako moras stavljati poseban support za svaki sub-tag, to je onda prilicno beskorisno i zahtjeva dozivotno trosenje vremena za odrzavanje sto je neprihvatljivo) sto bi zadrzalo broj wayova za takve stvari minimalnim, a ipak omogucilo upis detalja. Problem je sto to jos uvijek (usprkos hrpi truda) ne rjesava sve probleme. I dalje imas laneova unutar same ceste (npr. biciklisticka staza u kontrasmjeru usred ceste, cycleway=opposite_lane i sl) kao i probleme sto sa relationima (koji bi tada trebali moci specificirati specificni sub-lane ili parallel-track), sto je poseban problem za speficne mape kao cyclemap i sl. Takodjer imas ruzne situacijama kod situacija gdje ti je tvoj sub-way recimo 95% paralelan sa glavnim wayom, a onih 5% nije (i onda moras ili trpiti krive podatke, ili ga crtati skroz posebno sto ubija smisao shareanih wayova, ili ga razbijati na shared+unshared dio sto izgleda jos ruznije i jos vise zbunjujuce). Primjeti da *svih* tih problema sa vise posebno ucrtanih wayova nema, i da su jedini nedostaci kod tog pristupa (koji vec sad odlicno funkcionira !): - nesto veci clutter na ekranu (sto upotreba lane_grupe i sl. stvari moze eliminirati/pojednostavniti ukoliko bi ti editor podrzavao takvu opciju) - nesto veci datasetovi za isti bbox (sto sam gore objasnio zasto performanse nikako ne bi trebale biti razlog za throttleanje unosa podataka u OSM) Neka razmisljanja na temu su recimo na: http://wiki.openstreetmap.org/wiki/Users:cmuelle8/multiple_way_tagging_on_single_geometry Dakle iako se slazem s tobom da paralelni wayovi nisu idealno rjesenje problema zbog cluttera, mislim da imaju ogromnu prednost sto: - su mu nedostaci znacajno manji nego od konkurentnih ideja (koje bi trebalo prvo dobro osmisliti, dogovoriti, implementirati, cekati da ljudi unesu, vidjeti nedostatke, reimplementirati sa izmjenama pa tek onda koristiti) - daje ti *uvijek* NAJVECE mogucnosti od svih mogucih alternativa (koje u najsavrsenijem, i nikad dostiznom, slucaju mogu biti tek jednako toliko dobro, nikad ne i bolje sto se tice mogucnosti). - *VEC SADA ISPRAVNO RADI* svuda ! lane_grupe i sl. prijedlozi su samo ideje kako umanjiti/otkloniti clutter koji je jedini prakticni nedostatak doticne esencijalne ideje OSMa (na kraju krajeva, OSM ne zanima da li su neki od ucrtanih wayova paralelni slucajno ili namjerno). -- Opinions above are GNU-copylefted. _______________________________________________ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
