Simone Cortesi ha scritto: > On Wed, Sep 3, 2008 at 4:27 PM, Daniele Forsi <[EMAIL PROTECTED]> wrote: > >> Il 3 settembre 2008 15.37, Roberto Navoni ha scritto: >> >> >>> In realtà utilizzando sempre le aree istat da un'analisi che ho fatto >>> questo mattina con altri miei colleghi l'idea potrebbe essere da un lato >>> quello di effettuare delle query geografiche delle vie contenute >>> all'interno del confine comunale , dopodichè assegnare un tag ... e >>> vorrei capire con voi quale , ad ogni singola via per associare la via >>> al comune di appartenenza . >>> >> ma non puoi mettere questo tag nel database generale di OSM perché è >> usato per una specifica applicazione (che non è l'unica applicazione >> possibile) ed è ridondante perché calcolabile in base ai dati già >> presenti nel db (se usi i confini ISTAT importati) oltre che >> modificabile a piacimento in stile wiki >> > > infattamente. > > Roberto, quando ti scarichi in locale il DB di osm, ogni settimana, > ogni mese, quando decidi di aggiornarlo per i tuoi clienti, applichi > il tag is_in ad ogni singola via, cassetta della posta, farmacia, > basandoti per il geocoding sullo shape (relation composta da piu' way, > del comune) gia' presente nel planet. Ok ho capito che il problema di inserire tag particolari per certe applicazioni non piace , pero' in realtà puo' aiutare in fase di standardizzazione e di editing del dato. Per esempio , ho visto che i comuni si riferiscono ad un codice Gfoss , che probabilmente è univoco e probabilmente legato al codice istat , se non lo forse bisognerebbe legarlo , perchè in fase di update dei dati il fatto di avere un id univoco aiuta a non dupplicare le informazioni , ma semplicemente ad aggiornarle. Poi per quanto riguarda il vantaggio di questo tipo di tagging in realà risulterebbe a livello universale , perchè qualsiasi applicazione di mapping ha bisogno di un geocoding efficente per essere presa in considerazione , mi spiego meglio. Se io voglio navigare il dato e cercare una via in un comune oggi in Italia non posso , mentre invece in altri paesi è possibile. Io ho quindi due opportunità , o mi adeguo allo standard de facto di un'altro paese come la germania , oppure creo un'altro standard e lo adatto a livello di codice dell'applicazione standard perchè supporti anche la mia implementazione. Di fatto si affermerà lo standard piu' efficace che risolve il mio problema. Parlando con te ieri Simone , il livello di complessità di produzione del dato che vuoi costruire in realtà non farebbe altro che dare ragione all'implementazione dei tedeschi , quando ti ho chiesto a cosa servivano quei tag fatti in quel modo in realtà nemmeno tu mi hai saputo dare una risposta convincente ... e comunque non risolverebbero il problema delle strade contenute in due comuni. Senza poi contare il problema di mettere i numeri civici . Quindi il tema è seguiamo pedissequamente qunto proposto dai tedeschi , oppure ci inventiamo qualcosa di piu' semplice ed efficace ? Che magari poi verrà utilizzato anche da altre nazioni ? Ditemi che ne pensate. Un saluto Roberto Navoni
P.S. dobbiamo al piu' presto attivare una sandbox per fare un po' di pasticci sul dato senza incasinare il server principale. > la mia idea di base è: se possiamo fare uno script che funzioni una > volta...lo puoi applicare tutte le settimane dopo averlo scaricato. e > se ti accorgi di voler modificare qualcosa nella codifica lo fai senza > concordare nulla con nessuno. > > -S > > _______________________________________________ > Talk-it mailing list > Talk-it@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-it > ------------------------------------------------------------------------ > > > Nessun virus nel messaggio in arrivo. > Controllato da AVG - http://www.avg.com > Versione: 8.0.169 / Database dei virus: 270.6.15/1649 - Data di rilascio: > 03/09/2008 7.15 > > _______________________________________________ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
