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."
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-vectorialede 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>
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 municipiu2,5,17 town orase si resedinta de oras3,11,19,22,23 village sate si comune10,18 village alte localitati6 <null> aici nu am idee ce sa trec (sunt sectoarele Bucurestiului)
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 tipplace=municipalityname=MUNICIPIUL ALBA IULIA
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 |
_______________________________________________
Talk-ro mailing list
Tal...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ro
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
> >http://lists.openstreetmap.org/listinfo/talk-ro
>
> --
> Manuel R. Ciosicihttp://manuelciosici.com
>
> _______________________________________________
> Talk-ro mailing list
> Talk...@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ro
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
###
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
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: |
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.
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
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.
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.
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: |
|
Date: Wednesday, June 10, 2009, 10:34 PM |
|
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.
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: |
|
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
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?
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.
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
> ------------------------------------------------------------------------
Pînă luni vom publica un update ce vizează coordonatele localităților
din 33 de județe (cele cuprinse între Buzău și Giurgiu).
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
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
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
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"
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.
_______________________________________________
Talk-ro mailing list
Tal...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ro
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: |
|
-----Inline Attachment Follows----- |
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.
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.
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.
_______________________________________________
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
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:
> >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 -
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)
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
_______________________________________________
http://www.openstreetmap.org/browse/node/356267877
http://www.openstreetmap.org/browse/node/422879634
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
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
> >http://lists.openstreetmap.org/listinfo/talk-ro
>
> --
> Manuel R. Ciosicihttp://manuelciosici.com
>
> _______________________________________________
> Talk-ro mailing list
> Talk...@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ro
_______________________________________________
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
Toate bune - si un weekend placut,
Nini.
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)
>> 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
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
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).
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
_______________________________________________
_______________________________________________
Talk-ro mailing list
Tal...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ro
si eu sunt de aceeasi parere cu nini
cel ebune
Alex.
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ă
> 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...
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.
Eddy Petrișor a scris:
- Show quoted text -
Codul e public acum:
http://repo.or.cz/w/osm-ro-tools.git
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ă.
/ 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ă.
>
>
>
Încă nu mi-e clar dacă ar trebui ca is_in să fie de forma „AB;RO” sau de
forma „Alba;România”.
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