2010/1/13 Carlo Stemberger <carlo.stember...@gmail.com>: > Il 13/01/2010 19:55, Damjan Gerli ha scritto: >> Sono d'accordo. > > Anch'io condivido in pieno questo approccio, e l'avevo già proposto > diversi mesi fa. Da studiare bene all'atto pratico, ma ne vale > senz'altro la pena.
Io voto contro con un ragionamento un po' complesso. Prendiamo l'isola di Bergeggi (Liguria): la sua coastline appartiene a 3 relazioni: Bergeggi (comune); Savona (provincia); Liguria (regione). Queste 3 relazioni sono di tipo boundary. Se ora si guarda l'isola di Bergeggi su Mapnik si vede che la sua coastline è etichettata "Bergeggi Savona Liguria" che mi sembra eccellente. Se invece usassimo le relazioni "mattoncino", che tipo assegneremmo all'ipotetica relazione "costa della Liguria"? E che name=? Se fosse di tipo boundary, con name=Costa della Liguria, allora su Mapnik la coastline dell'isola di Bergeggi diventerebbe "Bergeggi Savona Costa della Liguria" che secondo me è meno chiaro (o addirittura peggio "Costa di Bergeggi Costa di Savona Costa della Liguria"). Quindi le relazioni mattoncino dovrebbero essere fatte rispettando almeno uno di questi vincoli: 1. o gli si assegna un nome meno chiaro, ad esempio alla relazione della costa della Liguria si mette nome "Liguria" (ma a quel punto si farebbe fatica a distinguere tra la relazione della costa della Liguria e la relazione del confine di terra della Liguria) 2. o gli si assegna un tipo diverso da boundary, ad esempio boundary-segment Se adottassimo l'approccio 2 (forse il più corretto), la coastline dell'isola di Bergeggi a quante relazioni dovrebbe appartenere? Sempre 3, di cui quella della Liguria non è più di tipo boundary ma boundary-segment, oppure 4, cioè 2 relazioni per la Liguria (una boundary, una boundary-segment)? Io penso questo secondo caso. Anzi potrebbe ancora peggiorare perché potremmo dividere anche il confine della provincia di Savona in terrestre e marino (e se siamo pazzi dividiamo anche il confine del comune di Bergeggi) Cioè in pratica dovremmo avere: a. tante relazioni mattoncino di tipo boundary-segment b. tante relazioni di tipo boundary, costruite "rapidamente" (ad es. in JOSM) inserendo tutti gli appartenenti ai mattoncini boundary-segment Questo approccio che sembra più potente dell'attuale è in realtà molto più fragile. Vuol dire che ogni singola way di costa deve appartenere a più relazioni delle attuali e la probabilità che per errore venga cancellata da almeno una relazione è molto più alta. E' vero che la relazione boundary, costruita dai mattoncini, potrebbe essere ricreata facilmente a partire dai mattoncini; ma le relazioni mattoncino no! Cioè adesso abbiamo l'ipotetico problema che per errore un tratto di way venga eliminato da una relazione boundary. Con il nuovo approccio avremmo l'ipotetico problema che per errore un tratto di way venga eliminato da una relazione boundary-segment. I due errori hanno la stessa probabilità di avvenire e la stessa difficoltà di essere intercettati (anzi col secondo approccio è peggio, perché bisogna pattugliare non una sola relazione Italia, ma tante relazioni boundary-segment). Senza contare che le relazioni mattoncino non aggiungono informazioni da un punto di vista GIS: Vuoi il confine marittimo della Liguria? Basta prendere tutte le way del confine Liguria che abbiano natural=coastline (o viceversa senza natural=coastline per il confine di terra) Vuoi il confine tra Liguria e Piemonte? Basta prendere tutte le way che appartengono ad entrambe le relazioni Liguria e Piemonte. ecc. Insomma secondo me tutte le domande a cui si può rispondere facilmente con le relazioni mattoncino, vi si può rispondere altrettanto facilmente con le relazioni che abbiamo attualmente. In conclusione, secondo me: l'approccio delle relazioni mattoncino sembra più pulito ma in realtà complica soltanto la manutenzione e non aggiunge informazioni. Ciao, Federico _______________________________________________ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
