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

[Flaviu]

/Greu de crezut că o aplicație de navigare va folosi harta OSM fără o
preprocesare și generare a hărții într-un format convenabil./

    Eu prefer să elimine cât mai mulți pași de preprocesare înaintea
    procesării efective.
    Părerea mea e că datele OSM ar trebui să fie cât mai ușor
    "digerabile" eliminând deduceri, preprocesări și alte acrobații.


Pe de altă parte, principala problemă pentru o aplicație nu este puterea de
calcul cât capacitatea mică a memoriei RAM, cu cât încarci în ram mai mult din
hartă cu atât procesarea va fi mai rapidă. În condițiile astea fiecare bit de
informație în plus contează dacă acesta este atașat multor tronsoane, Dacă mai
ții cont că în general încerci să aliniezi datele la 32 bit sau 64 se poate
întâmpla ca încă un bit în plus per entitate/tronson să te oblige de fapt să
folosești 4 sau chiar 8 octeți.

    Cred că nu te referi la o aplicație de navigare. Dacă te referi la
    un tool-ul de procesare a hărții OSM, la bază e un parser XML care
    citește secvențial doar buffere mici din fișier iar cache-ul OS-ului
    (read-ahead) își face treaba. Iar din datele XML de la parser
    filtrezi ceea ce te interesează și eventual le pui în cache-uri cu
    evacuare pe disk. In fine, e o discuție care se îndepărtează de la
    subiect.


    Flaviu

On 12/8/2010 9:43 AM, Octavian Chelu wrote:
> În data de Miercuri 08 Decembrie 2010 09:14:48 Flaviu a scris:
>> Salut,
>>
>> Sunt 2 probleme:
>> 1. Dacă se trec valorile direct (50, 90, 100, 130) și dacă de mâine se
>> vor schimba, toată harta României va trebui updatată. Soluția ar fi
>> notații generice gen RO:urban, RO:motorway, etc.
>> 2. Dacă nu există tag-ul maxspeed, limita maximă de viteză se poate
>> deduce din tipul de highway însă e nevoie și de verificări cu poligoane
>> de țară presupunând că este procesată o hartă care cuprinde mai multe
>> țări. Sunt convins că e mult mai simplu să verifici un tag
>> "maxspeed=RO:urban" decât să verifici dacă un way e sau nu într-un
>> poligon al unei țări; iar poligoanele de țară ajung și la mii de puncte.
>> De ce să încarci poligoane de țară cu mii de puncte și să faci
>> verificări până când determini pentru fiecare way în ce poligon de țară
>> se încadrează. La fel și cu way-urile având highway=primary care trec
>> prin localități și care n-au și tag-ul maxspeed. Iarăși trebuie
>> verificat dacă way-ul respectiv e inclus sau nu într-un poligon de
>> localitate. Eu mă îndoiesc să existe vreo metodă practică mai simplă
>> pentru acest caz.
>>
>> Soluțiea propusă este
>>
>> *În cadrul localităților*
>>       maxspeed=RO:urban   (50 km/h)
>>
>> *În afara localităților*
>>       maxspeed=RO:rural                (90 km/h)  - drumuri naționale
>> (care nu sunt și europene), județene, comunale, etc.
>>       maxspeed=RO:european    (100 km/h)   - drum european
>>       maxspeed=RO:motorway   (130 km/h)   - autostradă
>>
>> Poate în loc de RO:european ar merge și RO:trunk; țin doar ca
>> categoriile de drumuri să aibe notații distincte.
>>
>> Flaviu
>>
> Greu de crezut că o aplicație de navigare va folosi harta OSM fără o
> preprocesare și generare a hărții într-un format convenabil. Dacă o astfel de
> aplicație chiar are nevoie de tagurile despre care vorbești atunci tagurile se
> pot adăuga simplu în formatul harții folosit de aplicație prin calcul.
> Pe de altă parte, principala problemă pentru o aplicație nu este puterea de
> calcul cât capacitatea mică a memoriei RAM, cu cât încarci în ram mai mult din
> hartă cu atât procesarea va fi mai rapidă. În condițiile astea fiecare bit de
> informație în plus contează dacă acesta este atașat multor tronsoane, Dacă mai
> ții cont că în general încerci să aliniezi datele la 32 bit sau 64 se poate
> întâmpla ca încă un bit în plus per entitate/tronson să te oblige de fapt să
> folosești 4 sau chiar 8 octeți.
>
>   --
> Octavian Chelu
>
> _______________________________________________
> Talk-ro mailing list
> Talk-ro at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ro

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ro/attachments/20101208/40873462/attachment.html>