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

Fri Jun 12 23:34:50 BST 2009

Ioan Indreias a scris:
> Salut Eddy,
> 
> Am preluat ultima varianta a scriptului si de asemenea am adaugat in
> tool-ul de parsare regulile de sed mentionate aici
> <http://wiki.openstreetmap.org/wiki/User:Xybot/FixRomanianDiacritics> pentru
> ca diacriticile din fisierele sursa sunt de tip gresit (cel putin eu asa
> am inteles).

cam da, oricare din ş/Ş (s cu sedilă) ţ/Ţ (t cu sedilă) ã/Ã (a cu tildă
plus a cu caron adică ăsta - ˇ - cel care se vede şi pe bancnotele
românești - da, e dezastru) ar trebui înlocuite cu variantele corecte:

ș/Ș - s cu virgulă
ț/Ț - t cu virgulă
ă/Ă - a cu brevă (căciuliță)

Aaa, și ălea-s reguli de înlocuire în perl, dar ar trebui să mearga și
în sed.

> Atasez fisierul sursa (csv) si fisierul output (osm) pentru judetul Alba
> - pentru a obtine de la voi ultimele comentarii referitoare la acest
> import (tot am amanat importul pana cand Vasile ne da OK-ul pentru
> ultima versiune a surselor).

Sper să am timp sa mă uit.

> Referitor la codul postal am ales sa pun campul old_postal_code (la
> sugestia lui alex "alea alea") pentru ca grupul addr:* se refera la
> cladiri (cel putin eu asa am inteles), pentru cazul nostrul codul postal
> al unei localitati (asta importam) ar fi fost trecut in campul postal_code

(vorbind doar de codul poștal nou)

Hmm, nu văd de ce ne-am poticni în faptul că addr:* ar fi pentru clădiri
- dacă ar fi așa într-adevăr. Este corect că addr:postalcode pentru
anumite localități e același independent de stradă și repetarea lui „ad
infinitum” nu-mi pare un lucru prea util; pe de alta parte nu-mi pare
incorect deloc să fie trecut ca addr:postalcode la nivelul localității
cu pricina.

> Referitor la suprascrierea datelor - am ales sa facem manual aceasta
> operatie tocmai pentru a nu pierde date vechi (nu m-am gandit la history
> - crezi ca e asa de importanta?). Vom trata fiecare caz in parte si vom
> tine cont de comentariile tale.

Da, cred că e important. Anumite informații prezente au fost adăugate în
decursul timpului de diverși utilizatoricu diverse surse de informare.
Consider că e esențial să se poată identifica ușor cine ce a adaugat,
fie că e doar pentru a identifica dacă e de acord cu o schibare de
licență la un moment dat. Începrerea de la zero șterge/ascunde
informațiile de proveniență și le atribuie utilizatorului care face
importul, lucru total greșit. Imaginează-ți ce ar însemna să începi să
sapi de unde a provenit o anumită informație pe un nod care nu are deloc
istorie deși stii sigur că nodul a fost modificat de tine de cel puțin
două ori. Exinde acum dilema la nivelul întregii țări. Apoi extinde la
nivelul tuturor drumurilor. Cu încă un exercițiu extinde la nivelul
relațiilor și o să ai un dezastru în încercarea de a identifica cine ce
informații a adăugat ilegal și la ce versiune trebuie să te întorci mai
ales că informațiile legate de elementele șterse nu sunt tocmai ușor
accesibile și accesul în sine la ele e forate lent.

Ce ar fi dacă fiecare editor, în loc să actulizeze informațiile
exitente, ar șterge elementele de modificat și ar creea altele noi? În
plus, unde mai pui că bombardezi în mod inutil și excesiv baza de date
cu elemente noi - nu uita, în baza de date sunt ținute toate elementele,
și cele active și cele șterse.

- Presupunem că X a adăugat informația A la orașul M.
- Apoi Y a mai adăugat alte informații B la orașul nostru M.
- importul tau se face cu utilzatorul I care șterge nodul vechi și
creează altul nou cu vechile informații plus cele noi
- Z descoperă că X folosește o sursă de informații incompatibilă dpdv
legal cu licența OSM și decide în urma discuțiile cu OSM că datele
introduse de X trebuie șterse prin revenire la versiunile anterioare
modificărilor lui

Deoarece I pare că ar fi autorul tuturor informațiilor asociate lui M,
OSM va avea încă informații din surse incorecte, lucru care înfrânge
tocmai scopul OSM și al acțiunii lui Z făcând susceptibil proiectul de a
cădea în mâinile unor terți sau de a-l îngropa.

Știu pare de domeniul SF, dar, crede-mă, sunt programator și cunoașterea
istoriei este foarte importantă în a putea identifica probleme și a le
rezolva corect, și asta nu e valabil doar pentru cod ci se aplică și în
domenii mai tangibile precum administrarea caselor*, întretinerea
mașinilor**.

Î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. Ceea ce vrei tu să faci se cheamă în limbajul din breasă
„sindromul NIH - not invented here” și reprezintă dorința conștentă sau
inconștentă (în sensul de involuntară, nu nesăbuită) de înlocui sau
(re)crea de la zero orice element necesar într-un proiect, chiar dacă
există deja o soluție, dar care provine dintr-o altă sursă.

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

> Referitor la populatie - in fisierele sursa sunt incluse informatiile de
> la ultimul recensamant (2002). Daca tu ai avut alta surse te rog sa o
> mentionezi pentru a putea face medierea acestora.

În unele locuri am luat informațiile de pe wikipedia, alteori de pe
paginile de internet ale primăriilor localităților.

Totuși chestia cu populația era *DOAR* un exemplu și ceea ce vroiam sa
spun e că pentru *ORICE* infromație deja exitentă trebuie ca aceasta să
fie păstrată.

Cu alte cuvine, dependent de situație, nodul final ar putea fi într-unul
din cazurile:

1) elementul nu a existat; rezulatatul e un element nou în care se
adaugă majoritatea informațiilor în câmpuri siruta:* pentru a indica
proveniența și pentru a face posibilă actualizările ulterioare; alte
infromații (ex.: numele) ar putea fi adăugat atât în câmpuri clasice OSM
(ex. name) cât și în câmpuri siruta:* (siruta:name)

2) elementul exista dar nu există nici o informație care e și obiectul
importului; rezultatul este o nouă versiune a elementului cu câmpurile
existente combinate cu cele din import

3) elementul există și anumite informații există în ambele părți, dar
sunt identice; rezultatul e o versiune nouă cu infromațiile combinate
din ambele surse; deoarece informațiile existente deja sunt dublate de
cele din import, adăugarea unor etichete siruta:* care sa duplice
elementele exitente e benefică pentru că întăresc infromațiile existente

4) elementul există , dar informațiile sunt conflictive; rezultatul e o
nouă versiune a elementului existent în care au precedență informațiile
din elementul vechi iar pentru oricare conflict pentru informația „bla”
va exista un element „siruta:bla” și un altul
„siruta:bla:fixme=please-check-what-is-the-real-status-for-bla” ;
Singura excepție la care mă pot gândi în care datele de import ar putea
avea prioritate sunt cele referitoare la poziție, în rest probabil că ar
trebui ca datele exitente să aibă precedență

De ce importul nu are precedență? Pentru că oricare ar fi motivul cineva
a ajuns la concluzia că situația reală e alta decât ce e în import și
oricum voluntarii OSM sunt, de cele mai multe ori, atenți la detalii și
au șanse să se fi infromat din surse mai recente decât datele de import.
În orice caz, conflictul trebuie rezolvat manual după o verificare
(poate în teren).

* dacă știi că vechiul proprietar a fost neglijent și a petecit
instalațiile atunci când a fost nevoie, vei putea decide la primul eșec
că poate e mai bine să schimbi o mare parte din instalație decât să
rezolvi punctual

** dacă știi ca o mașină a fost lovită frontal la un moment dat, odată
cu un nou accident poate decizi că trebuie să faci o reparație mai de
anvergură; la fel, dacă știi că au fost probleme cu anumite părți
componente și nu au fost remediate corect vei putea fi mai atent la
uzura lor, întreținerea lor, etc.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk-ro/attachments/20090613/dcea2caf/attachment.pgp>