<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2014-11-06 8:12 GMT+01:00 Aury88 <span dir="ltr"><<a href="mailto:spacedriver88@gmail.com" target="_blank">spacedriver88@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">io uso per la stragrande maggioranza dei casi un nodo in prossimità del luogo<br>
dove è indicato effettivamente il civico con il cartellino.<br>
di solito questo è il perimetro di una proprietà e quindi il nodo con i tag<br>
dell'indirizzo spesso è uno dei nodi che compongono la way chiusa che<br>
delimita la proprietà/edificio. alcune volte però preferisco mettere quei<br>
tag direttamente sulla way che delimita la proprieta se questa ha un solo<br>
indirizzo (non è raro che una proprietà abbia più ingressi ed ognuno con un<br>
civico diverso) e magari indicando l'ingresso con il tag entrance=<br></blockquote><div><br><br></div><div>+1, faccio anch'io così.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
La relazione ammetto di non averla mai usata visto che non ho capito che<br>
vantaggi dia il suo utilizzo a fronte di una difficoltà maggiore di<br>
mappatura e manutenzione del dato...</blockquote><div><br> <br></div><div>+1, in generale si dice che è fallito l'approccio relazione per i civici (relazioni "street" e "associated_street"), perché sono difficilmente mantenibili da persone meno esperti in OSM, e non c'è un vantaggio diretto. Il suggerimento per chi ama ridurre la ridondanza (cosa ha senso in un db di produzione) è di crearsi delle relazioni in automatico dopo, nella sua copia del db.<br><br></div><div>Ciao,<br>Martin<br></div></div></div></div>