<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    <pre wrap=""><font face="Helvetica, Arial, sans-serif"><i>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. </i></font></pre>
    <blockquote>Eu prefer să elimine cât mai mulți pași de preprocesare
      înaintea procesării efective. <br>
      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.<br>
    </blockquote>
    <br>
    <pre wrap="">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.</pre>
    <blockquote>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.<br>
      <br>
      <br>
      Flaviu<br>
      <br>
    </blockquote>
    On 12/8/2010 9:43 AM, Octavian Chelu wrote:
    <blockquote cite="mid:201012080943.25279.tavy72@gmail.com"
      type="cite">
      <pre wrap="">În data de Miercuri 08 Decembrie 2010 09:14:48 Flaviu a scris:
</pre>
      <blockquote type="cite">
        <pre wrap="">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

</pre>
      </blockquote>
      <pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:Talk-ro@openstreetmap.org">Talk-ro@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstreetmap.org/listinfo/talk-ro">http://lists.openstreetmap.org/listinfo/talk-ro</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>