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

10 views
Skip to first unread message

Ciprian Talaba

unread,
Jun 5, 2009, 8:14:51 AM6/5/09
to tal...@openstreetmap.org
Salutare.


2009/6/5 Ioan Indreias <indr...@gmail.com>
Salut tuturor,

Am incercat sa postez prin "google groups" pe thread-ul "Import în masă a localităților" dar ceva nu merge - imi zice "You do not have the permission required to post."

Eu incercam sa ma joc cu setarile de la vechea lista pentru a limita abonarea. Acum ar trebui sa functioneze.


Any way - am vazut ca pe thread-ul de import al localitatilor nu s-a mai miscat nimic, desi Vasile a postat inca din 23 Mai link-ul http://earth.unibuc.ro/download/romania-seturi-vectoriale
de unde se pot trage datele despre localitati (fara poligonul de granita administrativa).

In ideea ca acestea se vor putea trage ulterior (sau din fisierele de pe www.cultura.ro, la care s-a obtinut dreptul de folosire) am inceput un script de parsare a fisierelor csv, cu output compatibil pentru JOSM (conform http://wiki.openstreetmap.org/wiki/JOSM_file_format)

Mai jos este un prim rezultat (din judetul Alba), pe care vreau sa-l discut cu voi, pentru o implementare consistenta/mai buna:

<node id='-2' visible='true' lon='23.573670047565251' lat='46.069475936456065'>
  <tag k='name'            v='ALBA IULIA'/>
  <tag k='SIRUTA:CODE'     v='1026'/>
  <tag k='SIRUTA:CODE_SUP' v='1017'/>
  <tag k='SIRUTA:TYPE'     v='9'/>
  <tag k='postal_code'     v='2500'/>
  <tag k='is_in'           v='ALBA,ROMANIA'/>
  <tag k='population'      v='65091'/>
  <tag k='place'           v='city'/>
</node>



Aici observatia lui Alex legata de codul postal este corecta.
 

Cum se vede din exemplul de mai sus am adaugat cheia SIRUTA cu subcampurile CODE, CODE_SUP si TYPE (puteti gasi descrierea metodologiei SIRUTA  aici)

Pe baza informatiilor din metodologia de mai sus am construit urmatoare relatie:

SIRUTA:TYPE     PLACE
-----------     -------
1,4,9,40        city      40 doar pentru Bucuresti. In rest sunt municipii sau resedinta de municipiu
2,5,17          town      orase si resedinta de oras
3,11,19,22,23   village   sate si comune
10,18           village   alte localitati
6               <null>    aici nu am idee ce sa trec (sunt sectoarele Bucurestiului)

Singura problema aici este legata de modul de etichetare a satelor. Avem de ales intre village si hamlet. Personal as alege hamlet pentru a putea face o diferenta intre o comunca si un sat.
 

De asemenea am construit is_in pe baza informatiei din campul NAME_SUP, din care am filtrat MUNICIPIUL si ORAS, cu eliminarea autoreferintelor (de tipul ALBA IULIA is_in ALBA IULIA). 

Aici ar exista varianta in care sa pastram referinte de tipul is_in=MUNICIPIUL ALBA IULIA si adaugarea unui punct de tip
   place=municipality
   name=MUNICIPIUL ALBA IULIA

Aici prefer varianta care nu introduce un nod nou.
 
Numai bine,
Ciprian

Francisc TOTH

unread,
Jun 5, 2009, 10:17:18 AM6/5/09
to tal...@openstreetmap.org
Eu nu cred ca e corect, deoarece:

in engleza village=sat, hamlet=catun. Exista si la noi localitati categorisite ca si catune(exista unul langa Sighisoara, langa DN, si sigur nu e singurul)

Pe de alta parte,  din cate stiu, comuna nu este o localitate, ci o unitate adm.-teritoriala(area), iar resedinta de comuna, consiliu local se afla deobicei in satul cel mai mare, numit si el, in mod gresit, comuna.

Eu nu am sa numesc 5 sate a cate 4000 de oameni ale unei comune, hamlet, si satul de 5000 de oameni village, doar fiindca are un consiliu local, cat timp un catun(hamlet) are 10-15case, sau mai putin.

Sper ca am argumentat convingator.

--owene

Ciosici Manuel R.

unread,
Jun 5, 2009, 10:22:06 AM6/5/09
to tal...@openstreetmap.org
Mie mi se pare că owene are dreptate cu folosirea village și hamlet.

2009/6/5 Francisc TOTH <yo6...@yahoo.com>
_______________________________________________
Talk-ro mailing list
Tal...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ro




--
Manuel R. Ciosici
http://manuelciosici.com

alex-map

unread,
Jun 6, 2009, 3:17:20 AM6/6/09
to tal...@openstreetmap.org
si eu sunt de aceeasi parere cu owene, catun inseamna doar cateva case
izolate

alex

On 5 Jun., 16:22, "Ciosici Manuel R." <manuelrcios...@gmail.com>
wrote:


> Mie mi se pare că owene are dreptate cu folosirea village și hamlet.
>
> 2009/6/5 Francisc TOTH <yo6...@yahoo.com>
>
>
>
> > Eu nu cred ca e corect, deoarece:
>
> > in engleza village=sat, hamlet=catun. Exista si la noi localitati
> > categorisite ca si catune(exista unul langa Sighisoara, langa DN, si sigur
> > nu e singurul)
>
> > Pe de alta parte,  din cate stiu, comuna nu este o localitate, ci o unitate
> > adm.-teritoriala(area), iar resedinta de comuna, consiliu local se afla
> > deobicei in satul cel mai mare, numit si el, in mod gresit, comuna.
>
> > Eu nu am sa numesc 5 sate a cate 4000 de oameni ale unei comune, hamlet, si
> > satul de 5000 de oameni village, doar fiindca are un consiliu local, cat
> > timp un catun(hamlet) are 10-15case, sau mai putin.
>
> > Sper ca am argumentat convingator.
>
> > --owene

> > --- On *Fri, 6/5/09, Ciprian Talaba <cipriantal...@gmail.com>* wrote:
>
> > Singura problema aici este legata de modul de etichetare a satelor. Avem de
> > ales intre village si hamlet. Personal as alege hamlet pentru a putea face o
> > diferenta intre o comunca si un sat.
>
> > _______________________________________________
> > Talk-ro mailing list

> > Talk...@openstreetmap.org

> _______________________________________________
> Talk-ro mailing list
> Talk...@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ro

indreias

unread,
Jun 9, 2009, 9:14:44 AM6/9/09
to tal...@openstreetmap.org
Argumentatia mi se pare corecta. As putea face o prelucrare in script
si satele cu populatie mai mica de 100 (de ex.) sa le trec ca si
catun=hamlet.

Ce parere aveti? Este OK 100 sau punem o alta valoare? Vezi de ex.
analiza de tip FREQUENCY pentru judetul Alba (judetul l-am ales pur
intamplator) de la sfarsitul mesajului.

Pe de alta parte chestia cu codul postal m-a "dezumflat" total - nu
bagasem de seama ca datele respective sunt vechi. Merit sa facem
importul asa (cu tag-ul old_postal_code) sau nu?

Daca da, voi incerca un test de import prin JOSM si va tin la curent.
Insa am nevoie de lamuriri la chestia cu catunul.

Toate bune,
Nini.

###
NIVELE FREQ
100 301
500 277
1000 69
5000 61
10000 2
20000 2
40000 3
60000 0
100000 1
###

indreias

unread,
Jun 10, 2009, 11:06:51 AM6/10/09
to tal...@openstreetmap.org
Am inceput importul cu judetul Alba - http://www.openstreetmap.org/browse/changeset/1478008
Importul s-a facut prin JOSM, durata de upload pentru datele din Alba
(aprox. 700 de localitati) fiind de maxim 2 minute.

Decizia de impartire sat/catun am facut-o pe baza numarului de
locuitori (sub 50 de locuitori am schimbat village cu hamlet).

Observatii:
1. Numele localitatilor este capitalizat, asa fiind prezent in
fisierul sursa de pe geo-spatial. A fost greu sa fac o regula de
transformare in caractere de tip lowercase pe urmatoarele motive:
a. diacritice (characterset: UTF-8)
b. probleme de tipul: "Timisul De Jos/Timisul de Jos/Timisul de jos"?
etc.

2. In fisierul sursa codul postal este cel vechi si a fost introdus cu
tag-ul old_postal_code.

3. Avem planificat un utilitar care va identifica dublurile
(localitatile deja definite), urmand sa-l rulam in timp iar corectia
sa fie facuta manual, pentru a nu se pierde informatia introdusa deja.

Daca feedback-ul vostru este pozitiv, voi continua upload-ul cu cate
un oras pe zi, incepand cu saptamana viitoare.

Toate bune,
Nini

Francisc TOTH

unread,
Jun 10, 2009, 1:03:38 PM6/10/09
to tal...@openstreetmap.org
Am verificat zona care imi este cunoscuta(jumatate de judet Alba) si pot confirma ca e o treaba foarte buna, au aparut o multime de localitati noi.
Exista suprapuneri, nu e problema, doar ca in unele cazuri punctele cad in locuri diferite, si cateodata gresite, dar totusi in apropiere. Probabil sunt siturile care cad inafara satului.
2 localitati cu numele trunchiat, se corecteaza,
Vreo 2 lipsa, dar probabil nu exista sit arheologic pe acolo
In concluzie nu cred ca e foarte mult de lucru, eu mi-am notat sa periez tot ce stiu.

verde de la mine

--- On Wed, 6/10/09, indreias <indr...@gmail.com> wrote:

indreias

unread,
Jun 10, 2009, 3:34:45 PM6/10/09
to tal...@openstreetmap.org
Salut,

Poate nu am precizat destul de clar insa importul nu s-a bazat pe
datele de pe www.cultura.ro (de acolo o sa luam granita administrativa
in pasul al doilea; datele de acolo sunt pentru localitati unde exista
cel putin un monument istoric, nu cred ca se refera la siturile
arheologice, desi cred ca exista si astfel de date, pe care inca nu le-
am "digerat") ci pe baza datelor de pe geo-spatial.org, puse la
dispozitie de Vasile Craciunescu (http://earth.unibuc.ro/download/
romania-seturi-vectoriale). De aceea am adaugat un tag de tipul
"source=geo-spatial.org"

Daca ai observat ceva probleme (multumesc pentru feedback) te rog sa
le adaugi aici in orice format (de preferat sub forma node_id -
problema remarcata) astfel incat sa-mi dau seama daca problema provine
din scriptul de parsare a datelor in formatul csv sau ele sunt direct
in fisierul sursa.

Asa cum am mentionat, dupa cateva zile de la import vom face o
verificare cu un script sql (tragem intr-o baza postgres datele de pe
stalpu) pentru a detecta unde exista dubluri - urmand sa le corectam
manual.

Eddy Petrișor

unread,
Jun 10, 2009, 7:19:59 PM6/10/09
to tal...@openstreetmap.org
indreias a scris:

> Am inceput importul cu judetul Alba - http://www.openstreetmap.org/browse/changeset/1478008
> Importul s-a facut prin JOSM, durata de upload pentru datele din Alba
> (aprox. 700 de localitati) fiind de maxim 2 minute.
>
> Decizia de impartire sat/catun am facut-o pe baza numarului de
> locuitori (sub 50 de locuitori am schimbat village cu hamlet).
>
> Observatii:
> 1. Numele localitatilor este capitalizat, asa fiind prezent in
> fisierul sursa de pe geo-spatial. A fost greu sa fac o regula de
> transformare in caractere de tip lowercase pe urmatoarele motive:
> a. diacritice (characterset: UTF-8)
> b. probleme de tipul: "Timisul De Jos/Timisul de Jos/Timisul de jos"?
> etc.

Nu văd care e problema.

Dacă se folosește UTF-8, care e problema? Jumate din ea e rezolvată. Tot
ce ai nevoie e sa rulezi regulile de transformare într-un mediu
localizat în ro_RO.UTF-8 pentru a te asigura că ordinea alfabetică e
respectată (iar acest lucru funcționază pe Linux, stiu sigur că m-am
ocupat pesonal să repar informațiile de localizare pentru limba română).


Folosește scriptul atașat ca să corectezi numele localităților.

echo 'tImiȘul DE jOs' | ./correct_case.pl
Timișul de Jos


> 2. In fisierul sursa codul postal este cel vechi si a fost introdus cu
> tag-ul old_postal_code.
>
> 3. Avem planificat un utilitar care va identifica dublurile
> (localitatile deja definite), urmand sa-l rulam in timp iar corectia
> sa fie facuta manual, pentru a nu se pierde informatia introdusa deja.
>
> Daca feedback-ul vostru este pozitiv, voi continua upload-ul cu cate
> un oras pe zi, incepand cu saptamana viitoare.
>
> Toate bune,
> Nini
>
> _______________________________________________
> Talk-ro mailing list
> Tal...@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ro
>


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

signature.asc
correct_case.pl

Eddy Petrișor

unread,
Jun 10, 2009, 9:10:06 PM6/10/09
to tal...@openstreetmap.org
Eddy Petrișor a scris:

> indreias a scris:
>> Am inceput importul cu judetul Alba - http://www.openstreetmap.org/browse/changeset/1478008
>> Importul s-a facut prin JOSM, durata de upload pentru datele din Alba
>> (aprox. 700 de localitati) fiind de maxim 2 minute.
>>
>> Decizia de impartire sat/catun am facut-o pe baza numarului de
>> locuitori (sub 50 de locuitori am schimbat village cu hamlet).
>>
>> Observatii:
>> 1. Numele localitatilor este capitalizat, asa fiind prezent in
>> fisierul sursa de pe geo-spatial. A fost greu sa fac o regula de
>> transformare in caractere de tip lowercase pe urmatoarele motive:
>> a. diacritice (characterset: UTF-8)
>> b. probleme de tipul: "Timisul De Jos/Timisul de Jos/Timisul de jos"?
>> etc.
>
> Nu văd care e problema.
>
> Dacă se folosește UTF-8, care e problema? Jumate din ea e rezolvată. Tot
> ce ai nevoie e sa rulezi regulile de transformare într-un mediu
> localizat în ro_RO.UTF-8 pentru a te asigura că ordinea alfabetică e
> respectată (iar acest lucru funcționază pe Linux, stiu sigur că m-am
> ocupat pesonal să repar informațiile de localizare pentru limba română).
>
>
> Folosește scriptul atașat ca să corectezi numele localităților.
>
> echo 'tImiȘul DE jOs' | ./correct_case.pl
> Timișul de Jos


Am mai făcut ceva modificări la script. Se pare că dintr-un motiv pe
care nu-l înțleg încă, pe â ăi pe î nu le considera caractere valide
pentru a fi parte dintr-un cuvânt.

Mai mult, am mai adăugat un pomelnic de prepoziții și conjuncții.

Din păcate se pare că atunci când încearcă să facă lowercase(Ș) o dă în
bară și pentru ca si conjuncția „și” să apară corect trebuie făcut un
artificiu si trecut prin sed rezultatul:


0 eddy@heidi ~/usr/src/osm/romanian-osm-corrections $ cat /tmp/test |
./correct_case.pl | sed -e 's# \(Și\) # \l\1 #g'
Strada Horia, Cloșca și Crișan
Strada Arcașilor
Strada Tătărași
Direcția Generală de Asistență Socială și Protecția Copilului
Strada Șincai Gheorghe
Cașin
Holdmann, Confort și Igienă
Holdmann, Confort și Igienă

0 eddy@heidi ~/usr/src/osm/romanian-osm-corrections $ cat /tmp/test
strada horia, cloșca și crișan
strada arcașilor
strada tătărași
direcția generală de asistență socială și prOTECȚia coPILului
sTRADA șINCAI gHEORGHE
Cașin
holdmann, confort ȘI igIEnă
hOLDMANN, cONFORT ȘI iGIENĂ

Noul script e atașat.

>> 2. In fisierul sursa codul postal este cel vechi si a fost introdus cu
>> tag-ul old_postal_code.
>>
>> 3. Avem planificat un utilitar care va identifica dublurile
>> (localitatile deja definite), urmand sa-l rulam in timp iar corectia
>> sa fie facuta manual, pentru a nu se pierde informatia introdusa deja.
>>
>> Daca feedback-ul vostru este pozitiv, voi continua upload-ul cu cate
>> un oras pe zi, incepand cu saptamana viitoare.

signature.asc
correct_case.pl

indreias

unread,
Jun 11, 2009, 3:31:22 AM6/11/09
to tal...@openstreetmap.org
Salut Eddy,

Multumesc mult pentru script - l-am integrat in parser si totul pare
OK.
In urma testelor am adaugat si particula "Lui" la trecerea in
minuscule (ex. "Valea lui Mihai").

$line =~ s/ (Lui|De|Din|Spre|La|Si|Pe|Și|Prin|Dinspre|Cu) / \l$1 /g;

Astazi voi sterge datele introduse ieri (judetul Alba) si le voi re-
importa (in jurul orei 17:00). Sper ca Francisc sa aiba timp si sa
transmita mai multe detalii ref. la observatiile lui de ieri.

Ref. la mediul meu de lucru (ca o scuza pentru mentiunea mea despre
diacritice...) lucrez cu cygwin pe o statie Windows si sunt total
neobisnuit sa lucrez cu diacritice. Nu ma pot schimab si nici nu vreau
sa pornesc o noua discutie pe aceasta tema - atata timp cat sursa are
diacritice si cu ajutorul tau si al colegilor de aici reusim sa
pastram informatia este excelent.

Francisc TOTH

unread,
Jun 11, 2009, 4:24:09 AM6/11/09
to tal...@openstreetmap.org
Salut!

Am raportat greşit cu truchierea, se pare că m-am grabit, Osmarender încă nu îşi făcuse treaba. Am verificat şi e ok, deja a trecut cineva si a şters câteva duplicate.

Tag-ul "is_in": localitate, judeţ, ROMANIA - localitate e cu diacritice, judetul nu stiu, ca Alba e fără, dar România ar trebui trecută cu diacritice, mai ales că e câmp fix.

Toate cele bune




--- On Wed, 6/10/09, indreias <indr...@gmail.com> wrote:

From: indreias <indr...@gmail.com>
Subject: Re: [Talk-ro] Import în masă a localităților (thread #2)
To: tal...@openstreetmap.org
Date: Wednesday, June 10, 2009, 10:34 PM

Salut,

Poate nu am precizat destul de clar insa importul nu s-a bazat pe
datele de pe www.cultura.ro (de acolo o sa luam granita administrativa
in pasul al doilea; datele de acolo sunt pentru localitati unde exista
cel putin un monument istoric, nu cred ca se refera la siturile
arheologice, desi cred ca exista si astfel de date, pe care inca nu le-
am "digerat") ci pe baza datelor de pe geo-spatial.org, puse la
dispozitie de Vasile Craciunescu (http://earth.unibuc.ro/download/
romania-seturi-vectoriale). De aceea am adaugat un tag de tipul
"source=geo-spatial.org"

Daca ai observat ceva probleme (multumesc pentru feedback) te rog sa
le adaugi aici in orice format (de preferat sub forma node_id -
problema remarcata) astfel incat sa-mi dau seama daca problema provine
din scriptul de parsare a datelor in formatul csv sau ele sunt direct
in fisierul sursa.

Asa cum am mentionat, dupa cateva zile de la import vom face o
verificare cu un script sql (tragem intr-o baza postgres datele de pe
stalpu) pentru a detecta unde exista dubluri - urmand sa le corectam
manual.

indreias

unread,
Jun 11, 2009, 5:58:49 AM6/11/09
to tal...@openstreetmap.org
Multumesc - greseala cu România a fost corectata.
Numele judetului este preluat din csv si va fi sigur cu diacritice.

Incerc sa vad cine a facut perierea duplicatelor (cel putin la Alba
Iulia l-am gasit pe gabri3l) sa vad ce pot face ca sa nu pierd
informatia unificata deja.

Francisc TOTH

unread,
Jun 11, 2009, 6:27:58 AM6/11/09
to tal...@openstreetmap.org
mai e o problema la decizia village/hamlet, am gasit la sud de orasul Blaj localitatile Fliteşti si Deleni+Obârşie, care au population=4 şi 5 şi totuşi sunt marcate ca village. In plus, confirm ca sunt hamlet, Fliteşti in 1995 era nelocuit.


--- On Thu, 6/11/09, indreias <indr...@gmail.com> wrote:

From: indreias <indr...@gmail.com>
Subject: Re: [Talk-ro] Import în masă a localităților (thread #2)
To: tal...@openstreetmap.org

Vasile Craciunescu

unread,
Jun 11, 2009, 6:59:20 AM6/11/09
to tal...@openstreetmap.org
Salutare,

La construcția setului de date cu localități ne-am folosit de
informațiile publicate pe siteul Institutului Național de Statistică, la
secțiunea nomenclatoare statistice SIRUTA (<http://tinyurl.com/lvy2ud>).
În felul asta ne-am asigurat că: (1) am inclus toate localitățile
recunoscute oficial, la nivelul anului 2008, în România; (2) avem ca
atribut pentru fiecare localitate un cod unic de identificare (codul
SIRUTA); (3) pentru fiecare localitate avem denumirea recunoscută
oficial de statul român. Actualizările viitoare se vor face ținînd cont
de aceleași nomenclator.

Vă recomand călduros să folosiți codul unic SIRUTA atunci cînd faceți
operații de filtrare a duplicatelor. Filtrarea pe bază de nume este
inexactă și necesită intervenții manuale. N-am verificat în ce măsură
localitățile existente în OSM conțin acest cod. Din punctul meu de
vedere se pot înlocui complet localitățile existente in OSM cu cele de
pe geo-spatial.org. Vă pot asigura că s-a lucrat foarte meticulos. De
exemplu, am petrecut ore bune încercînd să identificăm localități
desființate înainte de 1989 și reînființate ulterior. De cele mai multe
ori am apelat la seturi de hărți vechi, cum sînt cele de la
<http://earth.unibuc.ro/download/harile-austriece-1910-reproiectate-in-stereo70>.
Pînă luni vom publica un update ce vizează coordonatele localităților
din 33 de județe (cele cuprinse între Buzău și Giurgiu).

Printre cîmpurile provenite din nomenclatorl SIRUTA se găsește unul
numit "RANG". Este vorba de o clasificare oficială a localităților din
România. Corespondența numerelor din tabel o găsiți la
<http://preview.tinyurl.com/lcotue>. Mă gîndesc că poate fi de folos la
stabilirea corespondenței cu clasificarile din OSM.

Toate bune,
Vasile

indreias

unread,
Jun 11, 2009, 7:22:43 AM6/11/09
to tal...@openstreetmap.org
Salut Vasile,

Multumesc pentru informatiile transmise.

Si eu sunt sigur ca localitatile existente nu contin date SIRUTA iar
duplicatele le vom detecta prin analiza de proximitate (cu metodele
GIS din postgres) pentru puncte de tip localitate (place != ""), cu
nume de lungime egala (pentru a abstractiza diacriticile si upper/
lower case), cu distanta de maxim 2km intre ele (aici vom mai incerca
si alte valori, in functie de rezultate). Lista generata o vom folosi
intr-o procedura manuala pentru a analiza daca punctele existente au
informatii utile (de ex. old_name, nume in alte limbi, etc),
includerea acestora in descrierea noilor puncte si apoi stergerea
punctelor vechi.

Cel mai mult imi pare rau ca datele de la voi contin codurile postale
vechi - exista vreo sansa sa refaceti datele cu codurile noi?
Oricum, probabil aceasta nu se va face peste noapte si includerea
acestor date ar putea fi facuta ulterior - chiar daca ceva mai greu.

Este OK includerea campului source=geo-spatial.org , sau consideri
utila o alta nota?

Ciprian Talaba

unread,
Jun 11, 2009, 7:46:15 AM6/11/09
to tal...@openstreetmap.org
Salutare Nini,


2009/6/11 indreias <indr...@gmail.com>

Cel mai mult imi pare rau ca datele de la voi contin codurile postale
vechi - exista vreo sansa sa refaceti datele cu codurile noi?
Oricum, probabil aceasta nu se va face peste noapte si includerea
acestor date ar putea fi facuta ulterior - chiar daca ceva mai greu.



Din pacate nu cred ca este posibil sa fie actualizate codurile postale, pentru ca cele noi sunt la nivel de strada (chiar mai multe coduri postale pentru o strada lunga) si nu la nivel de localitate. Nu stiu daca ar fi posibil sa fie folosita radacina comuna, de exemplu 800000 pentru Galati.

--Ciprian

Vasile Craciunescu

unread,
Jun 11, 2009, 8:10:32 AM6/11/09
to tal...@openstreetmap.org
Nini,

Codurile postale sînt preluate tot din baza de date de la Institutul de
Statistică... din păcate pe aceasta nu o actualizează. Voi căuta să văd
daca există o baza de date publică cu codurile poștale. Apoi voi pune la
punct o procedură de join cu datele existente pe geo-spatial.org. Ideal
ar fi să găsesc codurile poștale asociate cu codurile SIRUTA... dar ma
cam îndoiesc :)

Folosirea valorii "geo-spatial.org" la tag-ul source este OK.

Vasile

Vasile Craciunescu

unread,
Jun 11, 2009, 8:17:30 AM6/11/09
to tal...@openstreetmap.org
Corect, majoritatea localităților din țară au însă un singur cod. Pot da
aici exemplul municipiului Câmpulung Moldovenesc (> 20 000 locuitori)
care are cod unic.

Vasile

> ------------------------------------------------------------------------

Ioan Indreias

unread,
Jun 11, 2009, 9:06:34 AM6/11/09
to tal...@openstreetmap.org
Pînă luni vom publica un update ce vizează coordonatele localităților
din 33 de județe (cele cuprinse între Buzău și Giurgiu).

Vasile,

Acum am remarcat nota ta despre update-ul programat sa fie facut pana luni. 

Voi decala procedura de import pana ne dai un semn ca datele sunt "la zi" astfel incat sa nu ratez update-urile voastre. Te rog ca dupa ce finalizati update-ul sa ne dai "OK-ul", eventual locatia lor (daca difera de cea mentionata anterior - http://earth.unibuc.ro/download/romania-seturi-vectoriale).

Multumesc,
Nini.

gabri3l

unread,
Jun 11, 2009, 11:39:42 AM6/11/09
to tal...@openstreetmap.org
Salut.


Am facut o mica periere cu verificarea daca localitatile respective
aveau date suplimentare si le-am adaugat la cele uploadate de
Indreias.


Gabi

On Jun 11, 1:27 pm, Francisc TOTH <yo6...@yahoo.com> wrote:
> mai e o problema la decizia village/hamlet, am gasit la sud de orasul Blaj localitatile Fliteşti si Deleni+Obârşie, care au population=4 şi 5 şi totuşi sunt marcate ca village. In plus, confirm ca sunt hamlet, Fliteşti in 1995 era nelocuit.
>

> --- On Thu, 6/11/09, indreias <indre...@gmail.com> wrote:


>
> From: indreias <indre...@gmail.com>
> Subject: Re: [Talk-ro] Import în masă a localităților (thread #2)
> To: talk...@openstreetmap.org
> Date: Thursday, June 11, 2009, 12:58 PM
>
> Multumesc - greseala cu România a fost corectata.
> Numele judetului este preluat din csv si va fi sigur cu diacritice.
>
> Incerc sa vad cine a facut perierea duplicatelor (cel putin la Alba
> Iulia l-am gasit pe gabri3l) sa vad ce pot face ca sa nu pierd
> informatia unificata deja.
>
> Toate bune,
> Nini
>
> _______________________________________________
> Talk-ro mailing list

> Talk...@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ro
>
> _______________________________________________
> Talk-ro mailing list
> Talk...@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ro

indreias

unread,
Jun 11, 2009, 3:36:46 PM6/11/09
to tal...@openstreetmap.org
Salut Gabriel,

M-am uitat prin schimbarile facute de tine si din cat mi-am dat seama
doar la Alba Iulia au fost date de tip old_name, name:hu, etc.
Mai tii minte sa mai fie si alta localitate?

Multumesc mult pentru informatii,
Nini

_______________________________________________
Talk-ro mailing list
Tal...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ro

gabri3l

unread,
Jun 11, 2009, 4:29:17 PM6/11/09
to tal...@openstreetmap.org
Salut


se pare ca doar la Alba Iulia am facut modificari.


Gabi

On Jun 11, 10:36 pm, indreias <indre...@gmail.com> wrote:
> Salut Gabriel,
>
> M-am uitat prin schimbarile facute de tine si din cat mi-am dat seama
> doar la Alba Iulia au fost date de tip old_name, name:hu, etc.
> Mai tii minte sa mai fie si alta localitate?
>
> Multumesc mult pentru informatii,
> Nini
>
> _______________________________________________
> Talk-ro mailing list

> Talk...@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ro

Eddy Petrișor

unread,
Jun 11, 2009, 6:20:48 PM6/11/09
to tal...@openstreetmap.org
indreias a scris:

> Salut Vasile,
>
> Multumesc pentru informatiile transmise.
>
> Si eu sunt sigur ca localitatile existente nu contin date SIRUTA iar

Apropos de SIRUTA, am văzut că în unele locuri au fost adăugate
informaţiile SIRUTA direct cu chei de genul "TIP", "SIRUTA" etc.

As vrea să vă sugerez să adaugați informațiile ăstea într-un „namespace”
propriu și să se folosească chei de tipul:

siruta:siruta
siruta:tip
siruta:superior
siruta:denumire
siruta:judet

Pentru a nu încurca și a nu suprascrie eventualele date deja existente
cu cele din siruta si pentru a clarifica faptul că există o corelație
între informațiile cu pricina.

> duplicatele le vom detecta prin analiza de proximitate (cu metodele
> GIS din postgres) pentru puncte de tip localitate (place != ""), cu
> nume de lungime egala (pentru a abstractiza diacriticile si upper/
> lower case), cu distanta de maxim 2km intre ele (aici vom mai incerca
> si alte valori, in functie de rezultate). Lista generata o vom folosi
> intr-o procedura manuala pentru a analiza daca punctele existente au
> informatii utile (de ex. old_name, nume in alte limbi, etc),
> includerea acestora in descrierea noilor puncte si apoi stergerea
> punctelor vechi.

Am ceva obiecții la procedura asta:

1) nu sunt de acord să se ștergă nodurile vechi; acestea au un istoric
și se pot muta pe pozițiile noi; adăugarea unui nod total nou face sa se
piarda tot istoricul pierzându-se informații importante
2) nodurile actuale ar putea avea informații utile, trebuie să se facă o
uniune a datelor din nodul actual cu cele din import; de exemplu, eu am
adăugat în multe locuri populația localităților
3) NU SUPRASCRIEȚI INFORMAȚII EXISTENTE!!! chiar eu știu că am adăugat
codurile poștale noi pentru câteva localități din Olt, deci scriererea
codurilor poștale vechi ar șterge codurile actuale

> Cel mai mult imi pare rau ca datele de la voi contin codurile postale
> vechi - exista vreo sansa sa refaceti datele cu codurile noi?

aș sugera addr:old_postcode ca nume de cheie pentru acele coduri poștale
cu ștergerea lui addr:postcode dacă e identic cu cel din baza de date -
deoarece, evident e cel vechi, cel nou trebuie adăugat; prezența codului
poștal vechi în forma asta ajută la identificarea localităților/zonelor
în care codul nou lipsește.

> Oricum, probabil aceasta nu se va face peste noapte si includerea
> acestor date ar putea fi facuta ulterior - chiar daca ceva mai greu.
>
> Este OK includerea campului source=geo-spatial.org , sau consideri
> utila o alta nota?

sugerez "source:siruta=geo-spatial.org" pentru a nu suprascrie valorile
existente și pentru a clarifica care e obiectul lui "source"

signature.asc

Eddy Petrișor

unread,
Jun 12, 2009, 3:09:15 AM6/12/09
to tal...@openstreetmap.org
indreias a scris:

> Salut Eddy,
>
> Multumesc mult pentru script - l-am integrat in parser si totul pare
> OK.
> In urma testelor am adaugat si particula "Lui" la trecerea in
> minuscule (ex. "Valea lui Mihai").

Cred că ar fi bine să adaugi și "Cel" - Alexandru cel Bun, Stefan cel Mare

> $line =~ s/ (Lui|De|Din|Spre|La|Si|Pe|Și|Prin|Dinspre|Cu) / \l$1 /g;

Mă gândesc să adaug scriptul la un repo public. Eu am mai făcut câteva
mici schimbări (după ce am mai citit un pic de documentație).

> Astazi voi sterge datele introduse ieri (judetul Alba) si le voi re-
> importa (in jurul orei 17:00). Sper ca Francisc sa aiba timp si sa
> transmita mai multe detalii ref. la observatiile lui de ieri.
>
> Ref. la mediul meu de lucru (ca o scuza pentru mentiunea mea despre
> diacritice...) lucrez cu cygwin pe o statie Windows si sunt total
> neobisnuit sa lucrez cu diacritice. Nu ma pot schimab si nici nu vreau
> sa pornesc o noua discutie pe aceasta tema - atata timp cat sursa are
> diacritice si cu ajutorul tau si al colegilor de aici reusim sa
> pastram informatia este excelent.

Hmm, sunt tare curios dacă nu cumva în urma transformării ai ajuns sa ai
chestii de genul:

CâMpulung, PetreșTi, SăVâRșIn

Adică nu cumva îți apare literă mare după oricare din diacritice?

Dacă da, atunci ai nevoie de locale și probabil de noul script care are
grijă să forțeze locala pe ro_RO.UTF-8 în script pentru a procesa corect
datele.

Noul script e atașat.

signature.asc
correct_case.pl

Ioan Indreias

unread,
Jun 12, 2009, 5:50:22 AM6/12/09
to tal...@openstreetmap.org
Salut Eddy,

Am preluat ultima varianta a scriptului si de asemenea am adaugat in tool-ul de parsare regulile de sed mentionate aici pentru ca diacriticile din fisierele sursa sunt de tip gresit (cel putin eu asa am inteles).

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

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

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.

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.

Multumesc,
Nini.

2009/6/12 Eddy Petrișor <eddy.p...@gmail.com>
_______________________________________________
Talk-ro mailing list
Tal...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ro




--
Best regards,
Ioan (Nini) Indreias - indr...@gmail.com
ab.csv
ab.v3.osm

Francisc TOTH

unread,
Jun 12, 2009, 7:03:44 AM6/12/09
to tal...@openstreetmap.org
Salut!

Te rog nu uita sa verifici codul unde faci decizia village/hamlet(>50/<=50), ca pare a fi o problema, am mai gasit un village cu population:49, "Dealu Roatei"; Mentionam inainte Flitesti cu population:4 si Deleni-Obarsie cu population:5. Trei modificari manuale nu ar fi problema, dar mai urmeaza si alte judete. In rest e ok din ce am mai vazut.



--- On Fri, 6/12/09, Ioan Indreias <indr...@gmail.com> wrote:

From: Ioan Indreias <indr...@gmail.com>
Subject: Re: [Talk-ro] Import în masă a localităților (thread #2)
-----Inline Attachment Follows-----

Ioan Indreias

unread,
Jun 12, 2009, 7:56:39 AM6/12/09
to tal...@openstreetmap.org
Salut,

Multumesc pentru verificari.

Dealul Roatei este de tip 19 = sat care apartine de oras.
Flitesti si Deleni-Obarsie sunt de tip 10 = localitate componenta a unui municipiu (fara sa fie resedinta)

Redau mai jos switch-ul folosit, de aici se vede ca decizia pentru catun am luat-o doar satele care fac parte dintr-o comuna, fara sa fie resedinta ei (tip=23) si au populatie mai mica decat 50.

  switch ($7) {
    case /^(1|4|9|40)$/      : place="city"; break
    case /^(2|5|17)$/        : place="town"; break
    case /^(3|22)$/          : place="village"; break
    case /^23$/              : if (pop >= 50)
                               {
                                 place="village"
                               }
                               else
                               {
                                 place="hamlet"
                               }
                               break 
    case /^(11|19)$/         : place="village"; break
    case /^(10|18)$/         : place="village"; break
    case /^6$/               : place=""; break
    default                  : place=""; break
  }

Mai jos este tabelul extras din metodologia SIRUTA pentru gasi definitiile fiecarui tip

    Cod tip                    Denumire tip de unitate administrativ teritorială

    40                            Judeţ, municipiul Bucureşti

     1                             Municipiu  reşedinţă de judeţ, reşedinţă a municipiului Bucureşti

     2                             Oraş ce aparţine de judeţ, altul decât oraş  reşedinţă de judeţ

     3                             Comună

     4                             Municipiu, altul decât reşedinţă de judeţ

     5                             Oraş reşedinţă de judeţ

     6                             Sector al  municipiului Bucureşti

     9                             Localitate  componentă,  reşedinţă de  municipiu

   10                             Localitate componentă, a unui municipiu alta decât reşedinţă de municipiu                     

   11                             Sat ce aparţine de municipiu

   17                             Localitate componentă reşedinţă a oraşului

   18                             Localitate  componentă a unui oraş, alta decât reşedinţă de  oraş

   19                             Sat care aparţine  unui oraş

   22                             Sat reşedinţă de comună

   23                             Sat ce aparţine de comună, altul  decât reşedinţă de comună


1. Judeţul - este unitatea administrativ - teritorială alcătuită din municipii, oraşe şi comune ca unităţţi  de bază ale organizării administrativ - teritoriale a ţării, în funcţie de condiţiile geografice, economice şi social - politice, etnice, de legături culturale şi tradiţionale ale populaţiei.


2. Municipiul  - este unitate administrativ - teritorială cu caracter general urban  care are un număr mai mare de locuitori, o însemnătate deosebită în viaţa economică, social politică şi cultural - ştiinţifică a ţării, un important fond de locuinţe şi dotări edilitar - gospodăreşti, o reţea complexă de unităţi de învăţământ, sănătate şi culturală; se compune din una sau mai multe localităţi componente în unele cazuri chiar şi sate. 


3. Oraşul - este unitate administrativ - teritorială cu caracter urban  alcătuit din una sau mai multe localităţi componente, (uneori poate cuprinde şi sate), având dimensiuni variabile; cuprinde dotări edilitare speciale cu funcţie politic - administrativă, industrială, comercială, sau culturală şi clădiri grupate în ansambluri arhitectonice şi organizate în zone cu utilizări bine definite.

 

4. Comuna - este unitate administrativ - teritorială alcatuită din unul sau mai multe sate care cuprind populaţie rurală unită prin comunitate de interese şi tradiţii, fiind organizată în funcţie de condiţiile economice, social - culturale şi geografice. 

5. Localitatea componentă - este o aşezare umană cu populaţie urbană constituind o categorie social - teritorială  complexă; este o aglomerare de case şi construcţii gospodăreşti anexe mai dezvoltată din punct de vedere edilitar gospodăresc. 

6. Satul - este o aşezare umană mai puţin dezvoltată din punct de vedere edilitar gospodăresc a cărei populaţie se ocupă în deosebi cu agricultura, constituind o categorie social - teritorială complexă; este alcătuită dintr-o aglomerare de case şi construcţii gospodăreşti anexe într-un teritoriu cu specific rural. 

7. Capitala ţării, municipiul Bucureşti, este organizată din punct de vedere teritorial administrativ în   6 sectoare  delimitate pe criterii social - culturale şi geografice.


Parca este cam radicala decizia de a categorisi catun un sat/localitate  care apartine de oras / municipiu desi numarul de locuitori e fosrte mic (nota: poate mai indicat era suburb - dar nu cred ca e cazul) si de aceea verificarea catunelor le-am facut doar pentru tipul 23 (daca apartin de o comuna).

Astept in continuare comentariile voastre - nu este nimic batut in cuie iar scriptul poate fi foarte usor modificat.


Multumesc,
Nini


2009/6/12 Francisc TOTH <yo6...@yahoo.com>

Eddy Petrișor

unread,
Jun 12, 2009, 6:34:50 PM6/12/09
to tal...@openstreetmap.org
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.

signature.asc

indreias

unread,
Jun 16, 2009, 3:48:05 AM6/16/09
to tal...@openstreetmap.org
Salut Vasile,

Cand ai timp poate ne confirmi daca update-ul a fost finalizat sau nu
(vad ca toate au ca data 22.03.2009) pentru a putea sa ne apucam de
importul in OSM.

Multumesc,
Nini.

_______________________________________________

Vasile Craciunescu

unread,
Jun 16, 2009, 9:40:43 AM6/16/09
to tal...@openstreetmap.org
Nini,

N-am termint inca. Am fost silit sa plec intr-o deplasare in interes de
serviciu. Sper ca miine sa-mi gasesc timp sa finalizez setul de date.
Voi face un anunt in acest sens si pe lista de discutii.

Pina atunci poti sa lucrezi cu localitatile din judetele cuprinse intre
Alba si Braila. Acestea nu se vor schimba.

Numai bine,
Vasile

indreias

unread,
Jun 16, 2009, 3:20:30 PM6/16/09
to tal...@openstreetmap.org
Salut Vasile,

Nu este nici o problema - timp este "berechet" - asteptam un semn de
la tine.

Toate bune,
Nini

On Jun 16, 4:40 pm, Vasile Craciunescu <vasile.craciune...@gmail.com>
wrote:

> > Talk...@openstreetmap.org


> >http://lists.openstreetmap.org/listinfo/talk-ro
>
> _______________________________________________
> Talk-ro mailing list

> Talk...@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ro- Hide quoted text -
>
> - Show quoted text -

indreias

unread,
Jun 17, 2009, 10:10:02 AM6/17/09
to tal...@openstreetmap.org
Salut tuturor,

Am importat Alba, Arad si Arges acum 5 minute.

http://www.openstreetmap.org/browse/changeset/1545101
http://www.openstreetmap.org/browse/changeset/1545174
http://www.openstreetmap.org/browse/changeset/1545186

Toate bune,
Nini.

####

Salut!
Cred ca ar trebui inceput totusi cu Alba-Braila, sunt totusi 9 judete
si daca tot nu se modifica nimic la ele, nu are rost sa asteptam. Va
fi un pic de modificat si oricum tot noi le vom face. Eu ma inscriu sa
fac corectiile pentru Alba si Brasov pentru inceput.
Toate cele bune,
Francisc(owene)

Eddy Petrișor

unread,
Jun 17, 2009, 3:06:48 PM6/17/09
to tal...@openstreetmap.org

Da' până la urmă nu s-a făcut merge cu datele deja existente?

Știu că e relativ dificilă identificarea Sagu = Șagu, dar asta e ce am
văzut doar la o trecere fugitivă:

http://www.openstreetmap.org/?lat=46.06286&lon=21.28153&zoom=17&layers=0B00FTF

Pe de altă parte nu era deloc dificilă identificarea Piteștiului:

http://www.openstreetmap.org/browse/node/126383941
http://www.openstreetmap.org/browse/node/422879619


Credeam că importul ăstă se face responsabil nu hei-rupist...

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

_______________________________________________

Eddy Petrișor

unread,
Jun 17, 2009, 3:09:12 PM6/17/09
to tal...@openstreetmap.org
În data de 17 iunie 2009, 22:06, Eddy Petrișor
<eddy.p...@gmail.com> a scris:

>
> Pe 17 iunie 2009, 17:10, indreias<indr...@gmail.com> a scris:
> > Salut tuturor,
> >
> > Am importat Alba, Arad si Arges acum 5 minute.
> >
> > http://www.openstreetmap.org/browse/changeset/1545101
> > http://www.openstreetmap.org/browse/changeset/1545174
> > http://www.openstreetmap.org/browse/changeset/1545186
>
> Da' până la urmă nu s-a făcut merge cu datele deja existente?
>
> Știu că e relativ dificilă identificarea Sagu = Șagu, dar asta e ce am
> văzut doar la o trecere fugitivă:
>
> http://www.openstreetmap.org/?lat=46.06286&lon=21.28153&zoom=17&layers=0B00FTF
>
> Pe de altă parte nu era deloc dificilă identificarea Piteștiului:
>
> http://www.openstreetmap.org/browse/node/126383941
> http://www.openstreetmap.org/browse/node/422879619

http://www.openstreetmap.org/browse/node/356267877
http://www.openstreetmap.org/browse/node/422879634

Ciosici Manuel R.

unread,
Jun 17, 2009, 3:14:56 PM6/17/09
to tal...@openstreetmap.org
Aș vrea să ajut la verificarea importurilor pentru Arad, dar nu știu mai exact în ce constă această verificare. Ajutor?

2009/6/17 Eddy Petrișor <eddy.p...@gmail.com>



--
Manuel R. Ciosici
http://manuelciosici.com

indreias

unread,
Jun 17, 2009, 3:41:40 PM6/17/09
to tal...@openstreetmap.org
Salut Eddy,

O sa verific care sunt problemele pe care le-ai remarcat mai sus. Nu
inteleg insa ironia ta - explicatia asupra importului a fost simpla:
nu se fac verificari asupra datelor care exista ci se aduga datele
prezente pe geo-spatial.org. Dublurile se rezolva manual, asa cum a
facut deja owne in Alba. Avem un "select" in postgres care detecteaza
dubluri si care o sa dea o lista de astfel de noduri. Totul este sub-
control si nu s-a facut nimic hei-rupist.

Nini.

On Jun 17, 10:09 pm, Eddy Petrișor <eddy.petri...@gmail.com> wrote:
> În data de 17 iunie 2009, 22:06, Eddy Petrișor

> <eddy.petri...@gmail.com> a scris:


>
>
>
>
>
>
>
> > Pe 17 iunie 2009, 17:10, indreias<indre...@gmail.com> a scris:
> > > Salut tuturor,
>
> > > Am importat Alba, Arad si Arges acum 5 minute.
>
> > >http://www.openstreetmap.org/browse/changeset/1545101
> > >http://www.openstreetmap.org/browse/changeset/1545174
> > >http://www.openstreetmap.org/browse/changeset/1545186
>
> > Da' până la urmă nu s-a făcut merge cu datele deja existente?
>
> > Știu că e relativ dificilă identificarea Sagu = Șagu, dar asta e ce am
> > văzut doar la o trecere fugitivă:
>

> >http://www.openstreetmap.org/?lat=46.06286&lon=21.28153&zoom=17&layer...


>
> > Pe de altă parte nu era deloc dificilă identificarea Piteștiului:
>
> >http://www.openstreetmap.org/browse/node/126383941
> >http://www.openstreetmap.org/browse/node/422879619
>

> http://www.openstreetmap.org/browse/node/356267877http://www.openstreetmap.org/browse/node/422879634


>
> > Credeam că importul ăstă se face responsabil nu hei-rupist...
>
> --
> Regards,
> EddyP
> =============================================
> "Imagination is more important than knowledge" A.Einstein
>
> _______________________________________________
> Talk-ro mailing list

> Talk...@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ro

indreias

unread,
Jun 17, 2009, 3:46:42 PM6/17/09
to tal...@openstreetmap.org
Salut Manuel,

Deocamdata nu este nevoie de prea mult lucru - daca ai timp si vezi ca
sunt 2 localitati dublate se muta punctul vechi aproximativ unde este
punctul nou (cel cu campurile SIRUTA) si se copiaza datele noi (eu as
face chestia asta cu CTRL+R in Potlach). Dupa care se va sterge
punctul nou. Asa nu se va pierde istoria punctului vechi.

Eventual Francisc poate da mai multe detalii asupra metodologiei pe
care a folosita la join-ul manual pe care l-a facut in Alba.

Toate bune,
Nini.

On Jun 17, 10:14 pm, "Ciosici Manuel R." <manuelrcios...@gmail.com>
wrote:


> Aș vrea să ajut la verificarea importurilor pentru Arad, dar nu știu mai
> exact în ce constă această verificare. Ajutor?
>

> 2009/6/17 Eddy Petrișor <eddy.petri...@gmail.com>


>
>
>
>
>
> > În data de 17 iunie 2009, 22:06, Eddy Petrișor

> > <eddy.petri...@gmail.com> a scris:


>
> > > Pe 17 iunie 2009, 17:10, indreias<indre...@gmail.com> a scris:
> > > > Salut tuturor,
>
> > > > Am importat Alba, Arad si Arges acum 5 minute.
>
> > > >http://www.openstreetmap.org/browse/changeset/1545101
> > > >http://www.openstreetmap.org/browse/changeset/1545174
> > > >http://www.openstreetmap.org/browse/changeset/1545186
>
> > > Da' până la urmă nu s-a făcut merge cu datele deja existente?
>
> > > Știu că e relativ dificilă identificarea Sagu = Șagu, dar asta e ce am
> > > văzut doar la o trecere fugitivă:
>

> >http://www.openstreetmap.org/?lat=46.06286&lon=21.28153&zoom=17&layer...


>
> > > Pe de altă parte nu era deloc dificilă identificarea Piteștiului:
>
> > >http://www.openstreetmap.org/browse/node/126383941
> > >http://www.openstreetmap.org/browse/node/422879619
>
> >http://www.openstreetmap.org/browse/node/356267877
> >http://www.openstreetmap.org/browse/node/422879634
>
> > > Credeam că importul ăstă se face responsabil nu hei-rupist...
>
> > --
> > Regards,
> > EddyP
> > =============================================
> > "Imagination is more important than knowledge" A.Einstein
>
> > _______________________________________________
> > Talk-ro mailing list

> > Talk...@openstreetmap.org

> _______________________________________________
> Talk-ro mailing list
> Talk...@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ro

_______________________________________________

Eddy Petrișor

unread,
Jun 18, 2009, 8:08:46 AM6/18/09
to tal...@openstreetmap.org
Pe 17 iunie 2009, 22:41, indreias<indr...@gmail.com> a scris:
> Salut Eddy,
>
> O sa verific care sunt problemele pe care le-ai remarcat mai sus. Nu

Acelea sunt doar două-trei pe care le-am văzut fără să fac vreun efort.
Situația e prezentă pentru multe alte localități.

> inteleg insa ironia ta - explicatia asupra importului a fost simpla:
> nu se fac verificari asupra datelor care exista ci se aduga datele
> prezente pe geo-spatial.org. Dublurile se rezolva manual, asa cum a

Se putea face de la bun început și automat unirea cu datele exsitente, fără
a mai fi necesară orice intervenție manuală ulterioară. Asta am spus de la
bun început și așa am crezut că va fi planul, mai ales după ce am obiectat
când s-a lăsat a se înțelege că se va proceda așa cum s-a procedat.

Credeam că nu a fost o întrebare retorică atunci când s-a cerut părerea celor
de pe listă, dar se pare că m-am înșelat.

Ce mă deranjează e că acum datele pentru România sunt într-o stare mult
mai rea decât erau înainte dpdv al unui utilizator obișniut și ca s-a creat în
mod inutil muncă în urma căreia n-avem nici o garanție că totul va fi prelucrat
corect, tocmai pentru că e făcută manual.

> facut deja owne in Alba. Avem un "select" in postgres care detecteaza
> dubluri si care o sa dea o lista de astfel de noduri. Totul este sub-

Sunt curios (sincer, nu e nici o ironie) care e acel select care
detectează dubluri?

> control si nu s-a facut nimic hei-rupist.

N-am vrut să jignesc pe nimeni, dar totul putea fi făcut mult mai bine
fără riscul
de a rata elemente sau a bulibăși manual datele.

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

_______________________________________________
Talk-ro mailing list
Tal...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ro

Ioan Indreias

unread,
Jun 18, 2009, 10:04:29 AM6/18/09
to tal...@openstreetmap.org
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. 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.

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

Toate bune,
Nini.

2009/6/18 Eddy Petrișor <eddy.p...@gmail.com>

Ioan Indreias

unread,
Jun 19, 2009, 2:55:04 AM6/19/09
to tal...@openstreetmap.org
Salut,

M-am apucat de rezolvarea duplicatelor (am inceput parcurgerea listei de jos in sus, pentru a nu ma suprapune cu altcineva). Pana acum am terminat literele "V" si "Z".

Toate bune,
Nini.


###
 Valea Faurului   | Valea Faurului   | 422880866 | 317657616 | village | village |  833.072223201076 - done
 Valea Iașului    | Valea Iasului    | 422881443 | 317657624 | village | village |  269.431375804078 - done
 Valea Mare       | Valea Mare       | 422878141 | 280953963 | village | village |  131.102235439895 - done
 Vârfurile        | Vârfurile        | 422878407 | 195602958 | village | village |  313.886216822523 - done
 Vinerea          | Vinerea          | 422868394 | 290135976 | village | village |  46.0449869055464 - done (owene)
 Vinga            | Vinga            | 422878394 |  34088266 | village | village |  885.513102054709 - done
 Vladimirescu     | Vladimirescu     | 422877547 |  34088257 | village | village |  520.957598977028 - done
 Vulturești       | Vulturesti       | 422880810 | 295836506 | village | village |  2549.15130011227 - done
 Vărșand          | Vărșand          | 422878066 | 128104842 | village | village |  413.976326176831 - done
 Vărădia de Mureș | Vărădia de Mureș | 422878385 |  34088356 | village | village |   1827.5428082597 - done
 Zerind           | Zerind           | 422878335 | 119839814 | village | village |  322.053750411243 - done
 Zimandu Nou      | Zimandu Nou      | 422878362 | 119846475 | village | village |  597.985496523219 - done
 Zăbrani          | Zăbrani          | 422878320 |  34088296 | village | village |  870.680107041041 - done
 Zădăreni         | Zădăreni         | 422877741 | 243727159 | village | village |  651.424269785733 - done
 Zărand           | Zărand           | 422878344 | 137702027 | village | village |  160.788750623179 - done
###

indreias

unread,
Jun 19, 2009, 9:45:28 AM6/19/09
to tal...@openstreetmap.org
Un update pentru localitatile duplicate - au fost rezolvate
localitatile care incep cu G,H,I,J,L,S-Z
Francisc mi-a transmis ca mai lucreaza si el la acesta "mediere" -
poate ne face si el un update cand are timp.
Probabil ca luni vom termina duplicatele pentru cele 3 judete
importate.

Toate bune - si un weekend placut,
Nini.

Eddy Petrișor

unread,
Jun 19, 2009, 12:26:40 PM6/19/09
to tal...@openstreetmap.org
În data de 18 iunie 2009, 17:04, Ioan Indreias <indr...@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)

Ioan Indreias

unread,
Jun 19, 2009, 2:39:42 PM6/19/09
to tal...@openstreetmap.org
Salut Eddy,

Din pacate tot nu retin din extrasele pe care le-ai citat unde iti exprimi dezacordul referitor la adaugarea unui element nou, daca exista deja unul in proximitatea acestuia. Din cele de mai jos am retinut (si am fost de acord) ca nu vrei sa se piarda istoria punctelor vechi si de aceea, manual, se mediaza datele din punctul nou cu cele aferente punctului vechi si apoi se sterge punctul nou (dupa ce in prealabil punctul vechi fost mutat langa cel nou). Procesul acesta (inclusiv adaugarea codului postal nou ca "bonus") mi-a luat astazi aproximativ 5 minute per nod.

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

Revenind la subiect, procedura descrisa de tine imi pare mult mai completa si in mod cert implica o un efort redus in prelucrarea manuala a datelor. Din pacate cunostintele mele ref. la API-ul OSM (si in general la programare) nu ma recomanda ca si resursa care poate sa ajute - pot doar sa ma "inscriu" de pe acum pe lista celor care vor ajuta la procesarea manuala (pe baza recomandarilor agreate aici) a nodurilor ce au nevoie de mediere.

Toate bune,
Nini.

Cristian Draghici

unread,
Jun 19, 2009, 2:39:59 PM6/19/09
to tal...@openstreetmap.org


2009/6/19 Eddy Petrișor <eddy.p...@gmail.com>
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



Eddy Petrișor

unread,
Jun 19, 2009, 3:01:40 PM6/19/09
to tal...@openstreetmap.org
Pe 19 iunie 2009, 21:39, Cristian Draghici<cristian...@gmail.com> a scris:
> 2009/6/19 Eddy Petrișor <eddy.p...@gmail.com>

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

>> Eu mă gândisem la un algoritm de genul:


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

Câte județe mai sunt?

Ideea e că mâine am ceva programare la un medic pe de o parte și, pe
de altă parte, de vreo 2 zile încerc să dau de originea unui bug în
nucleul Linux[1], lucru care implică repetate compilări de nucleu și
reporniri, ceea ce nu mă ajută să programez la ceva pentru import.

Dacă mai sunt puține județe, probabil că nu are sens să mă așteptați,
dar dacă e vorba de toate, atunci probabil că după vreo 4-5 importuri
(cu corecții) ca acum am să reușesc să termin codul pentru ce am
vorbit bazat pe PythonOsmApi[2], în condițiile în care mă apuc cât de
repede pot mâine sau duminică.

[1] http://bugzilla.kernel.org/show_bug.cgi?id=12878
[2] http://wiki.openstreetmap.org/wiki/PythonOsmApi

Ioan Indreias

unread,
Jun 19, 2009, 3:09:56 PM6/19/09
to tal...@openstreetmap.org
Salut Eddy,

Am facut doar 3 importuri - Alba, Arad si Arges. Astfel incat eu zic ca timp este suficient (nu se asteapta nimeni sa fie facut ceva nou peste noapte), mai ales ca Vasile a promis un update pentru judetele "de la Braila in jos" (nu am apucat inca sa verific daca a facut update sau nu, oricum ramasese sa anunte pe lista).

Take your time,
Nini

Vasile Craciunescu

unread,
Jun 20, 2009, 5:15:24 AM6/20/09
to tal...@openstreetmap.org
Salutare tuturor,

Din pacate sint nevoit sa mai trag de timp pina marti/miercuri. Placa
video de la macbook-ul meu a cedat ieri dimineata. Cei de la service
mi-au promis ca placa noua va sosi marti.

Joi am facut local actualizarea coordinatelor pentru judetele in
cauza. N-am apucat sa le urc pe server deoarece am vrut sa transform
numele localitatilor din upper case in sentence case, dupa modelul
implementat de voi.

Toate bune,
Vasile

Sent from my iPhone

Vasile Crăciunescu

unread,
Jun 28, 2009, 10:23:23 AM6/28/09
to tal...@openstreetmap.org
Setul de date cu localitatile actualizate a fost publicat la http://earth.unibuc.ro/download/romania-seturi-vectoriale. Am modificat numele din "upper case" in "sentece case" (am adaugat "Sub" la regula de inlocuire: ( De | Din | Spre | La | Si | Pe | Și | Prin | Dinspre | Cu | Lui | Cel | Sub )) si am corectat diacriticele.

Numai bine,
Vasile

 

2009/6/20 Vasile Craciunescu <vasile.cr...@gmail.com>

Ioan Indreias

unread,
Jun 29, 2009, 2:33:22 PM6/29/09
to tal...@openstreetmap.org
Vasile ne-a dat vesti foarte bune - datele au fost actualizate.
 
Ramane sa aflam in ce stadiu este Eddy cu metoda noua de import.
 
Toate bune,
Nini

Ioan Indreias

unread,
Jun 30, 2009, 9:49:26 AM6/30/09
to tal...@openstreetmap.org
Intre timp am lucrat la un script de import al limitelor administrative pentru localitatile in care exista monumente istorice (datele de pe www.cultura.ro).

El se bazeaza pe aceeasi metoda de import ca cea folosita la importul localitatilor din Alba, Arad si Asrges (JOSM+mediere manuala ulterioara importului) si genereaza poligoane cu urmatoarele tag-uri (exemplu dat din datele generate pentru judetul Alba - 160 de poligoane/din 717 total localitati, 7182 de noduri):

  <tag k='place'       v='town' />
  <tag k='place_name'  v='Zlatna' />
  <tag k='boundary'    v='administrative'/>
  <tag k='admin_level' v='6' />
  <tag k='siruta:code' v='1945' />
  <tag k='landuse'     v='residential' />
  <tag k='source'      v='Mircea Angelescu (CCBYSA)'

Chiar daca nu este agreata aceasta metoda, am putea macar sa agreem ce tag-uri sunt necesare pentru limitele administrative.

Din ce am citit in wiki, aceste limite au tag-uri de tip place, place_name (name este folosit pentru punct).
De asemenea am adaugat codul SIRUTA pentru identificare si sursa punctelor (conform acceptului primit de la dl. Angelescu).
Boundary si admin_level cred ca nu mai trebuie discutate. Ar ramane landuse (am vazut ca multe din limitele existente deja au acest atribut - si mi se pare OK).

Ce parere aveti? Mai exista si alte tag-uri care ar trebui adaugate?

Toate bune,
Nini

Gabi

unread,
Jul 2, 2009, 2:46:06 PM7/2/09
to tal...@openstreetmap.org

Salut

 

Landuse=residential nu mi se pare corect. Trebuie gasita alt tag pentru ca dupa paerea mea se refera la zonele locuite dintr-o localitate, si nu la intreaga localitate care poate contine si zone industrial, agricole, etc.

Un tag area=yes considerate a mai fi necesar?

 

Gabi

 

From: talk-ro...@openstreetmap.org [mailto:talk-ro...@openstreetmap.org] On Behalf Of Ioan Indreias
Sent: 30 iunie 2009 16:49
To: tal...@openstreetmap.org
Subject: Re: [Talk-ro] Import în masă a localităților (thread #2)

 

Intre timp am lucrat la un script de import al limitelor administrative pentru localitatile in care exista monumente istorice (datele de pe www.cultura.ro).

Eddy Petrișor

unread,
Jul 2, 2009, 4:06:04 PM7/2/09
to tal...@openstreetmap.org
Scuze de inactivitate, zilele astea a fost nebunie la serviciu şi n-am
avut timp de nimic.

Am să lucrez la script în "uichend". Probabil că am să lucrez fix la
partea algoritmică presupunând că obţinerea datelor siruta pentru un
nod oarecare e deja o problemă rezolvată sau uşor rezolvabilă.

Apropo, un link direct la ceva date ar fi grozav.

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

_______________________________________________

Ioan Indreias

unread,
Jul 3, 2009, 3:29:20 AM7/3/09
to tal...@openstreetmap.org
Salut Eddy,

Link-ul catre setul de date este -> http://earth.unibuc.ro/download/romania-seturi-vectoriale#limita_unitati_relief - la sectiunea Localitati (punct)

Eu am lucrat cu seturi de date in format WGS84, csv, UTF-8.

Toate bune,
Nini.

2009/7/2 Eddy Petrișor <eddy.p...@gmail.com>

Ioan Indreias

unread,
Jul 3, 2009, 3:52:17 AM7/3/09
to tal...@openstreetmap.org
Salut Gabi,

La prima vedere landuse=residential poate parea o "prostie" - insa:

1. La randarea pe harta zona respectiva apare clar delimitata si poti sa-ti dai seama unde este o localitate

2. Am verificat si in alte zone din tara / strainatate si in cazul in care nu exista date mai concrete ref. la o localitate, este marcata in intregime cu marcajul propus. Inteleg ca in momentul in care cineva va putea introduce mult mai multe date concrete intr-o anumita zona, va putea renunta la marcajul respectiv pentru ca deja a marcat el insusi unde anume sunt zonele rezidentiale, industriale, agricole (intravilan agricol) etc.

3. Cheia "area" nu aduce o randare speciala pe harta, decat daca se specifica o valoare in cheia "highway", ceea ce nu e cazul nostru (sper sa nu gresesc)

4. Cand un poligon este inclus intr-un alt poligon inteleg ca la randare se va tine seama si fiecare va avea culoarea potrivita.
De ex. http://www.openstreetmap.org/?lat=44.6015&lon=26.07372&zoom=16&layers=B000FTF , unde zona de retail Prisma este inclusa (si marcata corect) in zona de parcare. 

Nu vreau sa impun cu forta utilizarea "landuse=residential" (si mie mi se pare cam trasa de par) si de aceea ii rog si pe ceilalti colegi sa-si spuna parerea. Ideea era sa nu facem un astfel de import (limite administrative pentru localitati) si pe urma cineva sa ne traga de urechi ca nu am pus acest marcaj.

Toate bune,
Nini

2009/7/2 Gabi <gabri3...@gmail.com>
_______________________________________________
Talk-ro mailing list
Tal...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ro

alex-map

unread,
Jul 3, 2009, 4:24:52 AM7/3/09
to tal...@openstreetmap.org
salut Gabi,

si eu sunt de aceeasi parere cu nini

cel ebune
Alex.

Gabriel Mihai

unread,
Jul 3, 2009, 2:53:13 PM7/3/09
to tal...@openstreetmap.org
Salut.
 
am observat si eu ca o zona marcata landuse=residential apare randata pe harta, fiind mai simplu de identificat limitele localitatilor.
Poate ca nu e rau sa fie folosit acest tag, cel putin pana la obtinerea unor date mai detaliate privind structura unei localitati, asa cum ai spus tu Nini.
 
 
Gabi

Eddy Petrișor

unread,
Jul 5, 2009, 2:36:22 PM7/5/09
to tal...@openstreetmap.org
Ioan Indreias a scris:
> Salut Eddy,

Salut,

Am lucrat în weekend la scriptul de import.

Momentan am funcționalitățile:
- descarcă harta în jurul unor coordonate (implicit un pătrat de 10km)
- localizează într-o hartă o localitate cu același nume simplificat cu
cel dorit

Mai rămâne de făcut:
- unirea cu datele existente (local)
- codul de buclare: citirea datelor, trimiterea/actualizarea datelor


Am să continui cu funcția de unificare a datelor într-un nod existent și
apoi am să fac resul de cod. Cum azi am lucrat destul de puțin la cod și
poate n-o să mai fac mare lucru în seara asta, ma aștept să termin cam
marți seara, dacă am puțin noroc și nu apare nimic ciudat la serviciu.

Iată aici o mică demonstrație a codului deja dezvoltat:

pentru un nod existent „Fărcașele”, jud. Olt (a se observa potrivirea cu
„farcasele”):

In [385]: area_xml_string = OsmLocImport.getMapAroundPoint (
lon=24.435989180315492,lat=44.148768483403522 )

In [386]: placelist = OsmLocImport.loacatePlaceInXML ( area_xml_string,
unicode('farcasele', 'utf-8') )

In [387]: placelist
Out[387]:
[{u'changeset': 519290,
u'id': 346375574,
u'lat': 44.148460399999998,
u'lon': 24.4341583,
u'tag': {u'created_by': u'Potlatch 0.10f',
u'is_in': u'Olt; Rom\xe2nia',
u'name': u'F\u0103rca\u0219ele',
u'place': u'village'},
u'timestamp': u'2009-02-16T21:58:18Z',
u'uid': 66944,
u'user': u'eddyp',
u'version': 1,
u'visible': True}]


pentru o localitate scrisă fără diacritice în OSM „Stoenești”[*], jud. Olt:

In [393]: area_xml_string = OsmLocImport.getMapAroundPoint (
24.497197808799143,44.116750822942301 )

In [394]: placelist = OsmLocImport.loacatePlaceInXML ( area_xml_string,
unicode('Stoenești', 'utf-8') )

In [395]: placelist
Out[395]:
[{u'changeset': 1741751,
u'id': 264493139,
u'lat': 44.118617200000003,
u'lon': 24.497794599999999,
u'tag': {u'addr:postcode': u'237430',
u'created_by': u'Potlatch 0.10f',
u'is_in': u'Olt;Romania',
u'name': u'Stoenesti',
u'place': u'village'},
u'timestamp': u'2009-07-05T18:26:03Z',
u'uid': 66944,
u'user': u'eddyp',
u'version': 6,
u'visible': True}]


pentru un nod inexistent „Oboga”, jud. Olt:

In [388]: area_xml_string = OsmLocImport.getMapAroundPoint (
24.087239915998325,44.424481557058428 )

In [389]: placelist = OsmLocImport.loacatePlaceInXML ( area_xml_string,
unicode('Oboga', 'utf-8') )

In [390]: placelist
Out[390]: []

> Link-ul catre setul de date este
> -> http://earth.unibuc.ro/download/romania-seturi-vectoriale#limita_unitati_relief -
> la sectiunea Localitati (punct)
>

> <http://earth.unibuc.ro/download/romania-seturi-vectoriale#limita_unitati_relief>Eu


> am lucrat cu seturi de date in format WGS84, csv, UTF-8.


[*] în OSM era introdus ca „Stoienesti” dar am corectat să șterg „i”-ul
în plus; ar fi probabil o idee bună să calculez o distanță lexicală
între cele două denumiri, dar cred că nu are sens să investesc timp în
așa ceva deoarece probabil nu sunt multe cazurile de genul ăsta în țară

signature.asc

Eddy Petrișor

unread,
Jul 5, 2009, 2:41:28 PM7/5/09
to tal...@openstreetmap.org
Eddy Petrișor a scris:

> Ioan Indreias a scris:
>> Salut Eddy,
>
> Salut,
>
> Am lucrat în weekend la scriptul de import.
>
> Momentan am funcționalitățile:
> - descarcă harta în jurul unor coordonate (implicit un pătrat de 10km)
> - localizează într-o hartă o localitate cu același nume simplificat cu
> cel dorit
>
> Mai rămâne de făcut:
> - unirea cu datele existente (local)
> - codul de buclare: citirea datelor, trimiterea/actualizarea datelor
>
>
>
>
> Am să continui cu funcția de unificare a datelor într-un nod existent și
> apoi am să fac resul de cod. Cum azi am lucrat destul de puțin la cod și
> poate n-o să mai fac mare lucru în seara asta, ma aștept să termin cam
> marți seara, dacă am puțin noroc și nu apare nimic ciudat la serviciu.
>
>
>
>
>
> Iată aici o mică demonstrație a codului deja dezvoltat:

> In [386]: placelist = OsmLocImport.loacatePlaceInXML ( area_xml_string,


> In [394]: placelist = OsmLocImport.loacatePlaceInXML ( area_xml_string,

> In [389]: placelist = OsmLocImport.loacatePlaceInXML ( area_xml_string,

Mda, tocmai am corectat numele funcției; acum e locate...

signature.asc

Eddy Petrișor

unread,
Jul 6, 2009, 7:05:59 AM7/6/09
to tal...@openstreetmap.org
Eddy Petrișor a scris:

Codul e public acum:

http://repo.or.cz/w/osm-ro-tools.git

Licența, deși lipsește fișierul, este GPLv3 sau mai recent.

signature.asc

Ioan Indreias

unread,
Jul 10, 2009, 7:55:05 AM7/10/09
to tal...@openstreetmap.org
Eddy Petrișor a scris:
- Show quoted text -


Salut Eddy,

Am vazut ca ai mai lucrat la proiectul de import. 

Pentru a fi sigur ca nu exista diferente intre structura datelor importate pana acum si ce se va face cu utilitarul dezvoltat de tine redau mai jos un extras din judetul Alba:

<node id='-5' visible='true' lat='46.020333036671254' lon='23.594298234285848'>
  <tag k='name'               v='Oarda'/>
  <tag k='siruta:code'        v='1053'/>
  <tag k='siruta:code_sup'    v='1017'/>
  <tag k='siruta:type'        v='10'/>
  <tag k='siruta:county'      v='Alba'/>
  <tag k='siruta:county_code' v='AB'/>
  <tag k='siruta:county_id'   v='1'/>
  <tag k='old_postal_code'    v='2515'/>
  <tag k='is_in'              v='Alba Iulia,Alba,România'/>
  <tag k='population'         v='1830'/>
  <tag k='place'              v='village'/>
  <tag k='source'             v='geo-spatial.org'/>

si un extras din sirutacsv.py

namemap = {  'X':'lon', \
             'Y':'lat', \
             'NAME':'name', \
             'SIRUTA':'siruta:code', \
             'OLD_POSTAL':'old_postal_code', \
             'RANG':'siruta:rank', \
             'TIP':'siruta:type', \
             'SIRUTA_SUP':'siruta:code_sup', \
             'NAME_SUP':'siruta:name_sup', \
             'COUNTY':'siruta:county', \
             'COUNTY_ID':'siruta:county_id', \
             'COUNTY_MN':'siruta:county_code', \
             'POP2002':'population2002', \
             'REGION':'region', \
             'REGION_ID':'siruta:region_id', \
             'ENVIRO_TYP':'siruta:enviro_type', \
             'SORT_CODE':'siruta:sortcode' }


Observatiile mele sunt urmatoarele:

1. population versus population2002 - as inclina spre population, population2002 nefiind (cred) un tag standard. Eventual un population:year_of_census=2002 - sau ceva similar?

2. subtag-urile rank,region, region_id, enviro_type si sortcode eu le-am considerat inutile

3. inteleg ca tag-urile is_in, place si source le adaugi ulterior, cele de mai sus fiind doar o mapare intre campurile datelor de intrare si corespondentul OSM - corect?

Sper sa nu  te superi ca fac aceasta interventie, ideea fiind de a ne asigura ca suntem pe calea cea buna.

Toate bune,
Nini

Eddy Petrișor

unread,
Jul 10, 2009, 6:14:44 PM7/10/09
to tal...@openstreetmap.org
Ioan Indreias a scris:

> Eddy Petrișor a scris:
> - Show quoted text -
> Codul e public acum:
>
> http://repo.or.cz/w/osm-ro-tools.git
>
>
>
> Salut Eddy,
>
> Am vazut ca ai mai lucrat la proiectul de import.
>
> Pentru a fi sigur ca nu exista diferente intre structura datelor
> importate pana acum si ce se va face cu utilitarul dezvoltat de tine
> redau mai jos un extras din judetul Alba:
>
> <node id='-5' visible='true' lat='46.020333036671254'
> lon='23.594298234285848'>
> <tag k='name' v='Oarda'/>
> <tag k='siruta:code' v='1053'/>
> <tag k='siruta:code_sup' v='1017'/>
> <tag k='siruta:type' v='10'/>
> <tag k='siruta:county' v='Alba'/>
> <tag k='siruta:county_code' v='AB'/>
> <tag k='siruta:county_id' v='1'/>
> <tag k='old_postal_code' v='2515'/>
> <tag k='is_in' v='Alba Iulia,Alba,România'/>
> <tag k='population' v='1830'/>
> <tag k='place' v='village'/>
> <tag k='source' v='geo-spatial.org <http://geo-spatial.org>'/>

>
> si un extras din sirutacsv.py
> <http://repo.or.cz/w/osm-ro-tools.git?a=blob;f=sirutacsv.py;h=627cf62cd4b11bc951c85362de47b289aae48222;hb=e6ebef69436f73e25c3e7318b420b0b8e171bfdf>

>
> namemap = { 'X':'lon', \
> 'Y':'lat', \
> 'NAME':'name', \
> 'SIRUTA':'siruta:code', \
> 'OLD_POSTAL':'old_postal_code', \
> 'RANG':'siruta:rank', \
> 'TIP':'siruta:type', \
> 'SIRUTA_SUP':'siruta:code_sup', \
> 'NAME_SUP':'siruta:name_sup', \
> 'COUNTY':'siruta:county', \
> 'COUNTY_ID':'siruta:county_id', \
> 'COUNTY_MN':'siruta:county_code', \
> 'POP2002':'population2002', \
> 'REGION':'region', \
> 'REGION_ID':'siruta:region_id', \
> 'ENVIRO_TYP':'siruta:enviro_type', \
> 'SORT_CODE':'siruta:sortcode' }
>
>
> Observatiile mele sunt urmatoarele:
>
> 1. population versus population2002 - as inclina spre population,
> population2002 nefiind (cred) un tag standard. Eventual un
> population:year_of_census=2002 - sau ceva similar?

vezi mai jos.

> 2. subtag-urile rank,region, region_id, enviro_type si sortcode eu le-am
> considerat inutile

Nu intenționez să introduc toate câmpurile, dar pentru a avea un cod
care e corect dpdv semantic, trebuia să am o mapare (mai ales că
capetele de rând erau scrise cu majuscule).

> 3. inteleg ca tag-urile is_in, place si source le adaugi ulterior, cele
> de mai sus fiind doar o mapare intre campurile datelor de intrare si
> corespondentul OSM - corect?

Da, corect.

Ideea era ca prin mapare să ajung cât mai aproape de ce apare direct în
OSM, urmând ca pentru multe din câmpuri să fac o verificare. De exemplu,
pentru population2002, mă gândeam la ceva de genul:

dacă există population deja, atunci population2002 ar putea deveni
„population:census_2002".

Încă nu mi-e clar dacă ar trebui ca is_in să fie de forma „AB;RO” sau de
forma „Alba;România”.

> Sper sa nu te superi ca fac aceasta interventie, ideea fiind de a ne
> asigura ca suntem pe calea cea buna.

Nu, chiar deloc, și scuze că mă tot târâi cu implementarea.

Legat de idea importului am trimis un mail pe -dev să întreb dacă
utilizarea în stilul în care intenționez/inteționam eu, cu cereri pentru
fiecare localitate în parte, mi-ar putea atrage o interdicție de acces
la API:

http://lists.openstreetmap.org/pipermail/dev/2009-July/016102.html


Răspunsul lui Ævar m-a făcut să mă gândesc mai bine dacă nu cumva ar fi
o idee mai bună să am o instanță locală de postgres cu datele importate
via osmosis pentru a evita „ciocănirea” bazei de date în mod excesiv.


Oricum ar fi, am să continui lucrul mâine și duminică.

signature.asc

Ionut Muntean

unread,
Jul 10, 2009, 6:59:10 PM7/10/09
to tal...@openstreetmap.org
Daca vrei, iti fac o baza cu ultimul extract Romania pe
smaug.openstreet.ro, un cont shell pe server si lucreaza pe smaug. Ca
doar pentru asta exista pe lumea asta serverul asta.

/ Ionut

Eddy Petrișor wrote:
> ...


>
>
> Legat de idea importului am trimis un mail pe -dev să întreb dacă
> utilizarea în stilul în care intenționez/inteționam eu, cu cereri pentru
> fiecare localitate în parte, mi-ar putea atrage o interdicție de acces
> la API:
>
> http://lists.openstreetmap.org/pipermail/dev/2009-July/016102.html
>
>
> Răspunsul lui Ævar m-a făcut să mă gândesc mai bine dacă nu cumva ar fi
> o idee mai bună să am o instanță locală de postgres cu datele importate
> via osmosis pentru a evita „ciocănirea” bazei de date în mod excesiv.
>
>
> Oricum ar fi, am să continui lucrul mâine și duminică.
>
>
>

Ioan Indreias

unread,
Jul 11, 2009, 2:28:33 PM7/11/09
to tal...@openstreetmap.org


2009/7/11 Eddy Petrișor <eddy.p...@gmail.com>

Încă nu mi-e clar dacă ar trebui ca is_in să fie de forma „AB;RO” sau de
forma „Alba;România”.

Salut Eddy,

Eu propun sa ramanem la formula:
is_in=<nume_administrativ_sup (fara "prefix" de tip Municipiul/Comuna>,<nume_judet (nu abreviat)>,Romania

Daca nume_administrativ_sup=numele_localitatii atunci nu se va mai trece. Adica, la Alba Iulia avem Municipiul Alba Iulia ca si nume_sup si nu se va mai trece Alba Iulia (este redundant). Pentru Oarda, nume_sup este Municipiul Alba Iulia astfel incat is_in a devenit: Alba Iulia,Alba,Romania

Putem discuta daca sa scoatem Municipiul/Comuna din is_in - alegerea noastra (fac referire si la colegul meu Cristian Draghici) a fost sa simplificam si sa scoatem acel "prefix".

A doua observatie este ref. la despartirea pe care am remarcat ca ai propus-o - si anume ";" versus ","
Din ce am citit pe wiki (http://wiki.openstreetmap.org/wiki/Key:is_in) despartirea se face cu "," - ai gasit in alta parte despartirea (pentru is_in) cu ";"?

Mult succes si toate bune,
Nini.

Eddy Petrișor

unread,
Jul 11, 2009, 3:35:23 PM7/11/09
to tal...@openstreetmap.org
Ioan Indreias a scris:
>
>
> 2009/7/11 Eddy Petrișor <eddy.p...@gmail.com
> <mailto:eddy.p...@gmail.com>>

>
> Încă nu mi-e clar dacă ar trebui ca is_in să fie de forma „AB;RO” sau de
> forma „Alba;România”.
>
>
> Salut Eddy,
>
> Eu propun sa ramanem la formula:
> is_in=<nume_administrativ_sup (fara "prefix" de tip
> Municipiul/Comuna>,<nume_judet (nu abreviat)>,Romania
>
> Daca nume_administrativ_sup=numele_localitatii atunci nu se va mai
> trece. Adica, la Alba Iulia avem Municipiul Alba Iulia ca si nume_sup si
> nu se va mai trece Alba Iulia (este redundant). Pentru Oarda, nume_sup
> este Municipiul Alba Iulia astfel incat is_in a devenit: Alba
> Iulia,Alba,Romania
>
> Putem discuta daca sa scoatem Municipiul/Comuna din is_in - alegerea
> noastra (fac referire si la colegul meu Cristian Draghici) a fost sa
> simplificam si sa scoatem acel "prefix".

Sunt de acord cu abordarea asta.

> A doua observatie este ref. la despartirea pe care am remarcat ca ai
> propus-o - si anume ";" versus ","
> Din ce am citit pe wiki (http://wiki.openstreetmap.org/wiki/Key:is_in)
> despartirea se face cu "," - ai gasit in alta parte despartirea (pentru
> is_in) cu ";"?

Aceea e doar o propunere, dar, de facto, separatorul cel mai des folosit
este „;”. Mai mult, atunci când Potlatch unește două valori diferite
pentru aceiași etichetă (ex. unirea a două segmente într-unul singur,
iar „name” e diferit) folosește tot separatorul „;”. Din câte știu,
singurul câmp care face discrepanță la separatori e tocmai acel is_in,
din pricina acelei precizări din wiki.


(Știu că e puțin imprecisă numărătoarea în felul ăsta, dar ne putem face
o idee)


0 eddy@heidi ~/usr/src/osm/planet/git-planet-rom $ grep ';'
planet-rom.osm | wc -l
1335
0 eddy@heidi ~/usr/src/osm/planet/git-planet-rom $ grep ';'
planet-rom.osm | egrep -v
'(is_in|local:picture|note|description|wpt_symbol|source|fixme|created_by|quot|apos|amp)'
| wc -l
353
0 eddy@heidi ~/usr/src/osm/planet/git-planet-rom $ grep ','
planet-rom.osm | wc -l
2711
0 eddy@heidi ~/usr/src/osm/planet/git-planet-rom $ grep ','
planet-rom.osm | egrep -v
'(is_in|local:picture|note|description|wpt_symbol|source|fixme|created_by|quot|apos|amp)'
| wc -l
133

signature.asc
Reply all
Reply to author
Forward
0 new messages