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

[Eddy Petrișor]

Î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.



Ce ziceți?



* transformarea în coordonate nu e obiectul explicației, dar se poate găsi un
  corespondent lat/lon care să fie OK (deși distanța intre două grade de
  longitudine nu e constantă pe toate latitudinile)

--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein