On Fri, Feb 20, 2009 at 4:18 PM, Alberto Nogaro <bartosom...@yahoo.it> wrote: >>Ad esempio, supponiamo che qualche pazzo decida che taxi discende sia >>da motorcar che da psv (brutto esempio, ma potrebbero capitare casi >>meno ovvi), e che motorcar=yes e psv=no: cosa si applica a taxi? > Forse bisognerebbe introdurre, nel caso di genitori multipli, l'introduzione > di una gerarchia tra i genitori, per definire a priori quale prevale sugli > altri in caso di conflitto. In assenza di gerarchia (o comunque una
Questo è il classico incubo della ereditarietà multipla nei linguaggi di programmazione ad oggetti. Le soluzioni sono varie e abbastanza complesse, ma la migliore è: vietarla ;-) (vedi Java, .NET) > qualunque regola di decisione basate sulla combinazione dei valori dei > genitori) non vedo altra soluzione che obbligare (un editor potrebbe fare la > verifica) il mappatore a definire esplicitamente un tag specifico per il > discendente E' una soluzione palliativa: sempre usando il "linguaggio" dei linguaggi di programmazione, stai eliminando il problema della ereditarietà multipla con un "sistema di tipi" che disambigui tutti i casi ambigui. Il problema è che nel caso di OSM il sistema di tipi vivrebbe solo nell'editor (JOSM, Potlatch), non nel "compilatore" (le API di upload sul database) e quindi è aggirabile facendo un upload diretto a mano. Per proseguire l'analogia, sarebbe come se il controllo dei tipi lo facesse solo Emacs (editor) e non il GCC (il compilatore). > As es., come tratteresti le condizioni di accesso multiple? Per esempio, ho > una strada che solo i proprietari sono autorizzati a percorrerla in auto, ma > solo per raggiungere la propria destinazione (access=private intersezione > access=destination). E ne ho un'altra in cui i proprietari possono > scorrazzare in lungo e in largo, mentre chiunque può percorrerla per > raggiungere la propria destinazione: (access=private unione > access=destination). Mi sembrano esempi allucinanti... ma esistono davvero? Quello che mi sembra strano è che, in informatica teorica, tipicamente l'insieme dei valori è chiuso per operazioni di unione/intersezione: nel nostro caso, mi sembra strano che "private" intersezione "destination" non sia "private", e "private" unione "destination" non sia "destination". Se così non fosse la soluzione standard è di "chiudere" l'insieme dei valori rispetto alle operazioni consentite, cioè aggiungere i risultati di tutte le combinazioni di intersezione/unione tra tutti i tag esistenti. Ma come detto sopra, non capisco se questo sia il nostro caso. > Un altro esempio che mi viene in mente, condizioni di accesso condizionate > da altri elementi oltre al tipo di veicolo. Un caso concreto: ho una strada > che in settimana può essere percorsa da tutti, la domenica solo dalle bici. > I tag tipo day_on=, day_off= non li posso usare, perché non si capisce a > quale nodo si riferiscano. Questo è verissimo! Infatti c'è una proposta per creare nuovi tag per risolvere questi problemi, cioè arricchire la "sintassi". Quello che mi premeva, però, è di chiarire la "semantica" dei tag già esistenti: pur essendo abbastanza poveri (come hai giustamente notato tu, alcune restrizioni non si possono esprimere) danno già luogo a situazioni abbastanza incomprensibili (vedi sovrapposizione di tag di default e tag specifici) Ciao _______________________________________________ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
