[Talk-ro] Import automatizat pentru limita localitatilor (via cultura.ro)
Janos Rusiczki
Ioan Indreias
Ma bucur ca proiectul acesta nu a fost abandonat - felicitarile mele
pentru efortul de pana acum.
Observatiile mele ar fi urmatoarele:
1. de ce layer=-3 ? In sensul ca nu e nimic "ingropat" acolo -
probabil exista motive pentru care ai facut aceasta alegere si daca ai
putea sa explici ar fi excelent.
2. eu as adauga si codul SIRUTA -> siruta:code = XXXX
3. cred ca e necesar si tag-ul urmator -> admin_level=6
4. numele cred ca trebuie pus sub forma -> place_name = YYYYY
'The name of the place. place_name is used for closed ways drawn
around the perimeter of a place, while the straightforward "name" tag
is used on a central node.'
5. Inclin sa cred ca ar trebui completat cu
place=city|town|village|hamlet etc -> aici exista o decizie de alegere
a tipului de localitate bazat pe datele de la ultimul recensamant.
datele sunt cuprinse in setul pus la dispozitie de Vasile si poate
Eddy poate sa puna la dispozitie blocul decizional folosit de el la
importul localitatilor ca "puncte" pentru a-l refolosi.
Asta daca nu poti sa obtii aceasta informatie pe baza unei interogari
dupa codul siruta (cred ca ar fi cel mai bine insa nu stiu exact cum
poti sa o implementezi in tool-ul tau).
Toate bune,
Nini.
2009/11/26 Janos Rusiczki <janos.r...@gmail.com>:
> _______________________________________________
> Talk-ro mailing list
> Tal...@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ro
>
>
_______________________________________________
Talk-ro mailing list
Tal...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ro
Janos Rusiczki
Stefan UNGUREANU
Pregateam si eu ceva similar, dar extras din datele de la CORINE Land
Cover. Acum astept aprobarea de la European Environment Agency ca sa le
pot posta pe serverul OSM.
Ce localitati sunt puse deja pe http://api06.dev.openstreetmap.org/ ?
Incerc sa fac un export si nu imi aduce nimic. Vroiam sa vad daca ce am
reusit sa scot din CLC se potriveste.
Poate reusim sa facem ceva impreuna, ar fi pacat sa fie muca facuta de
doua ori ;)
Stefan.
PS. Unde pe cultura.ro sunt datele ? nu dau de ele ... :)
Janos Rusiczki wrote:
> Salut,
>
> 1. Am eliminat tag-ul layer
> 2. Am adaugat codul SIRUTA
> 3. Sa mai confirme cineva daca trebuie admin_level ca eu din explicatia
> de aici http://bit.ly/4ZHd7K si mai ales din imaginea atasata inteleg ca
> ar fi vorba de conturul regiunii - nu e prea clar la ce refera acel
> "includes the surrounding area around the city/town/village"
> 4. Am schimbat tag-ul de denumire din name=* in place_name=*
> 5. Daca ma ajuta baietii cu modul in care se decide tipul place-ului pot
> include si asta.
>
> Recapituland, intrebarile sunt:
>
> 2. admin_level = ?
> 5. place = ?
>
> Multumesc mult pentru sesizari si astept feedback in continuare,
> Janos
>
> 2009/11/26 Ioan Indreias <indr...@gmail.com <mailto:indr...@gmail.com>>
> <mailto:janos.r...@gmail.com>>:
> > Salut,
> > Am avut o zi productiva! Am scris cateva script-uri pentru importul
> > automatizat al limitei localitatilor si la aceasta ora (1 AM) ma
> declar
> > multumit. :)
> > Treaba functioneaza in felul urmator:
> > 1. se ia un fisier de judet in format .kmz de pe cultura.ro
> <http://cultura.ro> si se decomprima
> > source = Mircea Anghelescu (cultura.ro <http://cultura.ro>)
> > Intrebari:
> > 1. am gresit ceva?
> > 2. ce tag-uri lipsesc? (pot adauga orice din SIRUTA)
> > In momentul in care ajungem la o forma "finala" ii voi da drumul,
> cam cu
> > cate un judet pe zi.
> > Alte note:
> > 1. Printr-o mai veche trasare manuala de test am observat ca
> aceste limite
> > sunt departe de a fi perfecte (in Baia Mare intregi cartiere
> ramaneau pe
> > dinafara) dar tot sunt mai bune decat nimic.
> > 2. Nu sunt toate localitatile.
> > 3. Script-ul de import nu "vede" daca o localitate are deja
> limita trasata
> > asa ca vor aparea dublari / suprapuneri care vor trebui depistate si
> > eliminate manual.
> > Noapte buna,
> > Janos
> > _______________________________________________
> > Talk-ro mailing list
> > Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
> > http://lists.openstreetmap.org/listinfo/talk-ro
> >
> >
>
> _______________________________________________
> Talk-ro mailing list
> Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
> http://lists.openstreetmap.org/listinfo/talk-ro
>
>
>
> ------------------------------------------------------------------------
Janos Rusiczki
Vasile Craciunescu
Frumoasă inițiativa! Pentru moment, singura mea corecție este legata de
numele domnului Angelescu. Corect ar fi "Mircea Angelescu" :)
Toate bune,
Vasile
Stefan UNGUREANU
Daca inteleg eu bine, poligoanele par a fi limitele localitatilor.
In CLC, se face diferentierea intre diferitele utilizari ale zonelor
urbane, si anume (cf. clasificarii din wiki) :
- Continuous urban fabric -> landuse = residential
- Discontinuous urban fabric -> landuse = residential
- Industrial or commercial units -> landuse = industrial/retail
- Port areas -> landuse = harbour
- Airports -> landuse = aerodrome
- Dump sites -> landuse = landfill
- Construction sites -> landuse = construction
De ex. Bucuresti-ul contine cam din toate cateva.
O idee : Daca ni se permite folosirea datelor CLC, nu ar fi posibil sa
le folosim pe ambele ? De ex. datele de pe cultura.ro pentru limitele
localitatilor si cele de la CLC pentru suprafetele propriu-zise ?
Datele de la CLC acopera in intregime toata suprafata tarii. Am atasat o
poza cu o parte din tipurile de landcover in zona Bucuresti.
Stefan.
Janos Rusiczki wrote:
> Aici sunt fisierele .kmz pentru care exista deja permisiune de folosire:
> http://www.cultura.ro/Documents.aspx?ID=282
>
> La punctul 4 mentionat de Nini, in legatura cu place_name, m-am uitat la
> cateva perimetre romanesti si toate au numele in name asa ca-s confuz. :)
>
> 2. admin_level = ?
> 4. name=* sau place_name=* ?
> 5. place = ?
>
> 2009/11/26 Stefan UNGUREANU <stefan.u...@mytrek.ro
> <mailto:stefan.u...@mytrek.ro>>
>
> Salut,
>
> Pregateam si eu ceva similar, dar extras din datele de la CORINE Land
> Cover. Acum astept aprobarea de la European Environment Agency ca sa le
> pot posta pe serverul OSM.
>
> Ce localitati sunt puse deja pe http://api06.dev.openstreetmap.org/ ?
> Incerc sa fac un export si nu imi aduce nimic. Vroiam sa vad daca ce am
> reusit sa scot din CLC se potriveste.
>
> Poate reusim sa facem ceva impreuna, ar fi pacat sa fie muca facuta de
> doua ori ;)
>
> Stefan.
>
> PS. Unde pe cultura.ro <http://cultura.ro> sunt datele ? nu dau de
> ele ... :)
>
> Janos Rusiczki wrote:
> > Salut,
> >
> > 1. Am eliminat tag-ul layer
> > 2. Am adaugat codul SIRUTA
> > 3. Sa mai confirme cineva daca trebuie admin_level ca eu din
> explicatia
> > de aici http://bit.ly/4ZHd7K si mai ales din imaginea atasata
> inteleg ca
> > ar fi vorba de conturul regiunii - nu e prea clar la ce refera acel
> > "includes the surrounding area around the city/town/village"
> > 4. Am schimbat tag-ul de denumire din name=* in place_name=*
> > 5. Daca ma ajuta baietii cu modul in care se decide tipul
> place-ului pot
> > include si asta.
> >
> > Recapituland, intrebarile sunt:
> >
> > 2. admin_level = ?
> > 5. place = ?
> >
> > Multumesc mult pentru sesizari si astept feedback in continuare,
> > Janos
> >
> > 2009/11/26 Ioan Indreias <indr...@gmail.com
> <mailto:indr...@gmail.com> <mailto:indr...@gmail.com
> > <mailto:janos.r...@gmail.com
> <mailto:Tal...@openstreetmap.org> <mailto:Tal...@openstreetmap.org
> <mailto:Tal...@openstreetmap.org>>
> > > http://lists.openstreetmap.org/listinfo/talk-ro
> > >
> > >
> >
> > _______________________________________________
> > Talk-ro mailing list
> > Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
> <mailto:Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>>
Janos Rusiczki
Manuel R. Ciosici
> Azi dupa cateva teste pe sandbox am trecut pe serverul principal:
>
> Rezultatul: (de exemplu) http://osm.org/go/0gXkj8K--
>
> De dragul comparatiei am facut si screenshot-uri before / after. Iata-le:
>
> Before: http://snurl.com/tis6d
> After: http://snurl.com/tis6g
>
> Chiar daca, asa cum spuneam inainte, sunt departe de a fi perfecte, eu
> zic ca e mult mai bine decat nimic.
>
> Sper ca e bine. Sa continui? Si daca da, cu ce judet?
>
> 2009/11/26 Stefan UNGUREANU <stefan.u...@mytrek.ro
>
> Multumesc.
>
> Daca inteleg eu bine, poligoanele par a fi limitele localitatilor.
>
> In CLC, se face diferentierea intre diferitele utilizari ale
> zonelor urbane, si anume (cf. clasificarii din wiki) :
>
> - Continuous urban fabric -> landuse = residential
> - Discontinuous urban fabric -> landuse = residential
> - Industrial or commercial units -> landuse = industrial/retail
> - Port areas -> landuse = harbour
> - Airports -> landuse = aerodrome
> - Dump sites -> landuse = landfill
> - Construction sites -> landuse = construction
>
> De ex. Bucuresti-ul contine cam din toate cateva.
>
> O idee : Daca ni se permite folosirea datelor CLC, nu ar fi
> posibil sa le folosim pe ambele ? De ex. datele de pe cultura.ro
> CLC pentru suprafetele propriu-zise ?
>
> Datele de la CLC acopera in intregime toata suprafata tarii. Am
> atasat o poza cu o parte din tipurile de landcover in zona Bucuresti.
>
> Stefan.
>
>
> Janos Rusiczki wrote:
>
> Aici sunt fisierele .kmz pentru care exista deja permisiune de
> folosire:
> http://www.cultura.ro/Documents.aspx?ID=282
>
> La punctul 4 mentionat de Nini, in legatura cu place_name,
> m-am uitat la cateva perimetre romanesti si toate au numele in
> name asa ca-s confuz. :)
>
> 2. admin_level = ?
> 4. name=* sau place_name=* ?
> 5. place = ?
>
> 2009/11/26 Stefan UNGUREANU <stefan.u...@mytrek.ro
> <mailto:stefan.u...@mytrek.ro>
> <mailto:stefan.u...@mytrek.ro>>>
>
>
> Salut,
>
> Pregateam si eu ceva similar, dar extras din datele de la
> CORINE Land
> Cover. Acum astept aprobarea de la European Environment Agency
> ca sa le
> pot posta pe serverul OSM.
>
> Ce localitati sunt puse deja pe
> http://api06.dev.openstreetmap.org/ ?
> Incerc sa fac un export si nu imi aduce nimic. Vroiam sa vad
> daca ce am
> reusit sa scot din CLC se potriveste.
>
> Poate reusim sa facem ceva impreuna, ar fi pacat sa fie muca
> facuta de
> doua ori ;)
>
> Stefan.
>
județ? poate Arad?
Manuel R. Ciosici
Rares Rusu
Parerea mea e ca arata excelent. Felicitari.
As vota si pentru cluj :)
Ciprian Talaba
Azi dupa cateva teste pe sandbox am trecut pe serverul principal:Rezultatul: (de exemplu) http://osm.org/go/0gXkj8K--De dragul comparatiei am facut si screenshot-uri before / after. Iata-le:Before: http://snurl.com/tis6dAfter: http://snurl.com/tis6gChiar daca, asa cum spuneam inainte, sunt departe de a fi perfecte, eu zic ca e mult mai bine decat nimic.Sper ca e bine. Sa continui? Si daca da, cu ce judet?
Pe harta arata bine, trebuie sa arunc o privire si pe datele din spate. Eu as mai astepta un pic pentru a continua, sper ca in curand vor apare mai multe idei pe lista.
Momentan am o idee care din pacate nu stiu cat de simpla e: pentru fiecare poligon ai putea face o verificare sa vezi daca exista un punct cu tag-ul place=* si sa copii etichetele ce contin informatiile SIRUTA de acolo. Ideal ar fi sa marchezi apoi acel punct intr-un anume fel pentru a elimina cumva duplicatele.
--Ciprian
Janos Rusiczki
Ciprian Talaba
Pai chiar te rog sa arunci o privire asupra datelor din background. Pentru tipul conturului am folosit algoritmul ce mi-a fost oferit azi de Eddy (multumesc!), astfel punctul care reprezinta localitatea si conturul vor avea acelasi tip de place. Am observat ca unele localitati au 2 sau chiar 3 contururi (Borșa in Maramures de exemplu are 2), dar asta nu e "vina" mea asa sunt datele provenit de la cultura.ro.Sunt deschis ideilor, de aia am si lansat discutia aici pe lista si ce mi s-a propus pana acuma am cam implementat. A cam fost cateva zile de pauza pe subiect asa ca am crezut ca s-a cam zis ce se putea zice si de aia m-am apucat. Si fiindca ma mancau degetele, desigur. :)Pentru propunerea ta: nu este necesar sa ma uit dupa informatiile SIRUTA in punctele de pe harta deorece am toate datele necesare in baza de date. Scrie-mi te rog ce alte tag-uri ai mai vrea sa apara pentru un poligon si le adaug.Pe azi ma opresc la 3 judete:Maramures - 153 contururi / 10938 puncteArad - 88 contururi / 4599 puncteCluj - 245 contururi / 13025 puncte (am dat drumul inainte sa citesc acest mail si se importa momentan)O sa vad cum pot sa adaug informatiile necesare la aceste 3 judete.
Nu e nici o problema, in cel mai rau caz exista posibilitatea sa faci revert la un changeset si sa o iei de la capat.
Sa revenim insa la problema noastra. Am studiat ce zice lumea pe wiki (din pacate cred ca acesta pagina are nevoie de un mod mult mai clar de prezentare a eventualelor posbilitati). Am cauta si exemple pe harta, din pacate cele mai multe se limiteaza la a adauga tag-ul landuse=residential si eventual sursa.
Asa ca am trecut la ideile proprii :). Am pornit de la utilizatorii acestor date si uneltele care le folosesc ei pentru a interpreta datele, si avem asa:
- motoare de rendering
- motoare de routing
- motoare de geocoding.
E posibil sa existe mult mai multe unelte dar teoretic se pot incadra cumva in una (sau mai multe) din categoriile de mai sus.
Solutille pe care le avem la indemana si cum sunt vazute ele din ochii respectivelor unelte:
1. un punct cu datele respectivei localitati + aria marcata numai cu landuse=residential
- rendering - OK, apare atat numele cat si suprafata localitatii
- geocoding - cautarea unei strazi intr-o localitate este aproximativa pentru ca poligonul nu are un nume atasat
- routing - OK, este posibil ca strazile ce se intersecteaza cu poligonul suprafetei sa fie considerate cu o limita de viteza mai mica decat restul.
2. un punct cu datele respectivei localitati + aria marcata cu place=* si name=* (place_name este prea putin folosit din ce am vazut eu folosind tag watch, asa ca nu il consider o varianta):
- rendering - OK? Nu stiu daca numele ariei va fi afisatt. Daca da, atunci avem si aici o problema pentru ca vvom avea 2 labeluri.
- geocoding - vor apare duplicate la cautarea localitatilor datorita existentei a 2 entitati (punctul si poligonul)
- routing - OK, este posibil ca strazile ce se intersecteaza cu poligonul suprafetei sa fie considerate cu o limita de viteza mai mica decat restul.
3. doar un poligon cu toate informatiile care exista deja pentru puncte (tagurile is_in mi se par foarte importante pentru geocoding), punctul urmand sa fie sters:
- rendering - aceeasi problema ca la varianta 2, aici insa exista pericolul ca sa nu fie afisat nici un label
- geocoding - OK, cautarea dupa localitati functioneaza bine, precum si filtrarea dupa o anumita localitate
- routing - OK, este posibil ca strazile ce se intersecteaza cu poligonul suprafetei sa fie considerate cu o limita de viteza mai mica decat restul.
4. ar fi varianta ce exista deja (puncte, fara poligoane):
- rendering - apare numele dar nu si suprafata
- geocoding - cautarea unei strazi intr-o localitate este aproximativa pentru ca poligonul nu exista
- routing - este nevoie de limita de viteza specificata pentru fiecare strada.
Variantele 1 si 3 mi se par ca au cele mai putine probleme, iar din cele 2 eu optez pentru 3. Alte pareri, opinii?
Numai bine,
Ciprian
Janos Rusiczki
Ciprian Talaba
Ioan Indreias a scris in al doilea mesaj din acest subiect de discutie:numele cred ca trebuie pus sub forma -> place_name = YYYYY[din wiki] 'The name of the place. place_name is used for closed ways drawn around the perimeter of a place, while the straightforward "name" tag is used on a central node.'
Stiu, am citit wiki-ul, insa citind si pagina de discutii atasata am vazut ca utilizarea etichetei place_name este departe de a fi acceptata de o majoritate, si cum ziceam acest lucru se vede in utilizarea efectiva a etichetei.
Parerea e ca nu poti sa ai doar conturul unei asezari. Argument? Prima oara se va sti intotdeauna locatia aproximativa a unei localitati care se va marca cu un punct. Abia dupa aia se traseaza conturul (fie el chiar aproximativ). Trebuie de avut in vedere ca nici ceea ce import eu nu este complet, raman destule localitati fara contur. Si atunci, ar fi total aiurea ca unele localitati sa fie reprezentate de un contur iar altele de un punct. Omogenitate = 0.
Mi se pare normal sa existe elemente in stadii diferite (stadiul 1 - punct, stadiul 2 - poligon), arata o evolutie a informatiei si nu o lipsa de omogenitate. E acelasi lucru cu a spune ca harta OSM nu e omogena pentru ca in Romania detaliile nu sunt aceleasi cu cele din Germania.
Mie cel mai OK din ce ai propus tu mi s-ar parea punctul 2: "un punct cu datele respectivei localitati + aria marcata cu place=*" cu amendamentul ca numele sa fie trecut sub place_name=*. Problema de rendering ar disparea in acest fel (name este randat, place_name nu este randat) iar problemele de geocodare se pot rezolva in timp daca se implementeaza un filtru. Ceea ce ar fi necesar in acest caz ar fi o legatura intre punct si contur ca sa nu fie necesara copierea si dublarea datelor existente la punct si pentru contur. Dar nu stiu cum se poate face asta.
Pare sa existe o solutie eleganta pentru a pastra ambele informatii, si care va fi tratata corect de toate uneltele mentionate in mailul anterior. Are la baza o relatie, si este prezentata sub forma de propunere aici: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Region. Una din motivatii este si faptul ca centrul poligonului nu reprezinta neaparat centrul orasului, si atunci ar fi ideal sa avem ambele informatii (din pacate din ce stiu datele importate de Eddy de pe geo-spatial.org se apropie mai mult de centrul matematic, decat de cel organizational, Vasile/Eddy va rog sa ma corectati daca gresesc).
Pentru un municipiu am avea urmatoarele etichete pe relatie:
type=region
name=*
region_category=city
region_type=city
Poligonul va avea numai atributul landuse=residential pentru a fi randat corect, precum si pentru a nu aparea duplicate in geocoding. Binenteles este posibil sa avem mai multe poligoane ce vor face parte din aceeasi relatie (de ex in cazul Galatiului e nevoie de acest lucru pentru cartierul de pe celalalt mal al Siretului).
Centrul va avea (cel putin) atributele:
place=*
name=*
Nu stiu unde e mai corect sa punem celelalte etichete (is_in, population, coduri SIRUTA), pe relatie sau doar pe centru.
Ce spuneti?
--Ciprian
Cristian Draghici
Ioan Indreias
Si eu sunt de aceeasi parere cu Cristi. M-am uitat pe setul de date pe
care l-ai trecut in productie si mie mi s-au parut OK.
Din partea mea un mare MULTUMESC pentru efortul depus si nu pot decat
sa te incurajez sa finalizezi acest import.
Toate bune,
Nini.
2009/12/3 Cristian Draghici <cristian...@gmail.com>:
> Eu sunt pentru rezultate rapide, chiar cu riscul necesitatii editarilor
> ulterioare.
> Intoarcerea unei probleme pe toate partile are ca rezultat de multe ori
> demotivarea celui care a initiat procesul de schimbare; riscam sa ramanem cu
> discutii interminabile ingropate in arhive online si fara date pe harta.
> Janos, felicitari pentru initiativa si multumiri.
> --
> Cristi
>
_______________________________________________
Ciprian Talaba
Eu sunt pentru rezultate rapide, chiar cu riscul necesitatii editarilor ulterioare.Intoarcerea unei probleme pe toate partile are ca rezultat de multe ori demotivarea celui care a initiat procesul de schimbare; riscam sa ramanem cu discutii interminabile ingropate in arhive online si fara date pe harta.Janos, felicitari pentru initiativa si multumiri.--Cristi
De ce incerc sa adun cat mai multe idei (unele mai putin inspirate, alte mai mult) inainte de a face importul propriu-zis? E simplu, din punctul meu de vedere este important ca lucrurile sa fie facute cat se poate de bine de la inceput (exemplul cu importul de localitati la nivel de puncte cred ca este un exemplu pozitiv, si el a trecut prin diferite stagii si cred ca suntem cu totii incantati de ce a iesit).
Orice modificare pe care vrei sa o aduci dupa aceea, implica actiuni manuale (in cele mai multe cazuri). E mai greu sa scrii un algoritm care sa ia in calcul eventualele modificari aduse de useri datelor respective (este un lucru foarte posibil) decat sa pornesti cu o plansa alba.
Janos, sper ca ideile mele au fost privite ca un lucru constructiv, in nici un caz nu am urmarit sa umplu niste inbox-uri doar de dragul de a scrie mailuri (dupa cum se vede timpul meu e destul de limitat in ultima vreme). Imi place ce vad pe harta, contributia ta este foarte buna si iti multumesc pentru timpul pe care il aloci acestui proiect, dar consider ca acest import este inca perfectibil. As vrea sa aflu de la tine daca ultima mea idee (cu folosirea relatiilor) are vreo logica, si daca poate fi implementata (necesita gasirea punctului corespunzator pentru a putea creea relatia, stiu ca Eddy, daca nu ma insel, a folosit Python OSM API pentru acest lucru).
Numai bine,
Ciprian
Strainu
Care este situația drepturilor de autor cu fișierele alea? A fost
obținut dreptul de a le utiliza? Întreb pentru că m-ar interesa să mă
joc cu monumentele istorice din București.
Mulțumesc,
Andrei
Cristian Draghici
On 01-Jun-09 6:23 PM, Mircea Angelescu wrote:
> Imi pare rau ca raspund asa tarziu dar mailul dv a ajuns abia acum la mine.
> Datele mentionate de dv sunt create de mine si deci le puteti utiliza cu mentiunea source=Mircea Angelescu, in cadrul licentei CCBYSA
>
> __------------------------------
> dr. Mircea Angelescu
> Ministry of Culture,Religious Affairs and National Heritage
### ### ###
Cristian Draghici
Stefan UNGUREANU
pareri, sigestii si critici disponibile pe pagina
http://wiki.openstreetmap.org/wiki/Romania_CLC_Import, demotivarea este
si ea maxima.
Stefan.
On 09/03/2010 16:17, Cristian Draghici wrote:
> La asta ma refeream cu mailul meu din Decembrie. Prea multe discutii duc
> la demotivari.
>
> Avem accept pe datele din Corine Landcover si pe datele din cultura.ro
> <http://cultura.ro> si totusi pe openstreetmap n-avem contururi pe
> localitati.
>
> --
> Cristi
>
> 2009/12/5 Ciprian Talaba <cipria...@gmail.com
> <mailto:cipria...@gmail.com>>
>
> Salutare,
>
> 2009/12/3 Cristian Draghici <cristian...@gmail.com
> <mailto:cristian...@gmail.com>>
> Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
> http://lists.openstreetmap.org/listinfo/talk-ro
Cristian Draghici
alex-map
sugera sa continuati, modificari ulterioare se pot face oricand.
cele bune
Alex.
On 9 Mrz., 15:45, Cristian Draghici <cristian.dragh...@gmail.com>
wrote:
> Am adaugat un vot pentru solutia #3 (username-ul meu de wiki e diciu).
>
> Pe de alta parte, avand in vedere ca altcineva face munca, nu m-ar deranja
> nici o alta solutie, atat timp cat avansam cu importul.
>
> --
> Cristi
>
> 2010/3/9 Stefan UNGUREANU <stefan.ungure...@mytrek.ro>
>
> > In ceea ce priveste CLC, avand in vedere numarul foarte "mare" de
> > pareri, sigestii si critici disponibile pe pagina
> >http://wiki.openstreetmap.org/wiki/Romania_CLC_Import, demotivarea este
> > si ea maxima.
>
> > Stefan.
>
> > On 09/03/2010 16:17, Cristian Draghici wrote:
> > > La asta ma refeream cu mailul meu din Decembrie. Prea multe discutii duc
> > > la demotivari.
>
> > > Avem accept pe datele din Corine Landcover si pe datele din cultura.ro
> > > <http://cultura.ro> si totusi pe openstreetmap n-avem contururi pe
> > > localitati.
>
> > > --
> > > Cristi
>
> > > 2009/12/5 Ciprian Talaba <cipriantal...@gmail.com
> > > <mailto:cipriantal...@gmail.com>>
>
> > > Salutare,
>
> > > 2009/12/3 Cristian Draghici <cristian.dragh...@gmail.com
> > > <mailto:cristian.dragh...@gmail.com>>
> > > Talk...@openstreetmap.org <mailto:Talk...@openstreetmap.org>
> > > http://lists.openstreetmap.org/listinfo/talk-ro
>
> > > _______________________________________________
> > > Talk-ro mailing list
> > > Talk...@openstreetmap.org
> > >http://lists.openstreetmap.org/listinfo/talk-ro
>
> > _______________________________________________
> > Talk-ro mailing list
> >http://lists.openstreetmap.org/listinfo/talk-ro
>
>
>
> _______________________________________________
> Talk-ro mailing list
> Talk...@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ro
Cristian Draghici
Stefan UNGUREANU
Am modificat pagina de wiki, intrucat mai exista o propunere, care,
personal, mi se pare mai buna decat cele initiale.
In plus, am pus un tabel, ca sa vedem exact cine si ce solutie sustine,
dar momentan nu sunt decat eu pe lista ...
Stefan.
On 16/03/2010 08:34, Cristian Draghici wrote:
> Salut
>
> Avem o decizie ref la import?
>
> toate bune,
> Cristi
>
> 2010/3/9 alex-map <al...@email.ro <mailto:al...@email.ro>>
>
> odata ce s-au importat cateva judete intr-un anumit format eu v-as
> sugera sa continuati, modificari ulterioare se pot face oricand.
>
> cele bune
> Alex.
>
> On 9 Mrz., 15:45, Cristian Draghici <cristian.dragh...@gmail.com
> <mailto:cristian.dragh...@gmail.com>>
> wrote:
> > Am adaugat un vot pentru solutia #3 (username-ul meu de wiki e
> diciu).
> >
> > Pe de alta parte, avand in vedere ca altcineva face munca, nu
> m-ar deranja
> > nici o alta solutie, atat timp cat avansam cu importul.
> >
> > --
> > Cristi
> >
> > 2010/3/9 Stefan UNGUREANU <stefan.ungure...@mytrek.ro
> <mailto:stefan.ungure...@mytrek.ro>>
> >
> > > In ceea ce priveste CLC, avand in vedere numarul foarte "mare" de
> > > pareri, sigestii si critici disponibile pe pagina
> > >http://wiki.openstreetmap.org/wiki/Romania_CLC_Import,
> demotivarea este
> > > si ea maxima.
> >
> > > Stefan.
> >
> > > On 09/03/2010 16:17, Cristian Draghici wrote:
> > > > La asta ma refeream cu mailul meu din Decembrie. Prea multe
> discutii duc
> > > > la demotivari.
> >
> > > > Avem accept pe datele din Corine Landcover si pe datele din
> cultura.ro <http://cultura.ro>
> > > > <http://cultura.ro> si totusi pe openstreetmap n-avem
> contururi pe
> > > > localitati.
> >
> > > > --
> > > > Cristi
> >
> > > > 2009/12/5 Ciprian Talaba <cipriantal...@gmail.com
> <mailto:cipriantal...@gmail.com>
> > > > <mailto:cipriantal...@gmail.com
> <mailto:cipriantal...@gmail.com>>>
> >
> > > > Salutare,
> >
> > > > 2009/12/3 Cristian Draghici <cristian.dragh...@gmail.com
> <mailto:cristian.dragh...@gmail.com>
> > > > <mailto:cristian.dragh...@gmail.com
> <mailto:Talk...@openstreetmap.org <mailto:Talk...@openstreetmap.org>>
> > > > http://lists.openstreetmap.org/listinfo/talk-ro
> >
> > > > _______________________________________________
> > > > Talk-ro mailing list
> > > > Talk...@openstreetmap.org <mailto:Talk...@openstreetmap.org>
> > > >http://lists.openstreetmap.org/listinfo/talk-ro
> >
> > > _______________________________________________
> > > Talk-ro mailing list
> > > Talk...@openstreetmap.org <mailto:Talk...@openstreetmap.org>
> > >http://lists.openstreetmap.org/listinfo/talk-ro
> >
> >
> >
> > _______________________________________________
> > Talk-ro mailing list
> >
> Talk...@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ro
> <http://lists.openstreetmap.org/listinfo/talk-ro>
>
> _______________________________________________
> Talk-ro mailing list
> Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
> http://lists.openstreetmap.org/listinfo/talk-ro
>
>
>
>
>
> _______________________________________________
> Talk-ro mailing list
> Tal...@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ro
_______________________________________________
Talk-ro mailing list
Tal...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ro
Cristian Draghici
Stefan UNGUREANU
prelucrate (vezi si harta Garmin pe care am facut-o cu ele).
S.
On 16/03/2010 09:53, Cristian Draghici wrote:
> Am adaugat doua voturi pe solutia propusa de tine, al meu si al
> colegului Nini.
>
> --
> c
>
>
> 2010/3/16 Stefan UNGUREANU <stefan.u...@mytrek.ro
> <mailto:stefan.u...@mytrek.ro>>
>
> Salut,
>
> Am modificat pagina de wiki, intrucat mai exista o propunere, care,
> personal, mi se pare mai buna decat cele initiale.
>
> In plus, am pus un tabel, ca sa vedem exact cine si ce solutie sustine,
> dar momentan nu sunt decat eu pe lista ...
>
> Stefan.
>
> On 16/03/2010 08:34, Cristian Draghici wrote:
> > Salut
> >
> > Avem o decizie ref la import?
> >
> > toate bune,
> > Cristi
> >
> > 2010/3/9 alex-map <al...@email.ro <mailto:al...@email.ro>
> <mailto:al...@email.ro <mailto:al...@email.ro>>>
> >
> > odata ce s-au importat cateva judete intr-un anumit format eu
> v-as
> > sugera sa continuati, modificari ulterioare se pot face oricand.
> >
> > cele bune
> > Alex.
> >
> > On 9 Mrz., 15:45, Cristian Draghici
> <cristian.dragh...@gmail.com <mailto:cristian.dragh...@gmail.com>
> > <mailto:cristian.dragh...@gmail.com
> <mailto:cristian.dragh...@gmail.com>>>
> > wrote:
> > > Am adaugat un vot pentru solutia #3 (username-ul meu de wiki e
> > diciu).
> > >
> > > Pe de alta parte, avand in vedere ca altcineva face munca, nu
> > m-ar deranja
> > > nici o alta solutie, atat timp cat avansam cu importul.
> > >
> > > --
> > > Cristi
> > >
> > > 2010/3/9 Stefan UNGUREANU <stefan.ungure...@mytrek.ro
> <mailto:stefan.ungure...@mytrek.ro>
> > <mailto:stefan.ungure...@mytrek.ro
> <mailto:stefan.ungure...@mytrek.ro>>>
> > >
> > > > In ceea ce priveste CLC, avand in vedere numarul foarte "mare" de
> > > > pareri, sigestii si critici disponibile pe pagina
> > > >http://wiki.openstreetmap.org/wiki/Romania_CLC_Import,
> > demotivarea este
> > > > si ea maxima.
> > >
> > > > Stefan.
> > >
> > > > On 09/03/2010 16:17, Cristian Draghici wrote:
> > > > > La asta ma refeream cu mailul meu din Decembrie. Prea multe
> > discutii duc
> > > > > la demotivari.
> > >
> > > > > Avem accept pe datele din Corine Landcover si pe datele din
> > cultura.ro <http://cultura.ro> <http://cultura.ro>
> > > > > <http://cultura.ro> si totusi pe openstreetmap n-avem
> > contururi pe
> > > > > localitati.
> > >
> > > > > --
> > > > > Cristi
> > >
> > > > > 2009/12/5 Ciprian Talaba <cipriantal...@gmail.com
> <mailto:cipriantal...@gmail.com>
> > <mailto:cipriantal...@gmail.com <mailto:cipriantal...@gmail.com>>
> > > > > <mailto:cipriantal...@gmail.com
> <mailto:cipriantal...@gmail.com>
> > <mailto:cipriantal...@gmail.com <mailto:cipriantal...@gmail.com>>>>
> Talk...@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ro
> <http://lists.openstreetmap.org/listinfo/talk-ro>
> > <http://lists.openstreetmap.org/listinfo/talk-ro>
> >
> > _______________________________________________
> > Talk-ro mailing list
> > Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
> <mailto:Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>>
Ciprian Talaba
Binenteles intre timp putem sa discutam variantele deja propuse pentru import sau sa ne gandim la unelte care ne pot ajuta sa automatizam acest import :)
O zi buna,
Ciprian
==============================================
Kongens Nytorv 6 - 1050 Copenhagen K – Denmark
Tel.: +45 33 36 71 85 +45 33 36 71 85 | E-mail: jesse....@eea.europa.eu | Enquiries: www.europa.eu/help/infocentre/enquiries | www.eea.europa.eu
Ciprian Talaba
Incepand cu data de 27 mai datele CLC 2006 sunt disponibile in format vectorial: http://www.eea.europa.eu/data-and-maps/data/clc-2006-vector-data-version.
Avem pagina de wiki http://wiki.openstreetmap.org/wiki/Romania_CLC_Import unde se discuta despre solutii legate de importul acestor date iar Stefan a pus acest import in lista globala http://wiki.openstreetmap.org/wiki/Import/Catalogue si a inceput sa prezinte modul in care realizeaza in acest moment o harta compusa din datele OSM + CLC: http://wiki.openstreetmap.org/wiki/Corine_Land_Cover_Romania_2006.
Haideti sa tragem o concluzie in ceea ce priveste cea mai buna modalitate de import si sa ne apucam de treaba. Binenteles o comparatie cu datele OSM si eventual cu cele din CLC 2000 ar fi binevenita, dar din ce am inteles calitatea datelor este foarte buna.
Numai bine,
Ciprian
Stefan UNGUREANU
Pentru moment am luat datele si le-am prelucrat. N-am avut timp sa caut
diferente, insa ceea ce pot sa spun e ca fisierul a crescut.
Inainte aveam date in valoare de approx 173 Mb, acum avem approx 176 Mb;
fisierul este comprimat (tar.gz); e drept ca datele reale sunt probabil
cu vreo 10Mb mai mici pentru ca eu folosesc un contur al tarii extins cu
10 km (daca imi aduc bine aminte) pentru harta Garmin.
Stefan.
> _www.eea.europa.eu_ <http://www.eea.europa.eu/>
> _http://www.eea.europa.eu/help/eea-help-centre/faqs_
> New CLC 2006 is expected to be finalised during April. Version 13 of
> CLC2006 will include vector data of the countries that have been
> finalised. This will be published and made available on the EEA
> website by the end of April. For more see:
> _http://etc-lusi.eionet.europa.eu/CLC2006/_
> You can download the raster data for CLC2006 as well as new versions
> of CLC1990 and CLC2000 version 12 at:
> _http://www.eea.europa.eu/themes/landuse/datasets_
> For further information about the CLC2006 data from the missing
> countries, you may find it relevant to contact the responsible
> national authorities. For this purpose, I suggest that you utilise
> the contact information for the NRC for landcover for the countries
> of your interest. This information is available at:
> <http://eea.eionet.europa.eu/Public/irc/eionet-circle/Home/central_dir_admin?fn=roles&v=eionet-nrc-landcover-mc&rd=1&af=0&ud=1&od=1>
> General information
> From the EEA website, we have CORINE landcover data which is
> available free of charge. The current data we have available for
> landcover can be found at the following website:
> _http://www.eea.europa.eu/themes/landuse/datasets_
> To be provided with an overview of EEA land use data and reports,
> you can consult the EEA theme section at:
> _http://www.eea.europa.eu/themes/landuse_
> The CLC viewer may also be interesting for you at (here you can also
> download tiles specific for the area you are interested in):
> _http://dataservice.eea.europa.eu/clc/eeaclc.asp_
> The EEA EIONET GIS website includes guides on geographic information
> from the EEA and also a link to free open source GIS software.
> Please have a look at this information here:
> _http://www.eionet.europa.eu/gis_
> Hopefully, this information may be helpful to you.
> Kind regards,
> Jesse Goodman | Communications | *European Environment Agency
> *Kongens Nytorv 6 - 1050 Copenhagen K – Denmark
> Tel.: +45 33 36 71 85 +45 33 36 71 85 | E-mail:
> _jesse....@eea.europa.eu_ <mailto:jesse....@eea.europa.eu> |
> Enquiries: _www.europa.eu/help/infocentre/enquiries_
> <http://www.europa.eu/help/infocentre/enquiries> |
> _www.eea.europa.eu_ <http://www.eea.europa.eu/>
> /*Do something for our planet, print this email only if needed. Even
> a small action can make an enormous difference, when millions of
> people do it! */
Cristian Draghici
Stefan UNGUREANU
Asa cum spune si numele mesajului (Import automatizat pentru limita
localitatilor (via cultura.ro)), cred ca era vorba de a crea limitele
localitatilor din datele de la 'cultura.ro' si poligoanele de landcover
de la CLC.
Stefan.
> > <mailto:cipria...@gmail.com
> <http://eea.eionet.europa.eu/Public/irc/eionet-circle/Home/central_dir_admin?fn=roles&v=eionet-nrc-landcover-mc&rd=1&af=0&ud=1&od=1_>
> >
> <http://eea.eionet.europa.eu/Public/irc/eionet-circle/Home/central_dir_admin?fn=roles&v=eionet-nrc-landcover-mc&rd=1&af=0&ud=1&od=1
> > Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
> > http://lists.openstreetmap.org/listinfo/talk-ro
>
> _______________________________________________
> Talk-ro mailing list
> Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
Cristian Draghici
Stefan UNGUREANU
Pai nici nu cred ca e vreo legatura. In CLC nu exista limite
administrative, numai o suma de poligoane cu diferite caracteristici.
Tocmai din cauza asta sugerasem mai demult ca datele de la cultura.ro sa
fie folosite ca limite administrative, iar cele de la CLC doar ca
poligoane de land cover.
Stefan.
On 29/07/2010 21:28, Cristian Draghici wrote:
> Salut
>
> Speram sa inteleg cum anume se va realiza treaba, pentru ca, dupa cum am
> spus mai jos, eu unul nu vad legatura intre CLC land cover si limite
> administrative.
>
> Mai mult, limitele din cultura.ro <http://cultura.ro> sunt destul de
> incorecte (m-am uitat la Targu Jiu de exemplu) -> ele par sa reprezinta
> limitele "de interes cultural" mai degraba decat limitele administrative
> (pe satelitar sa vad zone locuite excluse din poligonul orasului).
>
>
> Multumesc,
> Cristi
>
> On Thu, Jul 29, 2010 at 7:16 PM, Stefan UNGUREANU
> <stefan.u...@mytrek.ro <mailto:stefan.u...@mytrek.ro>> wrote:
>
> Salut,
>
> Asa cum spune si numele mesajului (Import automatizat pentru limita
> localitatilor (via cultura.ro <http://cultura.ro>)), cred ca era
> vorba de a crea limitele localitatilor din datele de la 'cultura.ro
> <http://cultura.ro>' si poligoanele de landcover de la CLC.
> <mailto:stefan.u...@mytrek.ro
> <mailto:Tal...@openstreetmap.org
> <mailto:Tal...@openstreetmap.org>>
>
> > http://lists.openstreetmap.org/listinfo/talk-ro
>
> _______________________________________________
> Talk-ro mailing list
> Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
> <mailto:Tal...@openstreetmap.org
Janos Rusiczki
Manuel R Ciosici
Manuel R. Ciosici
Cristian Draghici
Ioan Indreias
Ciprian Talaba
SalutM-am uitat un pic peste datele CLC si ori nu gasesc ce ati gasit voi, ori nu inteleg cum pot fi folosite pentru definirea limitelor oraselor de exemplu (de aici a plecat thread-ul initial).Spre exemplu, daca ma uit la Giurgiu in Urban Atlas: (http://www.eea.europa.eu/data-and-maps/data/urban-atlas) CLC nu defineste un poligon care sa constituie limita orasului, ci un SET de poligoane (impartite functie de land use, etc). In acest set de poligoane e cuprins si un sat alaturat orasului (Slobozia) pentru simplul fapt ca si in acest sat exista o zona locuita.Ca atare, eu nu vad nici o legatura intre limitele administrative ale orasului asa cum sunt ele definite la primaria Giurgiu si datele din CLC, si atunci scopul initial al thread-ului (definire limite administrative pentru localitati) nu va fi atins.Va rog corectati-ma daca gresesc.Multumiri,Cristi
Intradevar, cele doua surse de date (cultura.ro si CLC) nu se suprapun. Cele de pe cultura.ro definesc limitele administrative si vor fi marcate in consecinta, in plus nu va fi utilizat tag-ul landuse=residential (ar fi avut sens doar daca nu aveam si datele CLC). Datele din CLC (cele la nivel de localitate) vor fi marcate doar cu tag-ul landuse=residential pentru ca pentru un oras mai mare este posibil sa avem mai multe astfel de poligoane.
Pe baza lor putem incerca sa definim manual limitele administrative adaugand un poligon (sau o relatie?) care sa contina toate poligoanele de tip residential din zona unei localitati marcate momentan doar cu un punct (nu e simplu, si nici perfect, dar e mai bine decat deloc).
Sper ca nu m-am inselat in ceea ce priveste modul de marcare a datelor din cele doua importuri, am incercat sa caut prin arhiva de mailuri si asta pare sa fie concluzia de acum 6-7 luni de zile.
Concluzia pe care o trag este ca Janos poate continua importul de pe cultura.ro si noi ceilalti trebuie sa dam o unda verde importului CLC2006. Pagina wiki unde puteti gasi metodele propuse pentru import este http://wiki.openstreetmap.org/wiki/Romania_CLC_Import. Cititi cu atentie si comentati daca nu sunteti de acord cu ceva. Pana acum metoda cea mai sustinuta este #1 bis, in care datele curente sunt marcate astfel incat sa nu mai fie randate pe harta, iar cele din CLC se vor suprapune peste ele. Apoi manual va trebui sa identificam zonele cu suprapunere mare si sa luam decizia daca revenim la datele initiale sau nu.
--Ciprian
Manuel R. Ciosici
_______________________________________________
Talk-ro mailing list
Tal...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ro
--
Ioan Indreias
alex-map
si eu sunt pemtru repornirea importului,
cele bune
Alex
On 30 Jul., 09:57, Ioan Indreias <indre...@gmail.com> wrote:
> Salut Ciprian,
>
> Atata timp cat importul CLC nu afecteaza poligoane marcate cu tag-ul
> boundary sau place este foarte bine.
>
> In plus importul CLC ar trebui sa evite modificarea poligoanelor care au
> tag-ul "name" sau "place_name" (nu ne dorim sa devina invizibile).
>
> Din mesajul tau inteleg de asemenea ca esti de acord cu re-pornirea
> importului lui Janos cu datele de pe cultura.ro - corect?
>
> Multumesc,
> Nini.
>
> 2010/7/30 Ciprian Talababegin_of_the_skype_highlighting end_of_the_skype_highlighting<cipriantal...@gmail.com>
> >http://lists.openstreetmap.org/listinfo/talk-ro
>
>
>
> _______________________________________________
> Talk-ro mailing list
> Talk...@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ro
Ciprian Talaba
Salut Ciprian,Atata timp cat importul CLC nu afecteaza poligoane marcate cu tag-ul boundary sau place este foarte bine.
Cat timp acestea nu au si landuse=* nu ar trebuie sa fie probleme.
In plus importul CLC ar trebui sa evite modificarea poligoanelor care au tag-ul "name" sau "place_name" (nu ne dorim sa devina invizibile).
Trebuie sa facem un inventar al poligoanelor cu name sau place_name si care au landuse=* (cel mai probabil residential) si sa tragem niste concluzii.
Din mesajul tau inteleg de asemenea ca esti de acord cu re-pornirea importului lui Janos cu datele de pe cultura.ro - corect?
Absolut.
Multumesc,Nini.
--Ciprian
Cristian Draghici
Salutare,2010/7/30 Ioan Indreias <indr...@gmail.com>Salut Ciprian,Atata timp cat importul CLC nu afecteaza poligoane marcate cu tag-ul boundary sau place este foarte bine.
Cat timp acestea nu au si landuse=* nu ar trebuie sa fie probleme.
In plus importul CLC ar trebui sa evite modificarea poligoanelor care au tag-ul "name" sau "place_name" (nu ne dorim sa devina invizibile).
Trebuie sa facem un inventar al poligoanelor cu name sau place_name si care au landuse=* (cel mai probabil residential) si sa tragem niste concluzii.
Cristian Draghici
Razvan Preda
| putea sa le imorti si pe acelea, pt comuna zambreasca vreau sa spun ca am folosit imaginile yahoo. Razvan Preda --- On Tue, 8/24/10, Cristian Draghici <cristian...@gmail.com> wrote: |
-----Inline Attachment Follows----- |
Cristian Draghici
Cristian Draghici
Ioan Indreias
Cristian Draghici
Ioan Indreias
Cristian Draghici
Cristian Draghici
Cristian Draghici
Constantin Popescu
As avea si eu o intrebare despre aceste importuri. Asa ar trebui sa arate aceste limite ? Nu vad in nicio tara sa arate asa. De obicei localitatile au un fundal gri daca nu ma insel.
Mi se pare si mai estetic cu acel fundal gri. Cel putin in vest unde sunt multe localitati una langa alta efectul este foarte frumos.
Mai mult, observ ca exista cateva situatii in care exist si fundal gri si acest contur intererupt de culoare roz(?).
Un import parca din aceeasi sursa dar realizat mai demult, in judetul Arad s-a facut cu acel fundal gri. De ce s-a trecut la acest contur ?
Toate cele bune si sper ca nu am suparat pe nimeni, e doar parerea mea personala.
alex-map
landuse=residential
On 30 Aug., 16:50, Constantin Popescu <popescu.constan...@gmail.com>
wrote:
> Salut.
>
> As avea si eu o intrebare despre aceste importuri. Asa ar trebui sa arate
> aceste limite ? Nu vad in nicio tara sa arate asa. De obicei localitatile au
> un fundal gri daca nu ma insel.
> Mi se pare si mai estetic cu acel fundal gri. Cel putin in vest unde sunt
> multe localitati una langa alta efectul este foarte frumos.
> Mai mult, observ ca exista cateva situatii in care exist si fundal gri si
> acest contur intererupt de culoare roz(?).
> Un import parca din aceeasi sursa dar realizat mai demult, in judetul Arad
> s-a facut cu acel fundal gri. De ce s-a trecut la acest contur ?
>
> Toate cele bune si sper ca nu am suparat pe nimeni, e doar parerea mea
> personala.
>
> 2010/8/30 Cristian Draghici <cristian.dragh...@gmail.com>
>
> > Azi: Caras
> > Severin, Buzau, Brasov, Galati, Vrancea, Timis, Sibiu, Covasna, Hunedoara, Alba, Bacau,
> > Vaslui.
>
> >http://wiki.openstreetmap.org/wiki/Import_www.cultura.ro
>
> > Salutari
> > --
> > Cristi
>
> > 2010/8/27 Cristian Draghici <cristian.dragh...@gmail.com>
>
> > Astazi Mehedinti, Gorj, Dambovita, Prahova, Braila, Tulcea, Arges.
>
> >>http://wiki.openstreetmap.org/wiki/Import_www.cultura.ro
>
> >> Salutari
> >> --
> >> Cristi
>
> >> 2010/8/26 Cristian Draghici <cristian.dragh...@gmail.com>
>
> >> Salut
>
> >>> Am adaugat localitati din: Calarasi, Dolj, Constanta, Ialomita, Olt.
>
> >>> Changeset-urile aici:
> >>>http://wiki.openstreetmap.org/wiki/Import_www.cultura.ro
>
> >>> Toate bune,
> >>> --
> >>> Cristi
>
> >>> 2010/8/25 Ioan Indreias <indre...@gmail.com>
>
> >>>> sure - acum am vazut - in chrome cache-ul e foarte "naravas" - dupa un
> >>>> refresh am vazut actualizarile tale.
> >>>> thx.
>
> >>>> 2010/8/25 Cristian Draghici <cristian.dragh...@gmail.com>
>
> >>>>> :-)
>
> >>>>> Cele cu changeset in tabel sunt deja importate.
>
> >>>>> --
> >>>>> Cristi
>
> >>>>> 2010/8/25 Ioan Indreias <indre...@gmail.com>
>
> >>>>> excelent - as sugera sa numim judetele care au fost importate de tine
> >>>>>> cu "Teleorman - done (diciu)" iar pentru judetele care au fost deja
> >>>>>> importate sa incercam sa gasim "user-ul OSM" si sa-l marcam ca atare.
>
> >>>>>> sau ceva similar, ca sa vedem cum merge progresul acestui import.
>
> >>>>>> Nini
>
> >>>>>> 2010/8/25 Cristian Draghici <cristian.dragh...@gmail.com>
>
> >>>>>>> O sa tin evidenta importului aici:
>
> >>>>>>>http://wiki.openstreetmap.org/wiki/Import_www.cultura.ro
>
> >>>>>>> --
> >>>>>>> Cristi
>
> >>>>>>> 2010/8/25 Cristian Draghici <cristian.dragh...@gmail.com>
>
> >>>>>>> Salut
>
> >>>>>>>> Am continuat cu limitele localitatilor din Giurgiu.
>
> >>>>>>>> Changeset-ul este:
> >>>>>>>>http://www.openstreetmap.org/browse/changeset/5589673
>
> >>>>>>>> Am exclus din import localitatile existente din judet: (Daia,
> >>>>>>>> Dobreni,Giurgiu, Grădiștea, Mogoșești, Prundu, Valea
> >>>>>>>> Dragului, Vărăști, Varlaam).
>
> >>>>>>>> Toate bune,
> >>>>>>>> --
> >>>>>>>> Cristi
>
> >>>>>>>> 2010/8/24 Razvan Preda <rap_...@yahoo.com>
>
> >>>>>>>> putea sa le imorti si pe acelea, pt comuna zambreasca vreau sa spun
> >>>>>>>>> ca am folosit imaginile yahoo.
>
> >>>>>>>>> Razvan Preda
>
> >>>>>>>>> --- On *Tue, 8/24/10, Cristian Draghici <
> >>>>>>>>> cristian.dragh...@gmail.com>* wrote:
>
> >>>>>>>>> From: Cristian Draghici <cristian.dragh...@gmail.com>
> >>>>>>>>> Subject: Re: [Talk-ro] Import automatizat pentru limita
> >>>>>>>>> localitatilor (via cultura.ro)
>
> >>>>>>>>> To: "OSM Romania" <talk...@openstreetmap.org>
> >>>>>>>>> 2010/7/30 Cristian Draghici <cristian.dragh...@gmail.com<http://mc/compose?to=cristian.dragh...@gmail.com>
>
> >>>>>>>>> 2010/7/30 Ciprian Talaba <cipriantal...@gmail.com<http://mc/compose?to=cipriantal...@gmail.com>
>
> >>>>>>>>> Salutare,
>
> >>>>>>>>> 2010/7/30 Ioan Indreias <indre...@gmail.com<http://mc/compose?to=indre...@gmail.com>
> >>>>>>>>> Talk...@openstreetmap.org<http://mc/compose?to=Talk...@openstreetmap.org>
> >>>>>>>>>http://lists.openstreetmap.org/listinfo/talk-ro
>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Talk-ro mailing list
> >>>>>>>>> Talk...@openstreetmap.org
> >>>>>>>>>http://lists.openstreetmap.org/listinfo/talk-ro
>
> >>>>>>> _______________________________________________
> >>>>>>> Talk-ro mailing list
> >>>>>>> Talk...@openstreetmap.org
> >>>>>>>http://lists.openstreetmap.org/listinfo/talk-ro
>
> >>>>>> _______________________________________________
> >>>>>> Talk-ro mailing list
> >>>>>> Talk...@openstreetmap.org
> >>>>>>http://lists.openstreetmap.org/listinfo/talk-ro
>
> >>>>> _______________________________________________
> >>>>> Talk-ro mailing list
> >>>>> Talk...@openstreetmap.org
> >>>>>http://lists.openstreetmap.org/listinfo/talk-ro
>
> >>>> _______________________________________________
> >>>> Talk-ro mailing list
> >>>> Talk...@openstreetmap.org
> >>>>http://lists.openstreetmap.org/listinfo/talk-ro
>
> > _______________________________________________
> > Talk-ro mailing list
> >http://lists.openstreetmap.org/listinfo/talk-ro
>
>
>
> _______________________________________________
> Talk-ro mailing list
> Talk...@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ro
Constantin Popescu
Cristian Draghici
Constantin Popescu
O alta intrebare, am voie sa modific in unele locuri acest contur ? Am vazut in cateva orase pe care le cunosc ca, conturul se suprapune peste un cartier, sau cateva strazi si e clar ca nu e o limita tocmai corecta.
Exemplu in atasament !
Toate cele bune
Cristian Draghici
Cristian Draghici
Stefan UNGUREANU
In incercarea de a stabili ce exista deja si ce implicatii are
redenumirea tag-urilor, am constatat o problema legata de tag-urile
"landuse=forest" si "natural=wood".
Mai precis, in wiki gasim definitia natural=wood : Natural woodland
(trees). Only for completely unmanaged/wild ares. For forests that are
owned or managed by someone, use landuse=forest instead.
Ssunt foarte multe poligoane (undeva in jur de 3000) etichetate cu
"landuse=forest" sau "landuse=forest;natural=wood", care cred ca ar
trebui sa fie de fapt (doar) "natural=wood".
Idei ? Sugestii ? Comentarii ?
Pe langa asta mai exista si o serie de elemente cu tag-uri care nu
respecta ce scrie la wiki, si pe care am inceput sa le ajustez. Cateva
exemple : "landuse=primary", "landuse=Hotaru", "natural=landuse", etc.
Stefan.
Strainu
<stefan.u...@mytrek.ro> a scris:
> Salut,
>
> In incercarea de a stabili ce exista deja si ce implicatii are redenumirea
> tag-urilor, am constatat o problema legata de tag-urile "landuse=forest" si
> "natural=wood".
>
> Mai precis, in wiki gasim definitia natural=wood : Natural woodland (trees).
> Only for completely unmanaged/wild ares. For forests that are owned or
> managed by someone, use landuse=forest instead.
>
> Ssunt foarte multe poligoane (undeva in jur de 3000) etichetate cu
> "landuse=forest" sau "landuse=forest;natural=wood", care cred ca ar trebui
> sa fie de fapt (doar) "natural=wood".
Ia uite ce mai scrie în wiki [1]: <<Check if the area is "managed
maintained or industrial used forest". This is almost always the case
in Europe, with an emphasis on "managed maintained". Only very small
areas are really left untouched and can be considered wild boondocks,
primeval forest, virgin wood, national parks etc. >>
Trecând însă peste asta, cum poți să faci diferența doar uitându-te pe
hartă? Senzația mea (bazată pe plimbările prin țară, deci practic doar
prin preajma zonelor locuite) e că cele mai multe păduri ar fi
"landuse=forest", mai ales în zona de câmpie. Practic natural=wood ar
fi doar pădurile de munte, unde panta e prea mare pentru a fi
exploatate. Vezi și [2]
Unde nu ești sigur, pune landuse=forest peste tot, mi se pare cel mai
sigur asa. natural=wood pare să fie o chestie bună pentru Siberia și
Amazon si mai puțin pentru România.
Strainu
[1] http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dforest
[2] http://www.rosilva.ro/categorie.php?id=4
Octavian Chelu
> În data de 24 septembrie 2010, 19:20, Stefan UNGUREANU
>
> <stefan.u...@mytrek.ro> a scris:
> prin preajma zonelor locuite) e că cele mai multe păduri ar fi
> "landuse=forest", mai ales în zona de câmpie. Practic natural=wood ar
> fi doar pădurile de munte, unde panta e prea mare pentru a fi
> exploatate. Vezi și [2]
>
Comana și Delta Neajlovului. Din câte știu, zona de rezervație din pădurea
Comana nu este exploatată forestier, motiv pentru care pădurea este superbă.
Stefan UNGUREANU
landuse; oricum sunt si destul de multe cu natural=wood, asa ca oricum e
ceva de munca la ele.
Vroiam doas sa ma asigur ca totul e tag-uit corect inainte de orice
prelucrare majora ;)
Comana este intr-adevar rezervatie si nu e exploatata, dar as zice ca
intra tot la 'managed'.
Concluzia ar fi ca la noi totul e "landuse=forest;wood=...", nu ?
Stefan.
Stefan UNGUREANU
O alta observatie : tag-ul 'layer'. La wiki scrie asa :
layer=*
The layer tag can have values between -5 and 5 (not +5). It describes
the relative position of map features and is most commonly seen with
bridges and tunnels [...]
Some people also use the layer tag to "fix" render issues. This is not
an appropriate use. If a renderer is broken, then you are better off to
open a ticket in trac, so somebody can start working on a real fix.
In momentul de fata avem :
-5 : 11
-4 : 61
-3 : 230
-2 : 212
-1 : 890
1 : 1867
2 : 30
3 : 0
4 : 0
5 : 5
restul obiectelor sunt in layer=0.
Sunt oarecum convins ca majoritatea intra la categoria "render issues",
dar verificarea lor individuala este destul de laborioasa si
consumatoare de timp. O sa incerc totusi sa iau prin sondaj cateva si
revin cu detalii.
Idei ? Sugestii ? Comentarii ?
Multumesc,
Stefan.
Ioan Indreias
a stabili nivelul de inaltime si de aceea e recomandat la poduri si
tunele.
my 2c.
Nini
Stefan UNGUREANU
exista obiectii/observatii/critici/sugestii.
Stefan.
Strainu
<stefan.u...@mytrek.ro> a scris:
Am și eu o întrebare legată de subiectul CLC 2006. În OSM majoritatea
râurilor sunt marcate cu linii, nu suprafețe (cum scrie și în Wiki).
În CLC în schimb pare să fie vorba de suprafețe. Cum se va face
conversia? Întrebarea asta ar putea fi valabilă și pentru alte tipuri
de informații, dar doar pentru ăsta mi-a venit acum ideea.
Strainu
Stefan UNGUREANU
Nu cred ca sunt toate marcate ca suprafete; cred ca suprafetele
corespund cu waterway=riverbank, dar trebuie sa verific.
Oricum, cand incep importul propriu-zis, las 'apele' pentru final, sau
nu le import deloc. Mi-am pus si eu problema asta, dar n-am ajuns inca
pana acolo.
Ca status general, mai am putin de lucru la corectiile de 'layer' si
trebuie sa-mi testez aplicatia care redenumeste tag-urile inainte sa
incep lucrul efectiv la aplicatia dde import.
Stefan.
Strainu
<stefan.u...@mytrek.ro> a scris:
> Salut,
>
> Nu cred ca sunt toate marcate ca suprafete; cred ca suprafetele corespund cu
> waterway=riverbank, dar trebuie sa verific.
>
> Oricum, cand incep importul propriu-zis, las 'apele' pentru final, sau nu le
> import deloc. Mi-am pus si eu problema asta, dar n-am ajuns inca pana acolo.
Ar fi preferabil să fie importate, cel puțin cele minore, în zone unde
nu există acoperire pe satelit. Aseară m-am chinuit o oră să desenez 5
km de râu din imaginile Landsat și tot a ieșit pătrățos. Dacă
consideri că e nevoie de verificări speciale pe partea asta, sunt
dispus să ajut.
>
> Ca status general, mai am putin de lucru la corectiile de 'layer' si trebuie
> sa-mi testez aplicatia care redenumeste tag-urile inainte sa incep lucrul
> efectiv la aplicatia dde import.
Frumos! O să faci public codul la sfârșit? :D
Stefan UNGUREANU
sunt luate din splitter-ul pentru harti in format garmin).
Dar nu va asteptati la ceva scris foarte 'frumos', pentru ca n-am avut
rabdare sa scriu foarte structurat, mai ales ca e ceva destul de
specializat si nu e nevoie de tehnici prea complicate.
Stefan.
Stefan UNGUREANU
http://wiki.openstreetmap.org/wiki/Corine_Land_Cover_Romania_2006
Stefan.
Stefan UNGUREANU
Se apropie momentul in care voi incepe importul. Mai am niste teste de
facut, dar destul de probabil (daca totul merge bine si am timp) ca pana
la sfarsitul saptamanii sa incep.
Solutia adoptata este de a schimba tag-urile elementelor existente si de
a le crea pe cele provenind din CLC.
Daca exista obiectii / idei / sugestii / critici, le astept inainte sa
incep (planificat maine seara sau joi de dimineata).
Stefan.
Cristian Draghici
Stefan UNGUREANU
1. Cred ca de fapt e vorba de un poligon de 'landcover' si nu unul de
'boundary'. In cazul asta, se intampla ca la toate celelalte, si anume
tag-ul ramane, dar in loc sa fie 'landcover' va deveni 'CLC:landcover',
ca in exemplul de mai jos.
<way id="137011" changeset="7671" user="Romania CLC import bot" >
<nd ref="4601463"/>
[...]
<nd ref="4601539"/>
<tag k="CLC:landuse" v="residential"/>
</way>
2. In cazul asta se intampla la fel; 'landcover' va deveni
'CLC:landcover' si restul tag-urilor raman neschimbate. Un astfel de
poligon va fi probabil randat ca un 'boundary' simplu.
Practic, 'landcover' devine 'CLC:landcover', 'natural' devine
'CLC:natural' si 'waterway' devine 'CLC:waterway', iar valorile raman
neschimbate.
Pentru inceput, voi incepe cu 'landcover', 'natural' si 'waterway' vin
mai tarziu, mai ales ca e destul de probabil ca 'waterway' sa nu le modific.
Stefan.
On 03/11/2010 08:09, Cristian Draghici wrote:
> Salut
>
> Am eu o intrebare - am citit pagina din Wiki si n-am gasit raspuns.
> Ce se intampla in urmatoarele situatii:
>
> 1/ Limita de oras (desenata ca sa apara gri pe harta) cu tag-uri
> ("landuse" = "residential").
> Inteleg ca se face re-tagging.
> Ce tag se foloseste in implementarea efectiva?
>
> 2/ Limita de oras cu tag-uri in plus fata de landuse ("landuse" =
> "residential", "boundary" = "administrative").
> Aici inteleg ca se inlocuieste "landuse" cu tag-ul de la (1), dar se
> lasa restul de tag-uri intacte, corect?
>
> Multumesc,
> Cristi
>
>
>
> 2010/11/2 Stefan UNGUREANU <stefan.u...@mytrek.ro
> <mailto:stefan.u...@mytrek.ro>>
>
> Salutare,
>
> Se apropie momentul in care voi incepe importul. Mai am niste teste
> de facut, dar destul de probabil (daca totul merge bine si am timp)
> ca pana la sfarsitul saptamanii sa incep.
>
> Solutia adoptata este de a schimba tag-urile elementelor existente
> si de a le crea pe cele provenind din CLC.
>
> Daca exista obiectii / idei / sugestii / critici, le astept inainte
> sa incep (planificat maine seara sau joi de dimineata).
>
> Stefan.
>
>
>
>
> On 01/11/2010 13:43, Stefan UNGUREANU wrote:
>
> Am adus la zi documentul cu starea actuala a importului :
>
> http://wiki.openstreetmap.org/wiki/Corine_Land_Cover_Romania_2006
>
> Stefan.
>
> _______________________________________________
> Talk-ro mailing list
> Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
> http://lists.openstreetmap.org/listinfo/talk-ro
>
>
> _______________________________________________
> Talk-ro mailing list
> Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
Cristian Draghici
Salut,
1. Cred ca de fapt e vorba de un poligon de 'landcover' si nu unul de 'boundary'. In cazul asta, se intampla ca la toate celelalte, si anume tag-ul ramane, dar in loc sa fie 'landcover' va deveni 'CLC:landcover', ca in exemplul de mai jos.
<way id="137011" changeset="7671" user="Romania CLC import bot" >
<nd ref="4601463"/>
[...]
<nd ref="4601539"/>
<tag k="CLC:landuse" v="residential"/>
</way>
2. In cazul asta se intampla la fel; 'landcover' va deveni 'CLC:landcover' si restul tag-urilor raman neschimbate. Un astfel de poligon va fi probabil randat ca un 'boundary' simplu.
Practic, 'landcover' devine 'CLC:landcover', 'natural' devine 'CLC:natural' si 'waterway' devine 'CLC:waterway', iar valorile raman neschimbate.
Pentru inceput, voi incepe cu 'landcover', 'natural' si 'waterway' vin mai tarziu, mai ales ca e destul de probabil ca 'waterway' sa nu le modific.
Francisc TOTH
| Sunt destul de sigur ca transformarea tagurilor "waterway" in "CLC:waterway" va face ca noua varianta sa devina nestandard si sa nu se randeze. Nici "waterway:CLC" nu se randeaza. Si restul la fel. Incercarile in Potlatch on-the-fly imi confirma treaba asta. Nu cred ca e o idee buna devierea de la standard cat timp exista alte metode la fel de usoare. --owene |
Stefan UNGUREANU
In total sunt 973 de elemente care au atat tag-ul 'boundary' cat si unul
din 'landuse', 'natural' sau 'waterway'.
Primul dintre ele s-a nimerit a fi Ploiesti-ul, ocazie cu care am
constatat ca nu prea e bine, si anume exista poligoane de 'landuse' care
se suprapun. Mai precis, exista in interiorul poligonului tag-uit
boundary=administrative si landuse=residential un altul tag-uit
landuse=industrial, ceea ce in opinia mea e incorect, pentru ca o
suprafata data nu poate fi si industrial si residential in acelasi timp.
Ceea ce ma face sa cred ca, in general, poligoanele boundary=* trebuie
sa ramana doar cu acest tag (si cele conexe), iar landuse sa fie doar
landuse.
Teoretic cel putin, modificarea tag-urilor 'landuse' in 'CLC:landuse'
rezolva aceasta problema.
Stefan.
On 03/11/2010 08:44, Cristian Draghici wrote:
>
>
> 2010/11/3 Stefan UNGUREANU <stefan.u...@mytrek.ro
> <mailto:stefan.u...@mytrek.ro>>
Stefan UNGUREANU
Pe de alta parte, ideea era sa nu stergem nimic, ci doar sa le facem
invizibile la randare in asa fel incat sa poata fi facute corectii mai
tarziu, daca e nevoie.
Stefan.
On 03/11/2010 09:01, Francisc TOTH wrote:
> Sunt destul de sigur ca transformarea tagurilor "waterway" in
> "CLC:waterway" va face ca noua varianta sa devina nestandard si sa nu se
> randeze. Nici "waterway:CLC" nu se randeaza. Si restul la fel.
> Incercarile in Potlatch on-the-fly imi confirma treaba asta. Nu cred ca
> e o idee buna devierea de la standard cat timp exista alte metode la fel
> de usoare.
>
> --owene
>
>
> 2010/11/3 Stefan UNGUREANU <stefan.u...@mytrek.ro
> </mc/compose?to=stefan.u...@mytrek.ro>>
>
> Salut,
>
> 1. Cred ca de fapt e vorba de un poligon de 'landcover' si nu
> unul de 'boundary'. In cazul asta, se intampla ca la toate
> celelalte, si anume tag-ul ramane, dar in loc sa fie 'landcover'
> va deveni 'CLC:landcover', ca in exemplul de mai jos.
>
> <way id="137011" changeset="7671" user="Romania CLC import bot" >
> <nd ref="4601463"/>
> [...]
> <nd ref="4601539"/>
> <tag k="CLC:landuse" v="residential"/>
> </way>
>
>
>
> 2. In cazul asta se intampla la fel; 'landcover' va deveni
> 'CLC:landcover' si restul tag-urilor raman neschimbate. Un
> astfel de poligon va fi probabil randat ca un 'boundary' simplu.
>
> Practic, 'landcover' devine 'CLC:landcover', 'natural' devine
> 'CLC:natural' si 'waterway' devine 'CLC:waterway', iar valorile
> raman neschimbate.
>
> Pentru inceput, voi incepe cu 'landcover', 'natural' si
> 'waterway' vin mai tarziu, mai ales ca e destul de probabil ca
> 'waterway' sa nu le modific.
>
>
> Multumesc pentru lamuriri si pentru efortul depus in import.
>
> --
> Cristi
>
>
>
>
Cristian Draghici
Revin cu detalii.
In total sunt 973 de elemente care au atat tag-ul 'boundary' cat si unul din 'landuse', 'natural' sau 'waterway'.
Primul dintre ele s-a nimerit a fi Ploiesti-ul, ocazie cu care am constatat ca nu prea e bine, si anume exista poligoane de 'landuse' care se suprapun. Mai precis, exista in interiorul poligonului tag-uit boundary=administrative si landuse=residential un altul tag-uit landuse=industrial, ceea ce in opinia mea e incorect, pentru ca o suprafata data nu poate fi si industrial si residential in acelasi timp.
Ceea ce ma face sa cred ca, in general, poligoanele boundary=* trebuie sa ramana doar cu acest tag (si cele conexe), iar landuse sa fie doar landuse.
Teoretic cel putin, modificarea tag-urilor 'landuse' in 'CLC:landuse' rezolva aceasta problema.
Ioan Indreias
Intervin si eu cu o rugaminte: poti sa ne dai un exemplu de way OSM
nou creat pe baza CLC 2006 astfel incat sa vedem toate tag-urile care
vor fi adaugate?
De asemenea, nu sunt sigur daca atunci cand importi ai acces si la un
identificator (sa-i zicem CLCID) astfel incat way-ul nou sa contina
si acest identificator. Aceasta ar ajuta daca pe viitor am avea acces
la o lista de tipul CLCID, name (sau ceva similar) prin care sa
adaugam date suplimentare.
In final propun ca schimbarea tag-urilor existente sa fie facuta cu
PRECLC in loc de CLC, pentru a rezulta ca obiectul respectiv exista
inainte de importul CLC (cu alte cuvinte nu are nimic de a face cu
CLC-ul).
Multumesc,
Nini
2010/11/3 Cristian Draghici <cristian...@gmail.com>:
Stefan UNGUREANU
http://api06.dev.openstreetmap.org/browse/changeset/7681
Fiecare way are urmatoarele tag-uri :
CLC:code = 112
CLC:shapeId = 51289
CLC:year = 2006
landuse = ... (in functie de tip)
source = Union européenne - SOeS, CORINE Land Cover, 2006.
CLC:code este codul CLC; au si ei clasificarea lor, si fisierele vin per
cod.
CLC:shapeId este indicele corespunzator din fisierul SHP pentru un
CLC:code dat.
Restul tag-urilor sunt oarecum evidente ;)
Stefan.
Stefan UNGUREANU
schimbare de tag-uri pentru cele 973 de elemente.
Pe toate elementele boundary=*, landuse=residential o sa modific tag-ul
'landuse'. landuse=residential nu are neaparat legatura cu limitele
localitatilor.
Stefan.
Stefan UNGUREANU
http://www.openstreetmap.org/browse/changeset/6286120
Rezultat : pe toate poligoanele care aveau 'boundary' si 'landuse', s-a
modificat tag-ul 'landuse' si s-a reintrodus tag-ul 'source' care fusese
sters anterior (tag-ul trebuia pastrat cf. permisiunii de a utiliza
datele cultura.ro)
Intrebare... vreo preferinta in legatura cu primele date ce vor fi
importate ? residential, forest, etc. ?
S.
Janos Rusiczki
Stefan UNGUREANU
problema e mai delicata acolo.
Intre timp mi-a venit ideea sa incep cu 'farmland', pentru ca sunt
foarte putine existente deja... Altfel padurile erau si prima mea alegere ;)
S.
On 04/11/2010 11:52, Janos Rusiczki wrote:
> As vota pentru paduri si apoi residential.
> Parca ziceai ca de ape nu te atingi pentru moment, ca altfel aia ar fi
> fost pe locul intai.
>
> 2010/11/4 Stefan UNGUREANU <stefan.u...@mytrek.ro
> <mailto:stefan.u...@mytrek.ro>>
>
> O prima executie cu succes :
>
> http://www.openstreetmap.org/browse/changeset/6286120
>
> Rezultat : pe toate poligoanele care aveau 'boundary' si 'landuse',
> s-a modificat tag-ul 'landuse' si s-a reintrodus tag-ul 'source'
> care fusese sters anterior (tag-ul trebuia pastrat cf. permisiunii
> de a utiliza datele cultura.ro <http://cultura.ro>)
> <mailto:stefan.u...@mytrek.ro
> Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
> http://lists.openstreetmap.org/listinfo/talk-ro
>
>
> _______________________________________________
> Talk-ro mailing list
> Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
> http://lists.openstreetmap.org/listinfo/talk-ro
>
>
> _______________________________________________
> Talk-ro mailing list
> Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
> http://lists.openstreetmap.org/listinfo/talk-ro
>
>
> _______________________________________________
> Talk-ro mailing list
> Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>