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

[Cristian Draghici]

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

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

> 2009/12/2 Janos Rusiczki <janos.rusiczki at gmail.com>
>
>> 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
>
>>
>>
>
> _______________________________________________
> 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/20091203/a7a40098/attachment.html>