[Talk-ro] Propunere pentru "maxspeed" în România

[Strainu]

În data de 8 decembrie 2010, 21:30, Octavian Chelu <tavy72 la gmail.com> a scris:
> În data de Miercuri 08 Decembrie 2010 19:00:17 Strainu a scris:
>> În data de 8 decembrie 2010, 18:29, Octavian Chelu <tavy72 la gmail.com> a
> scris:
>> > Eu aici mă dau bătut, poate are altcineva mai multă răbdare să-ți explice
>> > că atâta timp cât ceva poate fi determinat prin calcul nu are sens să
>> > poată fi memorat în datele brute, cum este cazul OSM.
>>
>> După logica asta, de ce să mai memorăm informații care se găsesc
>> libere în altă parte? Am putea să renunțăm la punctele pentru
>> localități de exemplu, că oricum pentru multe informațiile sunt
>> disponibile în articolele Wikipedia.
>
> Cumva Wikipedia face parte din OSM și eu nu știam?
> Când spun că nu are sens să dublezi ma refer în cadrul aceluiași set de date
> BRUTE.
> Și nu înțeleg ce vrei să spui cu „După logica asta”, paragraful care-l citezi
> nu conține o deducție logică ci o afirmație.

Dacă pui tagul "wikipedia", ai putea să consideri că ai o asociere cu
o pagină Wikipedia pe care o poți parsa. Dar hai să reformulez: "Hai
să ștergem punctele pentru localități pentru că acum avem poligoane de
boundary, iar coordonatele pot fi deduse ca medie dintre toate
punctele acestor poligoane."

Well, asta e o prostie. De ce să fac x apeluri de API pentru a obține
coordonatele unei localități când pot să fac 1/2 apeluri? Duplicarea
datelor are și ea rostul ei în anumite momente.

>
>>
>> Duplicarea datelor are sens pentru ușurința parsării și chiar și
>> pentru adaptarea la anumite programe defectuoase (recte tile
>> generator). Bineînțeles că trebuie găsit un echilibru între parsare și
>> mentenanță, dar acest echilibru nu cred că este "cât mai puține date
>> primare".
>
> De unde ai scos regula asta? Eu știam altceva:
>
> http://wiki.openstreetmap.org/wiki/Good_practice
> Don't map for the renderer
>
> Draw things the way they are on the ground and don't care what the renderers
> make out of it. They are continually improving, don't bend the data to make it
> look prettier, just be patient.
>
> Cu alte cuvinte nu introduc date în OSM aiurea doar ca să meargă corect un
> program defectuos. Soluția este ori repararea programului defectuos ori dacă
> nu este posibil prelucrarea datelor OSM înainte de a fi livrate programului
> defectuos.
>

Știi cum e...până la Dumnezeu te omoară sfinții. E frumoasă teoria de
acolo, dar realitatea e că marea majoritate a implementărilor de OSM
pe care le-am văzut eu folosesc Mapnik. Și nu știu câți proprietari de
situri au răbdare să se repare ns ce bug obscur într-un program de
care nici nu știu că există. Ei știu că așa arată OSM și vor "să
meargă", așa cum merge Google Maps. Am o bănuială că și ăsta e unul
din motivele pentru care vedem așa puține implementări de OSM.