
<font face="arial,helvetica,sans-serif">Ciao<br>Per evitare le doppie way in file topologici dove tutti i poligoni sono adiacenti, si potrebbe convertire lo shapefile da poligoni a polilinee.<br>Utilizzando questo algoritmo:<br>


<a href="http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00170000003t000000">http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00170000003t000000</a><br>è possibile ridurre tutto in linee singole e con l'opzione "</font><font face="arial,helvetica,sans-serif"><span>IDENTIFY_NEIGHBORS</span>" rimane traccia a quali poligoni appartenevano, quindi è possibile associarci la relazione. Qualora una linea fosse unica, chiusa e con una sola doppia relazione, sarebbe un "inner".<br>


Non facilissimo e volece, ma fattibile.<br><br></font><br><div class="gmail_quote">Il giorno 24 gennaio 2013 12:45, Groppo O <span dir="ltr"><<a href="mailto:groppo8@gmail.com" target="_blank">groppo8@gmail.com</a>></span> ha scritto:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">Il giorno 22 gennaio 2013 22:25, Leonardo <span dir="ltr"><<a href="mailto:kinetocore86@gmail.com" target="_blank">kinetocore86@gmail.com</a>></span> ha scritto:<br>


</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ciao,<div class="im"><br>

<br>

scrivo alla mailing list per esporre una possibile idea di import per i dati riguardanti l'utilizzo del suolo in Veneto<br></div></blockquote><div>... <br></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


Questo sarebbe il possibile piano di import ma prima vorrei sentire i vostri pareri, favorevoli, contrari, dubbi, ecc... <br></blockquote><br></div>Ciao,<br><br>ho dato un'occhiata al file. Nelle zone urbane mi sembra più accurata la CTR, che (a volte) ha anche le pertinenze dei singoli edifici.<br>


Per le zone alpine ed agricole, invece, i file sembrano più dettagliati e le way più accurate della CTR, quindi anch'io sono favorevole a degli import locali. Usando file divisi per comune si potrebbero confrontare meglio i dati ed evitare alcune zone, come i centri urbani.<br>


<br>Spesso i poligoni sono composti da way più lunghe del limite di 2000 nodi ed andranno quindi tagliati e trasformati in multipoligoni.<br><br>Mi chiedo anch'io come si possa gestire al meglio dei poligoni con copertura al 100 %, quindi composti da way che hanno sempre dei tratti in comune con altre.<br>


<br>Immagino che per il momento la soluzione migliore sia quella mista:<br>- creare way sovrapposte, con i nodi in comune, per poligoni adiacenti piccoli<br>- creare multipoligoni per poligoni adiacenti molto estesi, con una sola way di confine usata in entrambe le relazioni, es. boschi estesi.<br>


<br>Osservazione a parte.<br>Forse è inevitabile raggiungere il 100 % di copertura, prima o poi, anche in OSM.<br>L'ideale sarebbe avere degli editor (si dice topologici?) che creano automaticamente una relazione quando serve, in modo trasparente. Ad es. tracciando una way con dei nodi in comune ad un'altra l'editor trasforma da solo il poligono in un multipoligono, senza creare una nuova way sovrapposta.<br>


<br><br>Ciao,<br>Groppo<br></div><br></div></div>

<br>_______________________________________________<br>

Talk-it mailing list<br>

<a href="mailto:Talk-it@openstreetmap.org">Talk-it@openstreetmap.org</a><br>

<a href="http://lists.openstreetmap.org/listinfo/talk-it" target="_blank">http://lists.openstreetmap.org/listinfo/talk-it</a><br>

<br></blockquote></div><br>