[Talk-ro] Import în masă a localităților (thread #2)

[Cristian Draghici]

2009/6/19 Eddy Petrișor <eddy.petrisor at gmail.com>

> În data de 18 iunie 2009, 17:04, Ioan Indreias <indreias at gmail.com> a
> scris:
> >
> > Salut Eddy,
> > 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.
> > 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.
>
>
> Probabil că nu am fost prea clar când am zis:
>
> > În concluzie, îmi mențin poziția de a cere ca pentru elementele care
> > există deja să se modifice acestea, nu să se ștergă și să se adauge alte
> > elemente.
> [...]
> > Orice import de tipul ștergere+element nou cere să aducă probleme pe
> > termen lung.
> >
> >
> >
> > Dacă consideri că e e prea dificil sau ai nevoie de ajutor în a
> > implementa corect, sigur o să găsești ajutor (deși am puțin timp liber,
> > probabil că am să fac un efort, dacă e nevoie).
>
>
>
>
> > Importul s-a facut cu JOSM-ul si nu am avut nici un alt tool de
> verificare a duplicatelor.
> > Eu pot sa ma opresc aici cu importul (Alba,Arad si Arges) si poti
> continua tu/altcineva cu o alta metoda - este OK
> > pentru mine. Eu doar am remarcat ca de la anuntul lui Vasile au trecut
> luni de zile fara sa se faca nici un import
> > si de aceea am initiat acest thread.
> > Cred ca problema de retorica tine de modul in care fiecare intelege sa
> faca observatiile proprii - in plus nu vreau
> > sa intru in polemica pe aceasta tema, nu e scopul acestui thread si nici
> nu cred ca ajuta pe nimeni continuarea in
> > acest sens a discutiilor.
>
> Îmi cer scuze din nou dacă a părut că am avut intenția să jignesc pe
> cineva,
> sau am reușit să jignesc, deși nu am vrut asta.
>
> > Colegul meu Cristi a postat tool-ul de detectie a duplicatelor si in
> continuare consider ca nu s-a scapat nimic de
> > sub control (exista in jur de 160 de duplicate, cateva dintre ele
> existand de dinainte de acest import).
>
> Da, detecția e făcută după ce s-a făcut deja importul, eu am pledat să
> se facă înainte de import, a.î. sa nu fie niciodată în OSM data
> duplicate ;-) .
>
>
>
> Eu mă gândisem la un algoritm de genul:
>
>
> ================================================
> pentru fiecare nod de inserat
>  - fie POS poziția noului nod al localității N
>  - trage via API datele ce se alfă în proximitatea geografică a lui POS cu
> o
>    margine acceptabilă (aprox. 10km* cred că ar fi suficient); fie datele D
>  - caută în datele D un nod cu dediacritizat(name) = dediacritizat (N) care
>    este place=*; fie nodul vechi V
>    - dacă NU există, crează elementul nou; memorează nodul în LISTA_NOI
>    - dacă există doar unul, adaugă informațiile ce nu suprascriu date
>      exitente în V, iar datele cu conflict se adaugă în
>      'import-siruta-DATA:conflict:...';
>      - memorează că V exista (pentru a face update nu create în API) în
> lista
>        LISTA_ACT
>      - în câmpul 'name' se pune varianta din import (cu diacritice)
>    - dacă există MAI MULT de unul, memorează numele în LISTA_MULTI
>
> pentru fiecare nod din LISTA_NOI
>  - crează nodurile (via API)
>
> pentru fiecare nod din LISTA_ACT
>  - trimite noua versiune a nodului (via API)
>
> pentru fiecare nod din LISTA_MULTI
>  - afișează pentru rezolvare manuală prin intervenție umană
>
>
> ================================================
>
>
> Desigur, folosirea listelor și trimiterea întârziată poate fi evitată, dacă
> se
> dorește (poate e chiar mai eficient), dar probabil că e mai utilă pentru o
> verificare înainte de modificarea datelor din API.


Salut

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.

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.

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