Eu sunt pentru rezultate rapide, chiar cu riscul necesitatii editarilor ulterioare.<div><br></div><div>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.</div>
<div><br></div><div>Janos, felicitari pentru initiativa si multumiri.</div><div>--</div><div>Cristi<br></div><div><br><div class="gmail_quote">2009/12/2 Ciprian Talaba <span dir="ltr"><<a href="mailto:cipriantalaba@gmail.com">cipriantalaba@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im">2009/12/2 Janos Rusiczki <span dir="ltr"><<a href="mailto:janos.rusiczki@gmail.com" target="_blank">janos.rusiczki@gmail.com</a>></span><br>
</div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
Ioan Indreias a scris in al doilea mesaj din acest subiect de discutie:<div class="im"><div><br><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><div>numele cred ca trebuie pus sub forma -> place_name = YYYYY<br>
</div>
[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.'</span></div><div><font face="arial, sans-serif"><span style="border-collapse:collapse"><br>
</span></font></div></div></div></blockquote><div><br>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.<br>
</div><div class="im"><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div><div><font face="arial, sans-serif"><span style="border-collapse:collapse">
</span></font></div><div><span style="font-family:arial,sans-serif;border-collapse:collapse">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.</span></div>
</div></blockquote></div><div><br>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.<br>
</div><div class="im"><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div>
<div><font face="arial, sans-serif"><span style="border-collapse:collapse"><br></span></font></div><div><font face="arial, sans-serif"><span style="border-collapse:collapse">Mie cel mai OK din ce ai propus tu mi s-ar parea punctul 2: "<span style="border-collapse:separate;font-family:arial">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.</span></span></font></div>
<div><font face="arial, sans-serif"><br></font></div></div></blockquote></div><div><br>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: <a href="http://wiki.openstreetmap.org/wiki/Relations/Proposed/Region" target="_blank">http://wiki.openstreetmap.org/wiki/Relations/Proposed/Region</a>. 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 <a href="http://geo-spatial.org" target="_blank">geo-spatial.org</a> se apropie mai mult de centrul matematic, decat de cel organizational, Vasile/Eddy va rog sa ma corectati daca gresesc).<br>
<br>Pentru un municipiu am avea urmatoarele etichete pe relatie:<br>type=region<br>name=*<br>region_category=city<br>region_type=city<br>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).<br>
Centrul va avea (cel putin) atributele:<br>place=*<br>name=*<br><br>Nu stiu unde e mai corect sa punem celelalte etichete (is_in, population, coduri SIRUTA), pe relatie sau doar pe centru. <br><br>Ce spuneti?<br><br>--Ciprian <br>
</div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<br></blockquote></div><br>
<br>_______________________________________________<br>
Talk-ro mailing list<br>
<a href="mailto:Talk-ro@openstreetmap.org">Talk-ro@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-ro" target="_blank">http://lists.openstreetmap.org/listinfo/talk-ro</a><br>
<br></blockquote></div><br><br clear="all"><br>
</div>