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

[Ciprian Talaba]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ro/attachments/20091202/eff87bcf/attachment.html>