[Talk-ro] Import automatizat pentru limita localitatilor (via cultura.ro)

[Janos Rusiczki]

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

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.

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.

Cei 2 bani ai mei,
Janos

2009/12/2 Ciprian Talaba <cipriantalaba at gmail.com>

>
> 2009/12/2 Janos Rusiczki <janos.rusiczki at gmail.com>
>
>> 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 puncte
>> Arad - 88 contururi / 4599 puncte
>> Cluj - 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
>
> _______________________________________________
> Talk-ro mailing list
> Talk-ro at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ro
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ro/attachments/20091202/8a8226cc/attachment.html>