<br><br><div class="gmail_quote">2009/6/19 Eddy Petrișor <span dir="ltr"><<a href="mailto:eddy.petrisor@gmail.com">eddy.petrisor@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
În data de 18 iunie 2009, 17:04, Ioan Indreias <<a href="mailto:indreias@gmail.com">indreias@gmail.com</a>> a scris:<br>
><br>
> Salut Eddy,<br>
<div class="im">> Daca ai fi citit tot thread-ul ai fi vazut ca nu am facut nicaieri mentiunea ca scriptul va detecta dublurile si doar dupa aceea va lua decizia de a introduce un nod nou sau nu.<br>
> Pasii au fost descrisi foarte clar (import + prelucrare manuala a dublurilor) si nu am gasit nicaieri mentiunea ta ca nu esti de acord cu ei. Din postarile tale am preluat toate sugestiile de imbunatatire a scriptului de parsare.<br>
<br>
<br>
</div>Probabil că nu am fost prea clar când am zis:<br>
<div class="im"><br>
> În concluzie, îmi mențin poziția de a cere ca pentru elementele care<br>
> există deja să se modifice acestea, nu să se ștergă și să se adauge alte<br>
> elemente.<br>
</div>[...]<br>
<div class="im">> Orice import de tipul ștergere+element nou cere să aducă probleme pe<br>
> termen lung.<br>
><br>
><br>
><br>
> Dacă consideri că e e prea dificil sau ai nevoie de ajutor în a<br>
> implementa corect, sigur o să găsești ajutor (deși am puțin timp liber,<br>
> probabil că am să fac un efort, dacă e nevoie).<br>
<br>
<br>
<br>
<br>
</div><div class="im">> Importul s-a facut cu JOSM-ul si nu am avut nici un alt tool de verificare a duplicatelor.<br>
> Eu pot sa ma opresc aici cu importul (Alba,Arad si Arges) si poti continua tu/altcineva cu o alta metoda - este OK<br>
> pentru mine. Eu doar am remarcat ca de la anuntul lui Vasile au trecut luni de zile fara sa se faca nici un import<br>
> si de aceea am initiat acest thread.<br>
> Cred ca problema de retorica tine de modul in care fiecare intelege sa faca observatiile proprii - in plus nu vreau<br>
> sa intru in polemica pe aceasta tema, nu e scopul acestui thread si nici nu cred ca ajuta pe nimeni continuarea in<br>
> acest sens a discutiilor.<br>
<br>
</div>Îmi cer scuze din nou dacă a părut că am avut intenția să jignesc pe cineva,<br>
sau am reușit să jignesc, deși nu am vrut asta.<br>
<div class="im"><br>
> Colegul meu Cristi a postat tool-ul de detectie a duplicatelor si in continuare consider ca nu s-a scapat nimic de<br>
> sub control (exista in jur de 160 de duplicate, cateva dintre ele existand de dinainte de acest import).<br>
<br>
</div>Da, detecția e făcută după ce s-a făcut deja importul, eu am pledat să<br>
se facă înainte de import, a.î. sa nu fie niciodată în OSM data<br>
duplicate ;-) .<br>
<br>
<br>
<br>
Eu mă gândisem la un algoritm de genul:<br>
<br>
<br>
================================================<br>
pentru fiecare nod de inserat<br>
- fie POS poziția noului nod al localității N<br>
- trage via API datele ce se alfă în proximitatea geografică a lui POS cu o<br>
margine acceptabilă (aprox. 10km* cred că ar fi suficient); fie datele D<br>
- caută în datele D un nod cu dediacritizat(name) = dediacritizat (N) care<br>
este place=*; fie nodul vechi V<br>
- dacă NU există, crează elementul nou; memorează nodul în LISTA_NOI<br>
- dacă există doar unul, adaugă informațiile ce nu suprascriu date<br>
exitente în V, iar datele cu conflict se adaugă în<br>
'import-siruta-DATA:conflict:...';<br>
- memorează că V exista (pentru a face update nu create în API) în lista<br>
LISTA_ACT<br>
- în câmpul 'name' se pune varianta din import (cu diacritice)<br>
- dacă există MAI MULT de unul, memorează numele în LISTA_MULTI<br>
<br>
pentru fiecare nod din LISTA_NOI<br>
- crează nodurile (via API)<br>
<br>
pentru fiecare nod din LISTA_ACT<br>
- trimite noua versiune a nodului (via API)<br>
<br>
pentru fiecare nod din LISTA_MULTI<br>
- afișează pentru rezolvare manuală prin intervenție umană<br>
<br>
<br>
================================================<br>
<br>
<br>
Desigur, folosirea listelor și trimiterea întârziată poate fi evitată, dacă se<br>
dorește (poate e chiar mai eficient), dar probabil că e mai utilă pentru o<br>
verificare înainte de modificarea datelor din API.</blockquote><div><br></div><div>Salut</div><div><br></div><div>Am considerat si noi o varianta de import cu detectie de duplicate inainte ca Nini sa inceapa importul si am ajuns la concluzia ca efortul asociat implementarii si testarii este mai mare decat beneficiul de a nu avea ceva duplicate pentru o perioada limitata.</div>
<div><br></div><div>Desigur, in conditiile in care doresti sa implementezi si sa folosesti algoritmul de mai sus pentru importul judetelor care au ramas ne-importate, cred ca nu e o problema - din ce stiu Nini a pus importurile judetelor ramase on-hold pana se inchide discutia de pe acest thread.</div>
<div><br></div><div>--</div><div>Cristi</div><div><br></div><div><br></div><div><br></div></div>